Most groups in the GCC do not run a single legal entity. A trading company in Dubai, a sister company in Riyadh, a service arm in Cairo: the question comes up in almost every implementation we scope. Should all of these live in one Odoo database with multi-company switched on, or should each entity get its own database?
Both answers are valid. The wrong one is expensive to undo, because splitting a shared database later, or merging separate ones, is a migration project in its own right. This is how we think about the decision.
What multi-company in Odoo actually gives you
In multi-company mode, one database holds several companies. Each company keeps its own chart of accounts, journals, taxes, fiscal positions and fiscal localization, so a UAE entity and a Saudi entity can each run their own country package side by side. Users can be granted access to one or several companies and switch between them from the top bar.
What you can share is the real value: contacts, products, employees and configuration can be common across companies, or restricted to one, record by record. Odoo also offers inter-company rules, so a sale in one company can generate the matching purchase in the other, instead of someone keying the same transaction twice.
When one database is the right call
- The entities trade with each other. If goods or services move between companies every week, inter-company documents in one database remove a whole category of reconciliation work.
- They share products, customers or suppliers. One product catalog and one contact list means one place to fix a wrong price or a duplicate vendor.
- The same people work across entities. A finance team that closes three companies, or a procurement officer buying for all of them, works faster in one system than in three logins.
- Group reporting matters to management. Pulling figures from one database is simpler than stitching exports from several.
- You want one set of customizations. Custom modules, upgrades and testing happen once, not per database.
When separate databases are safer
- The businesses have little in common. A real estate company and a manufacturing company owned by the same family often share nothing but the owner. Forcing them into one database adds access rules and configuration without adding value.
- Confidentiality has to be absolute. Multi-company access is controlled by record rules, which work well, but every custom module and report must respect them. If a leak between entities would be a serious problem, physical separation is easier to defend.
- An entity may be sold or spun off. Carving one company out of a shared database is a project. Handing over a separate database is not.
- The entities need different Odoo versions or very different customizations. One database means one version and one code base for everyone.
- Data has to stay in a specific country. If one entity's data must be hosted somewhere the others' cannot be, separate databases may be the only option.
The trade-offs people underestimate
Multi-company is not free complexity. A few things catch teams out:
- Shared versus company-specific records. Every product, contact and pricelist has to be deliberately shared or deliberately restricted. Leaving it to defaults produces records that appear in the wrong company or disappear from the right one.
- Customizations must be company-aware. A custom report or automation that ignores the current company will mix data across entities. This needs to be part of the specification and the testing, not discovered after go-live.
- Licensing. On Odoo's current pricing, multi-company is part of the Custom plan rather than Standard. Check the current price list before you design around it.
- Testing effort grows. User acceptance testing has to cover each company and the flows between them, including users who belong to more than one.
Separate databases have their own costs: duplicated master data, manual inter-company entries, group reporting built outside Odoo, and every upgrade done several times.
A practical way to decide
Before the design phase, answer four questions for each pair of entities:
- How many transactions flow between them in a typical month?
- How many products, customers and suppliers do they have in common?
- How many users need to work in both?
- Is there any legal, ownership or data-residency reason they must stay apart?
If the first three answers are "a lot" and the fourth is "no", one database usually wins. If the fourth answer is "yes", that decides it regardless of the others. Mixed answers are common, and a hybrid is legitimate: closely linked entities share one database, while an unrelated business runs on its own.
Decide it early
The database structure shapes the chart of accounts, the access model, the migration plan and the test plan. It belongs in requirements and solution design, not in week eight of the build. Our Odoo implementation service works through this decision with you before any configuration starts, so the structure you go live on is one you will not have to rebuild.