Business Central Multi-Entity and Intercompany: Structure, Postings, Consolidation and Limits

Should each legal entity be a company in one environment or a separate environment?

In Business Central every legal entity is a company, and the first design decision is where those companies live. Companies in the same environment share the extensions installed there and the environment's update schedule, and they can exchange intercompany transactions and consolidation data directly through the database. Separate environments, or separate tenants, keep entities apart when they need different extensions, different update timing, data in a different Azure geography, or independent administration.

Microsoft supports both. Consolidation can transfer data from subsidiaries that use Business Central in different environments, and intercompany partners in another tenant or environment connect through an app registration in Microsoft Entra ID, as described in Set up intercompany transaction posting. We usually recommend one environment for a group that shares processes and a country set, and separate environments only where a real requirement forces it, because every extra environment is extra administration, update testing and integration.

How do intercompany partners, the IC chart of accounts and IC dimensions work?

Intercompany in Business Central is built on a shared vocabulary. All companies in the partnership use the same intercompany chart of accounts and, if dimensions travel with transactions, the same intercompany dimensions. Each company maps its own accounts and dimensions to the intercompany ones and back again, so a transaction leaves one company in its own accounts and arrives in the partner's own accounts. Microsoft's overview, Manage intercompany transactions, notes that partners can be in different countries, use different currencies, charts of accounts, dimensions and item numbers.

The Intercompany Setup page holds the company's intercompany code, the synchronization partner (usually the head office, whose chart of accounts and dimensions become the baseline), the partner list and the mappings. Each partner is then linked to a customer and a vendor through the IC Partner Code, so ordinary sales and purchase documents with that customer or vendor become intercompany documents.

• Agree the intercompany chart of accounts and dimensions first, usually from the synchronization partner.
• Map accounts and dimension values in both directions in every company.
• Set up each partner on the Intercompany Setup page with its transfer type and link it to a customer and a vendor.
• Decide how item numbers travel: your own numbers, the partner's numbers, a common item number or item references.
• Use the Intercompany Setup Diagnostics tiles to confirm every component is in place before the first live transaction.

How are intercompany postings automated in Business Central?

Intercompany documents travel through an outbox and an inbox. A sales order, invoice, credit memo, return order or intercompany general journal line sent to a partner lands in the partner's inbox, where it becomes the corresponding purchase document or journal line. A sales invoice sent through intercompany is created as a purchase invoice in the receiving company; purchase invoices themselves are not sent to partners.

To automate the flow, turn on Auto. Send Transactions on the Intercompany Setup page and Auto Accept Transactions on the partner, and set the default intercompany general journal template and batch. Microsoft is precise about what happens next: the journal lines are created for you, but not posted. That is a sensible control, and the design work is deciding who reviews and posts them, how duplicates are handled when a purchase order already exists (Microsoft warns that auto accept suppresses the duplicate purchase invoice warning), and how the month closes when one partner is late.

How does consolidation work for foreign-currency subsidiaries?

Each company in a consolidation is a business unit, and the consolidated company is a container for consolidated data without live business transactions. The consolidated company can use its own chart of accounts; each business unit maps its accounts to it through consolidation debit and credit accounts, and can exclude accounts. Business units can share data through the Database option when they are in the same environment, through an API when they are in other Business Central environments, or through an exported file, all described in Set up company consolidation. A partly owned company is consolidated at its Consolidation %.

Foreign-currency subsidiaries are translated account by account using the Consol. Translation Method. Business Central offers Average Rate (Manual) for income statement accounts, Closing Rate for balance sheet accounts, Historical Rate, Composite Rate (typical for retained earnings) and Equity Rate, and the Set Up Business Unit Currencies page keeps the rates used in each run so you can rerun a period with the same closing rate. Eliminations are a manual step: you enter journal lines in the consolidated company and review them with the G/L Consolidation Eliminations report before posting.

How is master data shared across companies?

Customers, vendors, items and other master data often need to be the same in every company. Business Central's master data synchronization couples records from a source company to subsidiary companies and creates a recurring job queue entry for each synchronized table, so changes in the source company flow to the subsidiaries, as described in Manage master data synchronization. You choose the tables and fields, decide whether the source may overwrite local changes, and monitor failures on the Integration Synchronization Jobs page. Subsidiaries that need fields added by an extension in the source company must install the same extension.

The decisions that matter are ownership and scope: which company owns each master record, which fields a subsidiary may change locally (for example posting groups that differ by country), and what happens to records that only one entity uses.

What does a group with an Armenian subsidiary look like on Business Central?

Take a scenario: a UK or German parent already runs Business Central and opens or acquires a company in Armenia. Business Central online is available in Armenia on the international (W1) version, and Microsoft leaves the Armenian localization to partners. The Armenian company is created as a company in the group tenant, on W1, with the Solzet Business Central Armenian localization installed: AMD as the local currency, an Armenian chart of accounts, Armenian tax and statutory reporting, Armenian-language documents, and State Revenue Committee e-invoicing where it applies. The localization extensions apply to that company; the parent's companies keep their own setup.

The subsidiary keeps its statutory books in AMD. Its accounts map to the group's consolidation chart of accounts, its income statement is translated at the average rate and its balance sheet at the closing rate, and it consolidates into the parent's consolidated company with the other business units. Intercompany recharges and sales between the parent and the Armenian company run through the intercompany chart of accounts, so both sides post their own accounts in their own currencies.

• One tenant, the Armenian company on W1 with the localization extensions, the other companies unchanged.
• Statutory books in AMD with the Armenian chart of accounts; group reporting through consolidation mapping.
• Intercompany partner setup between the parent and the Armenian company for recharges and trade.
• Payroll is outside the localization and planned separately.

When do multi-entity limits push a group towards Finance and Operations?

Business Central handles groups well when the entities are mid-sized, the intercompany flows are documents and recharges, and consolidation is a period-end task. The signals that a group is reaching the edge are about how tightly the entities work together, not about a number of companies. Dynamics 365 Finance covers general ledger, payables, receivables, budgeting, cash and bank management, cost accounting, fixed assets and financial reporting, and Supply Chain Management adds deep warehouse, transportation, planning and production; see Dynamics 365 Finance and Operations.

We compare the two in detail in Business Central vs Finance and Operations. The point here is narrower: when the intercompany design above starts to need a lot of custom AL to keep entities in step, that is a signal worth taking seriously before you build more.

• Shared services that pay, collect or purchase on behalf of many entities as a daily process, not a monthly recharge.
• Intercompany trade chains where one customer order has to flow through several entities automatically.
• Many countries with different statutory requirements in one operational model.
• Deep supply chain, warehouse or production shared across entities.
• Consolidation and eliminations that finance wants continuous rather than at period end.

How does Solzet design a multi-entity Business Central setup?

We start with the legal and reporting structure: which entities exist, who trades with whom, which currencies, which statutory requirements, and what the group reports. From that we decide the company and environment layout, design the intercompany chart of accounts and dimensions, set up partners, inbox and outbox handling and the auto accept rules, configure consolidation with the translation method per account and the elimination routine, and set up master data synchronization with clear ownership.

Then we test a full month of real intercompany flows and a consolidation run in a sandbox, reconcile both sides of every intercompany balance, and write the period close checklist the finance team will use. Where you run Dynamics 365 Customer Engagement as well, the same team connects it through the Dataverse connection so the CRM sees customers across companies. The implementation service is on Dynamics 365 Business Central.