ERP for multi-entity structures — what a group-capable setup really needs.

Multi-entity ERP is often the very reason a mid-market company starts thinking about a system change in the first place. Anyone who grows from a single-entity setup into two, three or more subsidiaries — through acquisition, internationalisation or splitting business units — quickly hits the limits of an ERP implementation that was originally configured for one company.

This profile is aimed at mid-market companies whose structures consist of two or more legal entities or are clearly heading there. It shows which functions are load-bearing, where the typical pitfalls lie, and which systems deliver multi-entity logic reliably in the mid-market.

1. What multi-entity really means

"Multi-entity" is often used synonymously with "multi-tenant" in selection conversations. That is not wrong, but too short. The term covers several aspects that need to be decided independently:

• Legal separation. Multiple independent legal entities with separate books, taxes and balance sheets.
• Organisational separation. Own management, accounting and reporting per entity.
• Technical separation. Separate datasets in the system — with or without a shared master data pool.
• Consolidation need. Joint reporting across all entities, often under different accounting standards.

An ERP that is "multi-entity capable" delivers more than just the technical option of creating multiple tenants. It carries the organisational and consolidation logic — and that is where the spread between systems becomes visible.

2. Typical mid-market constellations

Four multi-entity constellations show up especially often in the German mid-market. They have different ERP requirements.

In practice, hybrids are common: a holding with operating subsidiaries, some of which have international sales entities. The architecture has to cover such hybrids without forcing parallel ERP systems.

3. Tenancy vs. real multi-entity logic

A central distinction that often hits the table late in selection projects: does the system offer "only" multi-tenancy — or real multi-entity logic?

Tenancy (the weaker concept)

Multiple tenants can be held in the same system but are largely separated in data terms. Master data, reporting structures and workflows exist per tenant. Consolidation typically happens downstream via export, a consolidation tool or external software.

Real multi-entity logic

The system knows the concept of "subsidiary" / "legal entity" as a central database dimension. Master data can be maintained across entities or per entity. Consolidation, intercompany elimination and parallel accounting standards are standard functions, not add-ons. Every individual posting natively knows its entity context.

The practical difference becomes visible whenever cross-entity processes appear: a purchase from subsidiary A at subsidiary B, an employee working for several entities, a customer served by multiple entities. In the tenancy model this generates duplicate maintenance and workarounds; in real multi-entity logic this is covered in the standard.

4. Core ERP functions for multi-entity

Beyond standard ERP functionality, six areas decide most often whether a multi-entity setup succeeds.

Intercompany transactions

Sales from subsidiary A to subsidiary B is a daily occurrence in multi-entity. The system has to post a single transaction simultaneously as a sale at A and a purchase at B — including VAT logic, multi-currency and automated elimination in the consolidated statement. Anyone solving this with workarounds builds technical debt that surfaces at every period close.

Multi-currency logic with valuation depth

When subsidiaries book in different currencies, the ERP needs more than a conversion function. Daily, period-end and average rates, FX differences, valuation runs and multi-currency accounts have to be supported. Depth varies considerably between systems.

Parallel accounting standards

Subsidiaries can report under different standards — local GAAP, IFRS, US GAAP. A group-capable ERP setup runs parallel ledgers per standard. Bolting that on later costs significant complexity.

Global vs. local master data

An item is the same everywhere — its sales price is not. A vendor is shared, its terms are not. The system has to decide which master data is centrally maintained (with inheritance into entities) and which can be locally overridden.

Accounting localisation

Each entity needs its local accounting logic: chart of accounts, tax logic, document formats, statutory reporting. A group-capable ERP delivers localisation packages per country instead of separate customisation per entity.

Consolidated master data core

Anyone going multi-entity needs a single view of "the one customer", "the one vendor", "the one product" — even if entities have their own conditions, prices and processes. This is a master data architecture topic, not just an ERP module.

5. Master data strategy across entities

Master data is the backbone of any multi-entity setup. Three strategies are possible in principle:

Fully central

One single record per customer/vendor/item, identical for all entities. Only works when entities really have identical conditions — rarely the case in the mid-market.

Fully decentralised

Every entity maintains its own master data. Maximum flexibility but duplicate maintenance, lack of comparability, no consolidated view. Once three or more entities are involved, this is no longer sustainable.

Central pool with inheritance (recommended)

Global master data is centrally created, every entity inherits the definition and can override local fields (prices, terms, tax rates). This model needs two things: an ERP that supports inheritance natively (not every system does), and a clear governance process (who maintains what, who approves).

The master data strategy should be decided before the tool is selected. Anyone clarifying this later corrects in implementation — with the corresponding cost risk.

6. Permissions, security and audit trail

In multi-entity setups, the permission model becomes a critical function. Three requirements are load-bearing.

Entity-level visibility

A clerk in subsidiary A typically must not see documents from subsidiary B — unless given an explicit cross-group role. The permission logic has to enforce this at database and UI level, not just hide via standard views.

Functional separation

Anyone reading consolidated reports in the group holding need not see operational postings in subsidiaries. Granular roles per function and entity are a baseline expectation.

Audit trail

Every change has to be traceable — who changed what when. In a multi-entity setup this matters twice as much, because auditors and internal audit review evidence per entity.

ERP systems differ considerably in the depth of these functions. What looks "sufficient" with one entity can grind to a halt with five.

7. Consolidation and reporting depth

Multi-entity ERP without consolidation logic is half a solution. Four consolidation levels matter in the mid-market:

• Operational consolidation. Overview of revenue, costs and KPIs across all subsidiaries, in real time or close to it. Classic management reporting.
• Elimination consolidation. Intercompany sales, receivables and payables are eliminated to produce consolidated balance sheet and P&L. Minimum requirement for any group statement.
• Multi-GAAP consolidation. Consolidation under different standards (local GAAP, IFRS, US GAAP) in parallel. Increasingly relevant in the mid-market once international structures or external investors are involved.
• Proportional consolidation. Joint ventures, equity investments or partial holdings need to be modelled cleanly — more common in family-owned mid-market with complex shareholding than one might expect.

Anyone running real consolidation in the ERP needs a system that has these functions in the standard. Anyone using a downstream consolidation tool (LucaNet, IDL, SAP BPC) should define the interfaces between ERP and consolidation early.

8. Which ERP systems deliver multi-entity in the mid-market

Not every ERP is suited for multi-entity structures. A rough profiling of systems frequently considered in the German mid-market:

NetSuite OneWorld holds a special position in mid-market multi-entity work: the system was architecturally designed for multi-entity, with "subsidiary" as a central data dimension. Consolidation, multi-currency, parallel accounting standards and global master data inheritance are standard functions, not add-ons. For mid-market companies with two or more entities, international structures or consolidation needs, NetSuite is frequently the candidate that carries these topics with the lowest implementation risk — which is why the solution appears above average on shortlists in our advisory mandates.

D365 Finance & Operations and SAP S/4HANA can deliver comparable depth, but their complexity and implementation effort are in a different league — they typically fit upper mid-market and group sizes above the classic mid-market spectrum.

9. Typical mistakes in multi-entity projects

Four patterns repeat in multi-entity selection projects:

Architecture decision made too late

Whether the system needs to be multi-tenant or genuinely multi-entity capable is often clarified only when the selection is already running. As a result, systems remain on the shortlist that structurally do not fit. The clarification belongs before the first vendor evaluation.

Consolidation treated as a downstream question

"We will do consolidation with the tool we already have" — this attitude regularly leads to complex interface setups whose maintenance effort is underestimated. Anyone who can run consolidation in the ERP should evaluate that, instead of carrying a separate tool forward out of habit.

Master data governance not defined

Who maintains centrally, who locally? Who decides on creating new customers, items, accounts? Without clear answers, master data becomes the largest source of friction in implementation.

Localisation underestimated

International multi-entity setups demand accounting and tax localisation per country. Anyone dismissing this as "doable in any ERP" routinely overlooks the depth of local requirements (e. g. SAF-T, e-invoicing obligations, local audit tools). Localisation belongs in the selection decision, not just the implementation.

10. Frequent questions on multi-entity ERP

From when is a multi-entity-capable ERP worthwhile?

From the second operating entity at the latest — earlier if consolidation needs, international activity or group reporting are foreseeable. Anyone running multiple entities on a single-entity ERP architecture builds technical debt that is hard to repay.

Is it enough to run multiple tenants in a classic mid-market ERP?

For pure bookkeeping separation yes; for real cross-group steering no. As soon as cross-entity processes, consolidation or multi-GAAP appear, the tenancy architecture becomes a brake.

How do you handle acquisitions running on a different ERP?

Three strategies: short term, interfaces plus a consolidation tool; medium term, migration to the group ERP; alternatively a dual-strategy bridging period. Which strategy fits depends on the size, complexity and strategic relevance of the subsidiary. The decision should be CFO-driven, not IT-only.

How much more effort is multi-entity vs. single-entity implementation?

Experience values: between 1.5x and 3x effort per additional entity, depending on localisation, data migration and master data consolidation. The biggest drivers are master data and localisation, not software configuration.

How do you cleanly separate consolidation and operational steering?

Through reporting architecture. Operational steering happens in subsidiaries on entity-specific reports. Consolidation occurs centrally with group accounts and elimination logic. Both views must be served from the same data model — otherwise discrepancies appear that cost trust.

---

Note: This profile does not replace an individual project assessment. The patterns and recommendations presented here are experience values from selection projects in the German-speaking mid-market.

Author: Joerg H. Paul Schaefer · As of: May 2026 · erp-check.info is a vendor-neutral information platform.