Financial Reconciliation Engines
Everyone builds the matching algorithm first. The matching is the easy part. Exception handling is what makes reconciliation valuable.
Ask an engineer to build reconciliation and they reach for a matching algorithm: pair up two lists, flag the leftovers. That instinct is right and almost beside the point.
The matching algorithm is not the hard part. Exception handling is.
Most transactions match themselves
In practice the large majority of transactions match automatically — same amount, date, reference. If that were the whole job, reconciliation wouldn't need a platform. A script would do.
The system earns its keep on everything that doesn't cleanly match.
The product is the exception workflow
What makes a reconciliation engine valuable:
- Pending states — not matched yet, but not failed either.
- Partial matches — one bank deposit settling a batch of invoices.
- Force-match flows — a human asserting a match the engine couldn't.
- Refunds and reversals.
- Manual overrides with a reason.
- Audit trails for every decision.
Strip those out and users stop trusting the system. Trust is the product.
Lesson. Reconciliation is not a single pass that returns matched / not matched. It's an iterative workflow that converges as more data arrives. Some transactions match now, some need context, some need a human, and some only reconcile after the next file lands.
Why "Pending" matters more than the algorithm
A transaction can look unmatched for entirely normal reasons:
- the settlement report arrives later than the payment
- an exchange rate hasn't been applied yet
- a reference is missing
- an upstream system is delayed
Treating these as failures creates operational noise and erodes trust. Treating them as Pending — to be re-evaluated as data arrives — means many resolve themselves with no human at all.
Ingest → Match → Pending → Enrichment → Match againThe ability to revisit a decision turned out to matter more than improving the matching algorithm itself.
Payment success ≠ settlement success
A payment provider says ₹10,000 succeeded. The settlement nets fees and tax to ₹9,705. The bank shows ₹9,705. A naive engine reports a mismatch. A useful one understands the lifecycle from gross collection to net settlement.
The opinion
Most reconciliation problems are data-quality problems disguised as matching problems. The matching engine gets blamed for issues that originate in source systems. Fix normalization and enrichment first, and a surprising amount of "matching difficulty" disappears.
Related
- The essay version: Building a Financial Reconciliation Platform, Not a Matching Engine.
- Why re-ingestion must be safe: Idempotency Patterns.
- Why every decision needs a trail: Auditability and Traceability.
Multi-Tenant SaaS Architecture
Serving many customers from one system while making each feel like they have their own. The question is always how strongly tenants are isolated — and at what operational cost.
Auditability and Traceability in Fintech Systems
In financial systems, an answer you can't explain is worse than a slow one. Auditability is more important than intelligence.