
Blog · AutoRecon
Your reconciliation rules should not live in one person’s head.
Ask who understands the month-end recon macro and most finance teams can name one person. That is the real risk, and it is not a spreadsheet problem.

Ask who understands the month-end recon macro and most finance teams can name one person. That is the real risk, and it is not a spreadsheet problem.
It is easy to blame spreadsheets for reconciliation pain. They are slow at volume, they break when a column moves, and they are hard to audit. But we think the deeper problem is not the tool. It is that in many finance and operations teams, the actual matching logic exists only in the head of the person who built the macro.
Replace the spreadsheet with software and leave that problem untouched, and you have simply moved the risk somewhere more expensive.
Watch an experienced recon analyst work and you will see dozens of small rules applied without being written down:
Each rule is sensible. Together, they are the reconciliation. And none of them is visible to the checker who signs the close, the auditor who reviews it or the colleague who covers during leave.
When rules are implicit, three things go wrong at once.
Nobody can review them. A checker can confirm that the totals tie, but not whether the tolerance applied was reasonable or whether a match should have been made at all.
They drift. A rule added to clear one awkward month stays for years. A tolerance widens a little each time a break is annoying. Nobody decided to loosen the control; it simply happened.
They leave with the person. Leave, a resignation or a new role, and month-end becomes archaeology.
The fix is to treat matching rules as controlled artefacts, like a credit policy or a limit, rather than as working notes:
| Property | Why it matters |
|---|---|
| Named and described in plain language | Anyone can read what it does |
| Typed: exact, tolerance or fuzzy narration | The reviewer knows how strict it is |
| Versioned | You can see when it changed and what it was before |
| Approved by a maker and a checker | No single person can loosen a control |
| Linked to the matches it made | Every match can be traced back to the rule that made it |
With that in place, the analyst’s expertise is not lost. It is captured, reviewed and made available to everyone, which is a better outcome for the analyst too.
The same breaks appearing every day are a signal. Usually, someone already knows the pattern and clears them by hand. The right move is to turn that pattern into a proposed rule, show the checker the evidence, and let the rule take effect only after approval. Over time the break queue shrinks to the genuinely unexplained items, which are the ones worth a person’s attention. Our guide to classifying and ageing breaks covers what to do with what remains.
In AutoRecon, rules are the centre of the system. You write them; they run daily; exact, tolerance and fuzzy narration matching are explicit types. Rules are versioned and go through maker-checker before they take effect, and recurring breaks come back as suggested rules with the pattern explained. Everything lands in one audit log. Our matching rules guide explains the rule types in detail, and the rest of our material is in the AutoRecon guides.
The person who built the macro is usually the best person to write the first rule library. The goal is not to replace their knowledge. It is to stop it being a single point of failure.
When the matching logic exists only in one person’s spreadsheet or memory, so nobody else can review, maintain or run the recon without them.
Written in plain language, typed as exact, tolerance or fuzzy, versioned, approved by a maker and checker, and linked to the matches they make.
Treat the pattern as a rule waiting to be written: propose it with evidence and let it take effect only after a checker approves it.
See it on your own data. AutoRecon — Close the day before it starts. Book a 30-minute working session with an engineer.