Multi-Company Setup in Odoo 19:
Intercompany Rules & Consolidated Reporting

Your Multi-Entity Business Deserves One Source of Truth—Not Five Disconnected Databases

A holding company with three subsidiaries. A manufacturer that sells through a separate retail entity. A services group spanning four countries with a shared back-office. Every one of these structures runs into the same problem: each legal entity needs its own books, but management needs a single consolidated view. The moment you create a second company in Odoo, you inherit a cascade of decisions—who sees what, how intercompany transactions flow, where shared data lives, and how the CFO gets a group-level P&L without spending three days in a spreadsheet.

Odoo 19 handles multi-company natively. Company creation, intercompany rules (auto SO/PO, auto invoice/bill), multi-company record rules, the branch concept, and consolidated financial reports are all built in. But native doesn't mean automatic. We've audited dozens of multi-entity Odoo deployments, and the same configuration gaps appear every time: record rules that leak data between entities, intercompany transactions that generate on one side but not the other, and chart of accounts misalignment that makes consolidated reporting impossible.

This guide covers the complete multi-company architecture in Odoo 19: company creation and hierarchy, intercompany rule configuration, shared vs. company-specific data, multi-company security, branch setup, inter-company journal entries, chart of accounts alignment, user access control, and consolidated financial reporting.

Company Creation, Hierarchy, and the Branch Concept in Odoo 19

Every multi-company setup starts with the hierarchy. Odoo 19 uses a parent-child structure where a holding company sits at the top and subsidiaries nest below it. The hierarchy determines data inheritance, default fiscal positions, and which users can switch between entities. Getting this wrong creates data isolation problems that surface months later during the first consolidation attempt.

Creating the Company Hierarchy

Navigate to Settings > Companies and create each legal entity. The critical field is parent_id—it establishes the group structure that drives consolidation and intercompany visibility:

from odoo import api, SUPERUSER_ID


def create_company_hierarchy(cr):
    """Create a multi-company hierarchy programmatically."""
    env = api.Environment(cr, SUPERUSER_ID, {})
    Company = env["res.company"]

    # Create holding company (top-level)
    holding = Company.create({
        "name": "Acme Group Holdings",
        "country_id": env.ref("base.us").id,
        "currency_id": env.ref("base.USD").id,
    })

    # Create subsidiaries under the holding
    retail = Company.create({
        "name": "Acme Retail Inc.",
        "parent_id": holding.id,
        "country_id": env.ref("base.us").id,
        "currency_id": env.ref("base.USD").id,
    })

    manufacturing = Company.create({
        "name": "Acme Manufacturing GmbH",
        "parent_id": holding.id,
        "country_id": env.ref("base.de").id,
        "currency_id": env.ref("base.EUR").id,
    })

    services = Company.create({
        "name": "Acme Shared Services Ltd.",
        "parent_id": holding.id,
        "country_id": env.ref("base.gb").id,
        "currency_id": env.ref("base.GBP").id,
    })

    return holding, retail, manufacturing, services

Branches vs. Companies

Odoo 19 distinguishes between companies and branches. A branch is a child entity that shares the parent's chart of accounts, fiscal year, and tax configuration. A company is a fully independent legal entity with its own accounting setup. Use branches for regional offices within the same legal entity; use companies for separate legal entities that file independent tax returns.

User Access Across Companies

Users must be explicitly granted access to each company. The company_ids field on res.users controls which entities appear in the company switcher. The company_id field sets the user's current (active) company context. Intercompany automations run under the triggering user's security context—if the user doesn't have access to the target company, the automation fails silently.

Multi-Company Record Rules: Preventing Data Leaks Between Entities

Record rules are the security backbone of any multi-company Odoo deployment. They control which records a user can see based on their current company context. Odoo 19 ships with default multi-company record rules for most models, but custom modules often forget to add them—creating data visibility holes where users in Company A can see Company B's invoices, sale orders, or inventory movements.

How Default Multi-Company Rules Work

<!-- Default multi-company rule for account.move (invoices) -->
<record id="account_move_comp_rule" model="ir.rule">
    <field name="name">Account Move: Multi-Company</field>
    <field name="model_id" ref="account.model_account_move"/>
    <field name="domain_force">
        ['|', ('company_id', '=', False),
              ('company_id', 'in', company_ids)]
    </field>
    <field name="global" eval="True"/>
</record>

<!-- Custom rule for a custom model -->
<record id="custom_request_comp_rule" model="ir.rule">
    <field name="name">Custom Request: Multi-Company</field>
    <field name="model_id" ref="model_custom_service_request"/>
    <field name="domain_force">
        ['|', ('company_id', '=', False),
              ('company_id', 'in', company_ids)]
    </field>
    <field name="global" eval="True"/>
</record>

The domain ['|', ('company_id', '=', False), ('company_id', 'in', company_ids)] is the standard pattern. It says: show records that either have no company (shared data) or belong to one of the user's allowed companies. The company_ids variable is automatically injected by Odoo's security engine and reflects the companies listed in the user's Allowed Companies field.

Auditing Record Rules Across Custom Modules

from odoo import api, SUPERUSER_ID


def audit_multi_company_rules(cr):
    """Find models with company_id but no multi-company rule."""
    env = api.Environment(cr, SUPERUSER_ID, {})
    IrModel = env["ir.model"]
    IrRule = env["ir.rule"]

    # Get all models that have a company_id field
    models_with_company = IrModel.search([]).filtered(
        lambda m: "company_id" in env[m.model]._fields
    )

    # Get all models that have at least one global rule
    # referencing company_ids
    rules = IrRule.search([("global", "=", True)])
    protected_models = set(rules.mapped("model_id.model"))

    # Find the gaps
    unprotected = []
    for model in models_with_company:
        if model.model not in protected_models:
            unprotected.append(model.model)

    if unprotected:
        print("Models with company_id but NO record rule:")
        for m in sorted(unprotected):
            print(f"  - {{m}}")
    else:
        print("All models with company_id have record rules.")

    return unprotected

Inter-Company Journal Entries: Elimination Workflow and Reconciliation

Inter-company journal entries serve two purposes: they record the financial impact of intercompany transactions within each entity, and they provide the basis for elimination entries during consolidation. Every intercompany invoice creates a receivable in one entity and a payable in the other. At consolidation time, these must net to zero—otherwise your group balance sheet is inflated.

Setting Up Intercompany Accounts and Journals

Each company needs dedicated intercompany accounts and a journal for recording intercompany transactions. These accounts must be marked as reconcilable so that balances can be matched and eliminated:

from odoo import api, SUPERUSER_ID


def setup_intercompany_accounts(cr):
    """Create IC accounts and journals in all companies."""
    env = api.Environment(cr, SUPERUSER_ID, {})
    companies = env["res.company"].search([])

    for company in companies:
        AccountAccount = env["account.account"].with_company(company)
        AccountJournal = env["account.journal"].with_company(company)

        # Intercompany Receivable
        ic_recv = AccountAccount.create({
            "code": "131100",
            "name": "Intercompany Receivable",
            "account_type": "asset_receivable",
            "reconcile": True,  # CRITICAL for elimination
            "company_id": company.id,
        })

        # Intercompany Payable
        ic_pay = AccountAccount.create({
            "code": "231100",
            "name": "Intercompany Payable",
            "account_type": "liability_payable",
            "reconcile": True,
            "company_id": company.id,
        })

        # Intercompany Journal
        ic_journal = AccountJournal.create({
            "name": "Intercompany",
            "code": "ICJ",
            "type": "general",
            "company_id": company.id,
            "default_account_id": ic_recv.id,
        })

        print(
            f"{{company.name}}: IC Receivable {{ic_recv.code}}, "
            f"IC Payable {{ic_pay.code}}, "
            f"Journal {{ic_journal.code}}"
        )

How Intercompany Journal Entries Flow

When Company A posts a customer invoice to Company B, the following journal entries are created automatically (assuming intercompany rules are active):

At consolidation, the elimination entry reverses the IC Receivable and IC Payable (they net to zero within the group) and removes the IC Revenue and IC Expense (the group didn't earn or spend anything externally). The net effect on consolidated financials: zero.

Monthly Elimination Workflow

The elimination workflow runs at each month-end close. The sequence matters—posting eliminations before all intercompany transactions are validated creates imbalances that take hours to trace:

• Day 1–3 of close: Ensure all intercompany invoices and bills are posted in both entities. Run the intercompany reconciliation check to find mismatches.
• Day 3: Register and synchronize all intercompany payments. Verify that IC receivable and IC payable accounts reconcile to zero for settled transactions.
• Day 4: Run currency revaluation in all entities to align FX rates across the group.
• Day 5: Post elimination journal entries for outstanding IC balances, IC revenue/expense, and unrealized intercompany profit on inventory.
• Day 5: Generate consolidated P&L, Balance Sheet, and Cash Flow. Verify group-level figures against management expectations.

4 Multi-Company Configuration Mistakes That Break Your Group Reporting

Optimization Metadata