Multi-entity APAC holding groups can unify financial reporting across subsidiaries running different ERP systems by building a consolidation layer above their existing platforms rather than replacing them.
The practical path combines a purpose-built consolidation platform (such as OneStream, Oracle EPM, or CCH Tagetik) with standardized data integration protocols (XBRL, REST, OData) and automated intercompany reconciliation software to produce group-level reports while each subsidiary keeps the system it already operates.
TL;DR
A full ERP re-implementation is rarely the right answer. A consolidation layer above existing systems is faster, cheaper, and lower-risk.
The core technical problem is data harmonization across heterogeneous systems, solved through XBRL tagging, REST/OData APIs, and a shared chart of accounts.
Intercompany eliminations, multi-currency translation, and minority interest calculations are the three hardest consolidation tasks; modern platforms automate all three.
APAC-specific complexity (multiple tax regimes, currencies, and local GAAP variants) makes the architecture choices here different from a purely Western holding structure.
A dedicated integration team, not a one-off project team, is what keeps the consolidation layer healthy as subsidiaries add modules or change vendors.
About the Author: 724SOFTWARE has delivered ERP and financial systems across 10+ countries, including multi-entity Odoo and SAP deployments for holding groups in Vietnam, Singapore, and Hong Kong. As a Top 5 Odoo service partner in Vietnam with hands-on experience in both subsidiary-level ERP and group-level financial integration, the team brings an insider view of what actually breaks in consolidation projects.
Why Do APAC Holding Groups Struggle with Multi-Entity Consolidation More Than Their Western Counterparts?
The APAC context adds layers that a generic consolidation playbook does not cover. A holding group with subsidiaries in Vietnam, Indonesia, Singapore, and Japan is not just dealing with different ERP vendors. It is dealing with fundamentally different accounting standards (VAS in Vietnam, PSAK in Indonesia, SFRS in Singapore, J-GAAP in Japan), tax calendars that do not align, and currencies with varying liquidity profiles.
The result: the consolidation problem is not purely technical. It is a translation problem between regulatory environments, and any solution that ignores this produces reports that are technically aggregated but not actually comparable. Subsidiaries running SAP, Odoo, Microsoft Dynamics, and a locally-built system simultaneously is the normal state for many APAC holding groups, not an edge case.
What Is the Actual Architecture of a Consolidation Layer (and Why Does It Not Require Re-Implementation)?
A consolidation layer sits between subsidiary ERP systems and the group's reporting environment. Think of it as a translation bureau: each subsidiary speaks its own financial dialect, and the consolidation platform is the interpreter that produces one unified group language without forcing anyone to change how they speak locally.
The architecture has three components:
Data extraction: REST or OData APIs pull trial balance data, transaction records, and subsidiary reports from each source system on a defined schedule or in near-real-time [verified].
Transformation and mapping: XBRL tagging standardizes financial data so that "Revenue" in SAP and "Doanh thu" in a Vietnamese Odoo instance map to the same group-level account code [verified].
Consolidation engine: Platforms like OneStream, Anaplan, Planful, Oracle EPM, and CCH Tagetik apply automated intercompany eliminations, multi-currency translations, and ownership calculations for minority interests and equity pickups. They also handle top-side journal entries and pre-built logic for multiple reporting hierarchies such as GAAP and IFRS [verified].
The key insight: the subsidiary ERP is a ledger of record for local compliance. The consolidation platform is the group reporting system. These are two different jobs that do not need to run on the same software.
How Does Intercompany Reconciliation Software Fit Into This Picture?
Intercompany reconciliation software is where most APAC consolidations break down in practice. When a Singapore holding company sells a service to its Vietnamese subsidiary, that transaction appears as revenue in Singapore and an expense in Vietnam. Before the group can consolidate, both sides of the transaction must be confirmed, matched, and then eliminated from the group P&L.
Manual intercompany reconciliation at scale is unsustainable. A group with eight subsidiaries can have dozens of intercompany flows per month across loans, management fees, shared services, and inventory transfers. The matching problem compounds when each subsidiary closes its books on a different day.
Intercompany reconciliation software addresses this through:
Problem | Automated Solution
|
|---|---|
Mismatched transaction values across currencies | Real-time FX translation at a consistent rate per reporting period |
Different booking dates across entities | Configurable matching windows (e.g., +/- 3 days) |
Missing counterparty entries | Automated exception flagging before close |
Manual confirmation workflows | In-platform approval routing between entity finance teams |
Audit trail for eliminations | Immutable log of every matched and eliminated transaction |
The practical result is that the group consolidation close, which might take three to four weeks manually, can compress significantly once intercompany reconciliation software removes the back-and-forth between subsidiary controllers.
What Does the Phased Implementation Path Actually Look Like?
Stepping back from the technical architecture, a separate concern is sequencing. Most APAC holding groups make the mistake of trying to solve everything at once. A phased approach reduces risk without sacrificing the end goal.
Phase 1: Standardize the chart of accounts (months 1-3)
Before any platform is selected, map each subsidiary's existing account codes to a group-level chart of accounts. This is a finance and governance exercise, not a technology one. It is also the hardest phase because it requires subsidiary finance teams to agree on definitions.
Phase 2: Build the data extraction layer (months 3-6)
Stand up API connections or scheduled file extracts from each subsidiary ERP using REST or OData where the source system supports it, and flat-file ETL pipelines where it does not [verified]. Validate that the data arriving at the consolidation platform matches subsidiary trial balances exactly.
Phase 3: Configure the consolidation engine (months 6-9)
Configure elimination rules, currency translation methods, and ownership structures. Run parallel reporting alongside the existing manual process for at least one quarter before switching over.
Phase 4: Automate intercompany reconciliation (months 9-12)
Once the consolidation engine is stable, layer in intercompany reconciliation software and migrate intercompany matching from spreadsheets to the platform.
This phased path keeps subsidiaries on their existing ERP systems throughout. The group gains unified reporting without triggering local system replacements.
Frequently Asked Questions
How long does a consolidation layer implementation typically take for a 5-10 entity APAC holding group?
For a group with 5-10 entities, a phased implementation following the structure above typically runs 9-12 months to reach a stable automated close. The longest variable is the chart-of-accounts mapping exercise in Phase 1, which depends on how divergent subsidiary account structures are.
Can subsidiaries running locally-built or highly customized ERP systems connect to a consolidation platform?
Yes, but through a different route. Systems without REST or OData APIs typically export data as structured files (CSV, XML). A custom ETL pipeline maps these files to the group chart of accounts. It adds maintenance overhead but is technically feasible.
What is the difference between a consolidation platform and standard intercompany reconciliation software?
A consolidation platform manages the full group reporting process: currency translation, elimination entries, minority interests, and producing GAAP/IFRS statements. Intercompany reconciliation software specifically handles the matching and confirmation of transactions between entities before consolidation. The two tools work together; one does not replace the other.
How do APAC-specific local GAAP requirements affect the consolidation architecture?
The consolidation platform must maintain separate reporting hierarchies. Subsidiaries report locally under VAS, J-GAAP, or PSAK. The group reports under IFRS or US GAAP. Platforms like OneStream and Oracle EPM support multiple reporting hierarchies within a single system, meaning the same underlying data produces both local statutory and group IFRS reports without double-entry [verified].
Is a full ERP re-implementation ever the right answer?
Occasionally, yes. If a subsidiary's ERP is so outdated that it cannot produce a reliable trial balance export, the consolidation layer has nothing clean to work with. But this is a local modernization decision, not a group-wide re-implementation. Replace the outlier system; leave the others in place.
What security and compliance requirements should the consolidation layer meet for APAC financial data?
For groups operating in regulated APAC markets, the consolidation platform and any integration middleware should meet ISO 27001:2022 at minimum. Groups with Singapore or Australian entities will also encounter MAS and APRA expectations around data residency and access controls.
How does generative AI fit into this consolidation workflow?
AI can accelerate specific tasks: mapping subsidiary account codes to the group chart of accounts, detecting anomalies in intercompany flows before reconciliation, and drafting commentary for variance explanations in board packs. These are productivity gains on specific tasks, not a replacement for the consolidation architecture itself.
About 724SOFTWARE
724SOFTWARE is a Vietnam-based technology company with 200+ professionals, 58% of whom are senior-level engineers, delivering ERP, data, and custom software solutions across 10+ countries. As a Top 5 Odoo service partner in Vietnam with hands-on experience in SAP Business One, Microsoft Dynamics 365, and custom integration projects, 724SOFTWARE works with APAC holding groups as a long-term technology partner rather than a project-by-project vendor. The company is ISO 9001 and ISO 27001:2022 certified, SOC 2 Type II and GDPR compliant, and maintains a 95% client retention rate built on transparent billing and dedicated team models that clients can monitor directly.
If your holding group is working through a consolidation architecture decision or needs a dedicated team to build and maintain the integration layer between subsidiary ERP systems, the team at 724SOFTWARE is available to discuss your specific structure. Visit https://724software.com.vn/ to get in touch.
