Where reconciliation fails

Most of the work in a settlement system is not the matching. The processor gives you a report, the bank gives you a statement, your ledger knows what it posted, and most lines line up on transaction reference alone. A reconciliation system earns its keep on the residue.

The residue has a small number of recurring shapes, and every one of them will show up in your data eventually:

• Duplicates. A retried transfer posts twice at the processor and once in your ledger. The second posting is real money until someone notices it is not.
• Partial settlement. A processor settles in two batches and the bank sees one credit. Which ledger entries does it cover? The answer changes the balance.
• Timing skew. A transaction at 23:58 posts to your ledger today and lands on the bank statement tomorrow. Every day-end boundary invents a discrepancy that resolves itself if you wait, which is why an unmatched item needs an age, not just a flag.
• Reversals. A transaction that failed after settlement comes back as a debit days later, long after your reports said the books were clean.
• Rounding. FX conversions accumulate kobo-level differences that no single line explains and every aggregate report inherits.

The discipline is simple to state and easy to skip: match on evidence, escalate on doubt. A line that cannot be matched belongs in a queue that ages and that a named person owns. Auto-resolving an unmatched line is how a small discrepancy becomes the write-off nobody can explain at the end of the quarter.

The edge cases are the product. Anyone can build the part where the references match.