Bank Reconciliation Runbook: The Day-by-Day Sequence for Indian Enterprise Finance Teams

The first five days of the monthly close are the bank window. It is the least glamorous of the four reconciliation streams in the monthly close playbook and the one every finance team treats as the easiest to compress when the calendar slips. It is also the one whose compromises silently break the three windows that follow. A missed credit that turns out to be a TDS-net customer payment forces a re-run of the Day 6 to Day 10 TDS receivable ledger. A missed platform settlement fragments the Day 11 to Day 15 input tax credit match. A missed bank charge with GST on it distorts the Day 16 to Day 20 output register. Bank goes first in the cadence because it is the source data for every window that follows, and the sign-off on Day 5 is what unlocks the TDS window on Day 6.

This runbook is the day-by-day sequence for the window as it works in an Indian enterprise finance function — named owner per day, exact portal or ledger touched, exception trigger that stops the sequence, and the sign-off gate that closes it. Read it alongside the invoice-to-bank reconciliation failure modes article, which documents the design layer this runbook executes against — the two are engineered as a bidirectional pair.

Why the bank window compresses when the calendar slips

The bank window carries no permanent-loss statute. Nothing in the Companies Act 2013 or the Income-tax Act 1961 or the CGST Act 2017 turns a bank reconciliation kept open for an extra week into a permanent statutory loss. Unlike the Section 16(4) November 30 deadline that anchors the GSTR-2B window, the bank window’s downside is always recoverable — the credit is either identified in the next cycle, or the debit is either explained or reversed, or the platform settlement is either split correctly next month.

This is exactly the reason the window drifts. A finance team facing a compressed calendar defers the bank sign-off from Day 5 to Day 8, then Day 10, and by the time the TDS window is meant to open the bank data underneath it is a week stale. The Day 3 tax-analyst handoff never happens because the AR analyst is still tagging Day 1 auto-match items. The Day 4 platform-settlement split gets skipped because the aggregator dashboard is closed for the closed month. The exception queue does not get categorised because the analyst runs out of hours before the categorisation exercise begins. What lands on the TDS window on Day 6 is not a clean bank reconciliation; it is a partial reconciliation that the tax analyst has to fix before the TDS reconciliation can begin.

The fix is not more hours. The fix is a five-day sequence with an ownership map, a Day 0 preconditions gate, and a five-bucket exception queue that lets Day 5 close on categorisation rather than on resolution. Nothing in this article is new discipline — every enterprise finance team has run some version of it — but publishing it as a sequence turns it from a set of habits into a process the calendar can hold.

Day 0 — the pre-close checklist

Day 0 is the last working day of the closed month. Before the AR analyst can run Day 1 auto-match, the following must be true.

• Bank statements downloaded. MT940 or CSV extracts from every active current account dated to the last calendar day of the closed month. The MT940 format article documents the SWIFT standard structure and the field-level parsing rules. Column names and narration structures vary across banks — HDFC net-banking exports, ICICI corporate banking exports, SBI CINB, Axis, Kotak, and Yes each carry different column orders and truncation conventions. Public-sector banks may require branch collection if the corporate net-banking dashboard is behind an approval workflow. Across the five major private-sector banks and the leading PSU relationships, the bank statement narration patterns library documents more than three hundred column-name and narration variants, which is why the parser recipe in the bank narration parsing workbook covers a matched set of six narration structures — NEFT, RTGS, IMPS, UPI, NACH, and cheque.
• ERP AR and AP snapshots. Trial balance, receivables ageing, payables ageing, and the customer master with PAN, GSTIN, and TDS section or payment code. All extracts dated Day 0 and timestamped.
• Prior-month sign-off filed. The previous cycle’s finance-manager sign-off is filed in the monthly folder and any exception carried forward has a named owner and an age.
• Forex rate table. For enterprises with EEFC accounts in USD, EUR, GBP, or AED, the closing spot rate on Day 0 for every foreign currency is pulled from the bank’s card rate feed and filed for the Ind AS 21 reconciliation on Day 1.
• Platform dashboards accessible. The AR analyst confirms login credentials work on every merchant dashboard — Razorpay, PayU, Cashfree, Amazon Seller Central, Flipkart Seller Hub, Zomato Partner, Swiggy Partner, and any others active in the closed month. Locked-out credentials on Day 4 kill the platform-settlement window.

Day 0 takes half a day for a mid-market enterprise with three current accounts and one GSTIN. It takes a full day for a multi-GSTIN group with fifteen accounts across four banks and four platforms.

The owner map for the window

Four named roles run the window.

• The AR analyst owns the debits. Customer receipts, TDS-net splits, platform settlements, unidentified credits, aggregation queue. Runs Day 1 through Day 4 and produces the debits side of the Day 5 exception queue.
• The AP analyst owns the credits. Vendor payments, bank charges, GST on charges, NACH bounce reversals, forex conversion charges. Runs Day 1 through Day 4 in parallel with the AR analyst and produces the credits side of the Day 5 exception queue. The bank charges reconciliation article covers the AP analyst’s charge-side working paper structure.
• The tax analyst joins on Day 3. Handoff from the AR analyst for TDS-net customer receipts — every credit that arrives net of Section 393 code 1031 (Section 194Q on purchase of goods above Rs 50 lakh at 0.1 per cent) or code 1011 (Section 194O on e-commerce operator payments at 1 per cent) is tagged for pre-population of the TDS receivable ledger. This is the handoff that opens the TDS reconciliation runbook on Day 6.
• The finance manager reviews and signs off. Independent review on Day 5 covering the exception queue categorisation; sign-off releases the TDS window. Where the exception queue carries any item above Rs 10 lakh or any item aged above 60 days, the finance manager escalates to the controller for a co-sign.

The reason a co-sign is needed above Rs 10 lakh or 60 days is straightforward — an unidentified credit above Rs 10 lakh may signal a customer payment against an invoice that was never issued or, worse, a mis-directed wire from a payer the recipient does not know. Either case has audit implications. An exception item aged above 60 days that has not been resolved by Tier 1 or Tier 2 escalation almost always has a structural cause — a broken counterparty relationship, a lost invoice, a systemic ERP tagging error — that needs controller-level intervention.

Day 1 — auto-match against ERP AR and AP

Day 1 is auto-match day. The AR analyst loads the MT940 or CSV extract into the reconciliation tool or working sheet and matches auto-cleared items — standing instructions, salary NACH, EMI collections, direct customer transfers with a clean sixteen-character NEFT UTR reference. The exact match criteria are three-factor: UTR present in the narration, amount identical to the paise, counterparty name or reference matchable to a specific ERP AR entry. Any two out of three is not a Day 1 match; it is a Day 2 aggregation candidate.

The AP analyst runs the credits side in parallel. Vendor payments cleared through NACH batches with the batch reference number, RTGS wires above Rs 2 lakh with the RTGS UTR, cheques cleared with the cheque number matched to the payment voucher, and standing debits for utility payments with the biller reference. Bank charges — netbanking transaction fees, cash-deposit charges, wire-transfer commissions, foreign-currency conversion mark-ups — are booked to the expense line, and the GST on charges (typically 18 per cent) is booked to input tax credit for the Day 11 to Day 15 GSTR-2B match.

Expect roughly 60 to 75 per cent of the closed month’s credits and 70 to 80 per cent of the debits to clear on Day 1 for a well-mastered ERP with disciplined counterparty tagging. A team below 50 per cent is either mis-extracting the bank statement (wrong date range, missing accounts) or has an ERP master that carries stale counterparty aliases the auto-match cannot resolve.

Day 1 closes with a completeness check. The bank statement total credits and total debits are reconciled to the sum of matched items plus the count of unmatched items waiting for Day 2 processing. Any gap in the totals is a bug in the working paper and must be resolved before Day 2 begins.

Day 2 — multi-invoice aggregation with remittance advice

Day 2 handles the credits that landed against multiple invoices in a single wire. A corporate customer settles four invoices for Rs 3,42,000 with a single NEFT wire — Rs 1,10,000 plus Rs 68,000 plus Rs 92,000 plus Rs 72,000 — and the bank credit carries no per-invoice split. The AR analyst pulls the remittance advice from one of three sources: an email attachment from the customer’s AP team, a downloaded remittance file from the customer’s supplier portal, or a phone-and-email chase to the customer’s payables desk. Once the advice is in hand, the AR analyst splits the credit across the four invoice tags in the ERP and confirms the split totals reconcile to the paise.

Aggregation is the most common source of Day 2 friction because remittance advice is not universal in Indian B2B — corporates on SAP, Oracle, or Tally with a mature AP function reliably send it; MSME buyers, cooperatives, and government departments may not. Where the advice does not arrive within Day 2, the AR analyst flags the credit as “aggregation pending” and enters it in Bucket A of the exception queue with the customer name, the wire amount, the wire date, and the escalation date (Tier 1 at 30 days). The AR analyst chases the customer through the finance manager’s contact channel rather than through the sales team, because a sales-mediated chase adds a hop that slows resolution.

A special aggregation case is the customer whose ERP posts multiple invoices for a single delivery event — a manufacturer invoicing separately for goods, freight, and insurance on the same shipment — and settles all three on a single wire. Where the invoicing pattern is stable, the ERP customer master carries a note that flags the customer for consistent aggregation and the AR analyst applies the standing split rule.

Day 3 — TDS-net customer receipts and the tax-analyst handoff

Day 3 is the handoff day. The tax analyst joins the reconciliation and works with the AR analyst through every credit that arrived net of TDS. Two payment-code buckets dominate the Indian B2B pattern.

• Code 1031 — Section 194Q, 0.1 per cent above Rs 50 lakh. A buyer whose turnover in the immediately preceding financial year exceeded Rs 10 crore, purchasing goods from a resident seller against an aggregate purchase value above Rs 50 lakh in the current financial year, deducts 0.1 per cent TDS at the time of credit or payment. The credit arriving in the seller’s bank account is net of the deduction. A Rs 62 lakh gross invoice settled by a Section 194Q deductor produces a Rs 62,000 TDS deduction and a Rs 61,38,000 bank credit. The tax analyst tags the credit against the invoice, pre-populates the TDS receivable ledger with the Rs 62,000 expected credit, and files the deductor’s PAN and the payment code (1031 for FY 2026-27 onward, legacy Section 194Q code for FY 2025-26 residuals) for the Form 168 quarterly match.
• Code 1011 — Section 194O, 1 per cent e-commerce operator. Payouts from Amazon, Flipkart, Meesho, or any other e-commerce operator arrive net of the 1 per cent Section 194O TDS and the applicable platform commission. The Day 4 platform-settlement window will split the commission and GST components; Day 3 pre-populates the TDS receivable ledger with the Section 194O deduction so the tax analyst does not have to re-work the settlement on Day 4 from scratch.

Two other patterns surface less frequently but must be handled. Section 194C on payment for works contracts and Section 194J on payment for professional or technical services both produce TDS-net credits for the recipient enterprise where the recipient is a specified assessee — a contractor’s or a consultant’s bank credit arriving from a corporate paying customer will carry the Section 194C or Section 194J deduction. The tax analyst tags these against the invoice and pre-populates the receivable at the applicable rate (2 per cent under Section 194C, code 1002; 10 per cent under Section 194J, code 1005). The payment code 1001-1092 article covers the full FY 2026-27 mapping.

The handoff structure matters. The tax analyst is the one who owns the TDS receivable ledger for the Day 6 to Day 10 window; the AR analyst is the one who owns the bank credit tagging on Day 3. The handoff cannot be a one-way document dump — the tax analyst reviews the tagged credits with the AR analyst on Day 3 and flags any credit whose deduction pattern does not match the expected payment code for the counterparty. A Section 194C-registered contractor whose customer sends a credit with a Section 194J-shaped deduction is a tag error that needs correction on Day 3 before it enters the TDS ledger.

Day 4 — platform settlements from aggregator payouts

Day 4 is platform-settlement day. Every payment gateway (Razorpay, PayU, Cashfree, BillDesk, Instamojo), every e-commerce operator (Amazon, Flipkart, Meesho, Ajio, Myntra), and every marketplace aggregator (Zomato, Swiggy, Magicpin, Dunzo, MakeMyTrip, Goibibo, Booking.com) posts a net settlement to the current account after deducting a stack of components — merchant discount rate commission, GST on commission at 18 per cent, refunds and chargebacks initiated in the settlement window, TDS under Section 194O for e-commerce flows, and any platform-specific fees.

The AR analyst opens the settlement file from the platform’s merchant dashboard, splits the gross transaction total into the component parts, and reconciles the net figure to the bank credit. A worked example — a Razorpay settlement of Rs 8,17,120 for the closed week against a gross transaction total of Rs 8,50,000 splits as gross Rs 8,50,000, minus MDR commission at 2 per cent Rs 17,000, minus GST on commission at 18 per cent Rs 3,060, minus refunds Rs 12,820, giving net Rs 8,17,120. The MDR commission is booked to expense (payment gateway charges); the GST on commission is booked to input tax credit; the refunds are booked against the underlying customer receivables. Every line ties to the settlement file, and the settlement file is filed in the monthly folder as the working paper backing the credit.

Retention money is a variant to watch. Payment gateway operators typically hold back 5 to 10 per cent of the transaction value against future chargebacks for a defined rolling window (30 to 90 days depending on merchant category and risk tier), and the reconciliation must recognise that the day-of-settlement bank credit will not match the day-of-transaction gross. The retention balance is tracked in a separate ledger — Payment Gateway Retention Receivable — and released when the retention window expires and the gateway remits the held-back component.

Aggregator platforms carry an additional Section 194O layer. A Zomato or Swiggy payout to a restaurant partner is TDS-net at 1 per cent under Section 194O code 1011, and the platform commission (typically 18 to 25 per cent of the order value plus GST on commission at 18 per cent) is a separate stack. A Rs 1,00,000 gross order value from Zomato in the closed week for a restaurant that opted for the Zomato Gold programme with 18 per cent commission splits as gross Rs 1,00,000, minus commission Rs 18,000, minus GST on commission Rs 3,240, minus Section 194O TDS at 1 per cent Rs 1,000 (deducted on the gross of Rs 1,00,000), minus refunds and packaging charges, giving a net payout of roughly Rs 77,760 depending on the exact refund and charge stack.

Above four aggregator platforms in the closed month — a restaurant chain running Zomato plus Swiggy plus Magicpin plus Dunzo, or a marketplace seller running Amazon plus Flipkart plus Ajio plus Myntra — the Day 4 window fragments. Each platform’s settlement file has its own format, its own commission structure, its own TCS or TDS treatment, and its own settlement cadence (daily, weekly, or fortnightly), and the AR analyst cannot hold the reconciliation inside a single day. This is the threshold where the platform-settlement audit needs to move from the analyst’s spreadsheet to a continuously refreshed system.

Day 5 — exception categorisation and finance-manager sign-off

Day 5 closes the window. The AR analyst and the AP analyst together categorise every unreconciled item at the end of Day 4 into one of five mutually exclusive buckets. Every item lands in exactly one bucket and every bucket has an owner, an age, and an escalation rule.

Bucket A — Aggregation pending

The credit is a lump-sum against multiple invoices and the remittance advice has not arrived within Day 2. Owner: AR analyst. Escalation trigger: Tier 1 at 30 days (standard follow-up to customer’s AP head), Tier 2 at 60 days (finance manager escalation to customer’s finance controller), Tier 3 at 90 days (controller writeoff proposal or reversal). The Bucket A count is typically 3 to 8 items per month for a mid-market enterprise with 200 to 500 active customers.

Bucket B — TDS-net awaiting Form 168 confirmation

The credit has been tagged as TDS-net on Day 3 and the receivable has been pre-populated, but the deductor has not yet posted the challan and the credit has not yet appeared in the recipient’s Form 168 (successor to Form 26AS from April 2026 onward, per the Form 168 explainer). Owner: tax analyst. Escalation trigger: the quarterly Form 168 posting cycle. Anything open beyond one quarter without a matching Form 168 posting is escalated in the TDS window’s own escalation ladder.

Bucket C — Unidentified credit

A credit has landed with no clean UTR reference, no counterparty match in the ERP, and no remittance advice. Owner: AR analyst. Escalation trigger: Tier 1 at 30 days (bank-side chase for the counterparty behind a truncated UTR narration, sales-side check for any customer confirmation), Tier 2 at 60 days (finance manager authorises a suspense account posting to keep the bank reconciliation from carrying open indefinitely), Tier 3 at 90 days (controller writeoff proposal or provision entry). The Bucket C count is typically 2 to 5 items per month; a team consistently above 10 is either mis-parsing the narration or has a stale counterparty master.

Bucket D — Disputed debit

A bank charge, GST on charge, forex conversion mark-up, or NACH bounce reversal is being contested with the bank. Owner: AP analyst. Escalation trigger: Tier 1 at 30 days (formal dispute filed with the bank’s corporate relationship manager), Tier 2 at 60 days (finance manager escalates to the bank’s regional head), Tier 3 at 90 days (controller either concedes and books to expense or escalates to the bank’s ombudsman).

Bucket E — Timing difference

The bank date and the ERP posting date fall on opposite sides of the closed month. A cheque deposited on the 30th and cleared on the 2nd, a NACH batch initiated on the 31st and settled on the 1st, a customer wire sent on the 30th and credited on the 2nd. These are pure cutoff items and self-resolve in the next cycle. Owner: AR or AP analyst as applicable. No escalation clock — the timing difference is closed automatically when the corresponding entry lands in the next month.

The finance manager reviews the categorisation on Day 5 afternoon, samples the bucket-population working papers, and signs off the bank reconciliation. Where the exception queue carries any item above Rs 10 lakh or any item aged above 60 days, the finance manager co-signs with the controller. The sign-off releases the TDS window to open on Day 6 and closes the CARO 2020 evidence base for the monthly bank statement.

The escalation ladder in one place

Every exception in every bucket runs on a calendar clock, not on a reconciliation-cycle clock. An item that enters the queue on the 5th of April escalates on the 5th of May, the 5th of June, and the 5th of July regardless of which monthly cycle is running.

• Tier 1 — 30 days after the bank date. Standard follow-up letter or portal-side action goes out under the owning analyst’s name. Working paper updated with the escalation date.
• Tier 2 — 60 days after the bank date. Escalated to the finance manager. Second follow-up letter to the counterparty’s key contact — the customer’s finance controller for AR items, the bank’s regional head for AP items, the platform’s merchant support head for settlement items.
• Tier 3 — 90 days after the bank date. Escalated to the controller. Writeoff proposal, provision entry, or suspense account posting depending on the bucket. For Bucket B (TDS-net awaiting Form 168) the escalation runs on the quarterly Form 168 cycle rather than a fixed 90-day counter, because the deductor’s own filing calendar is what governs when the credit will appear.

The escalation dates are what the controller’s inbox on the 5th of each month carries — every Tier 1, Tier 2, and Tier 3 escalation across every bucket, in age order. This is the single control that most reliably prevents unidentified credits from sitting silent for six months and surfacing during the CARO 2020 statutory audit sample with no supporting working paper.

Where this connects to the failure mode design layer

Every bucket in this runbook is a Detection control against a specific failure mode documented in the invoice-to-bank reconciliation failure modes article. The design layer identifies each failure mode, rates it on Severity, Occurrence, and Detection, and specifies the controls needed to bring the aggregate action-priority down to acceptable. This runbook is the operational execution of those controls at monthly cadence.

Two examples make the pairing explicit. The failure mode “TDS-net credit tagged against the wrong invoice, distorting downstream Form 168 match” is scored at Severity 7, Occurrence 6 for a team without a Day 3 handoff and Occurrence 2 for a team with the handoff. Day 3 of this runbook is the control that drops the Occurrence score. The failure mode “aggregation credit posted to a single invoice, leaving three invoices open in receivables” is scored at Severity 6, Occurrence 5 without a remittance-advice discipline and Occurrence 2 with it. Day 2 of this runbook, with Bucket A as the escalation queue, is the control.

The runbook exceptions feed back into the design register. Any bucket that consistently produces more items than the design predicted — a Bucket C count consistently above 10 per month when the design predicted 5 — triggers a re-scoring on Detection in the design register and a review of the underlying control. This is the loop that keeps the operational cadence and the design layer connected.

When the manual runbook outgrows itself

The Day 1 to Day 5 cadence works for an enterprise finance team with three to five active current accounts on two banks, one or two aggregator platforms, one or two payment gateways, and an ERP master that is under active maintenance. Three thresholds break the cadence.

• Current-account count above fifteen across four banks. The Day 0 statement pull alone consumes half a day and the Day 1 auto-match slides into Day 2. Above twenty accounts, the AP-side charge reconciliation cannot be run inside a single day, and the AR-side aggregation and TDS-net tagging compete for analyst hours. The runbook still works as a training document; the continuous detection layer needs a system.
• Aggregator platform count above four. One or two platforms are absorbable in the Day 4 window; four or more restaurant-delivery platforms or four or more marketplace platforms each carry their own settlement cadence and their own commission-plus-GST-plus-TDS-plus-refund stack that fragments the reconciliation surface. The Day 4 window bleeds into Day 5 and the finance-manager sign-off compresses.
• Foreign-currency turnover above USD 10 million per year. A purely domestic-INR bank window closes in five days. An exporter running EEFC accounts in three or four foreign currencies with weekly foreign inward remittances, Ind AS 21 spot-rate reconciliations against the invoice-date rate for every remittance, and the associated exchange gain-or-loss booking stretches the window into six or seven days. Above USD 50 million, the forex reconciliation needs its own workflow and cannot be run as an appendix to the Day 1 auto-match.

Above these thresholds, the runbook remains valuable as a training discipline and a review sign-off structure, but the continuous detection layer — the exception queue with calendar-clocked escalation, the platform-settlement audit per aggregator, the forex reconciliation at Ind AS 21 spot rates — needs to move from the analyst’s spreadsheet to a system that runs on a daily rather than monthly cadence. This is the point at which Terra Insight’s reconciliation software installs the exception queue as a first-class continuously-refreshed output, the platform-settlement audit as a per-aggregator standing reconciliation, and the forex reconciliation as an Ind AS 21 rate-lookup service, and the manual runbook keeps its role as the discipline the system runs against rather than the process the finance team runs by hand.

Where this fits

• The Reconciliation Playbook — monthly close pillar
• Invoice-to-bank reconciliation failure modes — the design layer
• Bank narration parsing in Excel — the recipe workbook
• TDS reconciliation runbook — the window the Day 3 handoff opens
• HDFC bank reconciliation
• ICICI bank reconciliation
• Bank statement narration patterns

Related reading

• MT940 bank statement format
• Bank charges reconciliation
• CARO 2020 bank reconciliation audit
• Form 168 — the new TDS statement
• TDS payment codes 1001 to 1092
• Reconciliation software for India — pillar
• GST reconciliation software
• TDS reconciliation software

Frequently Asked Questions

Why is bank reconciliation the first window in the twenty-day cadence?

Because the downstream dependency graph runs bank to TDS to GST, and it runs one way. A missed bank credit that later turns out to be a TDS-net customer payment forces a re-run of TDS receivable ageing in the Day 6 to Day 10 window. A missed platform settlement that carries e-commerce commission and Section 393 code 1011 TDS forces a re-run of both the TDS receivable and the GST output register. A missed bank charge that carries GST at 18 per cent forces a re-run of the ITC claim in the Day 11 to Day 15 window. Every out-of-sequence discovery in the bank window costs a full day in a downstream window. Bank goes first because it is the source data for the two windows that follow, and the sign-off on Day 5 is what unlocks the TDS window.

What are the five exception buckets used at the Day 5 close?

Every unreconciled item at the end of Day 5 must land in exactly one of five buckets. Bucket A is aggregation pending — the credit is a lump-sum against multiple invoices and the remittance advice has not arrived. Bucket B is TDS-net awaiting Form 168 confirmation — the credit has been tagged as TDS-net on Day 3 but the deductor has not yet posted the challan. Bucket C is unidentified credit — a credit has landed with no clean UTR reference, no counterparty match in the ERP, and no remittance advice. Bucket D is disputed debit — a bank charge, GST on charge, forex conversion mark-up, or NACH bounce reversal being contested with the bank. Bucket E is timing difference — a genuine cutoff item where the bank date and the ERP posting date fall on opposite sides of the closed month. Every bucket has an owner, an age, and a documented escalation rule.

How do platform settlements from Razorpay, PayU, or Cashfree get reconciled on Day 4?

Each platform posts a net settlement to the current account after deducting merchant discount rate commission of roughly 2 per cent plus GST on commission at 18 per cent for a card or netbanking transaction and lower rates for UPI. The AR analyst opens the settlement file from the platform’s merchant dashboard, splits the gross transaction total minus the platform commission minus the GST on commission minus any refunds or chargebacks minus the TDS if the payment is from an e-commerce participant flow, to arrive at the net figure the bank credit shows. The commission and GST on commission are booked to expense and input tax credit respectively. Above four aggregator platforms the Day 4 window fragments and the manual runbook stops holding.

What is the escalation ladder for a Bucket C unidentified credit?

Tier 1 fires at 30 days from the bank credit date. The AR analyst sends the standard unidentified-credit follow-up to the bank asking for the counterparty details behind a NEFT or RTGS UTR whose narration was truncated, and to the sales team asking whether any customer confirmation has arrived. Tier 2 fires at 60 days and escalates to the finance manager, who authorises a suspense account posting so the bank reconciliation is not carried open indefinitely. Tier 3 fires at 90 days and escalates to the controller with a writeoff proposal or a provision entry. The clock runs on the calendar rather than on the reconciliation cycle — a credit that entered the queue on the 5th of April escalates on the 5th of May, the 5th of June, and the 5th of July regardless of which monthly cycle is running.

When does the Day 1 to Day 5 manual bank runbook outgrow itself?

Three thresholds. First, current-account count — above fifteen accounts across four or more banks, the Day 0 statement pull alone consumes half a day and the Day 1 auto-match slides into Day 2. Second, platform-settlement count — one or two aggregator platforms are absorbable in the Day 4 window; four or more restaurant-delivery platforms or marketplace platforms fragment the reconciliation surface and force the platform-settlement audit to run continuously rather than inside a single day. Third, foreign-currency turnover — a purely domestic-INR bank window closes in five days; an exporter running EEFC accounts in USD, EUR, GBP, and AED with weekly foreign inward remittances and Ind AS 21 spot-rate reconciliations against the invoice-date rate stretches the window into six or seven days. Above any of these thresholds, the runbook still works as a training document, but the continuous detection layer needs to move from the analyst’s spreadsheet to a system.

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published Invalid Date

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024