Organisations that operate through multiple legal entities, whether through acquisition, international expansion, or a deliberate group structure, face a distinct set of ERP challenges. Business Central was built with this in mind, supporting multi-entity and multi-site operations natively. But native support is not the same as a rollout that scales cleanly. This piece looks at what Business Central handles well out of the box, where it reaches its limits, and the architecture decisions that determine whether a multi-entity implementation holds up as the group grows.
Why Multi-Entity Organisations Face a Different Set of Problems
A single-entity Business Central implementation is largely a question of configuring one set of processes correctly. A multi-entity organisation has to solve that same problem multiple times, while also deciding how much should be standardised across entities and how much should be allowed to vary.
This becomes more complex when entities differ significantly in size, sector, or geography, which is common in group structures built through acquisition. A holding group with operating companies across dozens of vertical markets and countries, for example, has to balance group-wide financial visibility against the operational autonomy each entity needs to run effectively in its own market.
The Hub-and-Spoke Model
Business Central’s most common multi-entity pattern is a hub-and-spoke structure, where a parent company manages group-wide standards while individual entities retain configuration suited to their own needs.
(e.g. UK ops)
(e.g. EU ops)
(e.g. acquired co.)
In this model, the parent maintains a consistent chart of accounts structure and group reporting standards, while each entity can vary its own processes, local tax handling, and operational detail according to its sector or location. Business Central supports this natively through shared dimensions, intercompany transaction posting, and configurable company-level settings within a single tenant.
Forcing identical configuration across very different entities, by contrast, tends to generate more workarounds than it saves. A manufacturing entity and a professional services entity within the same group will have genuinely different reporting needs, and trying to force both into one rigid template usually backfires.
What Business Central Handles Well, and Where It Reaches Its Limits
Intercompany transactions
Posting transactions between entities within the same tenant, including automated intercompany invoicing and matching, is well supported out of the box.
Shared dimensions and structure
A consistent chart of accounts and dimension structure across entities makes group-wide analysis far more straightforward than reconciling disparate systems.
Consolidated reporting at scale
As entity count grows into the dozens, native consolidation can require additional tooling, such as Power BI, to remain fast and flexible.
Complex intercompany eliminations
Multi-currency, multi-jurisdiction elimination scenarios often need careful design work beyond default settings to get right.
Who Typically Runs Into These Challenges
Multi-entity complexity shows up most clearly in organisations that grow through acquisition, operate across multiple countries, or run distinct lines of business under one group structure. A few examples illustrate the range of contexts where this matters:
Vuelta Media
A media organisation operating across multiple markets, where group visibility needs to sit alongside the operational independence each market requires.
Ørsted
A large international organisation operating across multiple countries and business lines, representative of the scale at which group-wide standardisation and local flexibility both become essential.
Volaris Group
An acquisition-led group operating well over 200 portfolio companies across dozens of vertical markets and countries, an extreme example of the hub-and-spoke challenge at significant scale.
These organisations sit at different points on the multi-entity spectrum, but all face the same underlying question: how much should be standardised centrally, and how much should be left to each entity to manage on its own terms.
Five Architecture Decisions Every Multi-Entity Rollout Needs to Make
One tenant or several
Entities can sit as separate companies within a single Business Central tenant, or as fully separate environments. The right choice depends on how much data needs to flow between entities and how independently each one needs to operate.
Chart of accounts and dimension standardisation
Deciding what must be identical across every entity, and what can vary, shapes how easily the group can produce consolidated reporting later.
Intercompany transaction and elimination handling
How intercompany postings, currency conversion, and eliminations are handled needs to be designed deliberately rather than left to default behaviour, particularly across jurisdictions.
Consolidated reporting architecture
Whether native Business Central reporting is sufficient, or whether Power BI or another layer is needed for group-wide consolidation, should be decided early rather than retrofitted.
Onboarding new entities as the group grows
For groups that grow through acquisition, having a repeatable, documented process for bringing a new entity onto the platform is far more valuable than a perfectly tuned one-off setup.
If your organisation expects to add entities through future acquisition, ask any implementation partner specifically how onboarding a new entity works once the core platform is live. A rollout designed for a fixed number of entities can become expensive to extend later.
