A European mid-market industrial group opens a commercial subsidiary in Warsaw and acquires another in Seville. Its core ERP — SAP S/4HANA deployed three years ago at headquarters — runs smoothly. The question immediately arises: should the group extend S/4HANA to these two entities of 18 and 23 users respectively, or choose a lighter ERP and connect it to the central system?
This is the founding question of two-tier ERP strategy. And in 2026, the answer is not a vague “it depends”: it can be calculated, modelled, and architected.
This article is written for CIOs and IT managers at mid-market international groups managing between 3 and 15 subsidiaries, who are thinking through their ERP architecture. It complements our guide on multi-ERP strategy for groups, our reference on multi-site and intercompany consolidation, and our iPaaS architecture comparison.
1. What is the Two-Tier ERP Strategy?
1.1 Tier 1 vs Tier 2 ERP: respective roles
The two-tier ERP strategy means deliberately running two categories of ERP within a single group: a Tier 1 ERP for headquarters and large entities, and a Tier 2 ERP for subsidiaries or business units with simpler needs.
The Tier 1 handles the most complex group-wide processes: IFRS financial consolidation, multi-site production management, advanced tax compliance, international supply chain, and executive reporting. Vendors positioned here include SAP S/4HANA (RISE with SAP), Oracle Cloud ERP, Dynamics 365 Finance & Operations, and to a lesser extent Infor CloudSuite. These platforms are powerful and highly configurable, but costly to deploy and operate.
The Tier 2 covers the common needs of a subsidiary: local accounting, customer and supplier invoicing, basic stock management, CRM, payroll. It must be deployable quickly (within 3 to 6 months), maintained at a reasonable cost, and compliant with the local tax and accounting obligations of each country. The leading solutions in this segment are SAP S/4HANA Cloud Public Edition (GROW with SAP), Oracle NetSuite, Microsoft Dynamics 365 Business Central, and Odoo.
This is not an accidental multi-ERP landscape born from successive acquisitions and sedimentary IT legacies. It is a deliberate architecture, with governance and integration designed from the outset. The distinction is fundamental.
1.2 Why “one size fits all” doesn’t work for multi-country groups
Deploying a Tier 1 ERP across every entity of an international group looks attractive on paper: a single reference system, native consolidation, shared support. In practice, three obstacles make this approach unworkable for smaller subsidiaries.
First, disproportionate licensing costs. Tier 1 vendors price their licenses by deployment size, but their contractual minimums remain high even for 15-user deployments. Extending a SAP S/4HANA RISE contract to a 20-person subsidiary often costs two to three times what that entity would spend on an appropriate Tier 2 ERP.
Second, deployment timelines incompatible with operational reality. A standard S/4HANA or Oracle Cloud ERP project at an international subsidiary takes 12 to 24 months. A newly acquired subsidiary needs to be operational within 3 to 6 months. The two-tier approach lets you bring the subsidiary online with a rapidly deployed Tier 2, while the integration to the Tier 1 is planned at a comfortable pace.
Third, local regulatory requirements that the central ERP does not natively cover. Mandatory e-invoicing in Italy (SDI), the SII declaration in Spain, the e-Factura system in Romania: these country-specific tax localizations are often better supported by Tier 2 vendors who dedicate local teams to maintaining them.
Gartner, in its research note “Two-Tier ERP: A Useful, Composable ERP Strategy for Complex Organizations”, views two-tier as one of the concrete expressions of composable ERP: each layer of the group uses the tool best suited to its operational complexity.
2. When Does the Two-Tier Strategy Become the Right Choice?
2.1 Subsidiary size threshold: the 50 active ERP users rule
The most widely used rule of thumb among ERP integrators is the 50 active ERP users per subsidiary threshold. Below this number, the total cost of ownership of a Tier 1 ERP — licenses, deployment, training, and annual support — is disproportionate relative to the value generated for that entity.
A simplified calculation illustrates the logic: a SAP S/4HANA RISE license for 20 subsidiary users costs on average €30,000 to €50,000 per year, plus €150,000 to €250,000 in initial deployment. Over five years, total cost frequently exceeds €350,000. The same functional scope covered by Dynamics 365 Business Central or NetSuite costs €60,000 to €120,000 over five years for the same subsidiary, depending on activated modules.
Above 50 users, the balance tips toward Tier 1: operational complexity justifies the tool’s power, and the per-user cost becomes competitive.
2.2 Business-specific needs incompatible with the central ERP
Some subsidiary business models structurally resist the central ERP. A distribution subsidiary recently acquired by an industrial SAP group will have CRM and e-commerce requirements that S/4HANA covers poorly natively. A professional services subsidiary needs a PSA (Professional Services Automation) that the group’s manufacturing ERP does not provide.
In these cases, the Tier 2 is not a temporary workaround. It is the business-appropriate tool, integrated with the Tier 1 only for financial flows (revenue reporting, receivables, payables, and provisions).
2.3 Local regulatory requirements
Local tax compliance is often the most decisive argument. Subsidiaries in countries with advanced digital tax regulation — Italy, Spain, Poland, Romania — need an ERP that is localized and certified in-country. Configuring a generic central ERP to handle these obligations costs more, and takes longer, than adopting a Tier 2 whose vendor already maintains that localization.
2.4 Prohibitive deployment costs for the central ERP in small entities
The deployment cost of a Tier 1 ERP at a small subsidiary is rarely linear. SAP or Oracle consultants bill at the same rates as for a headquarters project. The risk of over-investment on a limited scope is real. A project that would have cost €200,000 for 100 HQ users may cost €150,000 for 15 subsidiary users, with features used at only 30% of their capacity.
3. The 4 Most Common Two-Tier Combinations in 2026
3.1 SAP S/4HANA + Microsoft Dynamics 365 Business Central
The most widespread combination in European mid-market groups. HQ runs on SAP S/4HANA (RISE with SAP, private cloud); subsidiaries of fewer than 80 users run on Dynamics 365 Business Central.
Integration runs through an iPaaS — Azure Integration Services or MuleSoft depending on the group’s technical stack. Financial flows — intercompany invoices, shared supplier master data, monthly consolidation — are synchronized via standardized APIs. Vendor heterogeneity is managed by the iPaaS, which requires a dedicated integration team.
3.2 Oracle Cloud ERP + NetSuite (multi-currency subsidiaries)
Oracle acquired NetSuite in 2016 precisely to structure this two-tier architecture. Oracle Cloud ERP handles the finances of headquarters and large entities; NetSuite OneWorld equips international subsidiaries, with native multi-currency and multi-entity management.
Integration is handled by SuiteCloud Connect for Oracle, a native connector that synchronizes financial data between the two tiers (NetSuite Two-Tier ERP for Oracle). The major advantage: with both vendors belonging to the same group, contractual governance and product roadmaps are aligned.
3.3 SAP or Oracle + Odoo (subsidiaries under 30 users)
For the smallest subsidiaries — fewer than 30 users with basic needs in accounting, invoicing, and CRM — Odoo stands out as the most cost-effective Tier 2. Its license starts at $24.90 per user per month (Odoo Pricing 2026). A straightforward deployment can be completed in 4 to 8 weeks.
Integration with a SAP or Oracle central system requires an iPaaS: Odoo offers no native connector to these Tier 1 vendors. Synchronization is generally limited to essential financial data — customer and supplier accounts, trial balance — to feed group consolidation. This is sufficient if the subsidiary operates independently.
3.4 Dynamics 365 Finance & Operations + Business Central
The most technically seamless combination. Microsoft designed Business Central as the natural Tier 2 companion for Dynamics 365 Finance & Operations. Both products share the Microsoft Dataverse layer, which significantly simplifies data synchronization: contacts, items, and chart of accounts can be shared via standard connectors, without custom iPaaS development (Two-Tier ERP Strategy with Business Central).
The decisive advantage: a single Microsoft contract, a single support team, and shared consulting skills. The overhead of managing a distinct Tier 2 is significantly reduced.
4. Integration Architecture: Making Both Tiers Work Together
4.1 Financial synchronization: consolidation, intercompany, multi-currency
The cardinal rule of two-tier strategy is this: the Tier 2 ERP must never create financial silos. Financial data from subsidiaries — revenue, trade receivables, payables, provisions — must flow up to the Tier 1 or to the CPM (Corporate Performance Management) consolidation platform, on a defined schedule and in a defined format.
Multi-currency consolidation requires the Tier 2 to transmit data in the group’s reporting currency (typically EUR or USD), with the exchange rates used at period close, so that unrealized currency gains and losses are correctly calculated. A Tier 2 that exports local-currency balances without attached exchange rates forces the consolidation team into time-consuming manual reworking.
4.2 Real-time vs batch interfaces: when to use each
Not all synchronization flows require the same frequency. A pragmatic framework distinguishes two categories:
Real-time (or near-real-time, delay < 15 minutes): available stock for intercompany customer orders, treasury position for financing management, intragroup delivery statuses. These flows drive immediate operational decisions.
Batch (daily or monthly): accounting trial balance, cost justifications, analytical positions, HR data. These flows feed planned close processes; latency is not critical.
Over-engineering real-time interfaces increases middleware costs and monitoring complexity. It is better to map flows by criticality and choose the right frequency rather than defaulting to real-time everywhere.
4.3 iPaaS and middleware: selection criteria
Three platforms dominate the ERP-to-ERP integration market in Europe:
Azure Integration Services: the natural choice when the Tier 1 is Dynamics 365 and the Tier 2 is Business Central. With both products on Azure, latency is minimal and native connectors reduce custom development.
MuleSoft (Anypoint Platform): the reference tool for SAP-Salesforce or SAP-multi-ERP stacks. Its library of SAP-certified connectors is extensive. The initial investment is high (licensing, training), but it absorbs complex integration architectures.
Dell Boomi: vendor-agnostic, with solid coverage of mid-market platforms (NetSuite, Odoo, Sage). Connection-based licensing model, suited to modest two-tier architectures.
The primary selection criterion is not the tool itself: it is the existence of in-house or partner skills to operate it sustainably. An iPaaS that no one masters internally becomes a bottleneck the moment the first integration change is needed.
5. Governance and Pitfalls to Avoid
5.1 Shadow IT and progressive fragmentation
The greatest risk of the two-tier model is uncontrolled expansion. A subsidiary deploys its Tier 2. Six months later, the subsidiary adds an unconnected expense management tool, then a local CRM because the Tier 2 “doesn’t do CRM well enough.” The two-tier becomes three-tier, then five-tier.
Governance must define from the outset a closed list of tools authorized alongside the Tier 2, with pre-validated integrations. Any addition outside the list must go through a group IT decision, not the subsidiary acting unilaterally.
5.2 Dual maintenance and dual training
The two-tier strategy structurally implies two separate software lifecycles. Version upgrades for the Tier 1 and Tier 2 are not synchronized. A major update on one side can break an interface on the other, if that interface relies on a versioned API.
The group IT team must maintain skills on both systems, or contract dedicated partners for each. This management cost is frequently underestimated in the initial business case.
5.3 Data ownership and cross-system master data
In a two-tier architecture, the same data entities often exist in both systems: vendor Acme exists in both the Tier 1 and the Tier 2. The question of the single source of truth must be explicitly settled: who creates new vendor records? In which system? What is the propagation process?
Without a clear decision, duplicates proliferate, accounting codes diverge, and consolidation becomes an exercise in endless manual reconciliation.
6. Four Mid-Market Profiles and Recommendations
Industrial group, 500 HQ users, 3 commercial subsidiaries of 15 to 25 users each in Central and Eastern Europe. Core ERP is SAP S/4HANA RISE. Recommendation: Odoo for the subsidiaries, integrated via MuleSoft or Azure Integration Services for financial flows. Expected ROI: total two-tier cost 40–60% lower than a uniform SAP deployment, for subsidiaries whose business requirements are 90% covered by Odoo.
Professional services group, 200 HQ users, 5 subsidiaries across Europe with 30 to 60 users each. Dynamics 365 Finance & Operations at headquarters. Recommendation: Business Central at subsidiaries, integration via Dataverse. Advantage: a single Microsoft ecosystem, shared skills, unified contract.
Multi-country e-commerce company, HQ in the Netherlands, subsidiaries that expand with geographic growth. Recommendation: Oracle Cloud ERP at HQ, NetSuite OneWorld for subsidiaries from day one. NetSuite’s SaaS model allows a new entity to go live in 6 to 8 weeks, without a heavy IT project.
Group resulting from a recent acquisition. The acquired subsidiary runs on an existing ERP. Recommendation: do not migrate immediately. Treat the existing ERP as a transitional Tier 2, build the minimum financial integration for group consolidation, and plan convergence at 18–24 months post-acquisition. Operational stability after an acquisition is worth more than immediate architectural purity.
Conclusion
Two-tier ERP strategy is not a compromise: it is a rational architecture for groups that refuse to make their small subsidiaries pay for a Tier 1 ERP designed for thousands of users. It works when three conditions are met: rigorous financial integration between the two tiers, clear governance over which tools are authorized alongside the Tier 2, and an IT team capable of maintaining skills across both systems.
The four combinations described in this article — SAP + Business Central, Oracle + NetSuite, SAP/Oracle + Odoo, and D365 F&O + Business Central — are not universal recipes. They are starting points to adapt to each subsidiary’s profile, the roadmap of the chosen Tier 1 vendor, and local regulatory requirements.
Download our ERP evaluation framework to benchmark your Tier 1 and Tier 2 options across 30 weighted criteria, from licensing cost to the maturity of local tax compliance coverage in Europe.
