Multi-Company ERP: Consolidation, Intercompany and the SME Decision

What is multi-company ERP?

Multi-company ERP, also called multi-entity ERP, manages multiple distinct legal entities inside a single ERP system. Each entity retains its own legal identity, statutory reporting obligations, tax compliance, currency, and chart of accounts, while the system supports entity-level operations, intercompany transactions between them, and group-level consolidated reporting.

The distinction matters because a legal entity is an accounting and legal boundary, not just a label. Two subsidiaries in two countries file separate tax returns, hold separate bank accounts, and keep separate general ledgers. Multi-company ERP preserves that separation at the data layer while giving headquarters a single integrated view it can consolidate, eliminate intra-group activity within, and report on as one economic group.

This is different from multi-branch or multi-site ERP, which runs divisions of the same legal entity in one set of books. Multi-company is the right frame when each entity is legally separate and must produce its own statutory accounts; multi-branch is the right frame when one legal entity operates across several locations. Odoo draws this line explicitly: it distinguishes Companies, independent legal entities with their own chart of accounts and currency, from Branches, subdivisions of a single legal entity that share the head office's journals, taxes, accounts, and fiscal positions and are not consolidated the same way as separate companies.

• →Multiple legal entities, each with its own ledger, chart of accounts, currency, and tax nexus.
• →Intercompany transactions documented and matched between entities.
• →Group consolidation with elimination of intra-group balances, revenue, and unrealized profit.
• →One operational system instead of one ERP per entity, with fragmented reporting.

Why SMEs end up needing multi-company ERP

Most SMEs do not start multi-company. They arrive there through a recognizable set of triggers, and recognizing which one applies decides whether the answer is light configuration in one platform or a full re-architecture.

The most common trigger is acquisition. A growing SME acquires a competitor or a complementary business and inherits a second legal entity, often in a different country, with its own chart of accounts, currency, and reporting calendar. Keeping both on the same ERP becomes the fastest path to integrated reporting and consolidated close.

Cross-border expansion is the second trigger. A Canadian or UK company opens a US subsidiary, or vice versa, and needs local tax registration, a USD ledger, and US GAAP or local statutory reporting alongside home-country accounts. Multi-entity setup handles the currency translation and the dual reporting calendar without a second ERP.

The third is restructuring, where a single legal entity is split into several for liability, tax, or ownership reasons, or where a holding company is introduced above operating entities. Each of these triggers changes the consolidation requirement, and therefore which platform architecture fits.

• →Acquisition: inherited second entity, often cross-border, with its own ledger and currency.
• →Cross-border expansion: new subsidiary needs local tax, currency, and statutory reporting.
• →Restructuring: legal-entity split for liability, tax, or ownership, or a new holding company.
• →Sector or franchise model: separately incorporated operating units under one group.

Single-instance vs multi-environment multi-company ERP

Multi-company ERP can be architected two ways, and the choice drives cost, control, and operational complexity for years.

A single-instance, single-database setup runs multiple legal entities inside one ERP instance and one shared database. Separation between entities is logical, enforced through company or entity identifiers, record-level access rules, and security roles, while controlled master data such as products and business partners can be shared across entities. Odoo runs multiple Companies under one database this way, and Microsoft Dynamics 365 Finance lets each legal entity keep its own ledger, chart of accounts, and fiscal calendar while still being managed from one application. The benefit is lower total cost of ownership, shared master data, and faster consolidated reporting; the trade-off is that all entities share an upgrade cadence, a security boundary, and a single point of failure.

A multi-environment, multi-tenant setup runs each legal entity in its own ERP instance or tenant, with consolidation handled by exporting balances into a consolidation entity or a reporting layer. Microsoft Dynamics 365 Finance supports this pattern explicitly: each legal entity has its own ledger, chart of accounts, and fiscal calendar, and a dedicated consolidation legal entity receives translated balances from each source. The benefit is hard isolation between entities, which matters for data residency, regulatory firewalls, divestiture-readiness, and highly autonomous subsidiaries; the trade-off is higher license and integration cost and slower consolidated close.

Neither architecture is universally superior. Single-instance wins on cost and consolidation speed for tightly integrated groups; multi-environment wins on isolation and flexibility for groups that may divest, that face strict data-residency rules, or that operate very autonomously. The right answer depends on entity count, intercompany volume, cross-border complexity, and how likely a divestiture or carve-out is over the system's life.

How intercompany transactions actually work

Intercompany transactions are the operational heart of multi-company ERP. When one entity in the group sells to, buys from, lends to, or transfers inventory to another, the system has to record both sides of the transaction in the right entities, in the right currencies, with offsetting due-to and due-from balances that reconcile at period end.

In a well-configured system, posting a sales document or journal in one entity creates an outbox entry that flows to the partner entity's inbox, where the mirror transaction, typically a purchase invoice, is created without re-keying the data. Accounts balance automatically through mapped intercompany general ledger accounts, and the documents can span different currencies, charts of accounts, countries, and dimensions. Microsoft Dynamics 365 Business Central works exactly this way through intercompany partners, an intercompany chart of accounts, and dimensions, supporting orders, invoices, credit memos, return orders, and general journal entries.

Microsoft Dynamics 365 Finance approaches intercompany at the legal-entity level through intercompany accounting setup that pairs legal entities with unique due-to and due-from main accounts and journal names, supporting centralized payments and subledger-level intercompany. Odoo takes a document-generation approach: its Inter-Company Transactions setting auto-creates counterpart documents, so one company's sales order can generate a purchase order in the target company, a customer invoice can generate a vendor bill, and stock moves can sync on delivery or receipt.

The mechanic that makes all three work is the same: a single source transaction produces two balanced entries across two entities, with the receivable and payable netting to zero at the group level. Where the platforms differ is in how much of the elimination, the cancellation of those intra-group balances for consolidated reporting, they automate, which is the next section.

Consolidation, eliminations, and the accounting standards

Consolidation is the reason most SMEs adopt multi-company ERP. Under IFRS 10 Consolidated Financial Statements, consolidated financial statements present the parent and its subsidiaries as those of a single economic entity, and intra-group balances, transactions, income, and expenses are eliminated in full, with unrealized profits on intra-group transfers eliminated until realized externally. US GAAP ASC 810 Consolidation states the same principle: in the preparation of consolidated financial statements, intra-entity balances and transactions shall be eliminated.

What ERP does is automate the mechanical application of those principles. Currency translation moves each foreign entity's results into the group's presentation currency, governed by IAS 21, with the cumulative translation adjustment recognized in other comprehensive income and accumulated in equity as a separate component, reclassified to profit or loss only on disposal of the foreign operation. Eliminations cancel the intercompany receivables and payables, the intra-group sales and purchases, and the unrealized profit still sitting in inventory transferred between group entities.

Where the platforms differ materially is how much of this is automated. Microsoft Dynamics 365 Finance runs a formal consolidation cycle: legal entities can be flagged as a consolidation company, an elimination company, or both, and the Consolidate online process uses templates to select legal entities, date ranges, and ownership percentages, processing actuals and budgets with currency translation from each source currency into the consolidation company's currency. Eliminations run through defined elimination rules, net-change or fixed-amount, mapped across source and destination accounts and dimensions, and post to a designated elimination legal entity.

Microsoft Dynamics 365 Business Central consolidates financial data across companies with different charts of accounts, currencies, fiscal years, and even environments, including non-Business Central sources, supporting full or partial consolidation, currency translation, and eliminations, but the eliminations themselves are entered as manual journal entries against a consolidation company. Business Central also caps an environment at 300 companies, which is generous for most SMEs but a real ceiling for acquisitive groups.

Odoo is the most manual of the three on group consolidation. Its consolidation tooling is report-oriented and adjustment-based, using account mapping across companies, multi-ledgers, a multi-company selector, horizontal groups in reports, and multi-currency cumulative translation adjustments that apply historical rates to equity, weighted-average rates to profit and loss, and closing rates to the balance sheet. But Odoo core has no native automated intercompany elimination engine; the mirrored intercompany documents still require manual elimination entries or workarounds such as dedicated journals excluded from reports, or fiscal positions routing to non-consolidated accounts. For a cost-conscious SME with moderate intercompany volume, that is tolerable. For a complex multi-subsidiary group needing fully automated statutory consolidation, it is a constraint worth knowing before committing.

• →IFRS 10 and ASC 810 both require eliminating intra-group balances, transactions, and unrealized profit in full.
• →Currency translation follows IAS 21, with cumulative translation adjustments booked to other comprehensive income in equity.
• →Dynamics 365 Finance automates consolidation and eliminations through rules and a dedicated elimination legal entity.
• →Business Central consolidates across companies but posts eliminations as manual journals; capped at 300 companies per environment.
• →Odoo is report-oriented with manual eliminations and no native automated elimination engine in core accounting.

Dynamics 365 vs Odoo: multi-company fit for SMEs

Flectic implements both Microsoft Dynamics 365 and Odoo, so the recommendation is platform-neutral and driven by entity complexity rather than preference. The two platforms serve multi-company needs at different points on the complexity curve.

Microsoft Dynamics 365 Business Central treats each legal entity as a company, a data container with its own chart of accounts, currency, and fiscal periods, within one or more environments. Its Company Hub extension provides a cross-company and cross-environment dashboard for accountants managing multiple subsidiaries, online only and requiring the D365 COMPANY HUB permission set. Native intercompany is strong, covering orders, invoices, credit memos, returns, and general journals across currencies, charts of accounts, countries, and dimensions. Consolidation supports different charts of accounts, currencies, fiscal years, and environments, with eliminations entered manually. The 300-company-per-environment cap is well above what most SMEs need. Business Central is the balanced fit for moderate-complexity SMEs that want native intercompany and acceptable consolidation without the overhead of an enterprise tier.

Microsoft Dynamics 365 Finance, the F&O tier, is the enterprise step-up. Each legal entity has its own ledger, chart of accounts, and fiscal calendar and can be flagged as a consolidation company, an elimination company, or both, with no daily journals allowed in a pure consolidation company. It adds formal elimination rules, a dedicated consolidation legal entity, cross-company data sharing policies, and Management Reporter for multilevel hierarchies and runtime drill-down. It is the right tier when scale, advanced eliminations, or enterprise statutory reporting justify the investment, typically beyond the SME mid-market into the upper mid-market.

Odoo runs multiple Companies in one database, each an independent legal entity with its own chart of accounts, currency, taxes, journals, and fiscal localization, with resources such as products, partners, and warehouses selectively shared. Odoo is careful to distinguish Companies from Branches: a Branch is a subdivision of a single legal entity that shares the head office's chart of accounts, taxes, and fiscal positions, and is not consolidated the same way as a separate company. Use separate Companies for legally separate subsidiaries and Branches for regional or departmental structure under one legal entity. Odoo's inter-company transactions setting auto-generates counterparts, but its consolidation is manual and report-oriented, with no native automated elimination engine.

The SME decision framework is straightforward. For cost-conscious groups scaling into multi-entity with moderate intercompany volume that can tolerate manual elimination steps, Odoo is typically the lowest-cost entry point. For balanced native intercompany and acceptable consolidation at mid-market scale, Business Central is the default fit. For complex global multi-subsidiary groups that need a fully automated statutory consolidation and elimination engine, Dynamics 365 Finance or a peer enterprise tier is where the conversation starts. Flectic's AI-Accelerated Delivery methodology is designed to deliver these multi-company implementations up to 3x faster, not as an unconditional guarantee but as a target enabled by AI-assisted entity discovery, chart-of-accounts mapping, and intercompany configuration testing.

What to evaluate before committing to a multi-company ERP

Multi-company ERP projects fail when the entity model is underspecified. Before selecting a platform or an architecture, pressure-test the following, because each answer changes the recommendation.

First, map every legal entity you will run for the next five years, including likely acquisitions, and document each one's country, currency, tax nexus, chart of accounts, and fiscal calendar. This map decides whether single-instance is viable or whether data residency and regulatory firewalls force a multi-environment design. Second, estimate intercompany volume and complexity. High-volume, multi-currency intercompany with inventory transfers and unrealized profit calculations pushes toward Dynamics 365 Finance; moderate volume with straightforward due-to and due-from flows is comfortable in Business Central; low volume that can be eliminated manually is acceptable in Odoo.

Third, define the consolidation requirement precisely. If you need automated eliminations, a designated elimination entity, and ownership-percentage handling for partial acquisitions, the platform choice narrows quickly. If manual elimination entries against a consolidation company are acceptable, the field widens. Fourth, decide on master-data sharing policy: which products, customers, and vendors are shared across entities and which are kept separate, because this drives configuration effort and the data-sharing mechanism you will use.

Finally, sequence the rollout. Multi-company ERP is rarely greenfield across all entities at once; a phased rollout that establishes the consolidation entity and one or two operating entities first, then onboards subsequent entities, is lower risk and faster to value.

• →Map every legal entity for the next five years, including likely acquisitions.
• →Estimate intercompany volume, currency complexity, and inventory-transfer depth.
• →Define the consolidation requirement: automated eliminations vs manual journals.
• →Decide master-data sharing policy across entities.
• →Plan a phased rollout starting with the consolidation entity and core operating entities.