Skip to main content
How-To · 14 min read

The Data Gaps Family: 9 Reconciliation Errors That Are Invisible Until the Arithmetic Forces Them Out

What is missing is invisible by definition. A bank statement with a hole in the middle, a fifth current account nobody uploaded, a March file mis-slotted as April — the data-gap family produces exceptions that a match-rate metric cannot see, because the arithmetic completes on the subset that was supplied. This is the honest walkthrough of nine such gaps, the Indian regulatory failure each one produces, and the single member of the family that no reconciliation on earth can catch alone.

Terra Insight
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 16 July 2026
Domain expertise
TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops
Knowledge Card
Problem

Nine specific reconciliation errors are invisible on the arithmetic alone because they attack the completeness of the supplied data, not the accuracy of what was supplied. A missing fortnight leaves the bank's stated opening and closing balances intact. An entire current account absent from the upload never enters the reconciliation window. A well-formed March statement dropped into the April slot ties on its own numbers. The hardest member of the family — the window-dressed truncation, where the tail is cut and the closing balance is restated to match — produces a file that is self-consistent and cannot be caught by any reconciliation against that file alone.

How It's Resolved

Treat completeness as a separate assertion from accuracy and design controls that fire outside the matching loop. A Day 0 checklist validates expected files against the account master before the sequence begins. Row-count and volume comparisons at file load flag zero-row headers and silent tail truncation against prior-period baselines. Companion sources — SA 505 bank confirmations, payment gateway settlement files, independent aggregator statements — cross-check what a single file cannot betray. Every gap that surfaces feeds back into the reconciliation process design register so the next cycle catches it earlier.

Configuration

A monthly-close Day 0 file expectation list bound to the ERP account and vendor masters. Row-count baselines for every recurring extract, with a percentage-drop threshold that flags a missing fortnight or a truncated purchase register. A required-file completeness gate that blocks the Day 5 bank window sign-off unless every active current account statement is loaded. Vendor register linkage so the MSME 45-day check fires against a validated MSME flag rather than a null default.

Output

A reconciliation cycle that refuses to certify a closing position when a required file is missing, an ITC match that reports its purchase-register row count alongside the GSTR-2B row count, a bank window sign-off that fails cleanly when the fifth current account never arrived, and an exception queue that flags a period whose transaction volume dropped without a business reason. The gap surfaces as an exception rather than as silence.

The family in one paragraph

What is missing is invisible by definition — unless the arithmetic is forced to account for it. This is the fourth of five error families in the reconciliation error catalogue, and it is the family that most tests the honesty of the tools that grade themselves on match-rate KPIs. A bank statement with a hole in the middle, an entire current account absent from the upload, a header-only file that clears validation, a well-formed March file dropped into the April slot — every member of this family produces a reconciliation that completes cleanly on the subset that was supplied. The numbers that were never in the file cannot argue for their own existence. The failure surfaces months later, in an auditor’s confirmation letter, in a Section 16(4) permanent loss on ITC, in an MSME payment that crossed day 45 because the register was never loaded. The pattern is the same each time: the arithmetic tied; something was missing.

Why this family is dangerous

Every match engine ever built is grounded in the same premise — take the entries on one side and reconcile them to the entries on the other side. A ledger row finds a bank credit; an invoice number finds a purchase register entry; a customer receipt aggregates against six invoices. The engine reports what matched and what did not. It is the strongest tool in the finance team’s kit for the errors it was built to catch — a typo the arithmetic betrays, a misconfiguration visible across every row, a bounce the bank shows and the books do not. It is the wrong tool for a class of errors whose defining property is that one side of the arithmetic never arrived.

The consequence is subtle. On a file with a missing fortnight, the reconciliation reports a match rate that is indistinguishable from a month where nothing was missing — because the entries that never entered the tool cannot be reported as unmatched. On a file with an entire bank account absent, the exception queue looks reasonable, because the reconciled accounts still reconciled and the absent account never produced exceptions to add to the queue. On a header-only purchase register, the ITC match reports “GSTR-2B has entries not in your purchase register” — a familiar exception category that a fatigued analyst reads as a supplier-timing issue rather than as evidence that the purchase register never arrived. The signal that would tell the analyst something is missing has to be engineered specifically. It is not a native property of the match.

This is why the family sits inside the reconciliation process design taxonomy as a distinct failure class — the data completeness class — with its own prevention controls (Day 0 file-expectation lists tied to master data), its own detection controls (row-count baselines, period-over-period volume comparisons, independent companion sources), and its own severity rating that is often the highest in the register because the errors compound silently for months before an auditor’s procedure exposes them.

The nine gaps, one at a time

1. A missing fortnight

What it looks like in the data. A bank statement dated 1-Mar to 31-Mar. Opening balance ₹28,42,15,000. Closing balance ₹31,71,80,000. Transactions listed cover 1-Mar to 14-Mar; the second fortnight is absent. The stated opening and closing are untouched; the arithmetic between them, if you sum only what is present, does not reconcile — but a fatigued analyst may treat the mid-month rows as a partial extract and continue.

Regulatory context. A mid-market enterprise pulling MT940 files from an HDFC current account hits a session timeout on 3-May while downloading the March statement. The re-triggered download resumes from where the previous run stopped rather than from the statement start, and the analyst saves the second file without noticing it is only the first fortnight. The closing balance carries through from the previous download’s session state.

Failure it produces. The bank reconciliation certifies a closing position the books cannot support. The CARO 2020 Clause 3(ii)(b) working paper is signed off with a hole. When the statutory auditor samples five late-March transactions under SA 500 audit evidence procedures, the response is “not found in reconciliation file” — and the audit expands.

2. An entire bank account absent

What it looks like in the data. The ERP account master lists five active current accounts. Four bank statements are loaded into the reconciliation window. The reconciliation completes on four accounts; nothing announces the fifth’s absence.

Regulatory context. A retail chain runs consumer card and UPI collections into an Axis Bank sweep account that funnels the daily net into the main HDFC operating account. AP owns HDFC, ICICI, SBI, and Kotak; the Axis sweep is “collections only” and never enters AP’s request list. Every daily sweep credit into HDFC is treated as an unreconciled inbound and lives in the exception queue as “aggregator settlement pending” for months.

Failure it produces. The Schedule III balance sheet note lists five bank accounts; the reconciliation working papers list four. The statutory auditor’s external confirmation under SA 505 surfaces the fifth account’s year-end balance and transaction volume. The reconciliation process is now a Section 143(3)(i) internal financial controls exception — the control did not operate effectively for a full fiscal year.

3. A sidecar covering half the period

What it looks like in the data. The TDS receivable ledger runs from 1-Mar to 31-Mar. The Form 26AS or Form 168 extract for the largest deductor covers 1-Mar to 15-Mar only. The reconciliation runs the full month’s receivables against the half-month reference.

Regulatory context. The quarterly TRACES pull ran on Day 6 of the 20-day cadence, but the deductor filed a corrective statement on 22-Mar that had not reflected in TRACES yet. The analyst saved the file as the March reference. Forty percent of the deductor’s March receipts show “no TDS credit found” — the tax executive writes to the deductor, the deductor points at TRACES, three weeks are lost before someone reruns the extract.

Failure it produces. Every day between the correct reference date and the discovery is a day the TDS receivable balance in the books is overstated relative to the deductor’s confirmation. Quarterly Form 168 reconciliation reports a mismatch that has no root cause in the deductor’s filing or the recipient’s books — it is a data-window mismatch. The confidence in the entire TDS receivable process degrades.

4. The books side missing entirely

What it looks like in the data. The bank statement is loaded, the format validates, the transactions parse. The GL ledger extract for the corresponding account is empty — a header row and no data.

Regulatory context. A cash-discount write-off account under other current assets, GL code 1345. The AR analyst posts discount write-offs monthly as a manual batch. This March, the batch was never posted. Five customer credits net of discount appear on the bank side; the books show zero corresponding entries.

Failure it produces. Five unmatched credits sit in the exception queue with no analytic to steer them. On a match-rate KPI the miss reads like a bank-side data problem — inbound receipts against an unknown remittance — rather than a books-side gap. The correct AR reversal never happens; the customer statement of account shows an open invoice that the customer has evidence they settled.

5. Random rows lost

What it looks like in the data. The purchase register export contains 1,847 rows. A parallel ERP query for the same period returns 1,942 rows. Ninety-five rows are missing from the export, scattered across dates and vendors with no obvious pattern.

Regulatory context. A SAP HANA query with a row cap that clipped silently after internal deduplication, or an export that ran on a filtered view excluding any invoice tagged “revision pending.” Ninety-five invoices happen to be in that state, from twelve suppliers. The GSTR-2B three-way match on Day 13 misses those ninety-five entirely; the tool reports “GSTR-2B has entries not in your purchase register” for those rows, and the at-risk queue expands.

Failure it produces. The Section 16(4) November 30 deadline runs on those invoices. Some are traced back to the ERP before the deadline; some are not. ITC on the untraced invoices is permanently lost. The magnitude depends on the deduction value of the lost invoices — for a mid-market industrial buyer with an average invoice IGST of ₹42,000, ninety-five lost invoices represents approximately ₹40,00,000 in permanent ITC leakage.

6. A header with zero rows

What it looks like in the data. An Excel or CSV file with the correct column headers — Invoice_No, Invoice_Date, Vendor_GSTIN, Taxable_Value, IGST, CGST, SGST — and no data rows. The file is well-formed; the schema validates; the tool accepts it.

Regulatory context. An ERP export where the “Financial Year” parameter defaulted to a blank value and the underlying query returned no rows. The report was still generated (a report with no rows is still a report) and saved to the input folder. The reconciliation module loaded the file, reported zero purchase register entries, and produced a three-way ITC match where 100 percent of GSTR-2B has “no matching purchase register entry.”

Failure it produces. The exception queue is not empty, but its composition is misleading. On Day 15 sign-off the controller asks how many purchase register entries were loaded; the answer of zero converts a supplier-filing-collapse hypothesis into a data-load failure. Two days are lost before the correct file is loaded and reconciled — days that eat into the buffer before the Day 20 GSTR-3B filing gate.

7. The wrong month in the slot

What it looks like in the data. A bank statement for HDFC dated 1-Mar to 31-Mar, saved with the filename HDFC_Apr2026.csv, and uploaded to the April reconciliation folder. Every entry looks legitimate — dates are consistent, amounts are real, the format is valid.

Regulatory context. Month-end pressure on 3-May. The analyst downloads statements for both March and April on the same day, saves March’s file under the April name by mistake, and moves on. The April reconciliation attempts to match April customer receipts to March invoices; the timing exceptions queue floods with “unusual delays” that no delay explanation actually fits.

Failure it produces. A week is spent chasing timing anomalies that are not timing anomalies. When the correct April statement is finally loaded, the April cycle restarts from Day 1; the March file was never wrong — it was in the wrong slot. Meanwhile the April GST filing on the 20th of the following month is under compressed schedule; the sequence-driven 20-day playbook collapses into a 12-day scramble.

8. A required register not uploaded

What it looks like in the data. The reconciliation module is enabled; the input folder for the module is empty. The module runs against a null input and produces zero exceptions — because there is nothing to compare against.

Regulatory context. The MSME 45-day payment tracker module is enabled. The AP master extract with MSME vendor flags is maintained in a separate Excel that the tax executive updates monthly and hands to AP. The tax executive is on leave during month-end; nobody hands anything to AP; the module runs against a null vendor list; every AP entry falls out as “not MSME” by default.

Failure it produces. No vendor is flagged for the 45-day check. Three MSME vendors cross day 45 without payment. Under Section 43B(h) of the Income-tax Act as amended by the Finance Act 2023, the disallowance is permanent for the year of non-payment. Discovery happens at year-end during tax audit sampling; the disallowance is added back to taxable income, and the effective tax cost is 25.17 percent to 34.94 percent of the unpaid MSME liability depending on the company’s tax bracket.

9. The window-dressed truncation

What it looks like in the data. A bank statement dated 1-Mar to 31-Mar. Opening balance ₹28,42,15,000. Transactions from 1-Mar to 20-Mar totalling to a running position of ₹31,71,80,000. Closing balance ₹31,71,80,000. The tail — 21-Mar to 31-Mar — is absent, and the closing balance has been restated to match the last transaction rather than the true statement position. The file is internally consistent. Opening plus transactions equals closing.

Regulatory context. This is not always malicious. A broken export in a banking system where the internal aggregation closed the balance to the last row it fetched rather than to the true statement position. A third-party bank data feed that reconstitutes statements from transaction webhooks, and the webhook feed stopped mid-month — the reconstituted “statement” ends where the feed ended, and the internal balance rolls with it. In every observed case the file is self-consistent because the source system did what source systems are asked to do: make the numbers tie.

Failure it produces. No reconciliation, no arithmetic check, no cross-check inside the file can detect this. The file ties. The books tie to a subset of what the bank actually holds. Discovery requires a companion source — a bank confirmation letter under SA 505 external confirmation procedure, a payment gateway settlement file whose settlement dates land in the missing tail, a period-over-period volume analysis flagging that March’s transaction count is 32 percent below February’s without a business reason. This is the hardest gap in the entire catalogue and it is the family’s honesty anchor: an error that produces a self-consistent file is invisible to any reconciliation against that file alone.

What a reconciliation platform does about this class

A reconciliation platform that takes the data-completeness assertion seriously ships controls that operate outside the matching loop. At load time, it captures the row count of every recurring extract and compares it against a rolling baseline of prior periods; a purchase register that drops 40 percent below the six-month median flags before the match runs. At sequence start, it binds the file-expectation list to the ERP account master and the vendor master; if the account master lists five active current accounts and only four statements are present at Day 0, the monthly close playbook refuses to open the Day 5 sign-off gate until the fifth statement is loaded or a written override is filed. At sequence close, it captures the ITC-match row counts on both sides — purchase register row count and GSTR-2B row count — into the sign-off working paper, so a zero-row purchase register cannot pass as “supplier-filing collapse.” Every exception that surfaces feeds back into the reconciliation process design register — the design layer that catalogues every way each function can fail, rates each failure on severity, occurrence, and detection, and specifies the control that catches it in the next cycle. Design informs the sequence; the sequence produces the data that refreshes the design.

The one that gets away

The window-dressed truncation is the crown jewel of the family’s honesty framing. When the tail of a statement is cut and the closing balance is restated to match the cut position, the file becomes self-consistent — opening plus transactions equals closing. This is a mathematical property, not an engineering one. No cross-check inside the file can betray what the file itself certifies. No signal-based reasoning against that file alone can find what is not there when the arithmetic ties.

The paths to detection all live outside the file. The classical audit procedure — SA 505 external confirmation — obtains the year-end balance and transaction totals directly from the bank on the auditor’s letterhead; if the confirmed year-end balance differs from the reconciled position, the truncation surfaces. A period-over-period transaction-volume analysis at load time flags a month whose transaction count is materially lower than prior months without a business reason; the analyst then investigates whether a decline in business activity or a truncated file explains the drop. A three-way tie — bank statement, payment gateway settlement file, and AR receipt ledger — catches a truncation whose missing tail includes any settled receivable, because the gateway file contains settlement records that the bank statement should show and does not.

None of these are properties a match engine possesses natively. They are process-design controls that must be engineered around the match, and the honest position — the position TransactIG takes and publishes — is that a class of gaps exists that no reconciliation on earth catches on the supplied file alone. Silently absorbing such an error, or worse letting the absence of contradicting evidence improve the match rate, is an automatic failure of the entire trust proposition. Which is why the next section exists.

Where this fits in the Detection Envelope

Every customer who deploys TransactIG receives a written per-customer report — the Detection Envelope — before go-live. The report walks the entire fifty-seven-error catalogue against the specific data shape the customer’s business produces. It classifies each error into one of three categories for that customer: caught deterministically by the reconciliation as configured; caught conditionally when a specific companion signal or upstream control is present; and structural-miss where the error is invisible on the supplied data alone and requires either an out-of-scope companion source or a process-design control outside the platform.

For a Family 4 gap like the window-dressed truncation, the Detection Envelope will name it as a structural miss on the supplied file alone and specify the companion controls that turn it into a catch — an SA 505 external confirmation at year-end, a period-over-period volume threshold at file load, a payment gateway cross-tie for periods where gateway settlements arrive. The report is signed by the implementation lead, filed alongside the working papers your statutory auditor will sample, and refreshed whenever the customer’s data shape changes. It is the trust artifact the buyer takes to the audit committee, and it is why the Detection Envelope is described on the top-level anchor page as the differentiated claim — not that TransactIG catches all fifty-seven, but that TransactIG tells you in writing which it catches, which it catches conditionally, and which no reconciliation on earth can catch.

The catalogue has four other families. Family 1 — Carelessness covers the sixteen month-end-at-9pm patterns that fatigue produces. Family 2 — Knowledge gaps covers the eleven consistent-wrong-belief patterns whose most dangerous member is invisible to any cross-check when the wrong belief is applied on both sides. Family 3 — Misconfigured systems covers the eleven never-updated-since-installation patterns. Family 5 — Missing and mistimed entries is the quarry — the ten patterns finding which is what reconciliation is FOR, and the anchor post for the whole catalogue. The full 57 in a single CA-facing reference is on the one-pager for accountants.

Terra Insight
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
Primary reference: Ministry of Corporate Affairs — CARO 2020 — Clause 3(ii)(b) of the Companies (Auditor's Report) Order 2020 requires the statutory auditor to report whether the quarterly returns or statements filed with lenders on the security of current assets agree with the books of account — the single strongest statutory anchor for bank-statement completeness that Family 4 gaps collide with..
Primary sources cited
Last reviewed against sources on 16 July 2026
  • 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 bank statement that arrives incomplete — a missing fortnight, a truncated tail, an entire account never supplied — breaks the evidence chain this clause depends on.
  • SA 505, Standard on Auditing — External Confirmations (ICAI) — The auditor shall design and perform external confirmation procedures to obtain relevant and reliable audit evidence. External confirmation from the bank on the year-end balance, transaction totals, and any facilities outstanding is the primary detection procedure for a statement whose tail has been truncated with the closing balance restated to match — the internally consistent file cannot betray the gap, but a direct confirmation from the bank can.
  • SA 500, Standard on Auditing — Audit Evidence (ICAI) — The auditor shall design and perform audit procedures that are appropriate in the circumstances for the purpose of obtaining sufficient appropriate audit evidence. Evidence about the completeness of a population is a distinct assertion from evidence about the accuracy of what was supplied — the family of errors covered in this article all attack the completeness assertion while leaving the accuracy assertion intact, which is exactly why a match-rate KPI does not surface them.
  • Section 16(4), Central Goods and Services Tax Act 2017 — Time limit for availing input tax credit. A registered person cannot claim ITC in respect of any invoice or debit note for supply of goods or services after the thirtieth day of November following the end of the financial year to which such invoice pertains, or furnishing of the relevant annual return, whichever is earlier. A purchase register that arrives with random rows lost or a header-only file that clears validation drops invoices out of the ITC match window; recovering them after the November cut-off is impossible.
  • Section 43B(h), Income-tax Act — MSME 45-day payment — 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 deduction only in the previous year in which such sum is actually paid. A required MSME vendor register that never arrives in the reconciliation window means no vendor is flagged for the 45-day check — the disallowance becomes permanent for the year of non-payment, and the discovery happens at year-end when the tax audit sampling exposes it.
  • Section 143(3)(i), Companies Act 2013 — Internal Financial Controls — The auditor's report shall state whether the company has adequate internal financial controls with reference to financial statements in place and the operating effectiveness of such controls. A reconciliation process that certifies a closing bank balance without having received every current account statement, or that certifies an ITC match against a purchase register with a silent row cap, is a control that is not operating effectively — the ICFR opinion is qualified even if no rupee has been mis-stated in the books.

Frequently Asked Questions

What makes gaps in the data harder to catch than typos or misconfigurations?
A typo produces an amount that does not match its counterpart; the arithmetic betrays it. A misconfiguration produces a systematic distortion visible across every row of the affected export. A gap produces neither. What is missing is invisible by definition — the reconciliation runs on the subset that was supplied, the match rate looks the way it always looks, and the numbers that were never in the file cannot argue for their own existence. The only structural counter is a completeness check that is independent of the reconciliation itself: a companion count, a period-over-period volume comparison, an inventory of expected files at Day 0 with a hard block if any expected file is missing when the sequence starts. Neither of those is a native property of a match engine; both have to be engineered into the process design.
How do we discover a missing bank statement if the reconciliation itself completes?
Two disciplines catch it. First, the [Day 0 pre-close checklist](/insights/reconciliation-playbook-monthly-close-india/) requires a downloaded MT940 or CSV extract from every active current account, dated to the last calendar day of the month, before the Days 1 to 5 bank window begins. If your ERP master says five current accounts and Day 0 lists four statements, the sequence stops. Second, at period-end the statutory audit procedure under SA 505 obtains an external confirmation directly from the bank on the year-end balance and facility position — this catches an entire account that never made it into the reconciliation cadence and it catches the tail-truncated statement whose file arithmetic tied. Neither discipline is a matching-engine feature; both are process-design controls that must fire before or after the match, not during it.
What is the relationship between the reconciliation process design register and the 20-day playbook when a data gap surfaces?
The [reconciliation process design](/insights/reconciliation-failure-mode-analysis-india/) register identifies every way a function can fail and assigns each failure a severity, occurrence, and detection rating with a documented prevention or detection control. Gaps in the data are a specific failure class in the taxonomy — the data completeness class — and the control that catches each one is documented in the register. The [20-day playbook](/insights/reconciliation-playbook-monthly-close-india/) is where the controls actually fire: the Day 0 checklist validates expected files against the account master, the Day 5 bank window sign-off gate closes only after every current account is reconciled, the Day 13 three-way ITC match logs the row count of the purchase register alongside the GSTR-2B row count. When a gap surfaces, the exception feeds back into the design register through the Friday failure review, and either the prevention (upstream fix) or the detection (a new completeness check) is strengthened for the next cycle. Design informs the sequence; the sequence produces the data that refreshes the design.
Can any reconciliation platform detect the window-dressed truncation on the file alone?
No. A file whose transactions have been cut and whose closing balance has been restated to match the cut position is internally consistent — opening plus transactions equals closing. No cross-check inside the file, no matching against the books, and no signal-based analysis of that file alone can find what is not there when the arithmetic ties. The detection paths that exist are all outside the file. A bank confirmation letter under [SA 505 external confirmation procedure](https://www.icai.org) surfaces the true year-end balance and transaction totals from the bank's own records. A period-over-period volume analysis flags a month whose transaction count is materially lower than prior months without a business reason. A three-way tie between the bank statement, an independent payment gateway settlement file, and the customer AR ageing can catch a truncation whose missing tail includes a settled receivable. These are process-design controls, not matching-engine features — which is why the honest position is that a class of gaps exists that no reconciliation on earth catches on the supplied file alone.
When does the Detection Envelope report get delivered and what does it look like?
The Detection Envelope is a written per-customer report delivered before go-live. It walks the entire 57-error catalogue against the specific data shape a customer's business produces — the bank formats, the ERP export cadence, the payment gateway feeds, the GSTIN structure, the MSME vendor register — and classifies each error into one of three categories: caught deterministically by the reconciliation as configured for this customer; caught conditionally when a specific companion signal or upstream control is in place; and structural-miss where the error is invisible on the supplied data alone and requires either an out-of-scope companion source or a process-design control outside the platform. The report is signed by the implementation lead, filed alongside the working papers your statutory auditor will sample, and refreshed whenever the customer's data shape changes. It is the trust artifact the buyer takes to the audit committee — not a marketing claim, a written statement.

See how TransactIG handles reconciliation for your industry

Configuration takes 2–4 weeks. No code development required. ISO 27001:2022 certified.