One Database or Several: Running a GCC Group on Odoo

The group has four entities. A Dubai mainland trading company, a free zone entity that holds the regional contracts, a Saudi subsidiary opened eighteen months ago, and a small Omani operation that was somebody's idea in 2023 and now has staff. Each of them keeps its own books and the group's real position is assembled once a month by a person with a spreadsheet.

The question that arrives at the first workshop is always framed as a technical one — can Odoo do multi-company — and the answer to that is yes, which is why it is the wrong question. Capability was never the constraint. What decides the design is what would have to be handed over if one entity ever left the group, and how much of the master data is genuinely common; everything else follows from those two. It sits on top of the general shape described in running Odoo in the UAE, with the difference that more than one authority now has a claim on the same database.

The pricing consequence, before anything else

There is a commercial fact that belongs at the start because it routinely surprises people three months in.

Odoo's plan structure puts running multiple companies on the higher tier, alongside Studio, external API access, and hosting other than Odoo Online. So the moment a second company is added to the database, the subscription plan changes — which means a decision taken in a design workshop, often by someone with no pricing authority, has moved the annual figure for every user in the group.

That is not a scandal and it is not hidden; it is stated on Odoo's own pricing page, and it is simply the kind of thing that is read after the fact rather than before. Read the plan boundaries at Odoo's published pricing before the workshop, not after, and note that this interacts with everything else in how an Odoo project's cost is actually built — the per-user subscription is the smaller half.

The question that actually decides it

One database with several companies, or several databases.

The honest test is not "how much do they share commercially" but this: is there anything a regulator, an auditor or a buyer could compel from one entity that must not be handed over with it. A single database means a single backup, a single export, a single administrator, and a single blast radius for a mistake.

Two situations push towards separate databases, and both are facts rather than preferences.

An entity that will be sold, closed or partnered. If a subsidiary has a realistic path out of the group, its data separability is worth designing now while it costs nothing. Separating it later means extracting one company's history out of a shared database, which is a project rather than an export.

Genuinely different operations with no shared master data. If the Omani entity sells different products to different customers with different staff, the argument for sharing a database is administrative convenience, and administrative convenience is a weak reason to accept a shared blast radius.

And one situation that looks like a third and is not, despite being the most commonly cited. The Saudi e-invoicing regime is a constraint on the system that issues the invoice rather than on a monthly filing — a signing, chaining and clearance pipeline attached to the moment of posting, which is a different class of requirement from a deadline. That makes it a capability question about your invoicing system, not an argument for a second database, and a group that answers it by buying a local package in Riyadh has bought a permanent seam through the middle of its own data. The distinction is worked through in what a Saudi entity actually does to a UAE group's systems.

Absent one of the two, one database is usually right, because the cost of several is paid every single month in reconciliation and the cost of one is paid once in design.

What has to be shared and what must stay separate

If you go with one database, the design is a list of decisions about which layer each thing sits on. Get this list wrong and you will be undoing it under time pressure.

Shared, and should be. The product master. The partner master. The structure of the chart of accounts — the same account meaning the same thing in every entity, which is what makes consolidation arithmetic rather than investigation. Users, as identities.

Separate, always. Journals and their sequences. Bank accounts. Tax configuration, because each jurisdiction has its own. Approval thresholds, because a limit that is generous in one entity is not in another. Document numbering, which auditors care about far more than implementers expect.

The one that gets missed. Fiscal position — the mechanism that decides which tax applies to which transaction for which counterparty. In a single-country installation this is a small piece of configuration. In a group spanning three tax authorities it is the piece that determines whether the return comes out right, and it is set per company and per partner rather than globally.

Intercompany is the whole difficulty

Everything above is a day of design. Intercompany is where groups actually lose their month-ends.

The rules that make it survivable are the same whether the entities are in one country or three: receivables and payables between group entities sit in dedicated accounts, one pair per counterparty entity, never mixed with third-party balances; both sides agree before the period closes rather than after; and the system preserves the basis of an intercompany price, not merely the price. The full design, including the free zone and mainland complications specific to the UAE, is set out in where the licensing, VAT and tax lines actually fall.

What changes across borders is that an intercompany invoice between two separately registered entities in two countries is a real export and a real import, with a customs event, a currency, and two different tax treatments. Groups that have been booking these as journals for years find that the practice has an expiry date the first time either country's e-invoicing rules reach them.

The error that costs a week every time

The single most common operational failure in a multi-company installation has nothing to do with any of the above. It is a user with access to every company and a default set to the wrong one, booking transactions into the wrong entity quietly for a week before anybody notices.

The fix is unglamorous and takes an afternoon. Every user gets an explicit default company and an explicit list of companies they can see, both derived from their job rather than from convenience. Nobody gets access to all companies by default, including finance. And the person who administers the system is not exempt — they are the most likely to make this exact mistake, because they are the one who moves between entities all day.

What to settle before anybody configures anything

Five decisions, in writing, before the first company record is created.

The entity list, including the dormant one. Every group has one. It has a licence, it may have a bank account, and it will need a chart of accounts eventually. Deciding now is free; discovering it in month four is not.

Which entities trade with each other, and on what basis. Not the volume — the basis. Cost, cost plus, market. Once an intercompany price has to be defensible to a tax authority, the system has to hold the reasoning behind it, which is a requirement nobody writes down at the start.

Whether a tax group exists or will. Corporate tax grouping changes what has to be identifiable at line level and what has to be eliminated, and it is far cheaper to design in than to retrofit. The systems implications are set out in what corporate tax requires of the ledger.

Who owns the group chart of accounts. One person. If each entity's finance lead can add accounts, the consolidation degrades within two quarters and nobody can say when it started.

What consolidation output the board actually reads. Ask for the file they read today. Build to that, then improve it. Building to a theoretical consolidation nobody asked for is one of the more reliable ways to spend three weeks.

The short version

Whether a GCC group runs on one Odoo database or several is decided by what an exit would require and whether the entities share anything at all, not by how many tax authorities are involved. One database, unless an entity has a realistic path out of the group or the operations genuinely share nothing. A foreign e-invoicing mandate is a capability requirement on the invoicing system and is not, by itself, a reason to split.

Before the design workshop, read Odoo's plan boundaries — adding a second company moves the subscription tier, and that is a pricing decision being made by whoever draws the entity diagram.

Share the product master, the partner master, the account structure and user identities. Keep journals, sequences, banks, tax configuration and approval thresholds separate, and treat fiscal position as the piece that decides whether the returns come out right.

Then spend your design effort on intercompany, because that is where the month-end goes, and give every user an explicit default company on day one. Settle the entity list, the intercompany basis, the tax group, the owner of the chart of accounts and the consolidation output before anything is configured — which is exactly the work that belongs in scoping rather than in the second month.