Teach financial controllers to record why they corrected an agent's journal, accrual or reconciliation, sort that reason into a fix for the agent's brief, sources or bounds, and send it to the agent owner for re-certification. A correction is banked when the agent stops making that mistake, without anyone retraining a model.
What does banking a correction mean in a finance team?
Every month-end, a controller fixes things. The agent proposed an accrual on last quarter's run rate when the contract changed; it coded a software renewal to the wrong cost centre; it matched a bank receipt to the wrong invoice because two customers share a reference format. Fixing the entry is the controller's normal work. Banking the correction is the extra step that stops the same error appearing at the next close.
Under a governed operating system the business never changes the model. It changes what the agent is told (the brief), what it may read (its sources), how far it may act (its bounds and depth) and what it has been certified to do. A banked correction is one of those four changes, made deliberately, tested, and filed. The agent owner makes the change; the controller supplies the evidence. Who owns which part is covered in the guide to AI agent skills by role.
How do you run the process, step by step?
- Agent, depth 2: drafts the journal or reconciliation and attaches the sources it used, each stamped with its provenance. Nothing posts until a person approves.
- Person (controller): corrects the draft and records a reason from a short list: wrong source, stale source, brief unclear, bound wrong, or one-off judgement. Free text explains the specifics.
- Agent, depth 1: groups corrections by reason and account at the end of each week of the close, so patterns show instead of isolated fixes.
- Person (controller): decides which patterns to bank. One-off judgements, such as a disputed invoice the controller chose to accrue at half value, stay out.
- Person (agent owner): makes the change. A new chart of accounts mapping goes into sources; a rule about when to accrue from the contract rather than history goes into the brief; a materiality threshold goes into the customer's limits.
- Attest replays the agent against real cases from your own ledger, including the corrected ones, and scores each gate.
- Person (controller and agent owner): accept or reject the result. If the agent clears, the change goes live with its new certificate. If it falls short, it keeps only the highest depth it cleared, or runs at depth 1 if it cleared none, until fixed.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Draft entry | Proposes journal, accrual or match with sources | 2 | Approving and posting |
| Record correction | Nothing; the record files the reason | 1 | Choosing the reason code |
| Find patterns | Groups corrections by reason and account | 1 | Deciding what counts as a pattern |
| Make the change | Nothing | none | Editing brief, sources or limits |
| Re-certify | Replayed in Attest | none | Accepting the new certificate |
What should a controller learn to tell apart?
The skill that matters most is sorting a correction into the right bucket. Controllers are good at fixing entries; fewer are practised at asking why the agent got there.
A source problem means the agent read something wrong or out of date: a superseded FX rate table, an old version of the cost centre list, a contract register that missed an amendment. The fix is to replace or re-stamp the source. A brief problem means the instruction was unclear: "accrue recurring costs" without saying what to do when a contract changes mid-period. A bound problem means the agent was allowed to do something it should not, or was stopped from something routine. And a one-off is a judgement the controller would not want repeated automatically.
Finance has its own trap here. Many corrections at close are really timing: the right entry, made too early or too late. Those usually belong in the brief as a rule tied to the close calendar, not in sources. A controller who learns to spot timing corrections removes a large share of repeat work.
Which controls keep banked corrections safe?
- Two people on every brief change. The controller who corrected the entry should not also approve the change to the brief alone. Evidence: the record shows the proposer and the approver by name.
- Re-certification before go-live. No banked change runs until Attest has replayed the agent on your own cases. Evidence: a dated certificate with gate results.
- Provenance on new sources. A replacement rate table must come from the system of record, sealed, not an emailed spreadsheet. Evidence: the provenance class on each fact the agent uses.
- No loosening by stealth. A correction that would let the agent post more without review is a change to depth, not a brief tweak, and goes through the full path. Evidence: depth changes appear separately in the record.
Controllers who already review agent work closely, as described in how financial controllers review an AI agent's decisions, will find the reason code is the only new habit; the rest is discipline they already have.
What should you measure?
Track how often the same reason code recurs on the same account after a change is banked. If corrections for a cost centre mapping drop to near nothing at the next close, the banking worked. Track the time from correction to live change, because a fix banked after two closes has cost you two closes. Track the share of corrections marked one-off; if it climbs, controllers may be avoiding the harder work of diagnosis. And watch the agent's certificate: banked changes should not cause a failed run, which would leave it at the highest depth the run cleared, or drop it to depth 1 the same day if it cleared none.
Where does it usually go wrong?
The most common failure is banking too fast. A controller corrects three accruals the same way and asks for a brief change, but the three cases shared an unusual supplier, not a rule. Wait for the pattern to show across accounts or periods.
The second is banking nothing. Corrections pile up in the record, nobody reads them, and the agent repeats the same errors every month. Put a fixed slot in the close calendar, after the books are locked, for the correction review.
The third is fixing the agent when the process is wrong. If the agent keeps misallocating shared costs, the allocation method may be unclear to people too. Banking corrections well often surfaces process questions that controllers, not the agent owner, must answer. Credit teams face the same pressure on a faster cycle, which is why teaching credit controllers to bank corrections puts more weight on daily review.
Where the Academy fits
Pryme Intelligence Academy's Operator track covers this directly: its modules on human review, teaching the agent and keeping knowledge current walk through recording a reason, choosing the change and reading a re-certification result. Module tests are set in the learner's own industry and role, so a controller practises on finance cases. Certified Pryme Operator requires a practicum of two weeks of real review decisions, signed off by a Pryme assessor.
Questions people ask
Does banking a correction change the model the agent runs on?
No. The model stays as it is. The change goes into the agent's brief, its sources, its bounds or its certification, and every one of those changes is filed in the record.
Should the controller or the agent owner write the brief change?
The controller describes what went wrong and what the right behaviour is. The agent owner turns that into brief wording and runs re-certification. Keeping the two roles apart is itself a control.
How long before a banked correction takes effect?
As long as it takes to make the change and clear re-certification. Most teams aim to bank finance corrections between closes, so the next month-end runs on the improved agent.