A transaction matching system can perform extremely well on the majority of records and still leave a surprisingly difficult problem behind.
The reason is simple:
The remaining transactions are not necessarily matching failures. They're ambiguity problems.
The easy case
Suppose both systems contain:
Bank:
Amount: 1250.00
Date: 2026-08-10
Reference: INV-4821
Ledger:
Amount: 1250.00
Date: 2026-08-10
Reference: INV-4821
That's easy.
Amount matches. Date matches. Reference matches.
An exact or deterministic matcher can resolve it.
But real financial data isn't always this clean.
The exception case
Imagine the bank contains:
$14,200
while the ledger contains:
$5,000
$5,200
$4,000
An exact matcher sees no match.
But the records may still represent the same underlying payment.
The problem has changed from comparison to interpretation.
The dimensions of ambiguity
A useful transaction matching system may need to consider more than one field:
amount
date
description
reference
transaction type
account
surrounding transactions
aggregation relationships
Even then, a similarity score alone isn't necessarily enough.
A high similarity score tells you that two records look related.
It doesn't automatically explain why they should be considered the same transaction.
One-to-one isn't always the correct model
A common assumption is:
Bank transaction ↔ Ledger transaction
But real reconciliation can involve:
Bank transaction ↔ Multiple ledger transactions
or:
Multiple bank transactions ↔ One ledger transaction
That means the matching problem can become an entity-resolution and aggregation problem rather than a simple equality check.
The last 2% is a different engineering problem
The first 98% can often be handled through deterministic rules and strong similarities.
The exceptions require additional reasoning.
You need to determine:
Are these records related?
What relationship exists between them?
Is the difference expected?
Is the difference explainable?
Should a human review it?
That last question is particularly important.
A useful reconciliation system shouldn't necessarily try to automate every decision.
It should also know when the evidence isn't strong enough.
The practical lesson
The performance of a reconciliation system shouldn't be measured only by:
"How many transactions did we match?"
A more useful question is:
"How much investigation remains after the obvious matches are resolved?"
Because reducing thousands of straightforward comparisons is useful.
But reducing the investigation required for the exceptions is where the real operational impact can appear.
The last 2% isn't just the tail of the matching problem.
It's often a fundamentally different problem.
Top comments (0)