The decision you make at the start of your international ERP programme locks in your architecture for at least five years. Should you deploy a single shared template across all subsidiaries, or let each country manage its own local instance? Should you impose a core model from headquarters, or federate entities that already function well independently?
This governance question — as strategic as a merger or acquisition decision — is all too often addressed too late, after technical choices have already been made, sometimes under pressure from a vendor pushing its preferred module. This guide gives you the decision framework to avoid being trapped in an architecture that does not match your operational reality.
The 3 International ERP Governance Models
Before talking technology, clarify your governance model. There are fundamentally three.
Centralised Model: One Template, One Global Instance
In this model, headquarters defines a core ERP model that applies to all subsidiaries. Every entity shares the same application instance, the same group chart of accounts, the same Order-to-Cash, Procure-to-Pay and Record-to-Report processes.
The advantages are real: consolidated real-time visibility with no reconciliation overhead, reduced maintenance cost (a single version to maintain), consistent group reporting. This is the model favoured by integrated groups where subsidiaries run the same business — national distributors of a retail group, commercial subsidiaries of an industrial conglomerate.
The limitations are equally real: local teams resist strongly, each subsidiary has its own habits, its own customers, sometimes its own brand identity. Above all, local regulatory requirements (local charts of accounts, payroll, VAT, e-invoicing) force adaptations that, if not properly managed, turn the shared template into an unmanageable patchwork.
Federated Model: Independent Local Instances with Limited Synchronisation
The federated model lets each country or subsidiary choose (or keep) its own ERP, with consolidation or data exchange interfaces between instances.
This model suits multi-sector conglomerates where subsidiaries operate in fundamentally different businesses, groups built through rapid acquisitions where harmonisation takes time, and groups whose subsidiaries have strong operational and commercial autonomy.
The main drawback: financial consolidation remains expensive in time and resources. Without a dedicated consolidation layer (Tagetik, Lucanet, OneStream, SAP Group Reporting…), teams end up maintaining complex ETL pipelines between heterogeneous systems.
Hybrid Model: Shared Common Core with Country-Level Regulatory Localisation
This is the most common model in mid-market European groups with 500 to 5,000 employees. Headquarters defines a common core model for cross-entity processes (group procurement, consolidated financial reporting, group-level inventory management), while each country retains its own configuration for local regulatory obligations.
In SAP S/4HANA, this takes the form of a group chart of accounts paired with local charts of accounts per country. In Odoo, it is a main instance with country-specific modules (l10n_fr, l10n_de, l10n_gb, l10n_us) activated by company entity. In Microsoft Business Central, it means per-country environments linked to a shared tenant.
The hybrid model is more complex to govern than the other two, but it is often the only one that lets you reconcile group efficiency with local compliance.
The Template & Roll-out Method: How It Works in Practice
The Template & Roll-out method is the operational implementation of the centralised or hybrid model. It structures deployment in distinct phases.
Phase 1: Building the Core Model
The first phase — typically underestimated in project plans — is defining what will be common across all subsidiaries. The central project team (Group CIO, Group CFO, business key users from the main entities) documents the target processes in the chosen ERP system.
This phase produces the “template”: a configured, validated and documented ERP instance that will serve as the foundation for all subsidiary deployments. It includes the group chart of accounts, standardised O2C and P2P processes, the shared item and supplier master data, and interfaces with group systems (HRIS, consolidation tool, BI platform).
Duration depends on process complexity and how many countries are involved from the design phase. For a group with relatively standardised processes, six months may be sufficient. For a multi-sector group with divergent processes across entities, twelve to eighteen months is more realistic.
Phase 2: Country-Level Regulatory Localisation
Once the core model is validated, the project team builds the regulatory localisations for each target country. This is where many programmes underestimate the effort.
UK accounting (UK GAAP, Making Tax Digital, iXBRL filing) differs significantly from German accounting (HGB, GoBD). French accounting (PCG, liasse fiscale, FEC) adds a third dimension. And if your group has subsidiaries in sub-Saharan Africa, OHADA (17 member states, revised SYSCOHADA plan) is natively supported by very few ERP products from the European or US markets.
Localisation typically covers: the local chart of accounts, local VAT management (rates, returns, payments), e-invoicing in line with country standards (Peppol for Nordic countries and the UK, ZUGFeRD for Germany, FatturaPA for Italy, SII for Spain), and interfaces with local payroll tools.
Phase 3: Roll-out by Subsidiary Wave
Once the template and localisations are validated, subsidiaries are deployed in successive waves. Wave sequencing follows several criteria: size and complexity of entities (simpler ones first, to validate the method), local IT maturity, and fiscal calendar constraints (avoid financial year-end close periods).
Based on experience from comparable projects, the cost of a subsidiary roll-out typically represents between 40% and 70% of the initial deployment cost at the first entity, depending on local complexity and the degree of process standardisation. For a mid-sized SAP S/4HANA roll-out (50 to 200 users), observed budgets typically fall between €300,000 and €1.5 million, including licences, integration, training and change management.
The Change Control Board: The Key Success Factor
The Change Control Board (CCB) is the governance body that decides on every modification to the shared template. It is the most important — and most often neglected — mechanism in the Template & Roll-out model.
Its role: to assess every change request to the template (new feature, regulatory update, common bug fix), evaluate its impact on all already-deployed subsidiaries, and prioritise and schedule template updates.
Without a CCB, each subsidiary starts adapting the template locally to meet its own needs. After eighteen months, every instance has diverged, common updates become impossible to apply without conflicts, and the promise of a shared template is lost. The group ends up in the worst possible situation: neither the advantages of the federated model (local autonomy) nor those of the centralised model (reduced maintenance cost).
Typical CCB composition: Group CIO (chair), a Group CFO representative, business key users from the main subsidiaries, and the technical team from the partner integrator.
The Drift Risk: When the Template Fragments
Template drift is the systemic risk of the Template & Roll-out model. It manifests in several ways: undocumented bespoke developments added by local teams, master data duplicated with subsidiary-level variants, standard processes bypassed by persistent Excel workarounds.
Early warning signals: change requests to the template arrive in parallel from multiple subsidiaries (each found its own workaround), monthly close times lengthen despite the shared ERP, and maintenance cost increases from one cycle to the next.
The 8 Factors That Should Drive Your Model Choice
Before making a near-irreversible five-year decision, assess your situation across these eight dimensions.
1. Degree of business process harmonisation. If your subsidiaries run the same business with similar processes (distribution, standard industrial manufacturing), the centralised model is viable. If they operate in different sectors, the federated or hybrid model is the right call.
2. Local regulatory requirements. The more your target countries have specific regulatory obligations (OHADA, HGB, Making Tax Digital, SII in Spain, TicketBAI in the Basque Country, GST in India, SAF-T in Norway and Poland), the more the hybrid model with strong localisation becomes necessary. The pure centralised model only works durably in geographies with closely aligned regulations.
3. Multiple languages and currencies. A group operating in five languages and four currencies needs an ERP that natively handles multilingualism and multi-currency across the interface and legal documents (invoices, purchase orders, payslips). Not all vendors deliver this equally well.
4. Local IT maturity. A subsidiary with three people in its IT team cannot manage an autonomous SAP S/4HANA instance. A centralised model with central support is then more appropriate. Conversely, a subsidiary with a well-resourced IT function can manage its own system.
5. Available budget. A Template & Roll-out programme over three years covering eight subsidiaries in five countries is a significant investment. The federated model (keeping existing ERPs and adding a consolidation layer) is sometimes the only realistic option for groups with a constrained IT budget.
6. M&A strategy. If your group acquires three companies per year, a strict shared template is a bottleneck: integrating a new entity into the template typically takes a minimum of twelve to eighteen months. A federated model allows rapid operational integration (90 to 180 days depending on complexity), followed by progressive harmonisation.
7. Subsidiary operational independence. A subsidiary with its own logistics, its own P&L, its own framework contracts, will not easily integrate into a centralised template without significant organisational friction. The level of cultural resistance is a major risk factor, consistently underestimated in business cases.
8. Vendor partner network in target countries. An SAP S/4HANA roll-out in Poland and Romania requires a locally certified partner with consultants familiar with local regulations. Some vendors have limited local presence in Eastern European countries or Francophone Africa. Verify this before signing your vendor contract.
Decision Matrix by Group Profile
| Group Profile | Recommended Model | Well-Positioned Vendors |
|---|---|---|
| Integrated group, same sector, common processes, fewer than 10 countries | Centralised | SAP S/4HANA, Infor LN, Microsoft Business Central |
| Multi-sector conglomerate, autonomous subsidiaries | Federated with central consolidation | Lucanet, Tagetik, OneStream, SAP Group Reporting by BU |
| Fast-growing via acquisitions (3+ per year) | Hybrid with fast onboarding | Odoo, NetSuite, Microsoft Business Central |
| International SME with lightweight subsidiaries (fewer than 20 users per country) | Light local instances | Odoo, Zoho Books, QuickBooks Online |
| Mid-market European group 500–3,000 employees, 3–8 countries | Hybrid | SAP S/4HANA RISE, Sage X3, Odoo, Business Central |
Key Considerations for SAP S/4HANA Roll-outs
S/4HANA Cloud Public vs Private Edition
The distinction is structurally important for international groups. S/4HANA Cloud Public Edition (GROW with SAP) enforces SAP standards with limited personalisation: ideal for straightforward subsidiaries in well-supported countries, but restrictive for specific business processes. S/4HANA Cloud Private Edition (RISE with SAP) offers more flexibility but at higher cost.
For a multi-country roll-out, the key question is tenant management: does each country have its own instance, or do they share a tenant with separate organisational clients? The answer affects data privacy (GDPR, data residency), close cycle timing, and the ability to adapt processes by country without impacting others.
RISE with SAP and Multi-Country Management
RISE with SAP offers a globalised contractual approach (infrastructure, licences, services) that simplifies negotiation for multi-country groups. However, managing SLA commitments per country, data residency requirements (German data stored in Germany, UK data in the UK), and coordination between local SAP teams and the central team can complicate operational governance considerably.
Indicative Cost of an SAP Roll-out per Subsidiary
Based on comparable project experience, the budget for an SAP S/4HANA subsidiary roll-out varies according to several factors: entity size (number of users, transaction volumes), local process complexity, availability of a local SAP partner, and the degree of template customisation. Observed ranges on comparable projects fall between €300,000 and €1.5 million for a mid-sized subsidiary. These figures include licences, integration, training and change management.
Key Considerations for Odoo and Microsoft Business Central
Odoo: The Fast Multi-Instance Advantage
Odoo’s main advantage is rapid country-by-country deployment thanks to its modularity and its marketplace of certified localisations. Odoo.sh (managed cloud) allows deploying a new country instance in days with the corresponding localisation module (l10n_fr, l10n_de, l10n_es, l10n_gb, l10n_us, etc.).
The main limitation for groups: financial consolidation across separate Odoo instances is not native. It requires either a third-party module or export to an external consolidation tool (Tagetik, Lucanet, or a structured Excel-based reporting layer). For groups that need real-time consolidated visibility, this is a blocking point.
The alternative: use a single Odoo instance with multiple companies configured within it. This is technically feasible, but performance can degrade beyond a certain transaction volume or number of concurrent users. Evaluate this against your projected volumes.
Microsoft Business Central: Well-Suited to Mid-Market, with Limits at Scale
Business Central is well positioned for mid-market groups up to approximately 1,000 users per instance, with multi-entity management via “companies” within a single tenant. Native intercompany functionality (intercompany invoices, intercompany journals) covers the typical needs of a group with 3 to 10 entities.
Beyond this scale, and for groups with complex manufacturing processes, Business Central shows its limits: less flexibility than SAP for advanced production processes, and weaker consolidation functionality compared to SAP or Oracle NetSuite.
Its strong point for roll-outs: the Microsoft partner network is dense in nearly every European country, with certified localisations available for the vast majority of markets, including many Eastern European countries.
Two Often-Overlooked Risk Factors
Local subsidiary resistance. The most significant underestimation in international ERP projects is not technical: it is the resistance of local teams to giving up their familiar tools, their home-grown processes, and their operational autonomy. A template imposed without co-designing it with the subsidiaries will be bypassed within twelve to eighteen months. Involving local key users from the core model design phase is not a nice-to-have — it is a condition of success.
The executive sponsor role. A Template & Roll-out programme does not succeed without a senior executive sponsor — typically the Group CFO or Group CIO — able to arbitrate in favour of the common standard against local exemption requests. Without this formalised decision-making authority, the CCB becomes a body without real power, and the template progressively drifts into as many versions as there are subsidiaries.
To go further, see our multi-site and multi-entity ERP guide covering financial consolidation, intercompany flows and multi-currency management, and our analysis of multi-ERP strategy for groups addressing orchestration when multiple ERPs coexist in the same perimeter. For groups built through acquisitions, our article on post-merger ERP integration provides the decision framework for the first 100 days.
