There is a version of this story in almost every finance function we have walked into. It is never a technology failure. It is a translation failure, and it happens in a predictable place.
The controller knows the rule. Ask her why the purchase-price tolerance is 2% and she will tell you it is because the steel supplier prices in tonnes and the site orders in kilos, so there is always a rounding difference and 5% was letting real errors through. She has known this for four years. It is not written anywhere.
The developer can build anything. Give him a specification and he will deliver it on time. What he cannot do is know that posting to the wrong control account breaks the intercompany elimination in March, because nobody has ever explained what an elimination is and it would not occur to anyone to mention it.
So the project gets scoped. Finance writes requirements in accounting language. IT reads them as data movement. Both sides believe they have agreed. Six weeks later there is a demo and the controller says the words that end most automation projects:
“That’s not quite what I meant.”
The specification is not the problem
The usual response is to write a better specification. More detail, more sign-off, more workshops. It rarely works, because the missing knowledge is not the kind that survives being written down by the person who has it for the person who doesn’t.
Try it yourself. Write the rule for which supplier invoices need a purchase order and which do not. You will produce three lines. Then someone will ask about the utilities and the annual insurance and the lawyer who bills against a matter number rather than a PO and the one supplier who sends a statement instead of an invoice because that is what they have done since 2011. Your three lines become two pages and they are still incomplete, because the real rule lives in a judgement the controller makes without noticing she is making it.
That judgement is the valuable part. It is also the part that a specification cannot carry.
What actually transfers
Three things move that knowledge reliably and none of them is a document.
Watching the work. Sit next to the person doing it for a morning. Not a workshop — the actual work, with the actual exceptions. Every time they hesitate, ask why. The hesitations are the rules.
Working from history rather than intent. Do not ask how invoices should be coded. Look at how the last twelve from that supplier were coded. The ledger is a far more honest record of the rule than anyone’s description of it, including the controller’s.
Running in parallel before anything has authority. Let the automation do the work alongside the team, on live data, posting nothing. Every difference between its output and theirs is a rule you got wrong, surfaced while it is still cheap. This is the single highest-value thing you can do and most projects skip it because it feels like doing the work twice. It is doing the work twice. That is the point.
The structural fix
All three of those are easier when the person writing the automation can read a trial balance. Not because Chartered Accountants make better developers — they generally don’t — but because the translation step disappears. There is no handover document because there is no handover.
That is not a claim that every automation team needs a Chartered Accountant. It is a claim about where to put the seam. If you must have two people, make the seam sit somewhere cheap to get wrong — at the integration layer, say, not between “what the control is for” and “what the code does”.
Put the seam in the wrong place and you get the demo and the sentence and the six weeks.