Match bank transactions to books

A restaurant owner's UPI and card settlements land in the bank account a day after the sale, so the daily till total and the bank statement never quite line up on the same date, and by month-end nobody can say with confidence which of forty settlement batches actually cleared and which are still sitting somewhere unexplained. Chasing that gap by eye, line by line, eats an evening that should have gone to closing the shop instead.

Bank statement reconciliation proposes matches between bank lines and existing ledger entries based on amount, date, and payee similarity, and surfaces anything unmatched in a queue before month-end arrives. Nothing here moves money or reconciles a statement on its own — every proposed match waits for the owner or CA to confirm it, so a same-amount coincidence between two unrelated transactions never quietly slips into the books unnoticed as a false match.

Reconciliation here is proposal, not automation of judgement. Khata compares bank lines to ledger entries and suggests likely matches on amount, date, and payee similarity, but it never moves money or marks a statement reconciled without a human accepting each match. An over-eager auto-match fails quietly: two unrelated transactions of the same amount, on nearby dates, look identical to an amount-and-date matcher, and accepting that false positive pollutes the ledger with a wrong reconciliation.

The restaurant scenario is a particularly common version of a broader timing problem. Settlement lag between a sale and the corresponding bank credit is normal for UPI and card payments, but it means a naive day-by-day comparison would flag every single day's total as unmatched, purely because of a one-day delay in how processors settle funds. The matching logic accounts for this lag rather than treating it as an anomaly, and the unmatched-aging check only flags an item once it's been outstanding longer than the expected settlement window, not the moment a normal delay simply begins.

Bank statement formats themselves vary widely across Indian banks, and a statement parser that handles one bank's PDF layout cleanly can stumble on another's column ordering or date format entirely. When a parse fails or reads a line incorrectly, that transaction simply won't propose a sensible match at all, which is why the unmatched queue exists as a safety net independent of parsing accuracy — anything the parser mishandled ends up visible and flagged for manual attention, rather than silently dropped from the reconciliation altogether without a trace.