Two-Tier ERP
A two-tier ERP architecture deploys different ERP systems for different parts of a group: a heavyweight enterprise ERP (SAP S/4HANA, Oracle Cloud ERP, Microsoft Dynamics 365 F&O) at headquarters and major operating entities; a lighter, often cloud-native ERP (Microsoft Dynamics 365 Business Central, NetSuite, weclapp, Sage) at subsidiaries, recent acquisitions or smaller country operations. The tiers are connected for financial consolidation and master-data synchronisation, but operate independently otherwise.
Why two-tier instead of single ERP
Single-ERP rollouts struggle when the group includes entities of very different sizes and operational complexity. Forcing a 30-employee Italian sales subsidiary onto SAP S/4HANA — the same system used by the 5,000-employee German HQ — results in months of implementation overhead, expensive licences, and a system the subsidiary cannot operate without dedicated IT staff. Two-tier ERP fixes this by acknowledging the size difference: HQ and major entities run the enterprise system, smaller entities run a right-sized system, both feed the financial consolidation and master-data layer. Industry analysts (Gartner, IDC) have called this approach a default best-practice for diverse multinational groups since the mid-2010s.
Typical two-tier combinations
SAP S/4HANA + Microsoft Dynamics 365 Business Central — the most common large-enterprise pairing. SAP at the group headquarters and major manufacturing or sales entities, Business Central at smaller country subsidiaries. SAP-side connectors and Microsoft-side connectors make this combination operationally smooth. Oracle Cloud ERP + NetSuite — Oracle's own two-tier story, with NetSuite as the SMB tier and Oracle Fusion for the enterprise tier. Tight Oracle-internal integration. SAP S/4HANA + SAP Business One — SAP's own two-tier offering, with Business One at smaller subsidiaries. Less common in DACH mid-market than the SAP+Business Central combination. Microsoft Dynamics 365 F&O + Business Central — Microsoft's own two-tier story for groups that have standardised on Microsoft.
Integration architecture
Two-tier ERP requires four kinds of integration. (1) Financial consolidation: subsidiary trial balances flow into the group consolidation tool (SAP Group Reporting, OneStream, LucaNet, Tagetik) monthly. (2) Master-data sync: customer, supplier and product master data flow between tiers as defined by ownership (usually HQ-owned, distributed to subsidiaries). (3) Intercompany transactions: cross-entity deliveries, services and royalty flows generate matching journal entries in both tiers. (4) Reporting: group-wide BI requires data flowing from both tiers to a common analytics layer. Integration via iPaaS (Mulesoft, Boomi, Azure Logic Apps), point-to-point connectors, or the consolidation tool's native data hub.
Risks and trade-offs
Two-tier ERP solves the size-mismatch problem but introduces its own challenges. Operational silos: two different ERPs need two sets of expertise and operational practices. Master-data drift: without strict governance, customer and product data diverge between tiers. Reporting complexity: comparing apples-to-apples across tiers requires structural mapping that can be fragile. Acquisition integration: acquired entities running yet another ERP add a third tier in practice, undermining the two-tier discipline. Successful two-tier programmes establish clear ownership: HQ owns master-data design, financial-consolidation rules and the integration architecture; subsidiaries own operational execution within those rules.
Related Topics
Frequently Asked Questions
When does two-tier ERP make sense?
When the group spans 5+ legal entities with very different sizes (HQ 1,000+ employees, subsidiaries 10-100 employees), operates in multiple countries with different tax and process requirements, and grew partly through acquisition rather than greenfield expansion. Below 5 entities or with similar sizes, a single ERP is usually simpler.
Can a subsidiary use Excel instead of a real second-tier ERP?
For very small subsidiaries (under 5 employees, simple operations), Excel plus a basic bookkeeping tool can work, with the data flowing to group consolidation via structured export. Anything above 10 employees with inventory or order management usually warrants a proper second-tier ERP — Business Central, NetSuite or weclapp typically.
Is two-tier ERP just delayed migration to a single system?
Sometimes yes, sometimes no. Groups with persistent operational diversity (different industries per subsidiary, very different sizes) maintain two-tier permanently. Groups that pursue operational standardisation eventually migrate the second tier into the first, typically over 5-10 years. The decision is strategic, not technical.