Three months after the release, the interesting question about Odoo 17 is no longer what shipped. It is whether a mid-market group running eight or twelve legal entities can now run them all in one place, and what breaks if it tries. That question is being asked more seriously this year than last, because the price gap has become hard to ignore. A group evaluating Odoo 17 for multi-entity operations is usually comparing it against a tier-one suite costing several times as much, and the honest answer depends far less on the software than on what shape the group is.
Multi-entity is not a feature you switch on. It is a statement about which things your companies must share and which they must not
Every multi-company implementation is an argument about that boundary. Shared customer master or separate? One product catalogue or several? Can a user in the trading entity see the contracting entity's margins? The software will implement whichever answer you give. It will not tell you which answer is right, and getting it wrong is expensive to unwind because it is encoded in every transaction posted since go-live.
What multi-company actually has to do
Six capabilities, and they are worth separating because vendors demonstrate the easy three. Shared master data with per-company overrides. Automatic intercompany document generation, in both directions. A separate chart of accounts and fiscal localisation per company. Consolidated reporting with eliminations. Access segregation that holds under audit. And genuine multi-currency, meaning different functional currencies per entity rather than one base currency with translation on a report. Odoo 17 does the first three well, the fourth adequately, the fifth well, and the sixth with caveats worth testing before you sign anything.
Three group shapes, and only one is an easy yes
The replica group — the same business operating through several entities, typically one per market. A trading company with arms in five countries, a services firm with an entity per jurisdiction. Shared products, shared customers, near-identical processes, differences confined to localisation and currency. This is where Odoo's multi-company model is strongest, and where a single database is clearly correct. The portfolio group — unrelated businesses under one holding company. Contracting, retail, logistics, a property arm. There is no shared master data because there is nothing in common except the shareholder. Forcing these into one database produces a chart of accounts that serves none of them and an access model that is permanently contested. Run separate databases, standardise the chart of accounts structure across them, and consolidate above. Odoo can still be the answer — just three or four times, not once. The vertical group — entities in one value chain. A manufacturer selling to a distribution entity selling to retail. This is the hard case and the one that deserves a real proof of concept. Intercompany volume is high, transfer pricing is a live tax question, and inventory valuation crosses entity boundaries. It can work. It should never be assumed.
| Boundary | Scenario to demonstrate |
|---|---|
| Intercompany | Trade both ways across different functional currencies |
| Close | Revalue balances and produce eliminations |
| Localisation | Print each entity's actual statutory documents |
| Permissions | Show legitimate cross-entity access and excluded entities |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to put in the proof of concept
Not a demo script. Six scenarios from your own operation. An intercompany sale generating the matching purchase automatically, in both directions, between entities with different functional currencies. A month-end close with open intercompany balances and a currency revaluation. A consolidation with eliminations, produced from the system rather than a spreadsheet. A statutory report per localisation, printed. An approval matrix that differs by company. And a user who legitimately works across three entities but must not see the fourth. If all six work on your data, the platform question is largely settled. If consolidation is the one that struggles, you are in good company — that is the weakest area, and plenty of groups run Odoo operationally and consolidate elsewhere. Decide that deliberately rather than discovering it in month nine.
Where the cost actually sits
The commercial advantage is straightforward: user-based pricing does not multiply by the number of companies, which is exactly where tier-one licensing hurts a group with many small entities. The implementation cost, however, scales with the number of distinct localisations rather than the number of entities. Five entities in one country is close to one implementation. Five entities in five countries is five sets of tax rules, statutory formats, payroll requirements and filing calendars. Price the assessment on the map, not the org chart.
Practical Guidance for Odoo Multi-Entity Assessment
- Classify the group as replica, portfolio or vertical before evaluating anything.
- Separate databases where entities share only a shareholder, not a business.
- Test intercompany in both directions with different functional currencies.
- Prove consolidation early; assume it may live outside the system.
- Count localisations, not entities, when estimating implementation.
- Design the access model around shareholder and commercial boundaries.
- Run one full close on copied data before committing.
- Keep customisation out of the multi-company layer, which changes most between releases.
The Regional Angle
The first thing to test for any group operating across this region is currency, and not the cosmetic part. A group with entities in the Gulf and entities in North Africa or Turkey is not running a multi-currency configuration; it is running two different accounting realities. Gulf currencies are pegged and behave predictably. Egypt has been through successive devaluations with an official rate and a parallel rate that have not agreed for some time, and Turkish operations fall under hyperinflationary accounting, which requires restatement rather than translation. Mid-market suites are consistently thinnest here. Before committing, test a full revaluation cycle with a large rate movement, test how the system handles an entity whose functional currency is not the group presentation currency, and establish in writing whether hyperinflation restatement is supported at all or will be done outside the system. If it is done outside, that is acceptable — but it needs to be a designed process with an owner, not a discovery your auditors make. The second is document output, which sounds trivial and consumes more implementation time than anyone budgets. Statutory documents in several jurisdictions here must be issued bilingually, with Arabic text alongside English, specific mandatory fields, tax registration numbers presented in a prescribed way, and right-to-left layout that does not collapse when a long company name is inserted. Crucially, these templates are per company, not per database — each entity has its own registration details, its own logo, its own footer and often its own regulator-approved format. Build and print the real documents for at least two entities during evaluation, in both languages, with a long Arabic customer name and a credit note as well as an invoice. Teams that defer this to the end of implementation find that the last three weeks before go-live are spent on layout, which is a demoralising way to finish a project. The third is ownership, and it is the one that most often overrides the technical answer. Groups here are frequently not groups in the clean sense. Entities have different shareholder mixes, local partners hold stakes in some and not others, and family branches sit behind different companies. A single shared database means one set of shareholders can, in principle, see another set's margins, customers and payroll. Technical access controls can enforce separation, but the question a minority partner's advisor will ask is whether the data sits in a database controlled by their counterparty, and no permission matrix answers that comfortably. Where a local partner holds a material stake in one entity, that entity frequently needs its own database regardless of how well it would have fitted technically. Map shareholding before architecture, and treat any entity with external co-ownership as a separate decision.
The objection worth taking seriously
The strongest objection is that this is a false economy. You save substantially on licences and hand the difference back in partner fees, and an annual release cadence means an upgrade decision every twelve months for the rest of the system's life. Tier-one suites cost more and come with a vendor that has to answer the phone, certified localisations maintained by the vendor rather than a community, and an audit trail your external auditors have seen a hundred times. For a group with genuine complexity, paying more for boredom is a defensible strategy. All of that is fair, and the upgrade cadence in particular is a real ongoing commitment rather than a one-off cost. Anyone evaluating on licence price alone will be unpleasantly surprised in year three. But the comparison has to be run over five years and against the full tier-one figure, including an implementation that routinely costs several times the software. For a group of sixty to two hundred users, with processes that are ordinary rather than exotic, the gap is wide enough to absorb a great deal of partner cost and still favour the cheaper platform. The genuine failure mode is not the software and not the fees. It is buying an open platform and then customising it until it is a bespoke product that only one consultancy understands — at which point you have tier-one lock-in without tier-one support. Keep configuration standard, keep the multi-company layer untouched, and the economics hold.
Common Questions
Can one database serve entities in different countries?
Yes, with a fiscal localisation per company. The constraint is how many distinct localisations you are prepared to implement and maintain, not the database.
Is consolidation really the weak point?
It is the area most groups supplement. Simple ownership structures consolidate acceptably; minority interests, step acquisitions and complex eliminations usually move to a dedicated tool.
How many entities is too many for one database?
The count matters far less than the divergence. Twenty similar entities are easier than three that operate differently.
What should we expect over the next twelve months?
Expect the next major release in the autumn, on the usual annual cycle, so treat any decision made now as carrying an upgrade within roughly a year — plan and budget it at the outset rather than treating it as an event. Expect localisation coverage across this region to keep improving, driven by e-invoicing mandates that give vendors no choice, which should narrow one of the historic gaps against tier-one suites. And expect the multi-company capability to keep attracting groups that have outgrown separate accounting packages but cannot justify a tier-one programme — which is precisely the segment where the classification question in this piece decides whether the project succeeds.
Odoo Multi-Entity Assessment — we classify your group before we evaluate the software, and we will tell you when two databases beat one.