Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Indian groups increasingly operate across multiple industries — a lending holding company with an NBFC arm, a rental-property arm, and a fintech subsidiary; a hospital chain that also runs a pharmacy retail business; a diversified conglomerate that touches jewellery retail, real estate, streaming media, and healthcare. Each industry has statutory rules that differ materially: GST composite-supply for hospitals versus mixed-slab pricing for jewellers, RERA escrow for developers versus PG settlement for OTT platforms, Section 194IA on property transfer versus Section 194O on marketplace commissions. Running a separate reconciliation system per industry doubles the audit training burden, multiplies the integration cost, fragments the audit trail across formats the CFO's auditor cannot compare, and blocks Ind AS 108 segment consolidation because the reconciling items across segments no longer share a common taxonomy.
Build a single reconciliation engine — the matching primitives, the accounting-identity checks, the paise-exact rounding, the audit-trail recorder — and express every industry-specific rule as a configuration bundle loaded at run time. The configuration bundle carries the rate matrix (GST slabs, TDS section rates, TCS rates for the industry), the field mappings (bank narration formats, ERP journal patterns, gateway settlement schema), the variance taxonomy overlay (industry-specific reason codes), the reconciliation cadence, and the settlement flow. The engine reads the configuration at reconciliation start, applies the industry rules, and produces the same audit-trail record format regardless of which industry configuration was loaded. When a group consolidates for Ind AS 108 segment reporting, the reconciling items across segments share a common variance taxonomy because the engine is common.
Industry preset library covering the 24 industries in scope (jewellery retail, residential real estate, gold-loan NBFC, streaming and OTT, hospital and healthcare, FMCG general trade, auto components, pharmaceuticals, IT services, hospitality, quick commerce, restaurant chains, retail modern trade, D2C brands, education services, logistics 3PL, insurance intermediary, financial services broker, media agency, telecom, EPC contractors, cooperative bank, digital lending, and account aggregator). Each preset carries: rate matrix by HSN or SAC, section-code map to the Income-tax Act 2025 taxonomy, GST composite-supply rules where relevant, ERP field mappings (SAP, Oracle Fusion, Tally, Zoho, MS Dynamics), bank narration parsers by acquiring bank, variance taxonomy layered on the shared root taxonomy, reconciliation cadence, and settlement flow. Configuration is versioned and audit-traced under Rule 3(1).
A multi-industry group runs one deployment of the reconciliation platform, loads one industry configuration per subsidiary, closes each subsidiary's books using rules native to its industry, and consolidates the whole group under Ind AS 108 with reconciling items expressed in a common variance taxonomy. The audit trail — every match, every classification, every re-run — is captured in a single edit-log format across all industries, meeting Rule 3(1) of the Companies (Accounts) Rules 2014. The 24-industry catalogue is extended as new configuration bundles rather than new codebases, and the engine version that runs the jeweller's close is the identical engine version that runs the hospital's close.
A national conglomerate closes its March books across five subsidiaries. The jewellery-retail arm carries 4,200 store transactions across the 3, 5, and 18 percent GST slabs — bullion at 3 percent, gold jewellery with making charges at 5 percent, and packaging and accessories at 18 percent. The residential-real-estate arm settles 47 property transfers with Section 194IA TDS at 1 percent per buyer, 70 percent of receipts sitting in RERA escrow awaiting completion-certificate withdrawal. The gold-loan NBFC arm books 12,400 loan disbursements with LTV drift against the day’s IBJA gold rate, 340 auction closures against post-default surplus payable to the borrower under Section 25 of the Sale of Goods Act. The OTT-streaming arm receives 2.1 million payment-gateway settlement lines net of MDR and Section 52 TCS. The hospital-chain arm closes 8,900 cashless claims through the TPA network with Ayushman Bharat and CGHS reimbursement windows layered on top. Five industries, five statutory frameworks, one closing week. The group’s controller runs the reconciliation for all five subsidiaries on the same platform, loading a different multi-tenant reconciliation architecture India configuration for each. That the same engine services all five is not an accident; it is a deliberate architectural choice with direct consequences for Ind AS 108 segment reporting, Companies Act 2013 audit-trail defensibility, and the group’s month-end close time.
The claim in one paragraph
A jeweller with mixed 3, 5, and 18 percent GST slabs, a residential developer running RERA escrow and Section 194IA property-transfer TDS, a gold-loan NBFC monitoring LTV drift and auction surplus, an OTT streaming platform reconciling payment-gateway settlement net of MDR and Section 52 TCS, and a hospital chain closing cashless TPA claims all reconcile on the same platform. The differences that distinguish these industries — rate matrices, field mappings, variance codes, settlement flows — live in configuration bundles layered on top of a shared engine, not in per-industry forks of the codebase. When a group consolidates across these subsidiaries for Ind AS 108 segment reporting, the reconciling items between segments and the consolidation share a common taxonomy because the engine that produced them is common. The Why TransactIG position is built on this discipline — one engine, 24 industry presets, and no per-tenant code branches.
Why this matters for a multi-industry group’s CFO and auditor
Three practical consequences flow directly from the single-engine architecture, and each shows up in the audit committee report at year-end.
First, the audit-training burden collapses. When a Big Four audit partner is engaged to sign off on a five-subsidiary conglomerate, the partner’s team must understand the reconciliation output for each subsidiary. If each subsidiary runs on a different system, the team learns five different systems — five different variance taxonomies, five different audit-trail formats, five different re-run mechanisms — and the audit cost inflates accordingly. When every subsidiary runs on the same engine with different presets, the team learns the engine once and reads five different configurations. The audit sign-off cycle compresses.
Second, the Ind AS 108 segment consolidation becomes traceable. The standard requires per-segment disclosure of revenue, results, assets, and liabilities on the basis the chief operating decision maker reviews them, and the segments must reconcile back to the consolidated totals in the financial statements. When each segment runs on a forked reconciliation system, the reconciling items between segments and the consolidation are opaque — a variance labelled “PG chargeback” in the retail segment might mean something entirely different from a variance labelled “PG chargeback” in the OTT segment because the labelling authorities are different. When every segment runs on the same engine, the taxonomy is shared, and the consolidation reconciles cleanly.
Third — and this is where most systems fail — the audit trail under Rule 3(1) of the Companies (Accounts) Rules 2014 is uniformly defensible. The proviso, effective 1 April 2023, requires every company using accounting software to maintain a recorded audit trail of each transaction, creating an edit log of every change with dates, and to preserve that trail as long as the underlying records. In most systems, each industry-specific fork records its edit log in a subtly different format — different field names, different timestamp resolutions, different change-set semantics. Under audit inspection, the auditor must map each format to the Rule 3(1) requirement independently. The common-engine architecture produces one edit-log format across all industries, and the audit test reduces to a single mapping exercise.
Here is what breaks in most reconciliation systems. A conglomerate deploys the leading global AR platform for its retail arm, a domestic reconciliation tool for its NBFC arm, and a hospital-specific claims system for its healthcare arm. Year-end consolidation for Ind AS 108 arrives, and the group finance team must manually reconcile variance categories across three systems that use three vocabularies. A “settlement variance” in the retail system corresponds to some subset of “MDR variance” plus “chargeback” plus “PG-fee reconciliation” in the NBFC system, and to “TPA short-settlement” in the hospital system. The mapping exercise takes two weeks of finance-team time every quarter. When the auditor requests re-runs of prior periods to test consistency, each system re-runs on its own schedule and produces artefacts in its own format. The consolidation is possible but expensive, and the audit sign-off carries an implicit qualification that the finance team knows about even if the audit letter does not spell it out.
The Indian regulatory and accounting framework
Four statutes anchor the single-engine architecture claim, and each ties directly to a specific consequence of the design.
Section 129 of the Companies Act 2013 read with Schedule III requires every company to prepare financial statements that give a true and fair view and to disclose per-segment information for multi-industry operations. The financial statements must comply with Ind AS notified under Section 133, and the reconciliation to the trial balance is the auditor’s primary test object under CARO 2020. When the reconciliation engine is common across segments, the reconciliation-to-trial-balance test uses a common set of primitives across every subsidiary — a variance identified in one segment can be traced back through the same matching logic that identifies variances in every other segment.
Rule 3(1) proviso of the Companies (Accounts) Rules 2014 — the audit-trail obligation effective 1 April 2023 — is the statutory anchor for the edit-log uniformity argument. Every reconciliation decision recorded by the engine is a transaction whose audit trail must be preserved as long as the underlying records. When the recording format is common across industries, the preservation duty is discharged in a single format and read in a single format.
Ind AS 108 (Operating Segments) requires a multi-industry entity to disclose per-segment revenue, results, assets, and liabilities on the basis the chief operating decision maker reviews them, and the segments must reconcile back to the consolidated totals. The standard also treats change in the definition of operating segments and change in the accounting policy applied to segments as change-in-estimate events under Ind AS 8, requiring restated comparatives. The common-engine architecture makes restated comparatives feasible because the engine version that produced the original numbers is documented and can be re-run against the same configuration bundle to reproduce the numbers exactly.
Section 8 read with Section 15 of the CGST Act 2017 governs composite and mixed supply and the value determination that follows. This is the statutory anchor for industry-specific GST treatment. The same engine must resolve a jeweller’s mixed-slab making-charge invoice, a hospital’s composite room-plus-food-plus-consumables billing, and a telecom operator’s bundled voice-plus-data-plus-content billing on the same taxable-value logic — layering industry-specific classification rules on top of a shared valuation primitive. The engine that gets Section 15 wrong for a jeweller gets it wrong for every industry; the engine that gets it right in one industry gets it right in every industry because the underlying valuation logic is shared.
A worked example — a diversified group with two very different subsidiaries
A national healthcare group operates two subsidiaries. The clinical operation runs 32 hospitals and 74 outpatient clinics across seven states, closing 8,900 cashless TPA claims per month plus Ayushman Bharat empanelled cases and CGHS reimbursements. The retail-pharmacy operation runs 480 owned pharmacies and a marketplace platform aggregating 2,100 third-party pharmacies, closing 1.4 million pharmacy transactions per month with a mix of walk-in cash sales, prescription-linked insurance reimbursements, and marketplace commission arrangements. The two subsidiaries file consolidated Ind AS 108 segment disclosures under a single audit engagement.
Illustrative — the operating scale and mix are representative of a mid-to-large diversified healthcare group; specific transaction counts and mix are indicative, not drawn from any single company’s disclosures. Cross-verify against your own operational data before relying on the numbers.
The clinical subsidiary runs the reconciliation platform with the healthcare industry preset loaded. The preset carries: HSN mapping to 9993 (human health services, GST exempt or 5 percent based on room-rent thresholds), settlement window mapping to the TPA network SLAs (typically 30 to 45 days for private TPAs, 60 to 90 days for Ayushman Bharat, 15 to 30 days for CGHS with a separate refund cycle), variance taxonomy overlay covering short-settlement, deduction disputes, and denial reasons per IRDAI notification, and reconciliation cadence set monthly with a weekly TPA-network follow-up cycle. The Section 194J TDS on professional fees paid to specialists — the corresponding entry under Section 393(1) Sl. 20 of the Income-tax Act 2025 — is layered into the settlement-flow configuration.
The retail-pharmacy subsidiary runs the same reconciliation platform with the retail modern-trade preset loaded. The preset carries: HSN mapping across the pharmacy product range (5 percent on most life-saving drugs per the September 2025 GST 2.0 notifications; 12 percent on some formulations; 18 percent on OTC and wellness lines), Section 194O TDS on the marketplace commission side (payment code 1028 for the successor to legacy Section 194O), Section 269ST cash-transaction cap enforcement on individual store sales, GST composite-supply treatment where prescription counselling is bundled with dispensing, and reconciliation cadence set weekly (retail-velocity demands faster close than clinical).
Both subsidiaries close month-end on the same engine. The audit-trail record — every claim matched to a TPA settlement, every pharmacy sale matched to a cash-collection, every marketplace commission reconciled to the aggregator’s payout — sits in a single edit-log format. When the group consolidates for Ind AS 108 segment reporting, the reconciling items across the two segments use a common variance taxonomy. A “short-settlement” variance in the clinical segment and a “short-payout” variance in the retail segment share the same root taxonomy node, and the group’s audit committee reads a single consolidated reconciling-items table rather than two incompatible tables stitched together.
Here is the tangible year-end consequence. The audit engagement partner requests a re-run of Q2 for both subsidiaries to test consistency with the closing December numbers. On the common-engine architecture, the finance team loads the Q2 configuration versions, points the engine at the Q2 input data, and re-runs — the engine version that produced Q2 is the same engine version running today, so the numbers reproduce byte-for-byte. Re-running last quarter produces the same envelope, exactly. On a per-subsidiary fork architecture, the re-run for the clinical subsidiary and the re-run for the pharmacy subsidiary use two different engine versions across two different vendors, each with its own re-run mechanism, and the auditor either accepts the operational risk of small drifts or spends a week reconciling the drift to non-material reasons.
What this means for you at each altitude
Chief financial officer. Adding a new subsidiary or a new industry is a configuration exercise on top of an already-running engine, not a fresh deployment cycle. Adding a jewellery arm to an existing multi-industry deployment is a configuration exercise on top of an already-running engine, not a fresh deployment. The controller closing the group books on 30 September has one engine to trust, not five.
Group financial controller and finance director. The variance taxonomy is shared across segments. When you present the audit committee with a consolidated reconciling-items table for Ind AS 108, the categories are consistent — “PG chargeback” means the same thing in retail as in OTT, “short-settlement” means the same thing in healthcare as in NBFC. The consolidation exercise reconciles cleanly across the group’s entities without a bespoke integration per subsidiary.
Statutory audit partner. A single reconciliation engine across the group means one integration training covers every subsidiary. The audit team learns the engine once and reads five configurations. The Rule 3(1) audit-trail test runs against a single edit-log format. Re-run tests for prior periods reproduce the original numbers exactly because the engine version is documented and re-loadable.
Head of integrations or CIO. Adding a new industry preset is a configuration exercise against an already-running engine. There is no vendor scoping call for a new industry, no six-month deployment cycle, no separate SLA to negotiate. The engine that services the existing four subsidiaries services the fifth on the same infrastructure with the same operational discipline.
Head of internal audit. The audit-trail record — every match, every classification, every configuration change — is captured in a single format across all industries. When you sample transactions from the retail segment for testing, the artefact you receive is structurally identical to the artefact you would receive from sampling the healthcare segment. Test procedures do not need to be re-authored per industry.
Operations lead for a specific subsidiary. The industry preset for your specific industry captures the rate matrix, the field mappings, and the variance taxonomy in a form that reflects native industry practice. You are not translating industry rules into a generic reconciliation vocabulary — the vocabulary is native. But the audit-trail record and the accounting-identity checks that guard your close are the same guardrails that protect every other subsidiary, which means the operational discipline is transferable across the group.
How TransactIG delivers this in practice
TransactIG is one engine that services 24 industry presets today, extended by adding configuration bundles rather than by forking the codebase. A jeweller with mixed GST slabs, a residential developer with RERA escrow and Section 194IA TDS, a gold-loan NBFC with LTV drift and auction surplus, an OTT platform with payment-gateway settlement and Section 52 TCS, and a hospital chain with cashless TPA claims all run on the same platform with different industry configurations loaded at run time. The variance taxonomy that classifies a mismatch is shared across industries — the patent-filed taxonomy that TransactIG maintains covers the material variance categories seen in Indian reconciliation practice, extended by industry-specific reason codes where the industry demands them. The audit trail is uniform across every industry, captured in a single edit-log format that meets Rule 3(1) of the Companies (Accounts) Rules 2014. When a diversified group consolidates for Ind AS 108 segment reporting, the reconciling items across segments share a common taxonomy because the engine that produced them is common. New industries onboard as configuration bundles, and the 24-industry catalogue grows without disrupting the deployments already in production. Group deployments benefit from a common training burden, a common audit-trail format, and a common re-run mechanism across every subsidiary — the properties that distinguish TransactIG’s product principles from single-industry point solutions and from global platforms not built around Indian regulatory practice. The same engine that produces deterministic reconciliation and audit reproducibility in one industry produces it in every industry, and the accounting identity gates that guard money conservation in a hospital’s cashless close guard it in a jeweller’s making-charge reconciliation.
For groups running across multiple industries, the further reading in the audit and assurance cluster covers the statutory audit checklist and ICFR obligations that the multi-industry architecture is designed to support. The buyer’s guide covers the evaluation criteria for a group RFP where industry breadth matters as much as depth in any single industry. And the reconciliation fundamentals cluster anchors the concepts — matching, variance classification, audit trail — that apply uniformly across every industry the engine services.
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →