Demo · Back-office automation
How much of the close can you auto-match, and how much of it is wrong?
Bank reconciliation is the classic back-office automation target: match each bank line to the ledger, and send only the leftovers to a person. Loosen the rules and the match rate climbs, but so do confident matches that pair the wrong items. This demo runs a matching engine on a synthetic month of transactions with a known answer key, so you can see both numbers at once.
Results
How each bank line was matched
The date window has a sweet spot
Exceptions and wrong matches as the date window changes, with the other rules as set. Too tight, and normal clearing delays fall out of the exact rule, so the amount-only rule grabs look-alikes; too wide, and more look-alikes qualify. A wrong match is worse than an exception: it looks finished, so nobody checks it.
The exception queue (first 12)
How the engine works
Rules run in order, and each bank line is matched at most once: (1) same reference, same amount, within the date window; (2) same amount within the window when references differ, taking the closest date; (3) a reference that differs by one or two characters with the amount within tolerance (this is how wire fees get matched, and the difference is flagged for a fee posting); (4) batch deposits, where several ledger receipts in the window add up to one bank line. Everything left over goes to the exception queue with a likely reason. Every result is graded against the answer key the data was generated with.
All data is synthetic. Real reconciliations add multiple accounts, currencies, partial payments and remittance files; a production system would also learn from how people clear exceptions. This demo shows the rule tradeoffs, not a vendor's accuracy.