Group IT review usually asks about the other half too: security, permissions and data residency.
The decision that comes before everything
Groups usually start this conversation at the wrong end, asking which features handle intercompany. The question that determines cost, timeline and how much pain you inherit is simpler: one environment or several?
In Business Central each legal entity is a company, and companies live inside an environment. Several companies can share one environment — sharing master data, users and the same release cycle — or each can have its own, fully isolated.
That choice is difficult to reverse. Splitting a shared environment later means a migration; merging separate ones means reconciling master data that has drifted apart for years. It deserves an hour of proper thought at the start rather than a default.
Three patterns, and who each suits
| Pattern | How it works | Suits |
|---|---|---|
| One environment, several companies | Shared item and customer master, shared users, one release cycle | Groups where entities trade with each other constantly and processes are similar |
| Separate environments | Full isolation, independent configuration and update timing | Entities in different countries with genuinely different operating models |
| Hybrid | Core entities together, outliers separate | The common real-world answer: a trading group plus one manufacturing subsidiary |
The instinct is usually to keep everything together for consistency. The constraint to weigh against it: entities sharing an environment share the update schedule, the extensions and much of the configuration. One subsidiary needing a localisation that conflicts with the group template can hold everyone up.
How intercompany actually works
Business Central has native intercompany handling, and it is more than a convenience feature — it removes an entire category of month-end reconciliation.
Each company gets an intercompany partner code and a mapping of its own chart of accounts and dimensions onto a shared set. When entity A raises a sales invoice to entity B, the corresponding purchase invoice appears in B's inbox ready to accept. Same document, same amount, both sides posted from one action.
What this changes at month end
The usual intercompany routine is two finance teams comparing balances by email and finding differences caused by timing, exchange rates or someone posting to a slightly different account. With native intercompany the documents are generated from the same source, so mismatches come from real events rather than data entry.
What still needs deciding
- Transfer pricing. The system will post whatever price you tell it. Which price is correct is a tax question, not a software one.
- Who accepts. Intercompany documents land in an inbox; someone in the receiving entity has to accept them, and if nobody owns that they accumulate.
- Currency. If entities operate in different currencies, exchange differences arise on both sides and need consistent treatment.
Consolidation
Business Central consolidates by pulling balances from subsidiary companies into a dedicated consolidation company, translating currency and eliminating intercompany balances along the way. It works well for straightforward group structures.
Where it stops being sufficient: complex minority interests, multi-tier structures with partial ownership, or reporting under a standard the group applies with significant judgement. At that point most groups keep Business Central as the source of transactional truth and run consolidation in a dedicated tool, with the ledger feeding it.
A practical rule from projects we have seen: if your current consolidation fits in a well-built spreadsheet, Business Central will handle it. If your spreadsheet has its own documentation, it will not.
Where local statutory rules bite
This is where multi-country groups underestimate the work, and it is worth being specific because the pattern repeats.
The group designs a chart of accounts centrally, rolls it out, and then discovers that one country's statutory reporting needs accounts, dimensions or document flows the template does not contain. The fix at that point is expensive because the template is already live in three other entities.
For a Ukrainian entity specifically: Business Central does not include Ukrainian statutory accounting in the base product. VAT, tax invoices and the ЄРПН registry come through a partner localisation, which has to coexist with the group template rather than replace it. The same is true of most other jurisdictions with distinctive statutory requirements.
The sequence that works is to map statutory needs for every entity before the group chart of accounts is locked, not during rollout. That covered in detail for the Ukrainian case in your Ukrainian subsidiary runs 1C.
Four mistakes that are expensive to undo
Deciding the environment structure by default. Whatever the first partner proposed becomes permanent. Ask explicitly why, and what it would take to change later.
Designing dimensions per entity. If each subsidiary invents its own department and project codes, group reporting requires a mapping layer forever. Dimension structure is a group decision, not a local one — the mechanics are in dimensions in Business Central.
Assuming one partner can cover every country. They can cover the template. Statutory localisation is local by definition, and the boundary between the two needs to be in the contract.
Leaving intercompany acceptance unowned. Documents pile up in inboxes, month end reverts to email reconciliation, and the feature that justified the design is quietly not used.
Frequently asked questions
Can several legal entities share one Business Central environment?
Yes. Each entity is a company within the environment, sharing users, master data and the update cycle. The alternative is separate environments with full isolation. The choice is difficult to reverse later, so it is worth deciding deliberately rather than by default.
Does Business Central handle intercompany transactions natively?
Yes. With partner codes and account mapping configured, a sales invoice in one entity generates the matching purchase invoice in the other, ready to accept. This removes most of the manual reconciliation that intercompany usually creates at month end.
Is built-in consolidation enough for a group?
For straightforward structures, yes — it pulls balances, translates currency and eliminates intercompany. For complex minority interests or multi-tier ownership, groups typically keep Business Central as the transactional source and consolidate in a dedicated tool.
How do local statutory requirements fit a group template?
They have to be mapped before the group chart of accounts is locked. Countries with distinctive statutory reporting — Ukraine among them — need a partner localisation that coexists with the template. Discovering this during rollout is the most common cause of cost overrun in multi-country projects.
Do all entities have to update at the same time?
Within one environment, yes — companies share the release cycle. Separate environments can be updated independently. This is one of the strongest practical arguments for keeping an entity with unusual requirements in its own environment.
Can entities operate in different currencies?
Yes. Each company has its own local currency, and consolidation translates into the group reporting currency. Intercompany transactions between entities in different currencies generate exchange differences on both sides, which need consistent treatment agreed in advance.