Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Reconciliation controls at Indian enterprises are designed as procedural checklists — run the report, tick the box, sign off. The controls do not identify the specific ways each function can fail, do not rank failures by severity, and cannot document why some failures were accepted while others were mitigated. Statutory auditors, ICFR reviewers, and CFOs cannot defend the process to a board or an audit committee without a documented failure analysis for every reconciliation function across every stream, including invoice-to-bank, TDS receivable versus Form 26AS transitioning to Form 168, GSTR-1 versus GSTR-3B output-side liability, and GSTR-2B input tax credit matching.
Apply Terra Insight's reconciliation process design method — a seven-step discipline running across three phases. Phase one decomposes each reconciliation function into work elements, function requirements, and expected outputs. Phase two enumerates the failure modes, effects, and causes for each function, rates every mode on an anchored Severity, Occurrence, and Detection scale, and prioritises using an Action Priority table where Severity dominates over Occurrence and Detection combined. Phase three documents prevention and detection controls, owners, and cadences in a living register. The 6P cause taxonomy — People, Policy, Process, Portal, Period, Partner — walks every function through the six categories manual reconciliation failure originates in. The 12-class failure mode taxonomy applies at the function level across data extraction, classification, completeness, matching logic, timing, partner behaviour, precision, policy interpretation, aging, cutoff, evidence, and portal drift.
One reconciliation process design worksheet per stream, covering the four core streams (invoice-to-bank, TDS receivable versus Form 26AS or Form 168, GSTR-1 versus GSTR-3B, and GSTR-2B input tax credit). Each row lists a function, the 6P cause category, the 12-class failure mode class, the Severity anchored to Indian statutory consequences (Section 16(4), Section 200A, Section 40(a)(ia), CARO 2020, DRC-01B, DRC-01C), Occurrence based on actual incidents in the prior four quarters, Detection based on the current control layer, the Action Priority (High/Medium/Low), the prevention control, the detection control, the owner, and the review cadence. Reviewed monthly by the controller and quarterly with the audit committee, and re-opened on any material process, portal, or rule change.
A living register of every High-Priority failure mode across all reconciliation streams, each mapped to a specific prevention control that reduces the likelihood of the failure occurring and a specific detection control that catches the failure before it reaches the counterparty, tax authority, or auditor, with a documented risk-acceptance rationale for any residual exposure. The register becomes the design documentation ICFR testing under Section 143(3)(i) verifies, feeds the statutory audit checklist for reconciliation, and defines the point at which manual detection has topped out and reconciliation infrastructure becomes the economically viable next layer for the finance team.
Most reconciliation controls at Indian enterprises are checklists. A checklist confirms that a task was done. It does not confirm that the task caught the failure it was designed to catch. The distinction is what separates a reconciliation process that a statutory auditor signs off from one that carries a material weakness finding under Section 143(3)(i) of the Companies Act 2013. This guide sets out Terra Insight’s reconciliation process design method — a seven-step discipline that installs failure analysis on top of the four reconciliation streams every Indian finance team runs: invoice-to-bank, TDS receivable against Form 26AS (transitioning to Form 168 from April 1, 2026), GSTR-1 versus GSTR-3B, and GSTR-2B input tax credit matching. The severity scale, occurrence scale, detection scale, cause taxonomy, and failure mode taxonomy in this framework are all anchored to Indian statutory consequences — Section 16(4) permanent ITC loss, Section 200A demand notices, DRC-01B and DRC-01C triggers, CARO 2020 reportable observations, and ICFR material weakness findings — rather than to abstractions borrowed from other domains.
Why reconciliation controls fail — they are checklists, not analyses
A typical mid-market Indian enterprise runs its month-end reconciliation with a spreadsheet, a Form 26AS download, a GSTR-2B extract, a bank statement, and a cadence discipline: bank reconciliation by day 5, TDS reconciliation by day 10, GST reconciliation by day 15, exception queue closed by day 20. Every one of these steps is documented as a task. None of them is documented as a failure mode.
The failure appears at year-end. The statutory auditor asks the controller to explain a ₹47 lakh input tax credit that was claimed in GSTR-3B but never appeared in GSTR-2B. The controller cannot say when the discrepancy first appeared, why the monthly reconciliation missed it, whether it was a supplier-side GSTR-1 delay or a book-side classification error, or what the process would do differently next time. The board hears about a ₹47 lakh permanent loss under Section 16(4) — the November 30 ITC time bar — and asks the CFO how it was possible.
The answer, almost always, is that the reconciliation process was defined as a task list rather than as an analysis of the ways each task can silently produce a wrong result. The task list would tell you the GSTR-2B was reconciled. The analysis would tell you the reconciliation function has fourteen distinct failure modes, that the missing-supplier-GSTR-1 mode has a Severity of 10 because Section 16(4) makes the loss permanent, and that the current detection control — an exception review that does not aggregate the at-risk invoices as they age toward November 30 — is inadequate for that severity.
Reconciliation process design exists to force that second conversation. It is the discipline of writing down every way a function can fail, ranking the failures by their true impact on the audit opinion and the statutory cash outflow, and confirming that a specific control catches each one. Adapted to Indian reconciliation, it produces a process that a controller can defend, an ICFR reviewer can test, and a board can trust.
The framework in seven steps
The framework organises failure analysis into seven steps across three phases.
- Phase 1 — System Analysis. (1) Planning and Preparation — scope, team, deliverables, cadence. (2) Structure Analysis — decompose the reconciliation process into a hierarchy of functions and work elements. (3) Function Analysis — write what each element does and the requirement it must meet.
- Phase 2 — Failure Analysis and Risk Mitigation. (4) Failure Analysis — for every function, enumerate the ways it can fail (Failure Mode), the impact on the customer, tax authority, or auditor (Failure Effect), and the root cause (Failure Cause). (5) Risk Analysis — rate each failure mode on Severity, Occurrence, and Detection, and prioritise using the Action Priority table. (6) Optimisation — assign prevention actions to reduce Occurrence, detection actions to reduce Detection, and design actions to reduce Severity.
- Phase 3 — Communication. (7) Results Documentation — a living record revisited on every process change and after every incident.
The design axiom that shapes step 5 is that Severity dominates the prioritisation. A Severity 9 or 10 failure mode is always High Priority regardless of how rare it is or how well the current controls detect it, because the consequence — a Section 16(4) permanent loss, a Section 200A demand notice, or a Section 40(a)(ia) expenditure disallowance — cannot be undone once it lands. A multiplicative score that averages Severity with Occurrence and Detection consistently under-prioritises the failure modes that carry the largest downside; it will hide a rare-but-catastrophic mode behind a common-but-cosmetic one because their scores can coincide. Severity-first prioritisation is the single most important idea to carry into finance.
Translating the vocabulary to a manual reconciliation process
The framework’s structural vocabulary — process step, work element, function requirement, failure mode, failure effect, failure cause, prevention control, detection control — must map cleanly to a finance team’s daily reconciliation vocabulary. The following equivalences do that.
| Framework term | Reconciliation Process Design equivalent |
|---|---|
| Process step | A single reconciliation function — for example, “match Form 26AS entries to the TDS receivable ledger by deductor PAN, section, and quarter” |
| Work element | The specific action the analyst performs (extract, filter, match, classify, escalate, sign off) |
| Function requirement | The output the function must produce (a matched ledger, an exception queue, a filing-ready register) |
| Failure mode | The way the function can produce a wrong or incomplete result |
| Failure effect | The consequence — Section 200A notice, DRC-01B trigger, permanent ITC loss, misstated books |
| Failure cause | Why the failure happens — analyst error, missing policy, portal timing, supplier default |
| Prevention control | A control that reduces the likelihood of the cause (templates, cutoffs, approval matrix, training) |
| Detection control | A control that catches the failure after it happens but before it reaches the counterparty, tax authority, or auditor (peer review, ratio analysis, exception aging queue, tick-and-tie) |
| Control Plan | The written reconciliation SOP plus the detection control register plus the exception escalation matrix |
The 6P cause taxonomy for manual reconciliation
Every failure mode traces back to at least one cause category. For manual reconciliation in India, the six cause categories that cover the field are Terra Insight’s 6P taxonomy — the branded framework that sits alongside the Seven Classes of Reconciliation Leakage as the second half of Terra Insight’s reconciliation methodology surface.
- People. Analyst error — skipped row, wrong period, misclassified section, missed sign, missed reversal, transposed digit, delegate not trained on cross-era rules.
- Policy. No written policy, or a written policy that does not cover the case — TDS on GST-inclusive amount, materiality thresholds not defined, treatment of retention money undocumented, foreign OTA commission RCM policy silent, treatment of blocked ITC under Section 17(5) not documented.
- Process. Missing cutoff discipline — bank statement pulled after cut-off, GSTR-2B pulled before the counterparty’s late filing, month-end close signed before the Section 393 challan is confirmed on the portal, exception queue reviewed by the same analyst who created it.
- Portal. Portal-side timing and drift — TRACES delay in updating Form 168 credits, GSTR-2B cut-off date changes, IMS action not taken before the auto-lock, NACH file received after the settlement is booked. Terra Insight’s cross-era TDS reconciliation guide documents several of these mechanics in detail.
- Period. Cross-era or period-boundary confusion — a receivable in FY 2025-26 settling under a Section 393 payment code in FY 2026-27; a March 31 challan that appears on TRACES in Q1 of the next year; a supplier’s GSTR-1 for March filed in September crossing the Section 16(4) clock.
- Partner. Counterparty behaviour — supplier’s GSTR-1 not filed, deductor’s TDS challan not deposited, aggregator’s TCS return not filed, TPA sending settlement file in a new column layout without notice, bank changing MT940 narration structure.
Every reconciliation function walkthrough asks, for each of the 6P categories: how can this specific function fail? The 6P is the discipline the process design method enforces — reproduced for a finance team, in language a finance team recognises.
Severity, Occurrence, Detection — anchored to Indian reconciliation
Generic 1-to-10 rating tables are inflatable — every analyst rates the same failure mode differently, and Severity 8 in one team is Severity 5 in another. Anchor tables solve this by mapping every rating to a specific, named consequence a controller can point to.
Severity — anchored to Indian reconciliation consequences
| Rating | Anchor |
|---|---|
| 10 | Permanent statutory loss with no recovery mechanism. Section 16(4) ITC time bar breach. Section 40(a)(ia) expenditure disallowance triggered. GST fraud exposure under Section 132. |
| 9 | Cash outflow with a recovery mechanism that is slow, expensive, or uncertain. Section 200A demand notice with interest under Section 201(1A) and fee under Section 234E. Section 234B/234C interest. TDS default triggering assessee-in-default status under Section 201(1). |
| 8 | Auditor qualification, CARO 2020 reportable observation, or material weakness in ICFR. DRC-01B or DRC-01C notice served. GSTR-9C three-way mismatch requiring justification. |
| 7 | Misstatement of the books — revenue or expense recognised in the wrong period, deferred revenue mis-scheduled, provision not booked, retention money mis-classified. |
| 5–6 | Ledger-level exceptions that will be caught at year-end but distort monthly reporting — TDS receivable rolling forward without ageing analysis, unreconciled bank items over 60 days, ITC unclaimed bucket growing without root cause. |
| 3–4 | Format or presentation errors that a preparer or reviewer notices — column mis-labelled, section rate applied at the wrong rate but corrected before filing. |
| 1–2 | Cosmetic — file naming convention deviation, missing hyperlink, minor formatting. |
Occurrence — given the current prevention control
| Rating | Anchor |
|---|---|
| 10 | Happens on the majority of transactions of this type. No prevention control in place. |
| 8–9 | Happens once a month or more frequently. Known to the team; not systematically prevented. |
| 6–7 | Happens once a quarter, or reproducible under known conditions (specific counterparty, specific bank format, specific portal state). |
| 4–5 | Happens once a year or less, but the analyst has personally seen it. |
| 2–3 | Prevented by a written policy or a system-enforced rule (for example, the ERP will not post a GST-inclusive TDS calculation because the field is a computed formula). |
| 1 | Impossible under current process design. |
Detection — probability the current control catches the failure before it lands with the counterparty, tax authority, or auditor
| Rating | Anchor |
|---|---|
| 10 | No detection control. The failure will only surface when a notice arrives or a stakeholder complains. |
| 8–9 | Manual review by the preparer — no independent second look. |
| 6–7 | Independent peer review at the end of the cycle, sample-based. |
| 4–5 | Independent peer review at the end of the cycle, plus a ratio or reasonableness test (month-on-month TDS receivable movement compared to invoiced revenue, for example). |
| 2–3 | Multi-layer detection — automated portal-side reconciliation report, plus peer review, plus a documented aging queue for anything not resolved within a threshold. |
| 1 | System-enforced constraint (the ERP cannot post an invoice without a valid PAN and TDS section combination). |
The Action Priority table for finance
The insistence that Severity dominates the prioritisation is the single most important rule to import into finance. A materiality threshold approach — the standard Indian finance heuristic that a variance below ₹X is not investigated — will miss every Severity-10 permanent loss that happens to be small in the current period but grows over time.
| Rule | Action Priority |
|---|---|
| Severity 9 or 10 | High, regardless of Occurrence or Detection |
| Severity 7 or 8, Occurrence 5 or higher | High |
| Severity 7 or 8, Occurrence 4 or lower | Medium |
| Severity 5 or 6, and either Occurrence 5+ or Detection 7+ | Medium |
| Severity 5 or 6, otherwise | Low |
| Severity 4 or lower | Low unless Occurrence is 10 |
Every High priority failure mode must have at least two independent detection controls, and at least one of them must be either a system-enforced rule or an aging queue with an explicit escalation trigger. Every Medium must have a documented peer review and a ratio or reasonableness test. Every Low may be handled with a standard SOP step.
The 12-class function-level failure mode taxonomy
Walk every reconciliation function through this taxonomy. It is Terra Insight’s branded twelve-class failure mode framework — the finance analogue of the manufacturing engineer’s question “how could this welding step fail?” but written for a reconciliation function.
| Class | Prototype failure modes |
|---|---|
| Data extraction | Wrong period; wrong entity or GSTIN; wrong reporting basis (accrual vs cash); portal report pulled before source system settles; PDF instead of structured export |
| Data classification | TDS section applied at the wrong rate; TDS calculated on GST-inclusive amount; GST rate applied wrong for room-tariff-linked hospitality; place of supply misdetermined; invoice classified as B2B when it should be B2C |
| Data completeness | Missing invoices from the register; missing challans; missing return leg for a reversal; missing forex remittance in the Form 27Q return; missing intercompany elimination |
| Matching logic | Match tolerance too wide (matches wrong invoice); tolerance too tight (misses legitimate match); rounding difference not accepted; PAN or GSTIN partial match accepted; date window off by one; tie-breaker between two candidate matches undefined |
| Timing and period | Cross-era mapping wrong (Section 194x to 393 code); accrual booked in wrong period; supplier files GSTR-1 in a period after the buyer’s Section 16(4) cut-off; NACH file received on a bank holiday |
| Counterparty / partner | Supplier’s GSTR-1 not filed; deductor’s Form 168 not updated; TPA sends new file format without notice; bank changes MT940 narration structure; aggregator’s GSTR-8 delayed |
| Precision and numeric | Rounding direction wrong (SGST and CGST paise split); currency conversion at wrong date; TDS on gross vs net base; retention money computed on the wrong invoice value; interest computation date off by one day |
| Policy and interpretation | Manpower supply invoice deducted under a technical services code instead of contractor code; foreign OTA commission treated without RCM; ITC on blocked expense under Section 17(5) claimed; TCS on scrap not tracked at PAN-cumulative basis |
| Aging and escalation | Exception raised but not aged; aging queue not reviewed; no escalation rule; escalation goes to a person who cannot resolve it; aged item written off without root cause analysis |
| Cutoff and sign-off | Bank cut-off crossed before extraction; month-end close signed before Q4 TDS challan confirmed on TRACES; GSTR-3B filed before GSTR-2B is stable; annual return filed before Section 16(4) audit trail is closed |
| Documentation and evidence | No source-file archive; screenshot instead of API-fetched evidence; evidence dated before the reconciliation was run; evidence not linked to the specific exception |
| Portal and system | TRACES down; GST portal maintenance window; ERP report timezone off; NACH gateway delay; IMS action not taken before auto-lock |
Every reconciliation function receives at least one failure mode from every class that could apply. Classes that do not apply are documented with a one-line rationale — the walkthrough itself becomes the evidence that the class was considered.
Detection techniques for manual reconciliation
Each failure class has a native detection technique that a manual finance team can run. A world-class reconciliation control plan closes every High Action Priority row with a specific technique, not with a vague “peer review”.
| Failure class | Native manual detection technique |
|---|---|
| Data extraction | Row count reconciliation between source system and extract; hash or checksum on the extract file; timestamp-and-user log |
| Data classification | Ratio analysis — TDS receivable as a percentage of invoiced revenue, month-on-month; section-wise split reasonableness test |
| Data completeness | Bank statement to book, book to bank two-way match; sequential invoice number gap analysis; register total reconciled to GL control account |
| Matching logic | Sample-based independent tick-and-tie by a peer; documented tolerance rule with sign-off; residual exception categorisation |
| Timing and period | Aging queue with mandatory review at day 30, 60, 90; cross-era mapping table maintained in a single document; portal cut-off calendar tracked separately |
| Counterparty / partner | Supplier follow-up queue keyed to GSTR-1 filing status; TPA file format version register; bank narration change log |
| Precision and numeric | Total reconciliation gate — variance total must equal zero to the paise; conservation checks on splits (SGST + CGST equals total GST for intra-state) |
| Policy and interpretation | Written policy document reviewed annually with signed acknowledgement from every analyst; new-transaction-type escalation to the tax head before booking |
| Aging and escalation | Aging queue with an owner, a review cadence, and a maximum-days-open rule that auto-escalates |
| Cutoff and sign-off | Sign-off matrix with named approver, cut-off calendar published to the team, no exceptions without written justification |
| Documentation and evidence | Evidence-attached-to-exception rule; API or portal-fetched screenshots with URL and timestamp; evidence retention aligned to the statutory retention rule |
| Portal and system | Portal status log; ERP job monitoring; rerun protocol documented |
Rule of thumb linking Action Priority to detection technique.
- High Action Priority — at least two independent detection layers, with at least one being an aging queue with escalation or a system-enforced rule. A peer review alone is not adequate for High.
- Medium Action Priority — peer review plus a ratio or reasonableness test.
- Low Action Priority — SOP step with sign-off.
A worked example — Form 26AS reconciliation walked through the seven steps
The example runs the TDS receivable-to-Form 26AS reconciliation function through the full method for a mid-market IT services company with 60 active clients.
Step 1 — Planning and Preparation
- Scope. The single function that reconciles the TDS receivable ledger to Form 26AS (transitioning to Form 168 from April 1, 2026) at the end of each quarter.
- Team. Controller, tax manager, one senior AR analyst, and the statutory auditor as an observer for the first cycle.
- Deliverables. A written failure analysis for this function; an updated SOP; a control plan with named owners; an integration into the quarterly close checklist.
Step 2 — Structure Analysis
- Parent process: quarterly TDS reconciliation.
- Item: reconcile TDS receivable ledger to Form 26AS by deductor PAN, quarter, and section (or payment code from FY 2026-27).
- Sub-elements: (a) extract Form 26AS by quarter; (b) extract TDS receivable ledger from ERP; (c) match by deductor PAN and quarter; (d) match by section or payment code; (e) categorise variance; (f) age the exception queue; (g) sign off.
Step 3 — Function Analysis
- Function. “Produce a variance register that classifies every quarter-end TDS receivable line as (a) fully credited, (b) partially credited, (c) not credited but supported by Form 16A or Form 131, or (d) not credited and not supported.”
- Requirement. Every High Action Priority failure mode must be caught before the return is filed. The register must be defensible to the statutory auditor and the assessing officer.
Step 4 — Failure Analysis
Walk the 6P and the 12-class taxonomy, keeping the modes that apply.
| Failure mode | 6P cause | Effect |
|---|---|---|
| TDS receivable includes a client on an invoice booked in Q4 but paid in Q1 of the next FY | Period | The Form 26AS credit will appear in the next FY. If the analyst does not classify this correctly the variance persists and ages into an audit qualification |
| Client deducted at 10 percent under a technical services code but invoice was for manpower supply | Policy | Excess deduction; the vendor is out of pocket, and the correction claim is a Section 197 process |
| TDS deducted on GST-inclusive amount by mistake — a common vendor error covered by CBDT Circular 23/2017 | Policy | Excess deduction; recovery requires a refund reconciliation |
| Deductor filed the return under the old section code post-April 2026 but the transaction is a new-era payment code case | Period (cross-era) | Cross-era matching failure; the analyst may write off legitimate credit |
| PAN mismatch between the vendor’s PAN and the deductor’s TDS entry — a common cause under Section 206AA | Partner | Deduction happened at 20 percent; the vendor’s receivable exceeds Form 26AS credit |
| Form 26AS extract taken on day 5 of the next quarter — deductor’s return not yet reflected | Portal | False variance flagged; the analyst wastes cycles chasing a portal timing artefact |
| Analyst rolls forward the unresolved bucket without ageing | Process | 8-quarter-old unresolved items become permanently uncollectible |
| No documented cutoff between the ERP extract date and the TRACES pull date | Process | Two data sources at different points in time |
| Analyst runs the reconciliation and self-reviews | Process | No independent detection layer |
| Client’s Form 168 shows a credit that the ERP does not record because the invoice was booked to a different entity in the group | Partner | Intercompany elimination gap; the credit is real but sitting in the wrong entity |
Step 5 — Risk Analysis (Action Priority)
| # | Failure mode | S | O | D | AP |
|---|---|---|---|---|---|
| 1 | Q4-to-Q1 boundary misclassified | 8 | 8 | 6 | H |
| 2 | Technical services vs contractor code wrong on manpower supply | 8 | 6 | 5 | H |
| 3 | TDS on GST-inclusive amount | 9 | 5 | 6 | H |
| 4 | Cross-era section code confusion (FY 2026-27) | 9 | 7 | 7 | H |
| 5 | Section 206AA higher-rate deduction due to PAN mismatch | 9 | 4 | 5 | H |
| 6 | Form 26AS pull too early | 5 | 8 | 4 | M |
| 7 | Unresolved bucket rolled forward without aging | 10 | 6 | 8 | H |
| 8 | Cutoff between ERP and TRACES undocumented | 6 | 7 | 6 | M |
| 9 | Self-review, no independent check | 8 | 9 | 9 | H |
| 10 | Intercompany credit landing in the wrong entity | 8 | 3 | 7 | H |
Step 6 — Optimisation
| # | Prevention | Detection |
|---|---|---|
| 1 | Cut-off rule: any invoice with payment date in the next FY is flagged in the ERP extract | Aging queue reviewed by the tax manager; every item over 90 days requires a written note before roll-forward |
| 2 | Vendor master carries a supply-type field enforced at PO stage; manpower vendors flagged to the contractor code | Ratio test — total technical-services receivable vs contractor receivable compared to prior-year mix, variance greater than 15 percent investigated |
| 3 | ERP field for TDS base is a formula (Invoice value minus GST); no manual override permitted | Sample-based tick-and-tie by peer; automatic ratio (total TDS receivable divided by net invoiced revenue) trended quarter-on-quarter |
| 4 | Cross-era mapping table maintained in a single document, reviewed monthly; both section code and payment code carried in the ledger for FY 2026-27 and FY 2027-28 | Two-key match — try old code first, then new code; residuals reviewed by tax manager |
| 5 | PAN validated at vendor onboarding via the TRACES bulk PAN utility; validation refreshed annually | Higher-rate deduction ratio flagged; every 20 percent deduction requires a documented PAN validation status |
| 6 | Documented pull-on-day-10 rule with rationale; earlier pulls are labelled preliminary | Preliminary pulls not signed off; second pull required before close |
| 7 | Aging queue with named owner and a hard 180-day maximum age | Any item aged past 180 days is written off only with controller approval and root-cause note |
| 8 | Cut-off calendar published; ERP extract timestamp and TRACES pull timestamp captured on the working paper | Both timestamps reconciled to be within 24 hours; variance investigated |
| 9 | Preparer and reviewer named separately in the reconciliation working paper; reviewer signs off with a checklist | Independent peer review is a hard control; no self-sign-off permitted |
| 10 | Intercompany PAN and GSTIN cross-reference sheet maintained; consolidation review by group controller | Group-level Form 26AS aggregate reconciled to entity-level totals monthly |
Step 7 — Results Documentation
- One-page reconciliation control plan per function, filed alongside the SOP.
- Reviewed monthly by the controller; reviewed quarterly with the audit committee.
- Re-opened on any process change, portal change (Form 168 switchover), or after every field incident.
- Every incident that reveals a new failure mode adds a row and gets re-scored.
When manual failure analysis outgrows its own controls
A well-run manual failure analysis will identify High Action Priority failure modes whose detection controls are economically infeasible for a finance team to run manually. The three canonical examples across Indian reconciliation are:
- Section 16(4) at-risk ITC across 200-plus vendors. The detection technique is an aging queue keyed to each vendor’s GSTR-1 filing status, refreshed daily, and prioritised by the number of days remaining until the November 30 deadline. A finance team can build this in Excel for a hundred vendors. At two hundred vendors, across multiple GSTINs, refreshed daily, with escalation to the vendor’s key account manager, the manual control breaks. This is the failure mode that carries a Severity of 10 — permanent loss with no recovery mechanism — and the reason Terra Insight’s GST reconciliation software treats the at-risk ITC queue as a first-class output.
- Cross-era TDS matching under the Income-tax Act 2025. The detection technique is a two-key match logic — try the legacy section code, then the new payment code in the 1001–1092 range — for every deductor entry, applied across three financial years while the correction windows for old years close. A manual team can carry both codes in a spreadsheet. Running the match logic correctly across thousands of receivable lines while the year-end correction deadlines close is where manual detection tops out. Terra Insight’s TDS reconciliation software delivers this as an automated aging queue with escalation triggers so the residual severity does not accumulate.
- NACH batch disaggregation with return code classification. A single ₹1.2 crore NACH credit against 480 employee accounts, with the return file arriving separately, is not reconcilable at the batch level. The detection technique is a line-level match against the mandate register, with automated classification of the return codes. Manual matching produces systematic gaps that only surface at the payroll or vendor complaint desk weeks later.
The finance team’s response is not to accept these failure modes — the Action Priority table forbids that when Severity is 9 or 10. The response is to install a reconciliation infrastructure layer that provides the detection control the manual process cannot. That is the intent of TransactIG — to be the continuously refreshed detection layer for the High-Priority failure modes that a rigorous manual analysis has already surfaced but that a finance team cannot economically catch by hand.
Where this fits
- TransactIG — reconciliation infrastructure
- Reconciliation software India — pillar guide
- GST reconciliation software
- TDS reconciliation software
Related reading
- ICFR and reconciliation controls under Section 143(3)(i)
- Statutory audit reconciliation checklist
- Section 16(4) ITC time bar
- DRC-01B reconciliation reply
- Form 168 — the new TDS statement
- Cross-era TDS reconciliation
- TDS penalty and interest — the multi-layered consequence framework
- CARO 2020 bank reconciliation audit
Frequently Asked Questions
What is the difference between a reconciliation checklist and a reconciliation failure analysis?
A checklist confirms a task was performed. A failure analysis identifies every way the task can silently produce a wrong result, ranks those failures by severity, and confirms that a specific control catches each one. A checklist tells the auditor that the reconciliation was done. A failure analysis tells the auditor what would happen if it went wrong, why the process would catch it, and how the residual risk is documented and accepted. Under Section 143(3)(i) of the Companies Act, the ICFR opinion requires the second form of evidence, not the first — the auditor tests the operating effectiveness of a designed control, and there is no designed control without an underlying failure analysis. Reconciliation process design converts a task list into an analysable, testable, defensible control base.
Why does Severity dominate the Action Priority table rather than a multiplied risk score?
A multiplicative risk score — Severity multiplied by Occurrence multiplied by Detection — treats a Severity 10 permanent loss with low occurrence the same as a Severity 3 nuisance with high occurrence; both can produce identical scores of, say, 60. This consistently under-prioritises the failure modes that matter most, because low-occurrence and well-detected ratings drag the score below the intervention threshold even when the consequence is catastrophic. For Indian reconciliation, the equivalents of catastrophic failure are Section 16(4) permanent ITC loss, Section 40(a)(ia) expenditure disallowance, and Section 201(1) assessee-in-default status. Severity-first prioritisation — where any Severity 9 or 10 failure mode is always High Priority regardless of Occurrence or Detection — is the design axiom that keeps these failure modes visible in the queue. It is the single most important rule Terra Insight’s reconciliation process design method carries.
How does the reconciliation failure analysis relate to ICFR and CARO 2020 reporting?
The failure analysis is the design documentation that ICFR testing under Section 143(3)(i) verifies. Every High-Priority row in the failure analysis becomes a testable control that the internal auditor samples, and every prevention and detection control listed against it becomes an evidence requirement. For CARO 2020, Clause 3(ii)(b) on bank reconciliation is directly served by the invoice-to-bank stream analysis — the auditor’s opinion on whether the quarterly stock statements agree with the books of account is grounded in the same reconciliation the failure analysis has already scored, controlled, and documented. A finance team with a current failure analysis for each reconciliation function will not receive a material weakness observation for control design; observations may still arise on operating effectiveness, which is a testing outcome, not a design outcome.
How often should a reconciliation failure analysis be re-scored?
Occurrence and Detection ratings should be re-scored quarterly based on actual incident data from the previous quarter — every exception that surfaced, every miss that only came to light after a notice or an audit query, and every prevention or detection control that was strengthened or weakened. Severity should be re-scored only when a rule changes — for example, the shift from Section 194x to the new Section 393 payment codes from April 1, 2026 changes the severity anchor for TDS section misclassification because the cross-era mapping window itself becomes a distinct failure surface. The full analysis should be re-opened on any material process change, any portal change (Form 168 switchover, IMS live-cutover, GSTR-2B date shift), and after every field incident that reveals a new failure mode.
When does manual failure analysis justify a move to reconciliation infrastructure?
When the analysis itself is producing High-Priority failure modes that carry Severity 9 or 10, and the only economically viable detection control for those modes is a system-enforced rule or an automated aging queue with escalation — and the finance team cannot build that detection layer manually at the current transaction volume. The three canonical Indian examples are the Section 16(4) at-risk ITC queue keyed to each vendor’s GSTR-1 filing status and refreshed daily; the cross-era TDS matching layer running two-key section-and-payment-code logic across three financial years while the correction windows close; and NACH batch disaggregation with return code classification against the mandate register. In each case, the manual process cannot economically produce the detection control the failure analysis demands. This framework is engineered to hold up under audit-committee scrutiny — the discipline it enforces is more durable than any specific control it produces — and the natural next layer, when the residual severity exceeds the risk-acceptance threshold, is TransactIG as the continuously refreshed detection surface for the failure modes the manual analysis has already surfaced.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
- ▸ Section 54(3), Central Goods and Services Tax Act 2017 — Refund of unutilised input tax credit. Where credit has accumulated on account of the rate of tax on inputs being higher than the rate of tax on output supplies, a registered person may claim refund of unutilised ITC at the end of any tax period. The Supreme Court in Union of India v. VKC Footsteps India Pvt Ltd (2021) 10 SCC 674 confirmed that the refund is confined to unutilised credit on inputs; input services and capital goods stand excluded. Reconciliation surface: the inverted-duty refund workbook that must reconcile against the RFD-01 filing base.
- ▸ 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. Where the supplier's GSTR-1 is filed after this cut-off and no book-side accrual has been made, the ITC is permanently lost. This is the Severity 10 anchor in the Action Priority framework — a permanent statutory loss with no recovery mechanism.
- ▸ Section 200A read with Sections 234B and 234C, Income-tax Act 2025 — Processing of TDS statements and intimation of demand. Where the return of TDS or TCS is furnished and any arithmetical error or incorrect claim is apparent, or the TDS liability is short-deposited, the assessing officer processes the statement and issues a demand under Section 200A with interest under Section 201(1A) and Section 234B/234C. The demand triggers assessee-in-default status under Section 201(1) where deduction has not been made or has been made short. This is the Severity 9 anchor — cash outflow with a slow, expensive, or uncertain recovery mechanism.
- ▸ Section 143(3)(i), Companies Act 2013 — 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. Reconciliation controls are the design and operating evidence the auditor evaluates under the Guidance Note on Internal Financial Controls over Financial Reporting. A reconciliation process built on a documented failure analysis, with prevention and detection controls mapped to each High-Priority failure mode, is the evidence base the auditor tests. A checklist without failure analysis is not.
- ▸ 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. Bank reconciliation is the direct evidence base. This is the Severity 8 anchor — auditor qualification, CARO 2020 reportable observation, or material weakness in ICFR.
- ▸ Rule 36(4), Central Goods and Services Tax Rules 2017 — Input tax credit availed by a registered person in respect of invoices or debit notes the details of which have not been furnished by the suppliers under Section 37 shall not exceed the amount of input tax credit available in respect of invoices or debit notes the details of which have been furnished by the suppliers under Section 37 in FORM GSTR-1 or IFF. The GSTR-2B ceiling is the operational anchor. DRC-01C, the ITC mismatch notice, is served when the GSTR-3B ITC claim exceeds this ceiling — the Severity 8 anchor for the GSTR-2B stream.