Reconciliation and breaks: the team that decides whether you survive audit

What is being reconciled against what

A single payment produces records in several places, and none of them agree automatically.

Your ledger holds the postings your system wrote, covered in ledger architecture.

The switch or scheme report records what NPCI or the card network believes was authorised and routed.

The bank statement records what actually hit the nodal, escrow or pool account, and when.

The settlement file records what the scheme says you are owed or owe on a net basis for a cycle.

The merchant or partner view records what the counterparty believes they are owed, which is where disputes originate.

Reconciliation is the continuous process of matching these five against each other. In a healthy system most records match automatically. The work is in the residue.

Why breaks happen

Breaks are not failures of competence. They are the normal consequence of distributed systems with independent participants and different clocks.

Timing differences. A transaction authorised at 11:58pm appears in your ledger on one day and in the bank statement on the next. Nothing is wrong, but an unsophisticated matcher reports a break.

Status disagreement. The transaction your system recorded as failed was deemed approved by the scheme, so the money moved. This is the UPI failure mode described in how UPI payments work, and it surfaces here.

Partial settlement. A batch settles for a different net amount than expected because of a fee, a reversal from a prior cycle, or an adjustment the scheme applied.

Chargebacks and disputes. Money comes back weeks after the original transaction, against a record that has already been reconciled and closed.

Fees and charges. The amount credited to your account is the transaction value less fees computed by someone else's logic, which must be independently derivable or you cannot verify it.

Genuine loss. Occasionally money really is missing, and the only reason you know is that the recon detected it. This is the entire justification for the function.

What a real reconciliation system looks like

The maturity curve is consistent across companies, and knowing where a business sits tells you what to hire.

Stage one: spreadsheets. Someone in finance downloads files and matches in Excel. This works to a few thousand transactions a day and then stops, usually abruptly, when a backlog forms that nobody can clear.

Stage two: scripted matching. An engineer writes jobs that ingest files and match on reference and amount. This handles the bulk and leaves an exception queue. Most Indian fintechs live here longer than they should.

Stage three: a recon platform. Configurable matching rules per source, tolerance windows for timing and amount, automated break classification, a workflow for investigation and resolution, an audit trail of every adjustment, and reporting that a finance team and a regulator can both use. Breaks are detected within the day and aged, so nothing silently persists.

The architectural requirements at stage three are specific: ingestion that tolerates late, malformed and duplicate files; matching that handles one-to-many and many-to-many relationships rather than only one-to-one; and an adjustment mechanism that writes compensating ledger entries rather than editing history.

The trigger for moving between stages is almost always an incident, not a plan. That is worth knowing when assessing where a company is and what they will admit to in an interview.

Nodal, escrow and why account structure is a recon problem

Indian payment businesses hold customer and merchant money in specific account structures mandated by the RBI, and the structure determines what reconciliation has to prove.

A payment aggregator collects funds into an escrow account and settles onward to merchants. The money in that account is not the company's; it is held on behalf of others, and the regulator expects it to be demonstrably intact at all times. Permitted credits and debits to the account are defined, settlement timelines are defined, and the balance must be explicable against the obligations it covers.

This turns reconciliation from an accounting convenience into a compliance control. The question is not only "do our numbers match" but "can we prove, on any given day, that the escrow balance equals what we owe." A business that cannot answer that quickly has a regulatory problem rather than a bookkeeping one.

The engineering consequence is that merchant-level obligation tracking has to be as rigorous as transaction-level matching, and the two have to agree.

The dispute lifecycle

Chargebacks and disputes are the part of reconciliation that most systems handle worst, because they violate the assumption that a transaction is finished once it has settled.

A dispute arrives days or weeks after the original payment, against a record already reconciled and closed. It has its own clock defined by scheme rules, its own evidence requirements, and its own financial consequences depending on the outcome. Each stage produces money movement that must post to the ledger and reconcile against the scheme's own view.

Three things make this hard. The timelines are externally imposed and missing one loses the dispute automatically, regardless of merit. The evidence usually lives in product systems rather than payment systems, so the pipeline crosses team boundaries. And the volume is unpredictable, spiking with a fraud episode or a product change.

Teams that treat disputes as an operations queue rather than a system discover the cost at scale, usually as losses that were avoidable with better evidence handling.

Talent implications

This is the function we see under-hired most consistently, and the reasons are structural rather than accidental.

Reconciliation is invisible when it works. It has no product surface, it generates no revenue directly, and it is difficult to demonstrate in a demo. Engineers rarely seek it out, because the work is detailed, operationally demanding and carries blame when something is wrong. So teams staff it with whoever is available, often a junior engineer or a finance analyst with scripting ability, and the function performs adequately until volume or complexity exceeds what that arrangement can hold.

The result is a predictable and expensive pattern: the company grows, the exception queue grows faster, and at some point a month cannot be closed or an audit cannot be answered. The search that follows is urgent, which is the worst condition under which to hire into a role that requires judgement.

Three things worth building into any brief for this function.

Hire before the incident. The same person is available more cheaply, and assessable more carefully, six months before the crisis than during it. Every firm that has been through the stage-two-to-three transition says this afterwards.

Look for people who chose it. The strongest reconciliation engineers are unusual: they find the detail genuinely interesting rather than tolerable. They exist, they are scarce, and they are often found in payment processors, banks and card networks rather than in consumer fintech.

Do not split ownership between finance and engineering. The most common organisational failure here is a matching system owned by engineering and an exception queue owned by finance, with neither accountable for the whole. Breaks age in the gap between them.