Bank-to-GL reconciliation: UTRs, NEFT timing, and silent charges

Bank-to-GL reconciliation has a reputation, both inside finance teams and in reconciliation tooling marketing, of being the easy one. The cardinality is mostly one-to-one — one bank credit, one GL journal entry — and the matching key is supposed to be the UTR or the cheque number or the deposit slip, which is supposed to be unique. The reputation is wrong. Bank-to-GL fails differently from AR-to-GL, but it fails just as often, and the failure modes are quieter, which is part of what makes them dangerous. Three concrete shapes those failures take: a UTR that appears in the bank statement formatted differently from the UTR field in the ERP, a bank credit dated three days after the GL journal entry because the NEFT batch settled after cut-off, and a forty-seven rupee inter-bank charge that nobody accrued and that nobody noticed leaking out of the operating account month after month.

The UTR canonicalisation problem is the most common and the least talked about. HDFC Bank writes UTRs in their statement narration as HDFCN12345678901, prefixed with the channel code. ICICI strips the prefix entirely and writes a sixteen-digit numeric. SBI prefixes with the branch code and pads to a different length. Axis Bank embeds the UTR inside a free-text narration field that has to be regex-extracted from a sentence containing the beneficiary name and the transaction date. The same payment shows up as three different UTR strings across the bank statement, the ERP, and the counterparty's confirmation email — and a direct equality match against the ERP UTR field fails on every row, even though every row would match if the UTRs were canonicalised first. ReconPe's Bank-to-GL wizard runs pattern detection over the column headers and the first few rows of an uploaded bank statement, identifies the bank from the format signature, and applies the bank-specific canonicalisation rule before matching. It currently recognises HDFC, ICICI, SBI, Axis, Citibank, JP Morgan, and HSBC formats, with mapping defaults for each. Banks outside that list still work — the user picks a template and reviews — but the autodetection collapses ten minutes of mapping work into the time it takes to confirm.

The second failure mode is timing skew, and it is structural rather than tooling. A salary payout instructed on the last working day of the month posts to the GL on day thirty. The bank settles the NEFT batch the next morning and credits the beneficiary accounts on day one of the next month. A naive date-equality match on these two artefacts produces two separate exceptions: one MISSING_TARGET on the GL side ('no bank entry for this journal entry') and one MISSING_SOURCE on the bank side ('no GL entry for this credit'). They are the same transaction. ReconPe handles this with a DATE_WINDOW rule type, which allows the matching engine to consider any bank entry within a configurable window of the GL journal entry date as a candidate for the same transaction, and with the TIMING_DIFFERENCE residual class, which lets the matched pair be marked as resolved even though the dates differ. The timing residual is one of the six residual classes that are explicitly not close-blockers — a recon can move to READY_TO_CLOSE with a hundred timing-residual exceptions, because the close is not waiting on those to clear; they will clear in the next period when the bank entry arrives.

The third failure mode is the smallest per-transaction and the most expensive in aggregate. RTGS charges of fifty to fifty-five rupees, IMPS slabs that scale with amount, FX conversion charges on outward remittances, return charges on dishonoured cheques, GST at eighteen percent on every banking service. Each is small. None is individually material. But on a high-volume current account doing thousands of transfers a month, they aggregate into a persistent unreconciled drift between the bank balance and the GL cash balance, often in the ₹50,000 to ₹2,00,000 range across a quarter. They are also genuinely cash; the bank really did debit the account, the company really did pay, and the failure is that there was no GL journal entry to match them against because nobody accrued for them at the time. The reconciliation surfaces these as MISSING_TARGET exceptions on the bank side, and the controller classifies them — usually as WRITE_OFF_OR_ROUNDING for the small operational charges, or as a deliberate accrual-adjustment that the GL accountant will book as a single net journal entry for the period. Either way, they stop hiding.

The one-to-one assumption is wrong even on the bank side, just in different places than on AR. Sweep transactions: ten cheque deposits across three days credited as one consolidated bank lodgement on day four. Vendor batch payments: one ₹47-lakh bank debit settling thirty-one separate vendor invoices, each posted as its own GL journal entry. Card-acquirer settlements: hundreds of individual card transactions netted against a single bank credit minus the acquirer's MDR. Each of these has cardinality greater than one, and a one-to-one matching engine fails on each. The same subset-sum aggregation engine that runs on AR-to-GL — depth-first search with branch-and-bound pruning, partitioned by currency and counterparty, bounded by date window and tolerance — runs on Bank-to-GL too, with bank-tuned tolerances. The currency partition is usually trivial because most accounts are single-currency, but the date window is shorter (sweeps don't span months) and the absolute tolerance is tighter (banks don't round to the rupee the way AR receipts do). The result is that batch transactions reconcile in seconds rather than being decomposed manually, line by line, in a spreadsheet.

The reverse direction — bank entries with no corresponding GL journal entry — is a category of its own. Bank charges, interest credits on sweep deposits, dividends from idle cash parked in liquid funds, demand drafts returned, cheques dishonoured weeks after they were credited. These show up in the bank statement and never had a GL journal entry, not because the recon missed them but because nobody booked them. The reconciliation surfaces them as MISSING_TARGET exceptions, and the controller has to decide what they are. Bank charges are usually written off through a single periodic accrual-adjustment journal. Interest credits get booked to interest income. Returned cheques reverse the original receipt. The fix is upstream — better accrual policy, automated charge accruals, faster cheque-status updates from the bank — but the recon must surface them in time for the close, with enough context for the GL accountant to book the right adjustment journal in the right period.

The cross-period exception memory matters more for bank-to-GL than for almost any other recon, because bank reconciliation has a structural shape where some entries arrive late. An interest credit posted on the last day of the quarter, a foreign remittance held up in correspondent banking, a cheque cleared eight days after deposit because the drawee bank was on a holiday cycle. In a stateless reconciliation tool, each of these surfaces as an exception in the period it appears, gets investigated, gets cleared, and the system forgets. The next quarter, the same vendor's payment arrives late again, surfaces as the same exception, gets investigated by a different analyst who has no memory of the prior cycle, and the work repeats. ReconPe's organisation-wide exception pool — fingerprinted by a SHA-256 over (counterparty, amount, sign), aged out at 180 days — links the late-arriving credit in the current period to the open exception from the prior period automatically. The analyst sees a candidate link, confirms it, and both sides close together. After three such links for the same counterparty, the system tags the counterparty as a recurring late-settler with the average lag, so the next period's exception comes pre-annotated.

The setup flow for a Bank-to-GL recon is five steps, designed to absorb as much of the manual mapping work as possible into automated suggestion. Step one: upload the bank statement file, in whatever export format the bank gave you. Step two: upload the cash GL extract from the ERP. Step three: AI Analysis — the wizard reads the column headers and the first sample rows of both files, attempts to detect the bank from the format signature, and proposes field mappings (which column is the UTR, which is the date, which is the amount, which carries the narration that contains the counterparty). Step four: Review — the user sees the proposed mappings and the proposed matching rules, and accepts or modifies. If the AI mapping is low-confidence, the wizard falls back to bank-specific defaults — the BANK_TO_GL_HDFC template, for example, ships with the canonical HDFC mapping pre-filled. Step five: Run. The actual reconciliation executes asynchronously; results land in the same workbench used for AR and AP recons.

The contrast with manual spreadsheet bank reconciliation is specific rather than rhetorical. The spreadsheet workflow involves manually copying the bank statement into a tab, manually cleaning UTR formats with find-and-replace and a trim formula, manually building a date-window match by sorting both sides and visually walking down the rows, manually flagging timing differences with a note in a comment cell, and manually compiling the bank-charge total at the end as a single accrual-adjustment line. Each step is doable for fifty transactions a month. None is doable cleanly for five thousand. ACRE absorbs the first three — UTR canonicalisation, date-window matching, batch decomposition — and surfaces the fourth (bank-charge accrual) as a classified residual rather than a hidden break inside an unreconciled balance. The honest qualifier: a small business with one bank account and fewer than a hundred transactions a month is fine on Excel, and bringing in a reconciliation tool for that volume is over-engineering. The pivot point is somewhere around five hundred transactions or two bank accounts, after which the spreadsheet workflow starts dropping things and nobody can prove what was dropped.

Bank reconciliation's value for a finance team is rarely framed correctly in tooling marketing. The framing is usually about speed — faster close, fewer hours per cycle. That is real, but it is the smaller half of the value. The bigger half is audit posture. Statutory auditors have been steadily raising the bar on what constitutes an evidenced bank reconciliation, and a growing number of audit firms now expect daily-reconciliation evidence rather than month-end snapshots, especially for companies with cash sweep arrangements or treasury operations. A reconciliation that can run end-of-day, classify residuals into typed categories, surface late-arriving credits via fingerprint linking, and produce a deterministic audit trail for every match changes what 'controlled' means for the bank account. The hours saved are nice. The defensibility under audit is the durable advantage, and it is the reason teams that have lived through one Big-Four cycle with weak bank-rec evidence rarely want to live through a second.