The 3% problem
Match rate is the metric everyone reports and the one that tells you least. What matters is the shape of what did not match.
Ane Etxeberria
Co-founder, Chief Executive
Every reconciliation vendor leads with a match rate. Ninety-seven per cent. Ninety-nine. The number is easy to produce, easy to compare and almost entirely useless, because it describes the part of the problem that was never hard.
A payments business running a million lines a month at a 97% match rate has thirty thousand unmatched records. That is not a rounding error. It is a full-time job for two people, and the reason the close takes eleven days rather than four. The interesting question was never how big the 97% is. It is what the 3% is made of.
Breaks are not randomly distributed
The instinct is to treat unmatched lines as noise — a scattering of one-off problems that have to be worked through individually. In practice, across the operations we have looked at, breaks cluster hard into a small number of recurring shapes. A representative month for a mid-size acquiring business looks roughly like this.
| Shape | Share of breaks | Median resolution |
|---|---|---|
| Timing — instructed, not yet cleared | 41% | 0 min (resolves itself) |
| Fee and spread differences | 23% | 6 min |
| Batch and aggregation mismatches | 14% | 24 min |
| Returns and reversals not applied | 9% | 18 min |
| Reference lost or truncated upstream | 7% | 11 min |
| Duplicate instructions | 3% | 31 min |
| Genuinely unidentified cash | 3% | 2–5 days |
Two things follow from that table, and both of them are uncomfortable for the way most teams currently work.
Most of your queue is not a problem
Forty-one per cent of the queue is timing. A SEPA credit transfer instructed on Friday afternoon has not cleared on Friday evening, and no amount of investigation will make it clear faster. Yet it sits in the same queue as a duplicated payout, styled identically, demanding the same attention.
This is the single largest source of wasted effort in reconciliation, and it is entirely self-inflicted. If the system knows the expected clearing window for a channel — and it does, because it has watched thousands of them — it can suppress an instruction that is inside its window and surface it the moment it is not. The queue that remains is smaller, and everything in it deserves a human.
The expensive breaks are not the frequent ones
Unidentified cash is 3% of breaks and consumes more analyst time than the top three categories combined. Duplicate instructions are 3% and carry direct financial loss. Meanwhile, fee differences are 23% of the queue and are mechanically solvable — the deduction either falls inside the contractual band you agreed with the acquirer, or it does not.
Ranking a queue by value, which is what most tools do, gets this exactly backwards. A €2.4M payout sitting in the queue because it cleared a day late is a non-event. A €680 debit advice with no remittance information might be a control failure. Rank by what the item might mean, not by what it is worth.
What to measure instead
Match rate survives as the headline metric because it is the only one that is trivially comparable between vendors. If you are running an operation rather than buying one, four numbers tell you more.
- 01Actionable break count — items requiring a human decision, after timing has been suppressed. This is your actual workload.
- 02Median age of an open break. A stable count with a rising age means you are resolving the easy ones and accumulating the hard ones.
- 03Share of breaks arriving with a classification. An unclassified break costs an analyst the investigation before the decision; a classified one costs only the decision.
- 04Repeat rate by reason code. Any code appearing every month is a defect somewhere upstream, and fixing it is worth more than resolving it faster.
That last one is the one that compounds. In one operation we worked with, a single reason code — references stripped by one sending bank's file conversion — accounted for 71% of the reference-loss category, every single month, for two years. Nobody had ever aggregated the queue by cause, so nobody had noticed that one phone call would remove a recurring six hours of work.
The uncomfortable conclusion
If your reconciliation improvement project is aimed at the match rate, it is aimed at the wrong thing. Moving from 97% to 98% halves the queue on paper and changes almost nothing about the working day, because the half that goes is the timing half that was already free.
Aim instead at the composition. Suppress timing properly. Make the mechanical categories mechanical. Classify what remains before a human touches it. Then count what is left, and you will find the number is small enough to argue about individually — which is exactly the state a reconciliation function should be in.
Keep reading
Engineering
camt.053 in practice
The schema is public, the standard is well written, and the files will still surprise you. Eleven things that actually break parsers.
9 min read
Engineering
Where rules-only matching stops
A well-written rule set gets you to about 92%. The remaining 8% is not more rules — it is a different class of problem.
8 min read
Compliance
An exception agent you can audit
Putting a language model near the general ledger is a governance question before it is an engineering one. Here is the architecture we could defend.
8 min read