Multi-Company Odoo for UAE Business Groups

Map companies, branches and reporting boundaries

Create a register of legal entities, branches, registrations, currencies and reporting periods. Ask finance which records must remain separate and which management reports need a combined view. Do not create a new legal-company record merely because a shop needs its own sales report, or merge separate entities just because they share an owner. The model should reflect the business and its obligations.

Document the approved structure before importing opening balances. Changing the model after staff begin posting can require more than renaming a company. Include accountants and the people handling purchasing, sales and stock in the design conversation. They will expose cases such as shared procurement, one warehouse serving several entities, or invoices issued by a different entity from the selling branch.

Specify shared records and company-dependent values

Odoo 19’s multi-company documentation describes shared and company-specific records and values. Use it for the version-specific design rather than assuming every field is shared identically. Decide who maintains contacts and products, how duplicate records are prevented and which values require entity-specific review.

For example, a product can have one agreed internal reference while accounting or costing behaviour needs separate consideration by company. Build a test that switches company context and checks the resulting purchase, sale and journal entries. A shared catalogue is useful only when it does not silently apply another entity’s settings. Keep a documented rule for creating new master records.

Test access with the intended user roles

Define who can view, create, approve and post in each entity. Include shared-service staff who work across companies and operational staff who should not. Test with their actual roles rather than an administrator account. Check reports, exports, attachments and search results as well as the main transaction screen; sensitive information can be exposed outside the obvious form.

Train users to confirm the active company before entering a document and make the context visible in their workflow. Record how mistakes are corrected through approved accounting procedures. Do not use broad cross-company access as a shortcut to fix a confusing setup. Access should follow a role and an accountable approval, not the convenience of making an error message disappear.

Prove intercompany flows from both sides

Illustrative case: Company A supplies goods to Company B. Define which document starts the flow, what the receiving company must approve, how prices and taxes are determined, and which references link the two sides. Test partial deliveries, returns and cancellations. A successful sale in A is not enough if B’s purchase is missing or has a different quantity.

Reconcile receivable and payable balances between the entities, recording timing and currency differences. Verify the actual automation supported by the proposed edition and modules; do not promise that every transaction automatically posts both sides. Where manual approval remains appropriate, keep it explicit. The objective is a controlled paired process, not maximum automation at the expense of oversight.

Treat consolidation as a defined reporting requirement

Write down the group reporting currency, chart mapping, period alignment and adjustment requirements. Establish how intercompany activity will be identified and eliminated where appropriate. These are accounting design decisions, not a consequence of selecting several companies in a report filter. Ask the implementer to demonstrate the complete consolidation result and its supporting detail for the proposed version.

Retain a clear separation between source entity entries and approved consolidation adjustments. If the group includes different periods or currencies, test representative cases rather than assuming a combined total is meaningful. Coordinate the reporting pack with the corporate-tax reporting checklist, while asking the adviser to determine any tax-group implications separately.

Confirm commercial scope and go-live evidence

Obtain a quote identifying edition, version, hosting plan, users, modules and any custom reporting. Do not assume the cost is determined only by company count or only by users. Review the edition selection guide for plan and dependency questions. Include the effort of separate balances, permissions and acceptance tests in the implementation scope.

Before launch, finance should approve entity reports, paired transactions, access tests and any group adjustments. Run a trial close using realistic data and document unresolved exceptions. A staged Odoo implementation can establish one controlled entity before extending the pattern, provided the group design is agreed at the outset.

Run a two-entity acceptance exercise

Use two test companies with clearly identified data. Create a shared customer or product according to the approved design, then issue separate transactions and verify that the correct company details appear on each document. Sign in as a restricted user and attempt only the authorised work. Confirm that the user cannot retrieve another entity’s sensitive records through reports or exports. Record what was tested, not simply that security was checked.

Next, process a paired intercompany transaction, reconcile both balances and introduce a controlled mismatch such as an unposted receiving-side document. The reconciliation should expose that difference. Finally, run the agreed group report and trace any adjustment back to its supporting calculation. Have finance approve both the entity-level result and the combined view. Repeat the exercise for material currency or workflow variations in your actual group. This provides much stronger acceptance evidence than a demonstration that several company names appear in a selector.

A checklist to use in your next review