Multi-Company Setup in Odoo

How multi-company works in Odoo

Odoo's multi-company model hosts several companies inside a single database and uses a company selector plus record-level company fields to keep operational and accounting data separate while sharing common masters. Every accounting document — invoice, journal entry, payment — carries a Company field, and Odoo enforces that postings land in the correct company's chart of accounts and journals. Authorized users can select more than one company in the selector to work across entities and run aggregated operational views without switching databases.

The benefit over a separate database per entity is operational: one login, one shared product and partner catalog when you want it, and inter-company document automation instead of re-keying. The constraint to understand up front is that each company still needs its own chart of accounts, journals, currencies, taxes, and fiscal localization. Multi-company does not merge the accounting of the entities; it hosts them side by side. Consolidation across those ledgers is a separate design decision — Odoo 19 ships consolidation tools (account mapping, multi-ledgers, horizontal groups, cumulative translation), but advanced IFRS eliminations often still need process design or a specialist tool.

Which Odoo plan unlocks multi-company

Before you create a second company on Odoo Online, confirm the plan impact. Official Odoo 19 documentation warns that enabling multi-company on a Standard plan database automatically triggers an upsell to the Custom plan. That upsell does not apply the same way to databases on the One App Free plan — Odoo's pricing FAQ also states the free plan can allow multiple companies, and that installing Studio or adding companies can switch you toward Custom when you leave pure free-tier usage. Custom is explicitly positioned for multi-company management, Odoo Studio, custom developments, and external API use.

Billing behavior matters as much as the feature flag. For yearly or multi-year contracts, Odoo creates an upsell order with a 30-day limit so finance can review the change. For monthly contracts, the subscription automatically switches to Custom and the new rate applies on the next bill. Regional pricelists and intro discounts change the per-user number (see our Odoo pricing guide for current US/CAD/EUR bands), but the structural rule is stable: multi-company on paid Online is a Custom-plan capability, not a free Standard add-on. Budget the plan jump before you create entity two just to try it in production.

Step 1 — Create companies, localization, and warehouses

Navigate to Settings → Users & Companies → Companies. Create each legal entity as a company record with name, address, country, currency, and logo. The company created at installation is the default; each additional company is a separate record that will carry its own accounting and documents. Set country and currency correctly before the first posting — Odoo's own multi-company training treats country and fiscal localization as hard-to-fix foundations once the ledger has activity.

For each company, configure accounting as a mini implementation: fiscal localization package (chart of accounts template, taxes, journals), bank accounts, fiscal positions, and document sequences. In a multi-company environment each company can use a different fiscal localization; that is the supported path when entities operate in different countries. Do not use branches for cross-border legal entities: official localization guidance states branches always follow the parent company's localization, so multi-country groups should be companies, not branches.

Warehouses are a common missed step. Odoo does not automatically create warehouses for additional companies created after the initial database setup. Create warehouses manually per company under Inventory configuration, assign them to the correct company, and wire them into inter-company purchase/sales options that reference Use Warehouse. Without this, inter-company order automation fails even when accounting rules look correct.

Step 2 — Grant users the right allowed companies

Access is controlled per user through Allowed Companies on each user record. A user with access to multiple companies can switch between them with the company selector and operate in the currently highlighted company; a user scoped to a single company never sees the others. Group controllers and consolidation users typically get access to all companies; operating staff stay scoped to their entity. Multi-select in the company selector is how power users review aggregated operational data without changing who can post where.

Two access rules deserve attention. First, multi-company access is set on the user record — do not assume a generic security group alone is enough. Second, watch each user's default company, because new records inherit that company. A finance user whose default is wrong will post into the wrong ledger until someone cleans the trail. Practitioners also stress custom record rules (ir.rules): if you add custom modules or multi-company CRM stages, test with at least two active companies and verify every custom domain respects company_id. After configuration, log in as each role and confirm the selector shows exactly the intended companies.

Step 3 — Configure inter-company rules

Inter-company rules are what make multi-company more than parallel ledgers: they generate counterpart documents in the partner company so internal trades stay in sync. Activate Inter-Company Transactions under Settings for each relevant company (company selector → Settings → Companies section), then choose which counterpart documents to create. Product records used in inter-company flows should be shared among the involved companies. Odoo also warns that fiscal positions and localizations must be set correctly or counterpart documents mis-tax or fail.

Odoo 19 documents four automation families plus a validation toggle. Create Vendor Bills auto-creates a bill/refund when another company confirms an invoice/credit note for this company. Create Sales Orders creates a draft quotation when a purchase order is confirmed for this company. Create Purchase Orders creates a draft RFQ/PO using the selected warehouse when a sales order is confirmed for this company. Synchronize Stock Moves keeps delivery and receipt moves aligned when fulfilling between companies. Selecting Validated auto-validates the generated records across those options. Developer mode also exposes an Inter-Company Transactions tab on the company form for the same settings.

On the accounting side, map inter-company due-to/due-from (or receivable/payable) accounts and test end-to-end with one internal invoice and one internal SO/PO before go-live. The usual failures are a missing warehouse, wrong counterpart company, incomplete fiscal position for intra-group tax treatment, or enabling rules without balancing accounts. Done correctly, an internal transfer is one confirmation that creates both sides; done incorrectly, it becomes month-end reconciliation debt.

Step 4 — Decide what master data is shared

In a multi-company database, new products and contacts are shared across companies by default. Leave the Company field blank to keep a record accessible to all companies; set Company to one or more entities to restrict visibility to users logged into those companies. Documents tied to a company (quotations, invoices, bills) remain company-specific and are only visible in that environment.

Shared records can still carry company-specific properties. On products, Sales Price and Reference are commonly shared while Cost is company-specific, so each entity can hold different cost structures under one SKU. Pricelists and vendor pricelists then layer entity-specific selling or buying prices for inter-company markup without duplicating the product master. Inventory quantity is tracked per company warehouse even when the product is shared.

Choose deliberately. Share the group catalog and common suppliers when entities trade the same goods; scope customers when sales teams must not see each other's accounts; scope products only when catalogs truly diverge. Document the rule so the fifth company inherits the same policy. Over-sharing clutters selectors and can expose customer lists across entities; under-sharing kills the point of one database and breaks inter-company product links.

Companies vs branches vs separate databases

Odoo supports companies, branches, and entirely separate databases — they solve different problems. Multi-company is for legally separate entities that need their own books, tax IDs, and optionally different fiscal localizations, while still sharing masters and inter-company flows. Branches are subdivisions of a single legal entity: they inherit the parent's accounting localization and often share journals, taxes, and accounts. Official fiscal localization notes are explicit: entities operating in different countries should be set up as companies, not branches.

Access rights alone are not multi-company. Restricting document visibility with groups does not give you separate ledgers, tax filings, or inter-company invoices. Separate databases are simpler when entities share nothing operationally, need hard data isolation, or want independent upgrade cycles — at the cost of no native inter-company automation and duplicated masters. Odoo's multi-company training frames the best choice for an additional company as a new entity with its own tax ID and independent filings, not merely different pricelists or document visibility.

A practical decision rule: same country, one legal entity, shared books → branches or analytic accounting and multi-warehouse. Multiple legal entities, shared catalog, internal trade → multi-company. Multi-country statutory filings → multi-company with per-company localization. Truly independent businesses or strict segregation → separate databases. Wrong architecture is expensive to unwind after go-live because company_id is baked into documents and stock.

Consolidation — native tools and remaining limits

Consolidation combines financial data from multiple legally separate companies into a group view. Odoo 19 documents a consolidation toolkit: account mapping across charts of accounts, multi-ledgers (regular company ledgers plus a consolidation multi-ledger that can include or exclude adjustment journals), multi-company selector views for group journal items, horizontal groups on Balance Sheet and P&L to show each entity's contribution, and cumulative translation adjustments for multi-currency groups (historical rates for equity, weighted average for P&L, closing rates for other balance-sheet accounts). Accounts can optionally be merged across companies to standardize reporting lines.

That is materially more than export-to-spreadsheet-only workflows, but it is not a full enterprise consolidation suite by default. Advanced intercompany eliminations (intra-group revenue/cost, unrealized profit in inventory, dividends, non-controlling interest) are not automatically complete for every IFRS 10 / IAS 21 scenario. Many groups still post elimination journals into a consolidation company or multi-ledger, or push trial balances into BI or a dedicated consolidation tool for statutory packs. IFRS 10 still governs when control requires consolidated financial statements; Odoo does not replace the accounting judgment.

For an SME with two or three same-currency entities, account mapping plus a consolidation multi-ledger and periodic elimination journals is usually enough and auditable. For multi-currency holding structures, model CTA, mapping, and eliminations before go-live — not after the first board pack is late. The honest guidance: Odoo multi-company operations are strong; consolidation is capable for mid-complexity groups if you configure multi-ledgers and mapping deliberately, and still needs process design when statutory complexity rises.

Common multi-company setup mistakes

Five errors recur. First, giving every user access to every company for convenience, which defeats segregation and causes wrong-entity postings — scope Allowed Companies tightly. Second, incomplete inter-company setup: rules enabled without warehouses, fiscal positions, or due-to/due-from accounts. Third, treating branches as multi-country legal entities and inheriting the wrong localization. Fourth, assuming consolidation is a one-click statutory report without mapping, multi-ledgers, or eliminations. Fifth, creating a second company on Standard production without budgeting the Custom plan upsell.

A subtler trap is over-sharing master data and under-testing custom code. Shared products with wrong company costs distort margins; shared customers expose commercial data; custom modules that ignore company_id create cross-entity leaks. Public practitioner chatter repeatedly flags multi-company gaps when implementation partners under-design access rules and inter-company tax. Multi-company is powerful because it is flexible — configuration discipline is on you. Test with two live companies, one inter-company invoice, one inter-company order with stock, and a consolidation dry-run before cutover.

When Odoo multi-company is the right model

Odoo multi-company is the right model when you run several legal entities that share products, suppliers, or operational processes and you want one database, one login, and automatic inter-company document flow. It fits multinational retail or distribution with local tax and currency, holding structures with internal service charges, and manufacturing groups that transfer stock between entities. It is the wrong model when entities are independent businesses with no shared masters — separate databases are simpler — or when you only need visibility limits inside one legal entity (use access rights, branches, or warehouses instead).

For most SME groups of two to five entities in one or two currencies, Odoo's model works well if you accept Custom plan economics, per-company localization and warehouse setup, deliberate master-data policy, and a designed consolidation step. Plan the entity structure, access model, inter-company accounting, and consolidation approach up front, and a multi-company Odoo rollout stays a contained project rather than a year of reconciliation firefighting.

Frequently asked questions