Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
In most Indian finance operations, an auditor requesting evidence for a single reconciliation variance triggers a scavenger hunt that consumes 30 to 60 minutes per variance — searching for the bank statement in the shared drive, opening the ledger to find the reconciled entry, digging through email to identify who approved the classification, and reconstructing the reason code from an analyst's memory. Across a statutory audit sample of 40 tested variances, this is 20 to 40 audit hours of pure evidence hunting, which the audit firm bills back to the company. Worse, when the reconciliation cannot be defended with contemporaneous machine-readable evidence, the statutory auditor either accepts a narrative reconstruction (against SA 500 sufficient-appropriate-evidence discipline) or forces a top-side adjustment. Companies Act 2013 Rule 3(1) proviso, effective 1 April 2023, and the CARO 2020 audit-trail clause raised the compliance bar without giving finance teams a natural machine-readable place to store the reconciliation-side evidence.
Every variance published in a TransactIG reconciliation run is a structured object carrying four evidence fields, not a narrative row on a spreadsheet. The source-file field references the raw feed the transaction was drawn from and is anchored by a cryptographic fingerprint of the file, computed at ingestion, so the same physical bytes are re-identifiable across the audit chain. The ledger-entry field references the exact voucher or invoice line the variance was measured against, drawn from the ERP feed. The classification-rule field references the specific rule that produced the reason code — partial payment under Section 15 valuation, timing difference across cut-off, credit-note netting under Section 34, TDS deducted at source under Section 393 of the Income Tax Act 2025 (the successor framework to the Chapter XVII-B sections in the 1961 Act), mismatched narration, and so on — with the rule reference embedded on the variance itself. The decision field is the ISO-8601 timestamp of classification, plus the reviewer identity and approval timestamp if a human took an action on the variance. The Recon Output Envelope binds all four fields together in a versioned, machine-readable output that can be re-generated deterministically.
Source-system feed configuration (bank statement parser per bank format, payment gateway settlement CSV parser, GSTR-2B/26AS extractor, ERP journal export); ingestion-time file fingerprinting; ledger reference resolution against the ERP voucher master; classification-rule library keyed by variance category (each rule carries a stable rule ID that gets stamped onto every variance it fires on); reviewer identity capture from the authenticated session at the moment of approval or override; envelope versioning aligned to industry preset versions and rule library versions; retention policy aligned to Section 128(5) of Companies Act 2013 (eight years) and CARO 2020 audit-trail preservation.
For every statutory audit cycle: an audit-ready envelope containing the fingerprinted source-file manifest, per-variance evidence rows with source file / ledger entry / classification rule / timestamped decision, a provenance walk from input file through classification to publication, and pre-computed CARO 2020 Clause 3(xi)(b) audit-trail compliance metadata for the reconciliation-derived population. The auditor's evidence request on any specific variance is already answered by the envelope. Re-running the same reconciliation later produces a byte-identical envelope if the inputs and rules have not changed, so audit evidence is stable across quarters.
An audit partner arrives at your Bangalore office on Wednesday morning for the FY 2024-25 statutory audit closeout. They open the reconciliation working papers, pick a single outward-settlement variance for ₹42,15,000 flagged in November, and ask a simple question: how do we know this classification is right? At most Indian companies, the next 45 minutes look like this. The controller opens the shared drive, searches for “razorpay settlement November”, finds four files with similar names, opens each one to guess which one produced the variance. The audit associate cross-references against the general ledger to find the entry the variance was measured against, then opens Outlook to search for the email thread where the finance manager approved the classification as a partial payment. The classification reason itself lives in the analyst’s head — the analyst is on leave in Kerala. The partner’s follow-up variance takes another 40 minutes. Across the tested sample of 40 variances, the audit firm bills 20 to 30 hours of pure evidence hunting.
TransactIG replaces that sequence with a machine-readable evidence trail that ships attached to every variance at the moment it is published. The auditor drills into the ₹42,15,000 variance and immediately sees four structured fields: the source file (with a cryptographic fingerprint that re-identifies the exact bytes), the ledger entry the variance was measured against, the classification rule that produced the reason code, and the timestamped decision including the reviewer’s identity. The envelope IS the evidence. The audit hour is spent testing sampling and edge cases, not reconstructing the story. This is what machine readable evidence trail reconciliation audit defensibility looks like in practice, and it is one of the five architectural claims that distinguishes TransactIG from spreadsheet-based reconciliation and from black-box matching engines that hide the reason code.
The claim in one paragraph
Every variance TransactIG publishes carries a machine-readable evidence trail attached to it — the source file the raw entry came from, the ledger entry it was reconciled against, the classification rule that produced the reason code, and the timestamped decision including the reviewer’s identity where a human acted on the variance. The trail is not narrative — it is parseable structured metadata, versioned by the same run that produced it and bound together in the Recon Output Envelope. When your statutory auditor opens the envelope, they do not need to ask for evidence, because the envelope IS the evidence. The Companies Act 2013 Rule 3(1) proviso audit-trail requirement and the CARO 2020 audit-trail reporting clause are already satisfied at close for the reconciliation-derived population.
Why this matters for statutory audit hours and CARO 2020 defensibility
Reconciliation is upstream of the accounting entry. When your statutory auditor questions a specific journal entry — a write-off, a re-classification, a variance provision, an adjustment to trade receivables — the auditor traces backward from the entry to the reconciliation that produced it, and from the reconciliation to the source file that raised the variance. If the reconciliation output is a PDF or spreadsheet without machine-readable provenance, the backward trace is a manual scavenger hunt performed jointly by the audit team and finance. The audit hours accumulate, the client gets billed, and the audit report may still carry an emphasis-of-matter paragraph on evidence sufficiency if too many variances have missing trail elements.
Here is what breaks in most systems. A payment gateway settlement CSV is uploaded to a shared drive, a spreadsheet-based reconciliation is run, the variances are copied into a summary tab with narrative notes (“per Razorpay statement dated 30 November”), the summary is emailed for approval, and the approval lives as a reply in an Outlook thread. Six months later the auditor asks which of the twelve Razorpay statements uploaded in November produced a specific variance. There is no cryptographic fingerprint on the file, no version stamp on the reconciliation, no rule reference on the variance, and no authenticated approval record. The finance team reconstructs the story from memory and file timestamps. The auditor either accepts the narrative reconstruction — against Standard on Auditing (SA) 500’s sufficient-appropriate-evidence discipline — or forces a top-side adjustment for the variances where the reconstruction is weakest. Neither outcome is what a CFO wants three weeks before board sign-off. The statutory audit checklist for Indian companies walks the broader terrain.
The Indian regulatory and accounting framework
Three statutes and one auditing standard anchor the machine-readable-evidence claim in Indian law.
The Companies (Accounts) Rules 2014, Rule 3(1) proviso, as inserted by the Ministry of Corporate Affairs notification effective 1 April 2023, requires that every company using accounting software must use software with an audit trail feature that records every transaction, creates an edit log of every change with the date and time it was made, and ensures the audit trail cannot be disabled. The requirement runs at the accounting-software layer, but reconciliation is functionally an upstream feeder into that layer — the variances raised by reconciliation drive the journal entries that eventually post to Tally, SAP, Oracle, or the ERP of record. When the auditor traces backward from a journal entry to test the audit-trail compliance, the reconciliation output is part of the chain of evidence, and a reconciliation without machine-readable provenance is a broken link.
The Companies (Auditor’s Report) Order 2020 (CARO 2020), Clause 3(xi)(b), requires the statutory auditor to report on whether the company has used accounting software with an audit-trail feature throughout the year, whether the audit-trail feature was tampered with, and whether the audit trail has been preserved as per the statutory retention requirement. The auditor’s ability to make this report cleanly on the reconciliation-derived population depends on the reconciliation output carrying its own trail — the auditor cannot certify audit-trail compliance for entries whose upstream evidence chain is broken.
Ind AS 1 (Presentation of Financial Statements) requires fair presentation, which presumes evidence supporting each recognised amount. Ind AS 8 (Accounting Policies, Changes in Accounting Estimates and Errors) requires that changes in accounting estimates and prior-period error corrections be disclosed with the reasoning that produced the revised estimate — a traceability requirement that presumes the evidence chain is available. Section 128 of the Companies Act 2013 requires books of account to give a true and fair view, kept on accrual basis and according to the double-entry system, and Section 128(5) mandates preservation for eight years.
Standard on Auditing (SA) 500 issued by the ICAI defines audit evidence as information contained in the accounting records and other information, and requires the auditor to design procedures to obtain sufficient appropriate evidence. Reconciliation output — where it carries source-file fingerprints, ledger references, classification rules, and timestamped decisions — is direct SA 500 evidence. Reconciliation output without those fields is a working paper the auditor still has to test with corroborating procedures, doubling the hours.
The convergence of the four sources is unambiguous. An Indian company operating in FY 2024-25 and beyond needs reconciliation output that can stand as machine-readable evidence in an audit challenge, or it will pay for the evidence reconstruction in audit hours.
A worked example — a ₹42 lakh outward-settlement variance drilled by the statutory auditor
Illustrative — figures and identifiers are representative of the operating pattern, not any real customer. Cross-verify against your own reconciliation output before action.
An FY 2024-25 statutory audit for a mid-market retail brand is in its final week. The audit partner is testing a sample of 40 variances from the reconciliation-derived population and drills into a single row: an outward-settlement variance of ₹42,15,000 flagged on 30 November 2024 in the Razorpay platform reconciliation.
The partner opens the Recon Output Envelope for the November settlement cycle. On the variance row, four structured fields are attached.
Source file. The reference reads razorpay-settlement-2024-11-30.csv with a cryptographic fingerprint sha256:9f2a...c47b. The manifest section of the envelope confirms the file was ingested at 2024-12-01T02:14:07+05:30, size 4.7 MB, from source system Razorpay via the SFTP feed. The partner asks for the physical file — the controller pulls it from the archived S3 folder, re-computes the SHA-256 in front of the partner, and matches the recorded fingerprint. The same bytes reconciled six months ago are the same bytes the partner is looking at today.
Ledger entry. The reference reads voucher SL-2024-000342, dated 30 November 2024, with linked references to Invoice INV-2024-11-1857, Goods Receipt Note GRN-2024-11-0921, and Purchase Order PO-2024-09-0483. The partner opens the ERP with the voucher reference, sees the same voucher, and confirms the variance was measured against a real, posted entry — not against a phantom or a re-numbered line.
Classification rule. The reference reads RULE:PARTIAL_PAYMENT_S15, which resolves to the classification “Partial payment settled under Section 15 valuation adjustment — customer discount applied post-supply, netted against the invoice for the balance, with the platform absorbing the differential per the promotional scheme.” The partner asks how the rule fired: the envelope’s provenance section shows the rule triggered because the settlement amount (₹42,15,000) was less than the invoice gross value (₹47,80,000) by exactly the promotional discount amount (₹5,65,000) recorded in the platform’s scheme master for that period, and the classification was made deterministically.
Timestamped decision. The reference reads decision: auto-classified 2024-12-01T02:14:47+05:30; reviewer-approved by S. Rao (Financial Controller) at 2024-12-04T14:22:15+05:30. S. Rao’s identity was captured from her authenticated session at the moment she opened the variance in the review queue and clicked approve; the timestamp is the server clock in ISO-8601 with timezone offset. The partner has an authenticated approval record with the reviewer’s identity and the exact time of action.
The four fields together answer every reasonable audit question on that variance in under two minutes. The partner samples 39 more variances the same morning and closes the reconciliation-derived audit-testing subplan by lunch. The audit-firm bill for evidence-reconstruction hours on this cycle: near zero. Cross-referenced with the GST reconciliation discipline, the same envelope structure would answer a CGST Section 15 valuation query from a departmental audit with the same structured evidence.
The same story would run for 20 to 40 minutes per variance in a spreadsheet-based reconciliation without the envelope, and the audit firm would bill for those hours.
What this means for you at each altitude
- CFO — Your statutory audit hours on reconciliation-derived entries shrink materially. The audit firm’s evidence-reconstruction billing drops. CARO 2020 audit-trail reporting on the reconciliation-derived population is pre-computed at close, so the audit report reads cleaner and lands faster. When the board asks how you know the year-end trade-receivable balance is right, you have machine-readable evidence, not a story.
- Audit partner (statutory or internal) — CARO 2020 Clause 3(xi)(b) reporting on the reconciliation-derived entries is answered by the envelope. SA 500 sufficient-appropriate-evidence testing on tested variances happens at the row level in minutes, not in half-hour scavenger hunts. Emphasis-of-matter paragraphs on evidence sufficiency drop out of the audit report.
- Integration engineer — The Recon Output Envelope’s provenance field is machine-readable. You can pull it into your audit workflow — a working-paper tool, a document management system, a GRC platform — so the auditor never has to leave their tool to request evidence. See the envelope developer reference for the shape and the versioning reference for how the envelope evolves across rule and preset changes.
- Operations lead / financial controller — Your review actions are captured with your authenticated identity and a server timestamp, so months later there is no ambiguity about who approved which classification. The friction of “please forward the email where you approved this” disappears.
For the broader architectural principle set, see the sibling articles on deterministic reconciliation and audit reproducibility and on the accounting-identity gates that guarantee money conservation. Together they form part of the guarantees that make TransactIG audit-defensible under the Companies Act, CARO 2020, and Ind AS reporting regimes — see the full architectural rationale on the Why TransactIG anchor and the technical envelope on the developers concepts page.
How TransactIG delivers this in practice
Every reconciliation run produces a Recon Output Envelope that carries the source-file manifest, the per-variance evidence rows with source-file / ledger-entry / classification-rule / timestamped-decision fields, and the provenance walk from input file through classification to publication. The envelope is versioned so that re-running the same reconciliation later — for example, to re-generate audit evidence a quarter after the original close — produces the same envelope byte-for-byte if the inputs and rules have not changed. Companies Act Rule 3(1) proviso audit-trail requirements and CARO 2020 audit-trail reporting on the reconciliation-derived population are already satisfied at the moment the envelope is published. Your statutory auditor drills into any variance and sees the evidence attached, not a note asking finance to fetch a screenshot.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →