Bank reconciliation: why the unmatched remainder matters
A matching closing balance proves nothing, and a clean first pass is suspicious. What the unmatched remainder tells you if you keep it visible.
· 5 min read
What reconciliation is actually checking
A bank statement and a business's own books are two separate, independently kept records of the same cash movements. The bank records what actually happened to the account, in the order it happened. The books record what a person or a system believed happened, entered from invoices, receipts and memory. Reconciliation is the act of lining these two records up, transaction by transaction, and confirming they agree — not just that the ending balances happen to match, which two wrong records can do by accident, but that every individual movement on one side has a matching movement on the other.
That distinction is the entire point of the exercise. A total that matches by coincidence — an omitted deposit and an omitted bank charge that happen to be the same size — looks identical to a genuinely clean reconciliation on the summary line, and completely different once anyone looks at the individual transactions underneath it.
It is worth separating this from a related but different question: what does a given line on the statement actually mean. Reading and explaining a bank statement — what a transaction was, what a recurring debit looks like, what an unfamiliar entry probably represents — is a different job from matching that statement against the books. Dena is built specifically for the first job, reading an account or an imported statement a person already has the right to see and answering questions about it, without touching the ledger or the money itself (automixai.in/docs/dena). Reconciliation, the subject of this article, is the second job: taking a statement already understood and checking it against what the books separately recorded.
Why a clean first pass is the suspicious one
In any business doing real volume, some disagreement between the bank and the books on a given day is normal and expected, not a sign something is wrong. A cheque issued and recorded in the books can sit for days before the bank actually clears it. A deposit made at the end of the month can show in the books before the bank has processed it. Bank charges, interest credited, or a payment gateway's fee deducted before the rest of the amount lands can all appear on the bank's side before anyone has entered them into the books at all.
A reconciliation that shows zero difference on the very first attempt, especially for a business with any real transaction volume, is more often a sign that something was matched wrong than a sign that everything was recorded perfectly. Khata's own reconciliation is deliberately built around scored suggestions that a person confirms one at a time, with an unmatched remainder that the tool always returns and never quietly shrinks by forcing a weak match through — automixai.in/docs/khata sets out exactly how that gate works.
What a matching algorithm can and cannot know
A reasonable matching system scores candidate pairs by how closely their amount and date line up, and offers the strongest candidates for a human to confirm. What it cannot know, from the numbers alone, is why two transactions that share an amount actually happened — whether a INR 4,500.00 bank debit and a INR 4,500.00 recorded payment really are the same event, or whether they are two separate coincidences of a common round figure.
A system designed to make its own report look tidy has an incentive to force every line into some match, because an unmatched remainder reads as unfinished work. That is precisely the wrong instinct. Forcing a plausible-looking pair together when they are not actually the same transaction can hide a real problem underneath an artificially balanced report — a duplicate payment, a transaction booked twice, or an entry that genuinely does not belong in this period at all — behind a summary line that now says everything reconciles.
Reading the remainder instead of hiding it
Whatever is left unmatched after a genuine reconciliation attempt falls into one of a few explainable categories, and working out which one a given line belongs to is the actual analytical work of reconciliation, not an afterthought to it. It might be timing — a cheque or a transfer that both sides will show once the other record catches up. It might be an omission — something that happened at the bank and was simply never entered into the books. It might be an error — the right transaction recorded with the wrong amount or the wrong date. Or it might be genuinely unexplained, which is the category that actually needs someone to go and find out what happened.
None of these categories are interchangeable, and lumping all of them into one generic unreconciled total loses exactly the information that made reconciling worth doing in the first place. A remainder that a business can name and explain, line by line, is a very different thing from a remainder a business has simply stopped looking at.
Why reconciling often changes what the remainder can tell you
A remainder built up over a single month is a manageable, explainable list. A remainder built up over a year, at close, is a much harder thing to reconstruct — by the time anyone looks at it, memory of what a specific INR 15.00 difference on a specific date was about has usually gone. Reconciling in small, frequent batches means each unmatched line is still fresh enough that someone can actually say what it was, rather than guess.
This is also why what a period close actually captures matters. Closing a period should freeze not just the balances but the fact of how many statement lines were still unreconciled at that exact moment — a number that gets harder to reconstruct honestly after the fact, once entries have kept moving and the original context is gone. A trial balance or a handoff pack that states this count plainly, rather than a books that quietly stop mentioning it, is the difference between a reconciliation that can be checked later and one that can only be taken on faith.
What good reconciliation hygiene looks like, mechanically
A few habits do most of the work. Import the bank's own statement lines rather than re-typing them by hand, since a hand-typed figure is one more place a transcription error can enter a record that is meant to be the independent check on exactly that kind of error. Guard against re-importing the same statement twice, since a duplicated line looks identical to a real one and will not surface itself later without a de-duplication check. Let a person confirm every suggested match individually rather than accepting a batch all at once, since a batch approval is exactly where a wrong pairing slips through unnoticed.
And keep the unmatched remainder visible on every report that comes out of the process — a trial balance, a period close, a handoff to an accountant — rather than netting it away into a tidier-looking single figure. A reconciliation report that cannot show you what it did not manage to explain is not actually more finished than one that shows a small, honest gap; it has just stopped telling you the truth about where it stands. Laxmi's own receivables and payables tracking follows the same discipline for the invoice side of this — automixai.in/docs/laxmi covers how an invoice there can only be marked paid by recording money that actually arrived, never by editing a status field.
Common questions
Is it a bad sign if a reconciliation never comes out perfectly matched?
Not by itself. A small remainder that can be explained — a cheque still clearing, a bank fee not yet entered — is normal for a business with real transaction volume. What is worth attention is a remainder nobody can explain, or a remainder that keeps growing period over period rather than clearing as the timing differences that caused it resolve.
Why would forcing every transaction to match ever be a problem — isn't a full match the goal?
The goal is an accurate reconciliation, not a complete-looking one. A matching engine scores candidates by how closely amount and date line up, which cannot distinguish two genuinely unrelated transactions that happen to share a round figure from two halves of the same event. Forcing a plausible pair together to clear the report can hide a real problem — a duplicate, a wrong-period entry — underneath a summary line that now reads as fully reconciled.
Should reconciliation only happen at year end, since that's when the accountant needs it?
Reconciling only at year end means working through a much larger, staler backlog, where the context for a specific small difference has usually been forgotten by the time anyone looks at it. Reconciling in smaller, more frequent batches keeps each unmatched line recent enough to actually explain, and surfaces a genuine problem — like a duplicate payment — closer to when it happened rather than months later.
What should an accountant actually see about the reconciliation at handoff — just the final matched total?
A useful handoff shows the unmatched remainder as it stood at the close of the period, not just a final balance with the gap smoothed away. That is what lets an accountant see exactly what is still open, rather than having to re-derive it from scratch or take an already-tidied number on faith.