DEV Community: QuickRecon

Why Exact Transaction Matching Breaks at the Last 2%

QuickRecon — Mon, 10 Aug 2026 11:48:28 +0000

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.

Why Exact Transaction Matching Breaks on 1 Relationships

QuickRecon — Sun, 09 Aug 2026 11:13:27 +0000

Exact amount matching is a useful starting point for transaction reconciliation.

But it makes an important assumption:

One transaction on one side corresponds to one transaction on the other.

That assumption breaks quickly in real-world reconciliation.

Consider:

Bank transaction:
14,200

Ledger:
5,000
5,200
4,000

The ledger transactions sum to the bank transaction:

5,000 + 5,200 + 4,000 = 14,200

Yet an exact row-to-row matcher will classify all three individual comparisons as failures.

The problem

A basic matching function might conceptually do this:

for each bank_transaction:
find ledger_transaction
where bank.amount == ledger.amount

For $14,200, none of the three ledger records qualifies.

The algorithm isn't mathematically wrong.

It's solving the wrong relationship.

The actual relationship is:

1 bank transaction
↓
3 ledger transactions

This is a 1 matching problem.

Why this gets difficult

The trivial version is easy.

Given:

14,200

and:

5,000
5,200
4,000

we can calculate the sum.

The real challenge is candidate selection.

Imagine thousands of ledger transactions.

You cannot simply generate every possible combination and compare it with every bank transaction without considering computational cost and false positives.

The matching process therefore needs additional logic to determine which combinations are plausible.

Potential signals can include things such as:

Amount
Transaction date
Description
Account
Direction
Existing matches
Tolerance rules

The exact implementation depends on the reconciliation system and its data.

The important distinction

There are really two different questions:

Question 1:

Does an individual ledger row equal the bank transaction?

Question 2:

Can a valid combination of ledger rows explain the bank transaction?

Exact matching answers the first question.

1 reconciliation requires answering the second.

Why this matters operationally

The straightforward 1:1 transactions are usually easy to automate.

The difficult cases are the exceptions where the relationship between records changes.

That means a reconciliation system isn't simply searching for equal values.

It is trying to identify the relationship between two representations of the same financial activity.

For transaction-matching systems, recognizing that distinction is critical.

A system that only handles 1:1 matching will inevitably push some valid transactions into manual review.

The more useful challenge is therefore:

How do we identify valid 1 relationships without introducing a large number of false matches?

That's where transaction matching becomes an interesting engineering problem