Odoo Multi-Company, Branches & Warehouses: Planning the Structure

Map legal responsibility and physical operations separately.

List the legal entities that issue documents, hold balances and own stock. Then list offices, shops, warehouses and service locations. A group may have several physical sites within one legal entity, while two separate companies may operate near each other. Geography alone does not determine the correct model.

Ask finance to explain the required accounting and reporting boundaries. Ask operations to explain stock ownership and movement. Any disagreement should be resolved before the implementation team creates the structure, because it can affect many later records.

Choose the concept that matches the business meaning.

This is a planning distinction, not a substitute for a review of the company’s legal and accounting obligations.

Agree the hierarchy before creating records.

Odoo’s documentation advises establishing the parent and branch structure first and identifies limitations around later changing a parent company into a branch. Treat this as an early design decision rather than a cosmetic setting that can always be rearranged without consequences.

Draw the proposed hierarchy and review several transactions against it. The right structure should let staff identify the correct business context without repeatedly switching to an unrelated entity merely to see the information they need.

Test visibility with the roles that will use the system.

Some staff work only within a branch; others oversee several parts of the business. Define the records each role should see and the actions it may perform. An administrator’s view is not a valid test of a warehouse clerk’s or salesperson’s access.

Use representative customer, product, quotation and invoice records. Confirm both the information that should be shared and the information that should remain restricted. Do not assume that a company selector or organizational label independently proves the required access control.

Decide who owns shared product and contact data.

Shared records can reduce duplication, but they also need a maintained identity and change process. A product used across several sites should have consistent units and technical meaning. Customer and supplier identities should remain understandable when different teams work with the same organization.

Entity-specific prices, accounts, operational settings or other values require their own review. Test how a shared record behaves in each intended context rather than assuming every setting is shared in the same way.

Distinguish an internal stock transfer from an intercompany transaction.

Moving goods between warehouses belonging to one entity can be different from supplying goods from one legal company to another. Finance should approve the documents, valuation and reconciliation required for the latter. The system design must reflect ownership, not merely the truck’s journey.

Similarly, group reporting and statutory reporting may require different outputs. Review the intended reports with finance and appropriate advisers. No generic multi-company setup should be described as automatic compliance with every local reporting obligation.

Test the proposed structure before broad data migration.

Use a small set of representative records and roles.

• A sale created in the correct company or branch context.
• A shared product and contact with the intended visibility.
• A user who must be restricted from another entity’s records.
• A stock transfer between sites and any distinct intercompany supply.
• Finance reports for the required organizational boundaries.
• A manager working across the permitted areas without unnecessary duplicate records.

Bring the organization chart and document ownership together.

A legal organization chart, list of operating sites and sample invoices provide a useful starting point. Include any planned expansion that affects entity ownership or reporting. The design should accommodate known needs without creating speculative complexity.

Ever Digital can help map the structure into Odoo and identify the decisions that finance and operations must approve. Confirm the selected edition and subscription implications before rollout, including the effect of branch or multi-company functionality.