Reconciliation & Exception Intelligence
Turn a large reconciliation problem into a small review queue.
A distributor receives payment through a bank lockbox and two clerks apply it to open invoices by hand. At the year end the aged receivables report — the one collections works from — was overstated by the cash nobody had posted. Which records actually require attention, and why?
The result
Five source files reconciled into distinct action and review populations.
Invoices open at the start of the period, invoices raised during it, the bank file, the cash receipts journal and the aged receivables report - matched in passes of decreasing certainty, so what reaches a reviewer is the part that needs judgment.
- Cash unapplied at year end
- $1,425,588$1,326,443 still unposted weeks later
- Linked automatically
- 89.8%of 19,122 receipts, at high confidence
- Ground-truth exceptions
- 747$54,969 of variance at risk
- Link precision
- 99.34%recall 97.6% on findable links
Demonstration project using synthetic data designed to simulate a realistic multi-system finance reconciliation problem.
The finding
The seven-figure backlog was a posting problem, not a matching problem.
For the 758 directly applicable receipts, the payment-to-invoice relationship was already clear. The control failure was that cash had not been posted to the invoice-level subledger.
Not all of it was a backlog
$99,145 was keyed in the first days of July in the ordinary course. $1,326,443 across 764 receipts was still unposted at the end of the observation window, and $1,311,231 of it can be posted exactly as it stands.
Separate populations, not one queue
Open receivables, payments awaiting sign-off, cash in transit and genuine anomalies are different quantities and are never added together. Where a customer holds cash the engine could not allocate, their invoices are held rather than chased, and 95.2% of the collections list is genuinely unpaid.
How it holds up
Matching and classification accuracy are measured against known ground truth.
The data is synthetic, so every problem in it was introduced deliberately and recorded before the engine ran. Accuracy is scored against that record rather than asserted.
Nothing is cleaned silently
The pipeline starts at the files, with the mess a real export carries, and reports everything it had to change before any analysis ran.
The weakest result is published
Holding invoices back against unallocated cash is the least reliable thing the engine does: 73.4% precision and 76.9% recall. The full analysis says why, and what a supervisor should work from instead.
The evidence package ships a standard-library verifier. 95 of 95 checks pass on this build across the reconciliation and exception-intelligence outputs, including the headline metrics shown here. Run it yourself: python verify.py.
Start here
Want this done on your data?
The first conversation is about the question, the data that exists, and whether the work is worth doing at all.