A D2C brand in Pune closed its books for a quarter and found 11 lakh rupees it could not explain. Not missing, exactly. The order table showed 41,200 paid orders. The gateway dashboard showed a slightly different count. The bank statement showed a third number, net of fees, net of refunds, net of chargebacks, and net of a handful of transactions that had settled in the following cycle. Nobody had been comparing the three.
This is the ordinary state of most growing businesses. Payments look reconciled because the customer got their goods and the money broadly arrived. The gap only becomes visible at audit, at fundraising, or when a genuine leak has been running for months.
Three Ledgers, Not One
Money movement always involves at least three independent records, and they disagree by design.
- Your internal ledger. Double entry, in integers of the smallest currency unit, written at the moment your system believes something happened.
- The processor record. What the PSP or aggregator says: authorised, captured, refunded, disputed, along with fees and taxes deducted per transaction.
- The bank settlement. A net amount landing on T+1 or T+2, covering a batch, minus adjustments that may relate to a completely different day’s transactions.
Reconciliation is a daily job that pulls all three, matches on a stable key, and produces a list of breaks. The key matters enormously. Amount and date will produce false matches the moment two customers pay the same value in the same hour. Use the processor’s transaction identifier, stored on your payment record at creation time rather than parsed out later.
Classify Breaks, Do Not Just Count Them
An unclassified break list is noise. A useful reconciliation job sorts every mismatch into a named category with an expected resolution path: settled but not recorded, recorded but not settled, amount mismatch from a fee change, refund settled against the wrong cycle, chargeback debit, or a genuine duplicate.
Set a tolerance and an age. A break under one rupee from rounding on a percentage fee can auto-close. A break over 5,000 rupees or older than three days should page a human. Most healthy operations run under 0.1 percent of transaction count as open breaks after 48 hours, and anything drifting above 0.5 percent points at an integration bug rather than at operational noise.
The other rule is that reconciliation never edits history. When a break resolves, it resolves through an adjusting journal entry with a reference to the break record. Silently updating an old row destroys the audit trail you built the ledger for.
Make It Boring And Automatic
The reconciliation that works is the one that runs at 6am without anyone asking. That means the settlement file fetch is a scheduled job with retries, the parser is version aware because processors change their CSV columns without much notice, and yesterday’s result is visible as a single number on a dashboard the finance team already looks at.
The payoff compounds. Once daily reconciliation is trustworthy, month end close moves from a week to an afternoon, refund disputes get answered with evidence instead of apologies, and revenue reporting stops being an estimate.
At Invexa, we treat reconciliation as a first class feature rather than a finance chore, because a business that cannot tie its ledger to its bank account is running on faith.