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

What is multi-company ERP?

Multi-entity ERP, also called multi-company ERP, manages multiple distinct legal entities inside one ERP system or coordinated system landscape. 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.

Three multi-entity ERP architectures SMEs actually choose

Multi-entity ERP is not one architecture. Groups almost always land on one of three patterns, and confusing them is how SMEs over-buy enterprise software or under-build consolidation. The choice drives cost, control, and close speed for years.

A single-database multi-company setup runs multiple legal entities inside one ERP instance and one shared database. Separation 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. Odoo runs multiple Companies under one database this way; Business Central companies and Dynamics 365 Finance legal entities can also live in one managed application surface. The benefit is lower total cost of ownership, shared masters, and faster consolidated reporting. The trade-off is a shared upgrade cadence, a shared security boundary, and a single operational failure domain.

A multi-environment, multi-database setup runs each legal entity in its own ERP instance, tenant, or database, with consolidation handled by exporting balances into a consolidation entity or reporting layer. 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. Business Central can also consolidate across companies in different environments. The benefit is hard isolation for data residency, regulatory firewalls, divestiture-readiness, and highly autonomous subsidiaries. The trade-off is higher license and integration cost and a slower, more manual consolidated close.

A two-tier ERP architecture is different again: headquarters runs a Tier-1 backbone for group finance and governance, while subsidiaries run a lighter Tier-2 ERP for local operations, with integration and consolidation flowing edge-to-core. SAP's definition is the industry standard framing: different ERP systems at two layers of the organization, one stable backbone and a second layer of independent, integrated systems. Two-tier is not the same as multi-company inside one product; it is multi-product by design. Practitioners still push the pattern hard in 2026 for M&A velocity, subsidiary agility, and cost control when forcing every entity onto the HQ monster fails. If you need the full two-tier playbook, see our dedicated two-tier ERP guide; here the point is only that two-tier is a valid multi-entity architecture option alongside single-database multi-company and multi-environment isolation.

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, and Odoo 19 made the model more explicit rather than more automatic. Official Odoo 19 documentation describes consolidation as a composition of tools: account mapping across companies, multi-ledgers that can exclude consolidation-adjustment journals from statutory views, a multi-company selector, horizontal groups on Balance Sheet and P&L so each company contribution is visible, and multi-currency cumulative translation adjustments (historical rates for equity, weighted-average for profit and loss, closing rates for the balance sheet). There is no dedicated, rules-driven elimination engine comparable to Dynamics 365 Finance. Partner and community content sometimes markets automatic intercompany elimination; the practical pattern remains designating intercompany journals, filtering them with multi-ledgers, and posting topside elimination entries where inventory unrealized profit, partial ownership, or purchase-price allocation still require a cleanroom entity.

Odoo staff have confirmed that elimination entities remain valid in Odoo 19: an elimination entity is simply another company record in a multi-company database. Official community guidance lists cases that still force that pattern: unrealized profit in intercompany inventory, non-controlling interest carve-outs on less-than-100% ownership, goodwill and fair-value topside adjustments from M&A, and auditor-driven separation of local statutory books from group adjustments. For a cost-conscious SME with moderate intercompany volume and disciplined journal design, Odoo's report-oriented model is workable. For complex multi-subsidiary statutory consolidation that needs fully automated elimination rules and ownership-percentage templates, treat Odoo as the operational multi-company layer and budget either manual close discipline or a dedicated consolidation process.

• →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 19 consolidation is multi-ledger + account mapping + report-oriented; elimination entities still matter for unrealized profit, NCI, and M&A topsides.

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; Odoo 19 consolidation remains multi-ledger and report-oriented rather than a rules-driven elimination engine, with optional elimination company records for topside adjustments.

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. When HQ already runs a heavy enterprise stack and subsidiaries need local speed, evaluate two-tier architecture instead of forcing every entity onto the same product. 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.

SME multi-entity setup pitfalls that break the close

Most multi-entity ERP pain is not platform choice; it is configuration debt that surfaces every period end. The failure pattern CFOs describe is consistent: separate files or databases, inconsistent charts of accounts, manual intercompany, and a spreadsheet consolidation that nobody trusts on first pass. Fixing the following pitfalls before go-live is cheaper than re-platforming after the third broken close.

Pitfall one is treating branches as companies, or companies as branches. If two units are legally separate, they need separate company or legal-entity records with their own statutory ledgers. If they are divisions of one legal entity, forcing them into multi-company creates fake intercompany and unnecessary eliminations. Odoo draws this line in documentation; Dynamics draws it between company/legal entity and dimensions or responsibility centers. Mis-modeling here poisons every report that follows.

Pitfall two is weak intercompany controls. Without dedicated intercompany partners, journals, due-to/due-from accounts, and auto-accept or counterpart rules, teams re-key both sides, timing differences pile up, and AR/AP never net cleanly. Manual intercompany is a silent tax on finance: every entity in its own process, currency conversions by hand, one typo off, and the group number is unusable. Design intercompany accounts and document types first; enable automation second.

Pitfall three is chart-of-accounts and dimension chaos. Consolidation without a mapping standard forces finance to rebuild the group trial balance every month. Standardize a group reporting chart or explicit account mapping early, even if local statutory charts differ. Pitfall four is skipping an elimination or consolidation company when you produce audited group statements. Business Central and Dynamics 365 Finance both expect a place to park elimination journals; Odoo uses multi-ledgers and optional elimination company records. Without that cleanroom, topside adjustments contaminate local statutory books.

Pitfall five is unrestricted multi-company access. Users with every company allowed and the wrong default company post invoices into the wrong ledger. Scope allowed companies tightly, set defaults deliberately, and test as those users. Pitfall six is buy-and-build sequencing: PE-style roll-ups fail when five workstreams (CRM, SKUs, customers, APIs, ERP) run in parallel without a dependency order. Onboard entities with a fixed playbook: entity record, CoA/localization, bank and tax, intercompany partners, then cutover balances, not a simultaneous full-stack rewrite of every acquisition.

Pitfall seven is confusing multi-entity multi-company with two-tier strategy language. Marketing sometimes labels mid-market ERP as "Tier 2" when it means product tier, not architecture. Two-tier ERP means HQ on a different product from the subsidiary, integrated edge-to-core. Single-database multi-company on Odoo or Business Central is usually not two-tier; it is one product, many legal entities. Use the architecture table above so the RFP language matches the system design.

• →Model legal entities as companies; model divisions as branches/dimensions, not fake companies.
• →Design intercompany partners, journals, and due-to/due-from accounts before go-live automation.
• →Standardize group account mapping even when local statutory charts differ.
• →Create a consolidation/elimination cleanroom for topside and unrealized-profit entries.
• →Restrict allowed companies and verify default company per user.
• →Onboard acquisitions with a sequenced entity playbook, not parallel big-bang rewrites.

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-database multi-company is viable, whether data residency forces multi-environment isolation, or whether two-tier is the only way to onboard entities at acquisition speed. 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. When the group already has a heavy HQ system and needs local speed, evaluate two-tier explicitly rather than forcing every subsidiary into the same instance.

• →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.
• →Choose architecture deliberately: single-database multi-company, multi-environment, or two-tier.
• →Plan a phased rollout starting with the consolidation entity and core operating entities.

Frequently asked questions