Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
The fifth family of reconciliation errors is not a data-quality problem. It is the reason reconciliation exists. Ten patterns where an entry that should be present is missing, or an entry that is present is in the wrong period, or an entry that should have been reversed is still standing. The most dangerous member of this family is the bounce pair unbooked — a credit received and returned on the same wire, netted to zero in the bank, still standing as cleared in the books. When this pattern occurs, the books certify money that has bounced; the finance team believes it holds cash that is not there; the writeoff happens at year-end when the debtor's account is finally reviewed.
Detection requires row-level narration inspection, not aggregate matching. Every bank row must be classified against the NACH return-code taxonomy — R01 insufficient funds, R06 account frozen, R09 account frozen due to notice, R58 account closed — and every books-side receipt must be paired against a return-file feed or a narration-inspected reversal row. Where the return file is unavailable, the detection layer must recognise the credit-and-return pattern in the bank narration itself. The cutoff straddle is caught by extending the bank match window three to five days into the next period and flagging any straddled entry. The late posting is caught by comparing the books entry date against the bank posting date and ageing the drift. The reversal-with-no-original and vendor-paid-twice cases are caught by cross-referencing bank debits against books entries by counterparty and amount within a rolling window.
The reconciliation platform must ingest bank statements with narration intact — not the truncated version many ERP integrations produce. The NACH return-code taxonomy must be configured against the current NPCI circular. The books side must expose the receipt or payment reference so a bank row can be paired to a specific voucher. Where a return-file feed is not available from the bank, the pattern-recognition layer must be trained on the bank's specific return-narration format — HDFC, ICICI, SBI, and PSU banks each format returns differently, and the training set must cover the customer's actual bank mix. The cutoff window must be configured — three days is standard, five days for banks with known posting delays. The cheque presentation window must be set to the RBI three-month directive.
Every missing entry surfaced as an exception with the counterparty, amount, and reason inferred from the bank row. Every mistimed entry surfaced as a period-drift exception with both dates and the arithmetic impact. Every bounce-pair unbooked surfaced as a top-severity exception blocking the AR sign-off until the receipt reversal is posted. Every cheque outstanding beyond its three-month validity window flagged for writeback or reissue. Every vendor debited twice flagged for recovery. The reconciliation working paper carries a class label for each exception — catch, catch-conditional, structural-miss — mapped to the Detection Envelope report the customer received before go-live.
Reviewed by Navin Krishnan, Founder, Terra Insight.
The other four families in the 57-error catalogue describe how data goes wrong on its way to the reconciliation. A transposed digit at 9pm, a wrong belief consistently applied, an export configured wrong years ago, a fortnight silently missing from the file. This family is different. This family is what reconciliation exists to find. Ten patterns where an entry that should be there is missing, an entry that is there is in the wrong period, or an entry that should have been reversed is still standing. And inside this family sits the single most dangerous pattern in the entire catalogue — a bounce pair that never got booked, where the bank statement nets to zero and the books certify money that has already bounced.
The family in one paragraph
The quarry. These are not data-quality problems — finding these is what reconciliation is FOR. A payment recorded twice, an entry posted to the wrong month, a receipt that bounced but was never reversed, a cheque issued that never presented, a deposit booked that never cleared. In the other four families the reconciliation platform is fighting the data. In this family the reconciliation platform is doing the job. Every error in this list is a real economic event the books have failed to capture correctly, and every one of them costs money if it is missed.
Why this family is different from the other four
The other four families are pre-conditions. A messy invoice number, an inverted debit-credit convention, a stale opening balance, an absent bank account. In each of those cases the underlying economic reality was fine — someone typed something wrong, or believed something wrong, or configured a system wrong, or forgot to send a file. Fixing the input fixes the reconciliation.
This family is not a pre-condition. This family is the reality itself. A vendor was paid twice. A customer’s cheque bounced. Two invoices exist for one payment. A March receipt landed in the bank in April. The reconciliation platform’s job is not to tolerate these — it is to surface them. Every one of them, with the rupees attached, in the right window, to the right owner.
And this is why this family is where the credibility of a reconciliation platform is actually tested. Anybody can match clean data. The product exists to find these patterns. Silently absorbing one, or worse letting one improve the match rate, is an automatic failure. The 57-error test catalogue Terra Insight runs against every release exists to prevent that failure from getting past release. Every test in the catalogue manufactures a specific error deliberately into realistic Indian financial data with a pre-computed expected outcome; the test only passes when the platform surfaces the error as the right exception with the right rupees. This family carries the highest weight in that test set because the cost of a miss here is measured directly in cash.
The ten errors, one at a time
1. Money in the bank, not in the books — unrecorded credit
What it looks like in the data. A credit on the bank statement with no matching entry in the AR ledger or GL. Narration typically references a UTR or a customer name; the customer has not yet been onboarded, or the receipt did not fire the AR posting rule, or the customer sent the money without a remittance advice.
Illustrative Indian regulatory context. A Rs 34,80,000 NEFT credit lands from a new customer on 15th of the month. The customer’s PAN and GSTIN have not been added to the master, so the AR module has no rule to match the incoming reference. The credit sits in the suspense account. If the credit is customer money against six unbilled invoices under Section 194Q’s Rs 50 lakh threshold, the counterparty is expected to deduct TDS on subsequent payments — the receipt has to be recognised, the invoices raised, and the TDS receivable set up before the next cycle. See the multi-invoice aggregation pattern for the specific books-side treatment.
The failure. Revenue understated. AR ageing wrong. TDS receivable never set up. The customer’s Form 168 credit, when it appears in the next quarterly cycle, has no receivable to match against.
2. Money in the books, not in the bank — unrecorded or unpaid obligation
What it looks like in the data. A payment posted in the AP ledger with no matching debit on the bank statement in the expected window. The voucher exists; the money never left.
Illustrative Indian regulatory context. An AP clerk posts a Rs 8,50,000 vendor payment on 28th March based on a payment approval, but the bank instruction is delayed or rejected at the utility layer. The books show the payment in March; the bank shows nothing. For an MSME vendor, the Section 43B(h) test operates on actual payment — the deduction is only allowed in the year the money moves. A books-only payment does not qualify. If the vendor is a micro enterprise and the 45-day window from the Section 15 MSMED Act count runs past the March 31 cutoff, the deduction is permanently deferred.
The failure. Books overstate cash outflow. AP ageing incorrect. Section 43B(h) test fails. The bank reconciliation carries a persistent “outstanding” entry that ages into a writeback question at year-end.
3. The cutoff straddle — books say March, bank says April
What it looks like in the data. A payment or receipt physically crossing the bank on 2nd or 3rd April, but recorded in the books on 30th or 31st March based on issue date or invoice date.
Illustrative Indian regulatory context. A cheque for Rs 12,00,000 to a supplier is drawn and posted in books on 29th March. The cheque physically clears at the bank on 3rd April. Both sides are correct within their own convention. The March-only bank reconciliation shows an unreconciled outstanding cheque; the April-only bank reconciliation shows a debit with no matching March-side voucher — until the reconciliation tool is told about the straddle. Under CARO 2020 Clause 3(ii)(b), the quarterly bank statement filed with the working-capital lender must agree with the books; a straddle that carries into the quarterly cut is a specific audit exception the working paper must document.
The failure. Working paper carries a mystery outstanding. Reviewer wastes time on it. In extreme cases the outstanding gets written back as a matching failure when the April clearing simply belonged to the next period.
4. The late posting — entry lands one period behind
What it looks like in the data. The bank shows the debit or credit on the actual transaction date; the books post the entry a week or more later, in the following reconciliation window.
Illustrative Indian regulatory context. A Rs 4,50,000 TDS challan is deposited via net banking on 5th April against the March deduction (statutory deadline 7th April). The tax executive posts the ERP TDS payable entry on 12th April after receiving the CIN. The April reconciliation window sees a Rs 4,50,000 books-side entry with a debit dated 5th April on the bank statement. The March reconciliation window, closed on 10th April, saw only the bank debit with no books entry — and if the reconciler treated it as unreconciled instead of pending-books-posting, the March close carried a false exception.
The failure. March working paper carries a phantom exception. April working paper has to explain the reconciliation of an out-of-period entry. The monthly close playbook’s Day 6 to 10 TDS window exists specifically to compress this posting drift.
5. A reversal with no original — the undo exists; the do doesn’t
What it looks like in the data. A credit note or reversal entry in the books with no corresponding original invoice or receipt in the current or a prior period.
Illustrative Indian regulatory context. A Rs 62,000 credit note is raised in July against invoice INV-2024-1147. The original invoice was raised in FY 2024-25, cancelled in April 2025, and then re-raised as INV-2025-0042 in April 2025 — but the July credit note references the old cancelled number. Under Section 34 CGST rules, a credit note has to be issued against a live invoice within the specified time window, and the mismatch here means the credit note fails GSTR-1 credit-note-reference validation and either bounces or wrongly reduces the wrong period’s supply.
The failure. GSTR-1 mismatch. Downstream ITC impact for the recipient. Ledger left with an orphaned negative that skews debtor ageing.
6. A bounce never reversed — bank shows the return; books still show the receipt
What it looks like in the data. A single NACH credit posted as a receipt in the books on Day 1, followed by an NACH return debit on the bank on Day 2 or 3 that never lands as a reversal entry in the books.
Illustrative Indian regulatory context. A Rs 2,15,000 NACH credit from a distributor lands on 8th of the month. The AR analyst posts the receipt, clearing the distributor’s ledger. On 10th of the month the credit is returned by the distributor’s bank under NACH code R01 — insufficient funds. The bank statement shows the return debit. The AR analyst is supposed to post a receipt reversal referencing the R01 code, restoring the debtor and updating the dunning workflow. If the return advice from the sponsor bank does not reach the analyst (email lost, feed unavailable, statement scan aggregated at line level rather than row level), the reversal never gets posted. The books show the distributor cleared; the bank net movement is zero.
The failure. Debtor incorrectly written off from ageing. Collections effort not restarted. When the Section 138 Negotiable Instruments Act window for legal action expires because nobody noticed the return, the legal remedy is gone.
7. A cheque issued, never presented — outstanding beyond its window
What it looks like in the data. A payment posted in the books against a specific cheque number, with no matching debit on any bank statement for more than three months after issue.
Illustrative Indian regulatory context. A Rs 1,85,000 cheque to a professional vendor is issued and booked on 3rd January. The vendor never presents it — the vendor closed operations, or lost the cheque, or forgot to bank it. By 3rd April the cheque is stale under the Reserve Bank of India three-month presentation directive. The books still show the payment as made. TDS under Section 393(1)(b) at 10 percent, if applicable, was already deducted and deposited on 7th February. The vendor’s bank credit never happened.
The failure. Books cash is understated. Vendor payable is understated. If the vendor eventually presents a stale cheque after the bank has posted a stop-payment window, the payment fails and both sides now need reconciliation to a new instrument. If the vendor is not chased and the amount is not restored, the cash sits misclassified indefinitely.
8. A deposit that never cleared — booked, but no credit arrived
What it looks like in the data. A cash or cheque deposit slip posted in the books, with no matching credit on the bank statement within the standard clearing window (three working days for local; ten working days for outstation cheques under the CTS system).
Illustrative Indian regulatory context. A branch cashier deposits Rs 3,20,000 in cash at a bank branch on 22nd of the month. The deposit slip is captured in the books. The bank credit never appears — the deposit was posted to the wrong account number, or held for a large-cash-deposit verification under the bank’s KYC review, or lost between counter and processor. The books show cash-in-bank up by Rs 3,20,000; the bank shows no such credit.
The failure. Bank balance overstated. Cash-in-bank reserved against payments that will bounce because the money is not there. CARO 2020 working paper carries the entry as unreconciled outstanding; auditor asks the question.
9. The bounce pair, unbooked — credit and return both in the bank (net zero); books certify money that bounced
THE SINGLE MOST DANGEROUS PATTERN IN THE CATALOGUE. This one gets its own section below. In short: the bank shows a credit and a return, netting to zero. The books show only the receipt. Aggregate reconciliation passes. The debtor sits cleared. The money is not there.
10. The vendor paid twice — two bank debits, one books entry
What it looks like in the data. Two identical or near-identical debits on the bank statement to the same vendor, with only one AP voucher recognising the payment. The vendor received one payment (which the books recognise), then received a second payment (which the books do not).
Illustrative Indian regulatory context. A Rs 5,40,000 vendor invoice from a contractor is paid on 8th of the month via RTGS. The invoice is approved a second time in the AP workflow because the first approval had a small error and was reset; the second approval fires a second RTGS. The books recognise one payment. The bank shows two debits of Rs 5,40,000 each. If the vendor is an MSME, Section 43B(h) is satisfied twice for one liability. If TDS at 2 percent under Section 393(1)(b) was deducted on both payments, there is now a Rs 10,800 excess deposit sitting with the government. The vendor may or may not tell you.
The failure. Cash outflow understated. AP is not carrying the credit balance that would let the finance team see the recovery opportunity. Working capital drained silently. When the vendor eventually surfaces the excess (or doesn’t), the recovery workflow starts months late.
The bounce-pair story
A mid-market finance team closes their April books. The controller reports a healthy AR position — the March outstanding was Rs 8.4 crore; the April collections came in strong; the AR aged more than 90 days dropped from Rs 1.6 crore to Rs 40 lakh. Cash flow forecast for May looks robust; the CFO signs off on a Rs 3 crore working capital drawdown to fund an inventory build.
The bank statement for April was fully reconciled. Books-side receipts totalled Rs 12.6 crore; bank-side credits totalled Rs 12.6 crore. The reconciler ran the tie-out; it passed. Sign-off went to the finance manager on Day 5 of the May close cycle.
What the reconciler did not do — what nobody in the process did, because the aggregate tie-out passed — was open every row of the April bank statement and inspect the narration on each. On row 47 of the April bank statement sits a Rs 1.2 crore NACH credit from Debtor Traders Pvt Ltd, posted on 12th April. On row 61 sits a Rs 1.2 crore NACH return debit against the same Debtor Traders Pvt Ltd, posted on 14th April. Return code: R09, account frozen due to notice. The bank’s net movement for Debtor Traders in April is zero. Debtor Traders’ invoice for Rs 1.2 crore, raised on 5th April, was closed by the AR analyst on 12th April when the credit landed. The reversal on 14th April was never posted to the books, because the return advice from the sponsor bank was sent to a shared distribution list that nobody actively monitored.
The books say Debtor Traders is cleared. The bank agrees, because credit-plus-return equals zero, matching the zero-current-balance the books now show for Debtor Traders. The AR ageing shows Debtor Traders at nil. The cash forecast that supported the Rs 3 crore working capital drawdown treats Rs 1.2 crore as cash in hand. It is not. Debtor Traders’ account is frozen and the money never landed.
The finance team learns of this on 3rd December. Debtor Traders’ relationship manager calls, apologising, saying the freeze was lifted three weeks ago and asking whether the company wants to restart the collection. The controller pulls up the ledger. Debtor Traders shows nil. The controller calls the AR analyst — the analyst has moved teams. The next analyst opens April’s bank statement, sees the R09 return, and turns pale. The Rs 1.2 crore has not been in the AR ledger for eight months. It was quietly written off as “cleared” the day the credit landed. The working capital drawdown funded inventory against cash that was not there. Interest cost on the drawdown for eight months is Rs 22 lakh. The debtor is now solvent again but the collections effort restarts from cold — no dunning happened in the interim, no legal notice, no negotiation.
Every practitioner has lived some version of this. The specific rupees change; the number of months to discovery changes; the counterparty changes. The pattern does not. The bank statement had both entries. The books had one. No aggregate reconciliation could catch it because the aggregates matched. That is why this article exists.
What a reconciliation platform does about this class
A reconciliation platform built for this family does not run aggregate tie-outs and call the reconciliation clean when the totals agree. It reconciles row by row. Every bank credit is paired against a specific books receipt with a reference key. Every bank debit is paired against a specific books payment. Every return-narration pattern in the bank statement is recognised against the NACH return-code taxonomy, and the return row triggers a pending-reversal exception that blocks AR sign-off until the books-side reversal is posted. The cutoff window is extended three to five days into the next period so straddled entries are visible on both sides. The cheque presentation clock ticks against the RBI three-month directive and any cheque past that window flags for writeback or reissue. Duplicate vendor payments — two bank debits within a rolling window against the same counterparty and amount, with only one books voucher — surface as a specific exception class. This is exactly the 12-class failure mode taxonomy the reconciliation process design method documents, run inside the Days 1 to 5 bank window of the 20-day monthly close playbook, with every exception carrying a class label that maps back to the customer’s Detection Envelope report.
The one that gets away
The bounce-pair pattern (error 9) is the single hardest error in this entire family to catch, and the reason is a mathematical fact rather than a product limitation. If the bank statement shows the credit and the return on the same wire as a pair, and if the books side received only the credit notification and never the return, then no cross-check between books and bank aggregates can detect the miss — the bank’s totals reconcile to the books’ totals if both sides include the credit and neither side includes the return. Aggregate reconciliation is structurally blind to this pattern.
Detection requires one of two data conditions to be present. First: row-level narration inspection with NACH return-code classification (not just aggregate matching). Every row of the bank statement is opened, the narration is parsed, and any row whose narration carries a return-code pattern (R01, R02, R03, R06, R09, R58 in the NPCI taxonomy) is flagged and paired against the corresponding credit row. If a matching books-side reversal is absent, an exception fires. Second: a companion NACH return-file feed from the sponsor bank, ingested by the reconciliation platform and pushed into the books side as a reversal-pending trigger. Either of these turns the pattern from a structural miss into a catch-conditional; without either, the pattern is invisible.
This is the honesty the 57-error catalogue is designed to force. An error consistent on both sides is invisible to any cross-check ever built. Silently absorbing an error, or worse letting an error improve the match rate, is an automatic failure of the test. The right response is not to claim the pattern is always caught — it is to document, per customer and per data shape, whether the conditions for catching it are present, and to tell the customer in writing before go-live. That is what the Detection Envelope is for.
Where this fits in the Detection Envelope
The Detection Envelope is a written per-customer report Terra Insight produces before go-live. It classifies each of the 57 error patterns against the customer’s specific data shape into one of three states — catch, catch-conditional, or structural-miss — with the specific data condition (or the specific reason the pattern cannot be caught) named for every classification. For this family in particular, the classifications turn on data conditions the customer’s environment either provides or does not provide: whether the bank statement carries full narration or truncated narration; whether a NACH return-file feed is available from the sponsor bank; whether the books side exposes a receipt reference the bank row can be paired against; whether the cutoff window is configurable to the customer’s bank posting behaviour. The report says exactly what data condition changes which classification, so the customer’s own IT or banking relationship team can decide whether upgrading a specific feed is worth the incremental catch it produces.
That written statement is the trust asset. Overclaiming the classifications — asserting that every pattern is always caught — would make Terra Insight the thing the product was built to kill. The anchor page for the 57 errors and the Detection Envelope walks through the mechanic, and the CA-facing one-pager is the trust artefact for the auditor who signs the working paper.
Where this fits
- TransactIG — reconciliation infrastructure
- Reconciliation software for India — pillar guide
- GST reconciliation software
- TDS reconciliation software
- Leakage Index 2026 — the sector-by-sector picture of what these errors cost
Related reading
- The 57 errors and the Detection Envelope — anchor page
- Family 1 — carelessness: 16 reconciliation errors
- Family 2 — knowledge gaps: 11 reconciliation errors
- Family 3 — misconfigured systems: 11 reconciliation errors
- Family 4 — data gaps in the reconciliation
- The reconciliation process design method
- The 20-day monthly close playbook
- CARO 2020 bank reconciliation audit
- HDFC bank reconciliation
- ICICI bank reconciliation
- Bank statement narration patterns
- MSME 45-day payment tracker
- ICFR internal financial controls and reconciliation
Frequently Asked Questions
The bounce-pair error scares me. Are you saying my bank reconciliation might be silently passing while a receipt bounced?
Yes, under two specific conditions. First, the bank statement includes both the credit and the return in the same reconciliation window, so the bank totals net to what the books totals show. Second, the books side never received the return notification — either the return advice from NACH did not flow to the AR analyst, or the analyst treated the return row as a duplicate of the credit row and suppressed it. Under those two conditions, an aggregate books-to-bank tie-out passes and the bounced receipt sits in the AR ledger as cleared. Detection requires row-level narration inspection with NACH return-code classification, or a companion return-file feed integrated into the books side. It cannot be caught by summing both sides and comparing totals.
Is this really the most dangerous error class? What about the wrong-GST-rate errors that break every invoice?
The wrong-GST-rate class is dangerous because it is consistent across many rows. This class is dangerous because the books side reports a healthy position — cash in hand, AR cleared, forecast on track — while the underlying reality is that the money is not there. The wrong-GST-rate class eventually shows up in a portal mismatch or a GSTR-2B recon. The bounce-pair class shows up in a writeoff at year-end, or in a cash-flow surprise, or in a debtor telling the CFO in December that they never actually paid the invoice the CFO thought had cleared in April. It is the class where the finance team finds out last. That is what makes it the most dangerous.
What is the actual accounting entry that goes wrong in the bounce-pair case?
The customer initiates a Rs 1.2 crore NACH credit on the 12th. The AR analyst posts a receipt on the 12th, clearing the debtor’s outstanding invoice. On the 14th, the customer’s bank returns the credit under R01 insufficient funds or R09 account frozen. The bank statement shows the credit on the 12th and the return on the 14th. The AR analyst is supposed to post a receipt reversal on the 14th, restoring the debtor’s outstanding. If the return advice does not reach the analyst — no email from the bank, no NACH return-file feed, no manual row-level bank statement scan — the reversal never gets posted. The books still show the debtor cleared. The bank net balance is unchanged (credit and debit cancel). No summary reconciliation catches it.
How does the cutoff straddle error differ from the late posting error? They sound similar.
The cutoff straddle is a period-assignment error. A cheque physically clears the bank on 2nd April but the books recognised the payment on 30th March based on cheque issue date. Both sides are correct within their own convention; the mismatch is in the period cut. The books show the payment in March; the bank shows it in April; a March-only bank reconciliation shows an unreconciled outstanding cheque. The late posting is a data-entry timing error. A payment was made on 12th March but the AP clerk did not post it in the AP ledger until 3rd April. Both sides now agree on the cash movement, but the books show a March accrual and an April payment where the bank shows a single March-12 debit. The reconciliation window that closes on 31st March cannot see the April posting, and the March close has an outstanding accrual that reappears with a matched debit only in the next window.
Does this article claim TransactIG catches every one of these ten errors?
No — and that is the whole point of the Detection Envelope. TransactIG is tested against all 57 patterns across the five families, every test manufacturing the error deliberately into realistic Indian financial data with a pre-computed expected outcome. The Detection Envelope report tells each customer, in writing before go-live, which of the patterns the platform catches for that customer’s specific data shape, which it catches only when a specific data condition is present (catch-conditional), and which no reconciliation platform can catch because the pattern is structurally invisible to any cross-check (structural miss). Publishing a general catch-list without the data-condition context would misrepresent what the product can promise. Every customer’s Detection Envelope is calibrated to their bank mix, their books format, and their return-file availability. See the anchor page for the full mechanic.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
- ▸ Section 138, Negotiable Instruments Act 1881 — Dishonour of cheque for insufficiency, etc., of funds in the account. Where any cheque drawn by a person on an account maintained by him with a banker for payment of any amount of money to another person from out of that account for the discharge, in whole or in part, of any debt or other liability, is returned by the bank unpaid, either because the amount of money standing to the credit of that account is insufficient to honour the cheque or that it exceeds the amount arranged to be paid from that account by an agreement made with that bank, such person shall be deemed to have committed an offence. This is the statutory anchor for what a bounce means in Indian finance — the criminal-liability regime that turns a bounce-pair error from an accounting event into a legal exposure if the books certified a receipt that never cleared.
- ▸ Section 43B(h), Income-tax Act 1961 (Finance Act 2023) — Any sum payable by the assessee to a micro or small enterprise beyond the time limit specified in Section 15 of the Micro, Small and Medium Enterprises Development Act 2006 shall be allowed as a deduction only in the year of actual payment. Where an MSME vendor is paid twice — one debit reversed after the year-end cutoff, one debit standing — the books entry and the actual payment position diverge, and the year-end 43B(h) test operates on the books entry rather than the net paid. A duplicate payment reversed in the following year produces a deduction the assessee has already lost the right to.
- ▸ Companies (Auditor's Report) Order 2020, Clause 3(ii)(b) — The auditor is required to report on whether during any point of time during the year the company has been sanctioned working capital limits in excess of five crore rupees, in aggregate, from banks or financial institutions on the basis of security of current assets, and whether the quarterly returns or statements filed by the company with such banks or financial institutions are in agreement with the books of account. A bounce-pair unbooked, a cheque outstanding beyond its validity window, or a receipt sitting in the books with no matching bank credit each break the quarterly-statement-to-books agreement CARO requires, and the auditor's evidence base is the bank reconciliation this family of errors is designed to catch.
- ▸ NPCI Procedural Guidelines for NACH — Return Codes — The National Automated Clearing House operating framework specifies the return-code taxonomy used across every sponsor and destination bank in India. R01 insufficient funds; R02 account closed at destination bank; R03 no such account; R06 account frozen; R09 account frozen due to notice from the government or court; R58 account closed. Each return code carries a specific remediation pathway. A bounce whose reason code is R58 requires vendor master update and receivable writeback; R01 requires resubmit or dunning; R06 or R09 requires legal review before any further collection attempt. The books-side entry that recognises the return must carry the code — a reversal that lands without it is a reconciliation event a compliance team cannot triage.
- ▸ Reserve Bank of India — Cheque Presentation Validity — Under RBI directions, a cheque is generally treated as stale after three months from the date on the instrument. A cheque issued and booked as a payment but never presented within that window becomes a stale instrument, and the books-side outstanding must be tracked against the presentation deadline. Every issued-not-presented cheque older than three months is an accounting entry the books still recognise as paid where the bank has never actually moved the money — this is Family 5, error 7, and it is the residual class the CARO 2020 quarterly working paper must reconcile before the auditor accepts the bank-book position.