Groups that run a trading company, a manufacturing arm and a services entity under one roof usually start with separate Odoo databases, one per legal entity. It works until someone asks for a consolidated balance sheet on Monday morning. Odoo multi-company lets you run several legal entities inside a single database, with their own books, their own sequences, and rules that decide exactly what each entity can see of the others. We set this up regularly for groups with entities split across Thailand, the US and India, and the configuration decisions made in week one tend to outlive the implementation by years.
This is not a feature you turn on and forget. It changes how access rights, accounting periods and even product masters behave. Below is how we approach it, what we check before go-live, and where the trade-offs sit.
What Odoo multi-company actually controls
Every record in Odoo, from a sales order to a journal entry, carries a company field. Multi-company mode adds a layer of rules on top of standard access rights: a user assigned to one company only sees records belonging to that company, unless you explicitly allow more. This is separate from user permissions (what a user can do) and controls what a user can see at all.
The practical building blocks are:
- Companies: each legal entity, with its own address, tax identification number, fiscal localization and currency.
- Branches or multi-company hierarchy: a parent-child structure if one entity reports up into a holding company.
- Chart of accounts: shared or separate, depending on whether entities file jointly or independently.
- Warehouses and inventory: each company typically owns its own warehouses, though shared products can appear in multiple company catalogs.
- Inter-company rules: automatic generation of matching sales and purchase documents when one entity trades with another.
Getting these five decisions right up front avoids the most common late-stage rework: discovering after go-live that a document numbering sequence, a tax code or a user's visibility was scoped to the wrong level.
Separate or shared chart of accounts
This is the first real decision, and it is more consequential than it looks. If your entities are in different countries, for example one in Thailand and one in the US, they need separate charts of accounts anyway because the statutory fiscal localization modules differ by country. Each company's accounting is independent: separate journals, separate tax reports, separate VAT or sales tax filings.
If your entities are in the same country and file jointly, or one is a pure holding company with minimal transactions, a shared chart simplifies maintenance. You configure accounts once and both companies post against the same structure. The trade-off is that you lose the clean separation auditors usually want to see entity by entity, so we only recommend it for genuinely simple holding structures.
A middle path that works well in practice: separate charts, but with a mapped structure, so that account 4000 in one company lines up conceptually with account 4000 in another even if local numbering differs slightly for tax reasons. This keeps consolidated reporting workable without forcing identical books onto entities with different compliance obligations.
Shared products, separate stock
A manufacturing entity and a distribution entity under the same group often sell the same catalog of finished goods. Odoo lets you mark a product as available to multiple companies, so you are not maintaining duplicate SKUs with duplicate descriptions, prices and barcodes across databases. This is one of the more underrated benefits of multi-company versus running separate instances.
What does not get shared automatically: stock quantities, valuation and warehouses. Each company keeps its own on-hand quantity, its own costing method (FIFO or average cost, for instance), and its own warehouse locations. This is almost always what you want, since the manufacturing entity's stock and the distribution entity's stock are legally and financially distinct, even if the product record is the same. Teams that assume shared products mean shared inventory levels are usually surprised the first time they check stock on hand from the wrong company's user.
Price lists, on the other hand, can be company-specific or shared depending on whether the entities sell at the same prices or negotiate independently. We generally scope price lists per company unless there is a clear reason to centralize pricing.
Configuring inter-company transactions
This is where multi-company earns its keep. When one of your own entities buys from another, for example the trading company purchasing finished goods from the manufacturing company, Odoo can automate the mirrored documents:
- A sales order confirmed on the selling company auto-generates a matching purchase order on the buying company.
- Validating a delivery on the selling side can automatically validate the corresponding receipt on the buying side, keeping stock moves synchronized.
- Posting a customer invoice can generate the matching vendor bill, reducing duplicate data entry and transcription errors between the two sets of books.
We configure these rules deliberately, not by default, because automatic rule generation on every internal transaction can clutter both companies with documents neither accounting team actually needs to see manually. A common approach is to automate the sales-to-purchase link but leave invoicing to a scheduled batch at month-end, so the finance team controls timing and can review before anything posts.
The limitation worth naming here: intercompany automation handles the document flow well, but it does not solve transfer pricing, intercompany reconciliation differences caused by currency timing, or the elimination entries needed for true consolidated statements. Those still need a controller's review each period, particularly where entities trade in different currencies and exchange rates move between invoice and payment dates.
Reporting across entities
Odoo's accounting reports accept multi-company selections, so a balance sheet or profit and loss can be pulled for one entity, several, or all of them combined. This works cleanly when charts of accounts are structurally compatible across the selected companies. It gets harder when one entity uses a country-specific fiscal localization with account codes that do not map one-to-one to another entity's chart.
For groups that need genuine statutory consolidation, elimination of intercompany balances, and multi-currency translation to a single reporting currency, plan for this as a distinct piece of configuration rather than assuming the standard financial reports solve it out of the box. We typically pair native Odoo reporting with a dedicated consolidation view or export for the group's management accounts, especially where entities span Thailand, the US and India with three different functional currencies and three different statutory calendars.
| Need | Native Odoo multi-company | Extra work usually required |
|---|---|---|
| Per-entity VAT or sales tax filing | Yes, by design | None, if localization module matches the country |
| Shared product catalog | Yes | Price list scoping decisions |
| Auto-generated intercompany documents | Yes, configurable | Deciding which steps to automate |
| Combined balance sheet view | Yes, if charts align | Account mapping across localizations |
| Full statutory consolidation with eliminations | Partial | Dedicated consolidation setup or export |
Access rights and the cost of getting them wrong
Multi-company security rules decide which users see which companies' data. The default behavior restricts users to their assigned company unless you grant multi-company access explicitly. This is the right default, but it needs testing before go-live, not after.
The risk runs in both directions. Too restrictive, and a shared finance team cannot do their job across entities without constant company-switching. Too permissive, and a user in one entity's sales team can see another entity's margins or supplier costs, which is a real problem in groups where entities have different ownership or minority partners. We test this with actual user accounts before go-live, logging in as each role and confirming what is visible, rather than inferring it from the configuration screens alone.
Multi-company versus separate databases
If your group is weighing this setup against running separate databases per entity, the deciding factor is usually how much the entities genuinely trade with each other and share master data. Heavy intercompany trading and shared catalogs favor one multi-company database. Entities that operate almost independently, with different industries, different growth plans or different eventual exit paths, sometimes do better staying on separate databases even if that means duplicating some master data.
We walk through this trade-off with the ownership structure and the finance team before committing, since migrating from one model to the other later is considerably more work than deciding correctly at the start. Our Odoo implementation services page covers how we scope this kind of decision phase by phase, and the Odoo ERP services overview lays out what typically comes after go-live for groups running several entities.
For groups already live on a single-company Odoo setup who are adding a second entity later, this is also a good moment to review your chart of accounts and accounting configuration rather than bolting a second company onto decisions made for one entity only. Reworking account structures after a year of postings is far more disruptive than planning for growth during the original Odoo consultancy phase. If the two entities will also trade heavily with each other, it is worth lining up the chart of accounts review with our hire Odoo developers team early, so the inter-company rules get built alongside the new company record rather than retrofitted afterward.
