The question “Should we put every entity on one ERP?” combines several decisions that deserve separate answers. A group can share financial definitions while operating different applications. It can use one product with separate instances. It can centralize administration while retaining local process authority. Confusing these choices can turn an architecture discussion into an unproductive contest between headquarters and subsidiaries.
The starting point should be the group’s operating model. Which activities must work as one business? Which differences create value or satisfy local obligations? Where does leadership need common information, and how quickly? The deployment design should follow those answers.
A single instance can simplify some forms of coordination. A federated arrangement can preserve specialist capabilities and isolate change. Neither structure removes the need for shared definitions, clear authority and dependable intercompany processes.
Separate policy, process, data and deployment
Policy centralization determines who sets rules: accounting policies, purchasing authority, access standards and reporting expectations. Process standardization determines how work is performed and where local variation is permitted. Data governance determines the meanings, identifiers and quality expectations needed across the group. Deployment architecture determines where software runs and how instances connect.
These dimensions influence each other, but they are not interchangeable. Buying one platform does not establish common purchasing authority. Publishing a group chart of accounts does not require every local process to use the same screen. A local application does not justify inconsistent definitions for consolidated reporting.
Map the dimensions before comparing vendors. For each important capability, record what the group needs to control, what entities need to decide and what information must cross boundaries. This is a working design heuristic rather than a formal maturity model.
The resulting architecture may be mixed. Common finance and consolidation can coexist with specialized operational systems. Shared customer identifiers can connect locally managed commercial processes. The design should be explainable in terms of operating needs rather than a general preference for centralization.
Find the processes that genuinely bind the group
Intercompany trading, shared inventory, common customers and centralized procurement create coordination requirements. If one entity sells goods held by another, the group must manage availability, transfer pricing inputs, transaction timing and reconciliation. A deployment that makes those exchanges fragile can impose continuing operational cost.
A holding company with largely independent subsidiaries has a different problem. It may primarily need dependable reporting, risk visibility and a repeatable acquisition model. Forcing every acquired business onto a common operational template immediately may offer limited benefit while disrupting valuable local capability.
Ask how often entities interact, how time-sensitive those interactions are and what happens when information is wrong. A monthly reporting need does not necessarily justify the same integration architecture as a shared real-time fulfillment promise. Conversely, calling subsidiaries autonomous does not excuse unreliable group-level information.
The Basel Committee’s 2013 Principles for effective risk data aggregation and risk reporting arose from banking failures to aggregate exposures quickly and accurately. The requirements are banking-specific, not a general ERP mandate. Their broader management lesson is relevant: organizational complexity does not reduce the need for dependable group-level visibility.
Compare the obligations each model creates
A centralized instance can make common data and process changes easier to propagate. It can also create contention over priorities, release windows and configuration choices. The group needs a governance model that can resolve conflicting local needs without allowing every entity to create a unique branch of the template.
Separate instances using a common template offer some local release flexibility and operational separation. They introduce template-version management, data synchronization and a need to decide which deviations are permitted. If template upgrades become optional indefinitely, apparent standardization can erode into several incompatible designs.
Different local platforms can preserve strong specialist fit and support acquisition speed. They require more deliberate integration, master-data mapping, reporting controls and support coordination. A group may accept that cost, but it should price it rather than treating local independence as free.
A central architecture also concentrates dependency. An outage or badly managed change may affect several entities simultaneously. Decentralization can limit some local failure effects, yet a shared identity provider or integration hub can still create group-wide exposure. Actual dependency analysis matters more than the number of ERP instances.
NIST’s 2010 Contingency Planning Guide emphasizes understanding operational priorities and recovery needs. Applied here, recovery design should follow critical business services across systems and entities, rather than assume that either centralization or separation guarantees resilience.
A hypothetical group chooses different treatment for two acquisitions
Imagine a group acquiring two businesses in the same year. One is a distributor that shares customers, suppliers and warehouse capacity with the existing group. The other provides specialist field services with scheduling and job-costing practices that differ substantially. These businesses and circumstances are hypothetical.
For the distributor, customers increasingly expect a single availability promise across locations. Procurement wants to combine orders, and inventory frequently moves between entities. The group tests a common ERP template and finds that most important operational scenarios fit. A shared deployment is a credible option because the businesses need frequent, tightly coordinated processes.
The field-service business has a different requirement. Its dispatching system manages technician qualifications, route constraints and service evidence. The group’s standard operational template does not handle those scenarios well. Replacing the specialist system immediately would create manual scheduling work and increase transition risk.
Leadership chooses common financial definitions and reporting controls for both acquisitions, but different operational paths. The distributor moves toward the common template after data and process validation. The field-service business retains its dispatching capability and connects approved job and billing information to group finance through a governed interface.
The retained system is not exempt from oversight. The group defines legal-entity identifiers, customer mappings, cost categories, interface reconciliation and responsibility for corrections. It also defines which records are needed for management reporting and how quickly they must arrive. Local autonomy applies within those boundaries.
For the distributor, the rollout cannot proceed merely because the template appears compatible. The group tests intercompany orders, returns, transfers in transit and period-end cutoffs. It also rehearses a local warehouse interruption and a central-system outage. These scenarios determine whether the proposed shared model works under stress.
This mixed design is not automatically optimal. If the group later integrates service contracts and product fulfillment into one customer proposition, the field-service boundary may need reconsideration. The architecture should include a review trigger tied to that operating-model change rather than a vague promise to standardize eventually.
Design intercompany work as a complete process
An intercompany transaction crosses accounting, commercial and operational boundaries. Assigning one integration team to “connect the systems” does not settle how the entities will agree quantities, prices, timing and dispute resolution.
Trace one transaction from request through delivery, invoicing, payment or settlement and consolidation. Identify the common reference that connects the records. Define who initiates corrections, how the counterparty receives them and how unmatched items are escalated. Include returns and cancellations, which often expose assumptions that ordinary transactions hide.
Distinguish local statutory records from group reporting adjustments. Requirements differ by jurisdiction and business, so qualified finance and legal owners must validate the chosen approach. Architecture should preserve the evidence and flexibility they require without embedding unreviewed legal assumptions into integration code.
Agree the cutoff policy for transactions in progress. Otherwise, different entities may report different states at period end even when every interface is technically functioning. Reconciliation needs to compare business meaning as well as totals.
Give the template an owner and a constitution
A common template requires an accountable business owner, a change process and explicit rules for exceptions. Define what is mandatory, what is configurable locally and what requires group approval. Document why each mandatory element exists so future teams can distinguish a genuine constraint from an inherited preference.
Local entities should have a reliable route to propose changes. Central teams should publish decisions and explain trade-offs. Without that mechanism, subsidiaries may build unofficial workarounds while the group believes the template remains consistent.
For a federated architecture, governance should be equally concrete. Define interface contracts, reporting obligations, security expectations and minimum recovery requirements. Test compliance through evidence rather than collecting annual assurances. Federation works when responsibilities are bounded and enforceable.
Budget for the people who maintain the model. Template stewardship, master-data governance and intercompany reconciliation continue after implementation. A centralized deployment with no operating team can become less coherent than a well-managed federation.
Use acquisition and divestiture scenarios to test the choice
A multi-entity architecture should be assessed against plausible changes in the group. How would a new acquisition be connected during its first reporting cycle? Which capabilities must converge immediately, and which can wait? How would an entity be separated if sold?
Divestiture is particularly revealing. Identify how records, access, shared services and integrations could be separated without exposing other entities’ data or losing required history. A design that is efficient under permanent common ownership may be costly to unwind.
Do not overengineer for every possible transaction. Use a few credible scenarios based on the group’s strategy and the expected life of the architecture. Record the costs and limitations of preserving optionality. Some groups should accept a tighter common platform because operating integration matters more than future separability.
The best decision is a documented operating bargain: these capabilities are shared because coordination creates value; these remain local because variation is necessary; these information and control obligations apply everywhere. Once that bargain is clear, the centralized-versus-decentralized question becomes a set of manageable design choices rather than an ideological debate.
