Deterministic Reconciliation and Audit Reproducibility Under Indian Statute

The audit partner walks in on the third Monday of FY 2026-27 and asks for the Q3 FY 2024-25 reconciliation — the one that fed the interim close signed off eighteen months ago. The controller has the sealed artifact on file. The commercial finance lead has the source data. The tax team has the TDS registers. What nobody has, in most Indian mid-market finance stacks, is a way to guarantee that if the reconciliation is re-run today, the numbers that come back match the numbers that were originally signed. Between the original close and today, the software has shipped four upgrades. Tolerance defaults have moved. Rounding conventions have been quietly refactored. Matching heuristics have been “improved.” The re-run either fails outright — the older configuration cannot be reloaded — or, worse, succeeds and returns different numbers. The audit gap that opens between the sealed artifact and the re-execution is where qualified opinions and disclosure caveats live. Deterministic reconciliation audit reproducibility India is the property that closes this gap, and it is what makes computed reconciliation defensible as audit evidence rather than opinion.

The claim in one paragraph

The public differentiator claim reads simply enough: same inputs and same configuration produce the same envelope — every rerun, every quarter, every audit. What that means in operational terms is that every reconciliation TransactIG produces is a self-contained, self-verifying artifact. The version pin travels with the envelope. The configuration in force at the moment of the close — engine version, industry preset, tolerance table, calendar, rounding convention, source-data hashes — is embedded in the envelope itself. When an auditor re-executes the reconciliation months or years later, the engine reconstitutes the pinned environment and re-runs against the same source inputs. The output is byte-identical to what was originally signed. This is not a promise that future upgrades will be backward-compatible in the abstract — it is a property of every artifact the engine has already delivered. The signed Q3 FY 2024-25 close remains fully re-derivable in FY 2027, in FY 2028, and through the eight-year statutory retention window the Companies Act 2013 Section 128 requires.

Why this matters for the statutory auditor

The auditor’s job under Ind AS is to distinguish between three kinds of change: new information that arrived after the close, a legitimate revision to an accounting estimate, and a mechanical error in the original computation. Ind AS 8 requires each to be treated differently — the first is a normal event, the second is applied prospectively, the third is applied retrospectively with restatement. Making that distinction is impossible if the original computation cannot be reproduced. When the FY 2023-24 reconciliation runs to different numbers in FY 2026 than it did at signature, the auditor cannot tell whether the drift is a legitimate refinement of the matching approach, a defensible tolerance change, or a bug that quietly restated the closed number. The safe response is to qualify the opinion — either through a paragraph on the reliance placed on computer-generated evidence, or through a scope limitation on the reconciled position.

Most reconciliation tools cannot make this bar. What breaks in practice is not the source data — the bank statements are preserved, the ledgers are preserved, the portal extracts are preserved — but the execution environment. The configuration that governed the original close is not versioned; it lives as the current state of a settings screen. Tolerance defaults drift when new features ship. Rounding conventions get “harmonised” in a service pack. Industry presets get renamed or restructured. A re-run against the same source data returns numbers that neither confirm nor refute the original — they simply come back different, and the difference is untraceable to any specific driver. This is where the audit gap becomes a live risk, because a qualified opinion on the reconciliation flows through to the wider audit report, and from there into loan-covenant reporting, ratings agency reviews, and public disclosure.

The Indian regulatory and accounting framework

Four instruments anchor the reproducibility bar in Indian statute.

The Companies Act 2013 Section 128 requires every company to prepare and keep at its registered office books of account and other relevant books, papers and financial statements for every financial year, and to preserve them in good order for a period of not less than eight financial years immediately preceding a financial year. The section applies to books of account regardless of whether they are kept in physical or electronic form. When reconciliation output feeds the general ledger — which it does at every mid-market and above — the reconciliation artifact falls inside the preservation obligation. Preservation without re-derivability is a weaker form of the record than the section contemplates.

The Rule 3(1) proviso to the Companies (Accounts) Rules 2014, effective 1 April 2023, sharpens the retention requirement into an active audit-trail obligation. Every company using accounting software must use only software that records an audit trail of every transaction, creates an edit log of every change with the date of the change, and ensures the audit trail cannot be disabled. The proviso applies through the auditor’s report — every statutory audit filed for FY 2023-24 onward must include an opinion on whether the audit-trail feature was operational throughout the year. A reconciliation engine that cannot reproduce its own artifacts turns the audit trail from substantive evidence into a compliance record — the trail shows that a result was produced on a certain date, but the result itself cannot be verified against the underlying data. The Ministry of Corporate Affairs — Companies (Accounts) Rules is the authoritative reference for the proviso text and the FAQ guidance issued by the department on its interpretation.

Ind AS 8, on Accounting Policies, Changes in Accounting Estimates and Errors, sets the classification framework the auditor uses to interpret any delta observed between periods. A change in an accounting estimate — such as the ageing-band composition of a stale-claim provision, or the recovery-probability score on aged receivables — is applied prospectively. A prior-period error — including a computational mistake — is applied retrospectively with restatement of comparative periods and, in material cases, restatement of the opening balance sheet of the earliest period presented. The auditor cannot classify a delta as one or the other without being able to reconstruct the original computation. Determinism makes the classification operable; without it, every delta lives in the ambiguous middle.

ICAI Guidance Note on Audit of Computer Information Systems requires the auditor to obtain an understanding of the CIS environment sufficient to plan the audit, including whether the same input, processed under the same conditions, will consistently produce the same output. The Guidance Note is the operational glue that connects the abstract Rule 3(1) requirement to the reconciliation software the company runs. When the CIS review concludes that the reconciliation engine is deterministic, the auditor can place substantive reliance on the computed output. When it cannot, the audit falls back on manual testing of underlying documents — which is materially more expensive, materially slower, and materially less complete.

The Income-tax Act 2025 Section 393 introduces payment codes 1001-1092 for TDS/TCS effective 1 April 2026, replacing the legacy 194/195/206 section framework. A reconciliation covering a straddle year — book postings dated before 1 April 2026 and paid across the boundary — must apply the correct code framework to each transaction based on the deduction date. In a non-deterministic engine, re-running the straddle-year reconciliation in FY 2027 or FY 2028 risks silently reclassifying legacy sections into new payment codes, breaking traceability against Form 26AS and the TRACES defaults tracking. A deterministic engine pins the classification rules to the underlying transaction date rather than to the run date, so the auditor sees the same numbers on the same transactions regardless of when the re-run is executed.

A worked example — Q3 FY 2024-25 close, re-executed in Q1 FY 2026-27

Consider an illustrative Indian mid-market SaaS company closing Q3 FY 2024-25 on 31 December 2024. The bank-reconciliation module produces an envelope covering the quarter — 341 reconciled bank credits against book postings, 89 exceptions carried into the exception queue, ₹42.7 crore in gross bank credits reconciled to ₹42.3 crore in book postings with a ₹0.4 crore identity-check tail split between four named exception categories.

Illustrative — figures represent a plausible operating pattern for an Indian mid-market SaaS company of this size, not any specific customer. Cross-verify against your own bank statement and ledger before any decision.

The envelope is sealed on 15 January 2025 with an engine version stamp, the configuration version stamp (industry preset “SaaS subscription”, tolerance table revision 7, calendar FY 2024-25, half-up paise-exact rounding convention), and the source-data hashes for the underlying bank statement export and book-ledger extract. The signed hash of the envelope itself is written to the archive alongside the artifact.

Eighteen months later, on 22 June 2026, the statutory audit team for FY 2025-26 begins its work. The audit partner requests re-execution of the Q3 FY 2024-25 reconciliation as part of the CIS review under the Rule 3(1) proviso obligation. The reconciliation engine has, in the intervening period, shipped four upgrades. Two industry presets have been refactored. The tolerance table has been extended. The matching heuristics for SaaS-specific transaction patterns have been enhanced.

None of that alters the Q3 FY 2024-25 artifact. The engine loads the envelope, reads the version pin, reconstitutes the FY 2024-25 execution environment — engine version, tolerance table revision 7, industry preset “SaaS subscription” as it existed at that revision, calendar, rounding convention — and re-runs against the source-data hashes recorded in the pin. The output is byte-identical to the January 2025 signature. Match count 341. Exception count 89. Gross ₹42.7 crore. Book ₹42.3 crore. Identity-check tail ₹0.4 crore in the same four exception categories. Envelope hash identical to the archived signature.

The auditor treats the re-execution as substantive evidence and moves on. Total audit hours consumed on the CIS reproducibility test: under ninety minutes of walk-through plus the machine time on the re-run itself.

Now consider what happens in the non-deterministic case. The re-execution runs against the same source data but under the current engine and current configuration. Tolerance defaults have shifted since the close — a tolerance previously set to accept a ₹5 variance now accepts up to ₹50, or vice versa. Two matches that previously resolved cleanly now sit in the exception queue; three exceptions that previously carried are now cleared. The re-run returns 339 matched, 91 exceptions, a ₹0.44 crore identity-check tail. The differences are small in absolute value but material to the audit: none of the delta is attributable to new data — the source data has not changed — and none of it is attributable to a documented change in estimate. The auditor cannot classify the delta as either a change in estimate or a prior-period error, because there is no way to tell whether the original January 2025 computation was correct at the time and the current re-run is drifting, or whether the January 2025 computation had an error that was silently absorbed in a service pack. The safe response is to raise it in the management letter and, if the pattern repeats across other reconciliations, to include a paragraph in the audit opinion.

This is the gap deterministic reconciliation closes. Not by making software immune to improvement — the engine has to be able to ship new versions to serve new industries and new statutory requirements — but by pinning every artifact to the environment that produced it, so that reproduction is a mechanical operation, not an act of faith.

What this means for you at each altitude

• CFO — Your close ledger is defensible in perpetuity. The reconciliation output that feeds the trial balance can be re-derived at any point in the eight-year statutory retention window, so a covenant question in FY 2029 on a signed FY 2024-25 number resolves by re-running the artifact rather than by writing a defensive memo. Board and audit-committee reporting on the internal-control framework has a real answer to give when the CIS reproducibility question comes up under the Rule 3(1) proviso.

• Audit partner — You can accept computed reconciliation as evidence, not opinion. The reproducibility test becomes a walk-through: request the artifact, request the re-execution, compare the envelope hash. When they match, you have substantive evidence of the recorded position under the ICAI Guidance Note on Audit of CIS. Your CIS review moves from an interrogation into a verification, and the classification of any period-over-period delta under Ind AS 8 becomes operable rather than judgmental.

• Integration engineer — You can hash the envelope and compare across periods. Downstream systems that consume the reconciliation output — the GL posting engine, the tax filing engine, the analytics warehouse — can rely on the envelope as an immutable input. A reconciliation that re-runs to the same hash across quarters gives you a strong integrity signal on the source-of-truth flow, and lets you build lineage checks that catch drift the moment it appears rather than at the next audit cycle.

• Operations lead — You can respond to any historical query from a statutory notice, a customer dispute, or an internal review by re-executing the artifact rather than by rebuilding it. The 90-day window in a Section 73 GST notice, the 12-month response window in a customer chargeback, and the multi-year window in a TDS reassessment all become tractable when the underlying reconciliation is reproducible on demand.

How TransactIG delivers this in practice

TransactIG is built so that every reconciliation envelope it produces is a self-contained, self-verifying artifact. The version of the engine, the industry preset in force, the tolerance table, the calendar, the rounding convention, and the source-data hashes are all part of the sealed envelope from the moment it is signed. When an audit team asks for last quarter’s close — or the close from three years ago — the engine reconstitutes the exact environment in which the artifact was produced and returns the byte-identical output. New industries, new statutory requirements, and new customer needs are served by new configurations layered on top of the same engine going forward; they never alter the numbers on an artifact that has already been signed. That is what closes the audit gap between the sealed close and the CIS reproducibility test, and it is what turns the reconciliation software India buying decision into something that satisfies both the Rule 3(1) proviso and the Ind AS 8 restatement discipline. Read more on the architectural stance in Why TransactIG, how it interacts with accounting-identity gates and money conservation, and how the machine-readable evidence trail surfaces reproducibility to auditors on demand. For the wider audit-assurance cluster, the audit and assurance hub collects the statutory-audit checklist, ICFR, and tax-audit 3CD companion pieces.

Terra Insight Reconciliation Infrastructure

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

Published 5 July 2026

Domain expertise

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

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024