Why TransactIG

Deterministic by construction

Same inputs and same configuration produce the same envelope — every rerun, every quarter, every audit.

Auditors working under the Companies Act 2013 Rule 3(1) proviso — the audit-trail requirement that took effect 1 April 2023 for every company maintaining books through accounting software — need reproducibility to accept computed reconciliation as evidence. If re-running last quarter's reconciliation produces different numbers, the output is not evidence. It is an opinion that happened to be current on the day the file was generated.

TransactIG treats reproducibility as an architectural property, not a best-effort behaviour. The same input files, run against the same configuration, produce the identical envelope on every execution — the same match set, the same variance classifications, the same timestamped decision trail. This property is what makes Ind AS 8 change-in-estimate reasoning possible: distinguishing a genuine estimate revision from a silent numeric drift depends on knowing that last quarter's numbers will reconcile to today's baseline.

The ICAI Guidance Note on Audit of Companies Using Computerised Information Systems anticipates this requirement. Statutory auditors from PwC, Deloitte, EY, and KPMG have working practices built around it. Reconciliation software that cannot guarantee reproducibility forces the audit team to re-verify every closing figure from source — which defeats the purpose of automating reconciliation in the first place.

One engine, 24+ industry configurations

A jeweller, a residential developer, a gold-loan NBFC, a streaming platform, and a hospital chain all reconcile on the same engine — with different presets, not different codebases.

Reconciliation problems look industry-specific on the surface. A national jewellery chain reconciles mixed 3%, 5%, and 18% GST across gold, making charges, and studded pieces. A RERA-registered residential developer reconciles project escrow accounts against Section 194IA TDS on property transactions. A gold-loan NBFC reconciles loan-to-value drift and auction surplus back to individual mandates. A streaming platform reconciles payment-gateway settlement with Section 52 TCS collected by e-commerce operators. A multi-city hospital chain reconciles TPA claims, Ayushman Bharat settlements, and CGHS remittances against patient billing.

The instinctive vendor response is to write a new module per industry. TransactIG rejects this pattern. Every one of those workflows runs on the same reconciliation engine. What varies is the configuration preset — the matching rules, the tolerance bands, the variance taxonomy, the exception routing. A new industry is onboarded by adding a preset, not by forking the codebase.

This is why customer engagements do not have to wait for a per-industry release cycle. It is also why capability improvements — a better fuzzy-reference resolver, a stricter accounting-identity check, a new evidence-trail field — arrive simultaneously across every industry. A jewellery retailer benefits from the same engine improvement as an NBFC. There is no "healthcare version" three releases behind the main branch.

Accounting identities are structural, not advisory

Bank vs book must tie. Currency conservation must hold. Match rates cannot silently regress. Results that don't add up are refused, not shown.

Money conservation is not a soft-preference in double-entry bookkeeping. Under Companies Act 2013 Section 128 and Ind AS 1 fair-presentation requirements, financial statements that violate the fundamental accounting equation are not merely imperfect — they are unfit for purpose. Most reconciliation tools treat this as an advisory concern: the identity is checked, and if it fails, a warning is surfaced and the user decides whether to proceed. TransactIG treats it as a gate.

A TransactIG run that violates bank vs book conservation cannot publish an envelope. A run that shows currency leakage between accounts cannot publish. A run where a smaller share of the money has been reconciled than the target set at go-live is held for review before publication — quiet degradation between periods is not something you should have to notice by comparing spreadsheets. The platform refuses. The alternative — publishing a reconciliation envelope that internally does not add up — is a defect masquerading as a report, and it is the source of an entire class of audit queries.

CARO 2020 Clause 3(vii) — the auditor's obligation to report on the maintenance of records — is materially easier to comply with when the underlying reconciliation platform enforces conservation as a precondition. If the envelope exists, the identity held. This is what allows CFOs to accept a monthly close package as evidence rather than as a starting point for verification.

Paise-exact by convention

Exact decimal arithmetic with half-up rounding is enforced end-to-end — the rounding rule every Indian CA expects. CGST/SGST penny splits follow the CA-ratified up-rounding convention. Both Income Tax Act 1961 code families and Income Tax Act 2025 Section 393 payment codes resolve to the correct rate for every period.

Floating-point arithmetic on money is a category error in Indian tax reconciliation. CGST Act 2017 Section 15(2) valuation rules, Section 34 credit note adjustments, and GSTR-1 rate-wise reporting all require exact decimal treatment — a 0.005 rupee floating-point residual that a bookkeeping engine happily ignores becomes an unreconciled paise variance under a CBIC-aligned audit query. Every rupee, every paisa, matches the CA convention: exact decimal arithmetic with half-up rounding, applied consistently from ingestion through envelope publication.

CGST/SGST penny splits follow the up-rounding convention that ICAI members and CBIC clarifications since 2017 have consistently applied. A ₹1,000 taxable value at 18% GST rounds to ₹90.00 CGST and ₹90.00 SGST — not to a split that hides a paisa. The output reconciles to the invoice, to the GSTR-1 rate-wise summary, and to the GSTR-3B outward liability without residual variance.

Dual-Act awareness is not optional in 2026. Deductions for FY 2024-25 sit under Income Tax Act 1961; deductions for FY 2025-26 sit under Income Tax Act 2025 Section 393 payment codes 1001-1092. A rate-by-date lookup that does not know which era a transaction belongs to will apply the wrong section, the wrong threshold, and — critically for reconciliation — quote the wrong reason code in the Form 26AS mismatch. TransactIG resolves the applicable rate for every payment code and every date, across the era boundary, using the CBDT-published mapping. TRACES portal reconciliation stays clean because the underlying rate lookup is right.

Every rupee, machine-readable evidence

Every variance carries a machine-readable evidence trail: the source file, the ledger entry it reconciled against, the rule that classified it, and the timestamped decision. Auditors don't ask for evidence — the envelope IS evidence.

Companies Act 2013 Rule 3(1) proviso — the audit-trail requirement that took effect on 1 April 2023 — obliges every company maintaining books through accounting software to log edits and deletions with user identity and date. TransactIG's Recon Output Envelope goes materially beyond the minimum. Every reconciliation decision is timestamped. Every classification carries the identifier of the rule that produced it. Every match links back to the specific source-file row and the specific ledger entry that reconciled it. Every override captures the user, the timestamp, and the reason code.

This is what changes the shape of a statutory audit. Instead of a mid-audit request for supporting documentation followed by a reconstruction exercise, the auditor receives an envelope that already contains the evidence. Sampling a variance shows the source file, the ledger entry, the rule that classified it, and the decision timestamp — with no email trail to chase. Concurrent audit teams working under RBI-mandated timelines for NBFCs and banks operate against the same envelope structure, which is why turnaround shrinks without headcount growth.

The technical shape of the envelope is documented in the developer documentation — including field-level schema, error semantics, and versioning behaviour. It is the same evidence structure the audit team consumes and the same structure the finance team's workflow tools query, so there is no reconciliation-of-the-reconciliation problem downstream.