When Things Go Wrong
Every instruction has a failure path whether or not you wrote one. If you did not write it, the fallback is whatever the model infers — and what a model infers from a finance task is almost always "produce a plausible number".
Lesson 1
The instruction you did not write
Write a reconciliation instruction and you will describe the reconciliation. Match on amount and date, mark the pairs, report the closing balance. It reads complete because the work it describes is complete.
Then the bank feed arrives two days short.
The agent does not stop. Stopping is a behaviour, and you did not ask for one. It does the thing the shape of the request implies, which is finish the reconciliation — and the only way to finish a reconciliation with missing days is to produce numbers that were not measured.
This is the difference between a human junior and an agent, and it is worth being precise about it. A junior who hits a short feed feels the wrongness. They have watched someone get in trouble. That feeling is a control you never had to write down, and it does not survive the handover.
A failure mode is in one of three states in your instructions, and only one of them is handling it.
Missing. You never mentioned that the feed might be short. Nothing to discuss.
Named. You wrote "the bank feed is occasionally incomplete." This is the trap, and it is the most common thing that goes wrong in real instruction files, because it reads like a control to the person who wrote it. It is not one. You have told the agent a fact about the world and given it nothing to do with it. It will finish the reconciliation.
Handled. "If the bank feed is incomplete for any day in the period, stop and report the missing date range. Do not reconcile a partial period." Now there is a behaviour, a trigger, and a prohibition on the thing it would otherwise have done.
The gap between named and handled is one clause, and reviewing your own work will not reveal it. You know what you meant.
Lesson 2
A trigger someone else could apply
"If the variance is material, escalate."
Material to whom? The word is doing real work in accounting and none at all here, because the agent has no materiality threshold and will pick one. So will the next agent, differently.
A trigger has to be something a reviewer could apply twice and get the
same answer both times. exceeds $500 qualifies. So does has no match in the chart of accounts — it is categorical rather than numeric, and it is
just as checkable. looks unusual does not qualify. Neither does
where possible, which quietly makes the whole requirement optional.
There is a related move that feels responsible and is not: routing the exception to a note. "Estimate the missing figures and note the estimate in the summary." A note is not a control. Nobody is required to read it, nothing stops on it, and the estimate is already in the total by the time anyone might.
Lesson 3
Because
Never post to Cash without a verified Bank Statement ID.
A good rule, and it holds for exactly the case it names. The agent hits a transaction that belongs in Cash Equivalents, finds no rule about it, and posts.
Never post to Cash without a verified Bank Statement ID, because a posting with no statement reference cannot be traced back to a source during review.
Same rule. Now the agent has the property that made the first version true — traceability to a source — and it recognises the case you did not enumerate. The reason generalises where the rule alone cannot.
This is the cheapest thing in this module and the one most often skipped, because when you write the rule the reason is obvious to you. It will not be obvious to the agent, and it will not be obvious to the associate who inherits your instruction file in March and cannot tell whether the rule still applies or was a workaround for something that got fixed.