A payments-heavy business was reconciling gateway, bank and internal records by hand — days of spreadsheet work every month, ending in an “adjustment” entry nobody could defend. I built an automated matching engine: daily three-way reconciliation, exceptions queued with reason codes, and write-offs that require a name.
Who this story is for
Any business where the finance team’s best week each month goes to explaining a difference, and where the word “adjustment” has quietly become a category in the books rather than an exception to them.
The situation
Three sources of truth, none agreeing. The gateway’s settlement files said one thing, the bank statement another, the internal database a third. The monthly ritual consumed several days and still ended with a balancing entry that existed because the alternative was not closing the month.
Individually the differences were small enough to absorb. Annually they were material, and — more importantly — nobody could say which of them were timing, which were fees treated differently by each side, and which were genuine losses. That distinction had never been available, because the reconciliation was performed by a person under time pressure rather than by a process that recorded its reasoning.
[METRIC — your sign-off: the annual write-off figure that made this urgent, if shareable]
What I did
Normalised the feeds. Half the work in any reconciliation is that every counterparty speaks its own dialect — column names, date formats, sign conventions, and a settlement file that nets fees in a way the dashboard does not. All three sources were mapped into one comparison plane: reference, amount, currency, business date, source.
Built the matching cascade. Exact matches on reference and amount auto-clear. Tolerant matches — rounding differences, timing across a cycle boundary — flag for review with the tolerance recorded. Everything else queues with a reason guess rather than as an undifferentiated pile.
That last point is where the engine earned its keep. “Unmatched” is a shrug; “gateway settled net of a refund we booked gross” is a fix. The taxonomy came from sitting with the people who had been resolving these by hand for years — they already knew the categories, and encoding their knowledge was the actual deliverable. The matching logic was the easy half.
Made write-offs cost something. Every write-off now requires a maker, a checker and a named reason from a fixed list. The “adjustment” category was deleted outright, because a catch-all is where a systemic problem hides as a thousand individually trivial decisions.
Aged the queue. Exceptions climb: day three to the team, day seven to the finance lead. Without escalation a queue becomes a graveyard, and graveyards eventually get bulk-cleared by someone under pressure — which is worse than never building one.
The result
Month-end reconciliation went from days of archaeology to a morning reviewing exceptions. Write-offs became rare and, when they happen, explicable — each one carries a name and a reason rather than disappearing into a category.
The subtler outcome is diagnostic. Because exceptions are now classified, the trend of each category is visible: a rising count in one reason code points at a specific upstream problem while it is still cheap to fix. Before this, the same information existed only as a growing sense that something was wrong.
[METRIC — sign-off: match rate and exception counts before/after]
What it means for you
This is the cheapest fintech discipline to retrofit and the fastest to pay back, because it requires nothing from the rest of your architecture. No append-only ledger, no event sourcing, no rebuild. You need read access to your own records, the external files, and somewhere to put exceptions.
That is why I recommend it first to anyone already drifting. It does not fix the cause — that is the ledger rebuild — but it stops the growth and, more usefully, it measures the problem. Before reconciliation, “our numbers don’t match” is an unbounded worry nobody can fund. After a fortnight of daily matching, it is a categorised list with rupee values against each cause, which is a work plan.
Start here if the full rebuild feels too large to begin. The method is public: reconciliation at scale.
The lesson worth stealing
The taxonomy is the product. Everyone building reconciliation focuses on the matching engine, which is the tractable, satisfying part. But an exception queue that says “unmatched” nine hundred times is a list, not a tool — the value arrives entirely from the reason codes, and those come from the people who have been resolving differences by hand rather than from a whiteboard.
The corollary is that this project’s most important hour was a conversation, not a commit. Twenty recent exceptions, walked through one by one with the person who resolved them, produced eight categories that covered almost everything. Encoding those took a day. Inventing them from first principles would have produced a taxonomy that was theoretically complete and practically useless.
Related reading
/blog/reconciliation-at-scale — the method in full · /work/ledger-rebuild — fixing the cause rather than the symptom · /services/fintech — the practice · /blog/why-your-ledger-drifts — why late reconciliation compounds
Stop the bleeding first
If month-end involves a person, a spreadsheet and a phrase like “we’ll adjust it” — that is a fortnight of work away from being a morning review. /contact.