The brief
The client moved money between their own ledger, Stripe, and a banking partner. Once a month, two people spent three days matching transactions across the three systems in a spreadsheet. The brief: replace the spreadsheet with an engine.
The constraint
In a reconciliation tool, a false match is a quiet accounting error that surfaces during diligence. The engine had to refuse to guess. Anything it could not match with certainty had to land in an exceptions queue for a human, not get force-fit.
The approach
We built a deterministic matcher with explicit tiers. Tier one is exact id match. Tier two is amount, date, and counterparty within tight tolerances. Anything that does not clear a tier is an exception. The engine never uses a model and never approximates a money match.
The exceptions queue is the actual product. It groups unmatched items, suggests likely pairs without committing them, and records who resolved each one and why.
The build
Days 1 to 4: the data model, the importers for all three sources, and the matcher tiers. Days 5 to 11: the exceptions queue, the dashboard, and the audit log. Days 12 and 13: deploy, README, handoff.
The outcome
The engine shipped on day 13. It reconciled 100 percent of historical transactions on the first full run and dropped the unexplained items into the exceptions queue, where they belonged. The monthly close went from three days to an afternoon.
“They told us where AI did not belong, and the money math was top of the list. The engine is deterministic and auditable. Our monthly close went from three days to an afternoon.”