Running multiple companies on one system: how Odoo's multi-company setup works

Odoo can run two or more legally separate companies inside one database, sharing master data where it helps and enforcing strict financial separation where compliance demands it. For a CTO consolidating entities after growth, an acquisition, or a regional split, this removes the manual reconciliation tax that comes from running each company on its own system, while keeping each entity's books, tax rules, and access boundaries intact.

This works when the setup is designed around the org's real intercompany flows. It is not a switch you flip; a shared database with the wrong sharing rules leaks data between entities, and separate ledgers without intercompany automation just move the manual work around.

An Odoo multi-company instance is a single Odoo database configured to operate multiple distinct companies, with data segregated by company-level access rules and shared only where explicitly permitted.

What is an Odoo multi-company instance?

An Odoo multi-company instance is one Odoo database that hosts several companies, each with its own accounting, sequences, and users, under a common technical platform. The companies can share records such as products, contacts, and equipment, or keep them separate, controlled per record through the Company field.

Core capabilities:

• Per-company accounting. Each company keeps its own chart of accounts, journals, fiscal position, and currency, so financial separation holds for audit and statutory reporting.

• Shared or isolated master data. Products, contacts, and equipment can be shared across companies or scoped to one, decided per record through the Company field. New products and contacts are shared by default.

• Company-scoped access. Users are granted access to one or more companies; records linked to a specific company are visible only to users logged into that company.

• Intercompany transaction rules. A sale from company A to company B can auto-generate the matching purchase document in B, reducing double entry across the group.

• Consolidated and per-entity reporting. Reports run for a single company, a selected subset, or the whole group, so executives get a consolidated view without exporting and merging spreadsheets.

What does an Odoo multi-company instance mean for a business?

For a business, an Odoo multi-company instance means running the whole group on one platform: one source of truth for consolidated numbers, one system to license and maintain, and a structure that absorbs new entities as the group grows. The payoff is strategic before it is technical, and it concentrates in six places.

• Faster group decisions. Consolidated and per-entity figures are available on demand, so month-end close and board reporting stop depending on manual spreadsheet merges. Finance can report the group position within days, and executives act on current numbers.

• Lower total cost of ownership. One database to host, upgrade, and support replaces parallel systems and the integrations between them, which concentrates IT spend and shrinks the maintenance surface. Price in one caveat: enabling multi-company on an Odoo Standard plan triggers an upsell to the Custom plan (Odoo 19 documentation: Multi-company), so licensing belongs in the business case.

• Quicker entity and acquisition integration. Adding a company to an existing instance is faster than standing up a new system, so a newly acquired entity or a new regional operation reaches operational reporting sooner. The platform scales with the corporate structure instead of lagging behind it.

• Recovered finance and admin capacity. Shared master data ends duplicate entry across entities, which removes reconciliation work that grows with every company added. This is the clearest line-item saving and the easiest to measure.

• Compliance that holds as you scale. Each entity keeps its own tax localization and statutory books while rolling up to the group, so operating across jurisdictions does not force compliance shortcuts or a separate finance stack per country.

• Lower systems risk. Consolidating onto one platform reduces integration points, data drift, and the operational exposure of maintaining parallel systems

The value is conditional. It appears only when the sharing model and intercompany rules are designed around the group's real structure; a shared database with the wrong configuration reintroduces the reporting and reconciliation problems it was meant to remove.

Recently Redbee unified two legal entities of a Romanian distributor of automated dairy-farming equipment into one Odoo database. Shared database elements removed duplicate data entry across the group, administrative staff recovered dozens of hours per week previously spent reconciling records, and the client gained real-time visibility into every hardware unit's location and status.

What is the risk of running multiple companies on one system?

Running several legal entities together is hard because each one has its own compliance obligations while the business wants them to behave as a group. The friction concentrates in a few places.

• Duplicated master data When entities run on separate systems, teams re-key vendors, customers, and products into each one. The records drift, reconciliation becomes a standing task, and no one trusts a single number. A shared instance removes the duplication only if the sharing rules match how the group actually operates.

• Separate books with group-level reporting Each entity needs its own ledger, tax treatment, and statutory filings; leadership needs one consolidated view across all of them. Systems that give you one usually make the other painful. The design has to keep the ledgers legally distinct and still roll up cleanly.

• Intercompany transactions Sales, purchases, and transfers between the entities generate matching documents on both sides. Handled manually, they are slow and error-prone, and month-end close absorbs the cost. This is where a shared instance earns or loses its keep.

• Access control across entities Some staff work across all companies; others must see only one. Getting this wrong exposes financial data across legal boundaries. Access has to be scoped by company at the record level, not assumed from a single login.

How does Odoo run multiple companies in one instance?

Odoo runs multiple companies in one instance by tying each record to a company through the Company field and granting each user access to one or more companies, so the database is shared while the records a user reaches are scoped by company (Odoo 19 documentation: Multi-company). The mechanism has five moving parts a CTO should understand before committing.

Company creation and the company selector. You create each company under Settings, Users and Companies, Companies. Authorized users select or combine companies through the company selector in the header menu, and the active company sets defaults for new records. This is what lets one user work across entities without switching systems.

The Company field controls visibility. Leaving a record's Company field blank makes it available to all companies; setting it to specific companies restricts it to users logged into those companies. Company-linked documents such as quotations, invoices, and vendor bills are visible only within their owning company. Under the hood this is enforced by company record rules on company_id, which is what makes a shared database safe for separate legal entities.

Shared versus company-specific records. Sharing is decided per record, not per module. New products and contacts are shared across all companies by default; set the Company field to restrict them. Individual fields inside a shared record can differ by company: a product's Sales Price and Reference are shared while its Cost is company-specific, which supports different cost structures across entities on the same product.

Inter-company transactions. With the Inter-Company Transactions feature enabled, one company selling to or buying from another in the same database can auto-generate the counterpart document. The configurable options are create vendor bills, create sales orders, create purchase orders, and synchronize stock moves. Product records must be shared among the involved companies, and fiscal positions and localizations must be set correctly for the postings to be right.

Per-entity accounting and localization. Each company carries its own chart of accounts, currency, and fiscal localization, so a group spanning jurisdictions applies the correct tax and reporting rules per entity while reporting up to the group.

Single instance or separate instances: which fits?

A single multi-company instance fits groups that share data and transact internally; separate instances per company fit portfolios of unrelated businesses with little overlap. The table below sets out the trade-off.

There is a third path worth checking before creating any second company. When a single company only needs to run a distinct product line or process, analytic accounting and multiple warehouses can handle it without a new company, which Odoo notes avoids unnecessary database complexity. Reach for multi-company when the driver is separate legal entities, distinct tax jurisdictions, or intercompany trade, not merely separate operational streams.

How to set up an Odoo multi-company instance well

Set it up as a build sequence, deciding data sharing and access before configuring transactions, because the order determines whether the instance stays clean as it grows.

1. Map the legal and reporting structure first. Define each company, its currency, and its fiscal localization, and confirm how leadership needs to consolidate. This drives every downstream choice.

2. Decide shared versus scoped records via the Company field. Agree which records stay shared (often products and contacts, shared by default) and which are restricted to one company before importing anything.

3. Configure user company access and test isolation. Grant each user access to the correct companies and verify that company-linked records stay isolated. Test with a user who should see only one company.

4. Enable intercompany rules where entities trade. Turn on counterpart-document generation only for the company pairs that actually transact, so automation matches real flows.

5. Set per-entity chart of accounts and journals. Keep books legally distinct; confirm each company's statutory reporting runs independently.

6. Validate consolidated reporting. Run group and per-company reports and reconcile them against known figures before go-live.

Talk to our team →