Training a finance team on AI tools without losing the controls

Software training in finance usually covers navigation: where things are, which button does what, how to run the report. People pass it, use the system, and the implementation is declared complete.

Then, six months later, the exception queue has four hundred items, nobody remembers why the tolerance is set where it is, and approvals are being cleared in bulk. Nothing broke. The training simply covered the wrong things.

Here is what actually needs teaching.

Teach why it stopped, not how to clear it

The single highest-value session is walking through each type of exception the system produces and explaining what causes it.

Not "click here to approve" but: this stops when the price is above the tolerance on the purchase order, which usually means the supplier raised prices without telling the buyer, and the right response is to hold it and contact them rather than approve it.

Once someone understands the cause of each exception type, they handle new ones sensibly. Without that, they pattern-match on what previous items looked like, which works until it does not.

Practical format: take the last month's real exceptions, group them by type, and go through each group. Twenty minutes per type, using actual cases rather than a demo dataset.

Teach the difference between correcting and overriding

This one has a lasting effect on system quality and is almost never covered.

Changing a proposed code inside the workflow teaches the system. Fixing it later with a manual journal produces the right monthly number and teaches nothing — so the same wrong proposal returns indefinitely.

Teams that do not learn this end up with a system that never improves and a growing habit of correcting things downstream, which also destroys the audit trail's usefulness.

Teach what must never be automated

People need to know where the boundary is and why, otherwise they will helpfully move it.

The specific cases worth stating explicitly: period cut-off decisions, estimates and provisions, first transactions with a new counterparty, anything material and irreversible. Someone will eventually ask why the system cannot just handle these, and the answer needs to exist before the question.

See when not to automate an accounting process.

Teach reviewing as a skill, not an instruction

"Review before approving" is not training. Reviewing is a craft that fails predictably — people accept plausible output, check arithmetic rather than treatment, and only look at what was flagged.

Worth teaching directly:

• Form an expectation before opening the item
• Check the treatment, not just whether it balances
• Sample the confident transactions periodically, not only the exceptions
• Resolve recurring causes upstream instead of clearing the same thing weekly

The full version is in when the accountant becomes the reviewer.

Teach the audit trail before the auditor asks

Show the team what the system records for each transaction and how to retrieve it. Two reasons: they will need it when someone queries an entry, and knowing that every action is recorded changes how carefully people act.

It also surfaces gaps early, while they can still be fixed. Discovering during an audit that a category of change is not logged is an expensive way to find out.

Who needs what

Not everyone needs everything.

Processors moving to review need the exception causes, the review craft and the correcting-versus-overriding distinction. This is the largest group and the one most often given navigation training only.

The controller or finance manager needs all of the above plus threshold ownership: what is set where, why, and when it was last checked against how the business now operates.

Occasional approvers outside finance — department heads approving their own costs — need almost nothing except what they are attesting to when they approve, and that it is recorded against their name. Two minutes, and skipping it is why approvals get clicked through.

The session that pays for itself

If there is time for only one thing beyond navigation, do this: take twenty real transactions the system processed confidently and have the team check them properly.

It teaches calibration, demonstrates that confident does not mean correct, establishes sampling as a habit, and usually finds at least one genuine configuration problem.

It is also the single best inoculation against the failure mode that matters most — a team that trusts the system completely because it has been right so far.

When to run it

Not all at implementation. The useful sequence:

• Before go-live: navigation and the exception causes
• After two weeks: the review craft, using their own real exceptions
• After two months: the sampling exercise, once there is enough processed history to sample
• Every six months: revisit the thresholds and whether they still match the business

The two-month session is the one always skipped and the one that changes behaviour, because by then people have formed habits worth correcting.

Common questions

What should finance teams be trained on beyond how to use the software?

The causes behind each type of exception rather than how to clear them, the difference between correcting inside the workflow and overriding downstream, which processes must stay human and why, how to review machine output properly, and what the audit trail records. Navigation training alone produces teams that operate the system fluently while gradually losing the controls it was meant to provide.

Why does it matter whether corrections are made in the workflow?

Because a correction made inside the workflow becomes a training signal that improves future proposals, whereas a downstream manual journal produces the right number for the period while teaching the system nothing. Teams that habitually fix things downstream end up with automation that never improves and an audit trail that no longer explains how balances were reached.

How do you stop a team from over-trusting automation?

The most effective exercise is taking a sample of transactions the system processed with high confidence and checking them properly, which demonstrates concretely that confident does not mean correct, builds calibration, and usually surfaces a real configuration issue. Repeating it periodically establishes sampling as a habit rather than a one-off.

When should training happen?

In stages rather than all at go-live: navigation and exception causes beforehand, the review craft after about two weeks using the team's own real exceptions, and a sampling exercise after roughly two months once there is processed history to examine. The later sessions are the ones usually skipped and the ones that actually change behaviour, because by then habits have formed that are worth correcting.

Related: when the accountant becomes the reviewer · change management in a finance team · bringing your team along