WHAT WE SEE IN THE FIELD
One group, several companies, too many versions of the same information
A group grows through new legal entities, new countries or acquisitions.
Each company develops its own way of working. One has its accounting system, another has a different ERP, commercial teams maintain separate customer databases and products are created several times with slightly different references.
Eventually management wants a consolidated view of the business.
Then the real complexity becomes visible.
Which customer is the same customer across three companies? Are product references consistent? How much stock does the group actually hold? What is being sold internally between companies? Are management reports comparing equivalent information?
The instinctive answer is often:
“We need to put every company in the same ERP.”
Sometimes that is exactly the right architecture.
But sharing an Odoo database is not the same as making every company operate as if it were one legal entity.
The real design question is more precise: What should be shared across the group, and what must remain company-specific?
That is the question Odoo multi-company should answer.
ODOO MULTI-COMPANY IN PRACTICE
One database does not mean one company
Odoo allows several companies to operate within the same database. Users with the appropriate access can work across multiple companies, while records can either be shared or restricted to a specific entity.
That distinction is fundamental.
A group may want to maintain one common product catalogue across Portugal, Belgium and France while preserving different accounting, taxes, warehouses and transactions for each legal entity.
Products and contacts, for example, can be shared between companies. In Odoo, leaving the Company field empty on relevant records makes them available across companies, while assigning a company restricts them to that entity. Transactions such as quotations, invoices and vendor bills remain associated with a specific company. Odoo can even maintain some properties differently by company on a shared record, such as company-specific product costs.
This provides an architecture that sits somewhere between two extremes.
The group does not need three completely independent databases containing duplicate master data.
But it also does not need to pretend that three legal companies are operationally and financially identical.
That balance is where multi-company creates value.
HOW WE WOULD CONFIGURE IT
Decide what belongs to the group and what belongs to the legal entity
Before activating inter-company automation or configuring accounting, we would map the group's information model.
Take the product catalogue.
If several entities sell the same products, maintaining one shared reference can make sense. But perhaps purchase costs differ because each company negotiates independently with suppliers.
The product can remain shared while some company-dependent information differs.
Customers require the same discussion. If the same corporate customer buys from several entities, a shared contact record may prevent duplicates. However, invoices, receivables, payment terms and fiscal transactions still need to belong to the appropriate legal company.
Warehouses are another obvious boundary. Each entity may operate its own physical stock, even if the product catalogue is shared.
And Accounting requires an even clearer separation because each legal entity has its own books, fiscal responsibilities and reporting requirements.
This is why we would not start a multi-company project with the company selector.
We would start with the information.
For every important object in the system, the question is:
Is this group information, or company information?
Getting that distinction right at the beginning makes almost everything that follows easier.
INTER-COMPANY TRANSACTIONS
Internal trade should not require both companies to enter the same transaction
Sharing a database becomes particularly valuable when companies transact with each other.
Imagine a Belgian entity sells equipment to the Portuguese company.
- For Belgium, this is a sale.
- For Portugal, it is a purchase.
Without inter-company automation, someone may create the Sales Order in one entity and another person creates the corresponding Purchase Order in the other.
The business event happened once.
The ERP records it twice manually.
Odoo's inter-company functionality can automate counterpart transactions between companies in the same database. Depending on the configuration, confirming a Purchase Order can generate the corresponding Sales Order, a Sales Order can create the corresponding Purchase Order, and invoices can generate counterpart Vendor Bills. Stock movements can also be synchronised between companies.
This can remove significant duplicate administration.
But we would not automatically switch on every available option.
Internal flows still need rules.
Which company initiates the transaction? Does the counterpart document remain in draft for verification or should it be automatically validated? Which warehouse supplies the goods? What internal pricing applies? Which taxes and fiscal positions should be used?
Odoo can automate the documents.
The organisation still needs to define the commercial and accounting logic behind them.
LOCALIZATION AND COUNTRY DIFFERENCES
A shared ERP does not mean shared fiscal rules
This becomes especially important in international groups.
A Portuguese company and a Belgian company may share customers, products and management processes.
They do not share tax legislation.
Odoo allows different companies in the same multi-company environment to use different fiscal localization packages. Odoo's documentation explicitly notes that entities operating in different countries should be configured as separate companies rather than branches, because branches inherit the fiscal localization of their parent company.
That makes multi-company architecture highly relevant when designing an international Odoo environment.
The group can standardise areas such as product structure, commercial processes, purchasing logic or management reporting where appropriate, while each legal entity retains the accounting and tax configuration required in its own country.
For example, a group could operate Portuguese, Belgian and French entities within the same overall Odoo environment without pretending that their accounting configuration is interchangeable.
The goal is not absolute standardisation, but rather a controlled standardisation.
- Common where being common creates value.
- Local where legislation or business reality requires it.
MANAGEMENT ACROSS COMPANIES
Group visibility should not depend on rebuilding the numbers outside the ERP
One of the reasons groups consider multi-company is management visibility.
Odoo allows authorised users to select multiple companies and view information across them. Its multi-company environment is designed to support aggregated reporting while maintaining company-specific records and access.
That does not automatically solve every consolidation requirement.
Statutory financial consolidation, eliminations, different accounting standards or complex group reporting may still require specific configuration and, depending on the organisation, additional processes.
But it changes the starting point.
If companies use common structures and their transactions already exist in the same environment, management does not first need to reconstruct the operational picture from unrelated systems.
A group can begin with consistent information instead of beginning with reconciliation.
That is a significant difference.
THE MOST COMMON MISTAKE
Creating a company whenever the business wants separate reporting
Not every division, brand, warehouse or business unit should become an Odoo company.
Odoo itself warns against introducing multi-company unnecessarily. Its documentation gives the example of a company considering a separate company structure for a new product line, while capabilities such as analytic accounting and multiple warehouses may provide the required separation without adding the complexity of another company.
This distinction matters.
Suppose one legal company operates two brands and Management wants separate P&Ls.
That does not automatically mean we need two Odoo companies since Analytic accounting may provide the required financial dimension.
If there are two warehouses, Odoo can manage multiple warehouses without introducing another company.
If there are several sales teams, they can also remain inside the same legal company.
Multi-company should reflect a meaningful organisational or legal separation, not simply every dimension management wants to analyse.
Otherwise the architecture becomes heavier than the business itself.
ANOTHER COMMON MISTAKE
Sharing data without deciding who owns it
Shared master data sounds efficient until several companies start maintaining it differently.
- One entity changes a product name.
- Another changes a customer address.
- Someone creates a duplicate because they cannot find the existing record.
- A third team introduces a new naming convention.
Technically, the information is shared, operationally, nobody owns it.
A multi-company implementation therefore needs some level of master-data governance.
- Who creates products?
- Who can modify shared records?
- Which information can differ by company?
- How are new customers checked for duplicates?
- How should group naming and coding conventions work?
These questions may sound administrative, but they directly affect the quality of reporting and automation.
Sharing data only creates value when the organisation can trust that data.
OXALYO'S TAKE
Standardise the group without erasing the companies
The biggest advantage of multi-company is not simply having several companies in one Odoo database.
It is being able to decide deliberately where the group should behave as one organisation and where each entity needs to remain independent.
- Products may be shared.
- Warehouses may be separate.
- Customers may be common.
- Invoices must belong to the correct company.
- Internal transactions may be automated.
- Fiscal localization must reflect the country where each entity operates.
- Management may need a group perspective while local teams need their own operational environment.
Those requirements are not contradictory. They are exactly what the multi-company architecture needs to reconcile.
When we design an Odoo multi-company environment, we therefore do not begin with:
“How many companies do you have?”
We begin with:
“How does information and value move between them?”
That answer tells us much more about the architecture the group actually needs.
FAQ: ODOO MULTI-COMPANY
Can Odoo manage several companies in the same database?
Yes. Odoo supports multiple companies in a single database, with users able to access one or several companies according to their permissions. Some records can be shared while transactions and other records remain associated with specific companies.
Can companies share products and customers in Odoo?
Yes. Records such as products and contacts can be shared across companies when no specific company is assigned to them. Other information can remain company-specific.
Can each Odoo company have its own accounting?
Yes. Companies have their own accounting environment and can use the fiscal localization appropriate to the entity. In a multi-country structure, different companies can use different fiscal localization modules.
Can Odoo automate transactions between companies?
Yes. Odoo Inter-Company Transactions can automatically create counterpart Sales Orders, Purchase Orders and Vendor Bills, and can synchronise stock movements depending on the configuration.
Can a Portuguese and Belgian company use the same Odoo database?
Yes. Separate companies within the same Odoo database can use different fiscal localizations. This makes it possible to share an ERP environment while retaining country-specific accounting and tax requirements.
What is the difference between an Odoo company and a branch?
A company can have its own fiscal localization, while branches follow the localization of their parent company. Odoo therefore recommends using separate companies for entities operating in different countries.
Should every business unit be configured as a separate Odoo company?
No. Depending on the requirement, capabilities such as analytic accounting, multiple warehouses or other organisational structures may provide the necessary separation without adding another company.
Do inter-company transactions require configuration?
Yes. Odoo specifically warns that inter-company flows require correct general and company-specific configuration, including fiscal positions and localizations.
Does your group need several ERP systems, or a better multi-company architecture?
If companies are duplicating products, customers and internal transactions simply because they operate as separate legal entities, Odoo multi-company may allow the group to share what should be common while preserving what genuinely needs to remain separate.
Talk to Oxalyo about your Odoo multi-company setup.