Odoo multi-company design before configuration begins

Multi-company Odoo design needs early decisions on legal ownership, shared records, intercompany flows, security, currencies, taxes, and consolidated reporting.

Multi-company problems are expensive to repair after transactions exist. The company structure affects access, sequences, warehouses, accounts, taxes, products, contacts, and integrations. It should be designed before teams start creating master data. Separate legal entity from operating convenience A branch, warehouse, brand, analytic dimension, or sales team is not automatically a company. Create companies for genuine ownership, accounting, tax, currency, or security requirements. Too many companies increase reconciliation and administration. Decide what is shared Products and contacts may be visible across companies, but properties such as accounts, taxes, prices, and routes can vary. Document which records are global, company-specific, or duplicated by rule. Model intercompany events Walk through sales, purchasing, stock transfer, services, expenses, and recharges between entities. Decide which documents should be generated, who validates them, how prices are set, and how mismatches are resolved. Test access with users who wear two hats A user may work in several companies while a manager needs consolidated visibility. Test active-company context, record rules, default values, and reports. Security should prevent leakage without forcing constant administrative workarounds. Practical checklist Confirm which units are actual legal/accounting entities. Define sharing rules for products, partners, and configurations. Document each intercompany document chain and pricing rule. Test taxes, currencies, sequences, and stock ownership. Validate access for single-company and multi-company roles. Final decision The design is sound when each transaction has an unambiguous legal owner and users can work across the structure without silently posting to the wrong company.