The Month Two Collapse: Why Inter-Company Rules Fail
The pattern is consistent enough that I can set a calendar by it. Go-live weekend goes fine. Week one goes fine, because everyone is watching closely and volume is low. Then somewhere between day 35 and day 55, a specific combination of transactions hits a rule nobody tested, and a controller who trusted the numbers on the screen finds out the hard way that they were wrong.
I saw this with a group running three legal entities out of one Odoo instance — a Rotterdam trading company, a manufacturing plant in Antwerp, and a small UK sales office. The demo was clean. UAT was clean. By week seven, intercompany purchase orders in the UK entity were auto-generating at the wrong price point, warehouse staff were hitting access errors during a cycle count, and the accountant doing the first consolidated close discovered that two of the three companies weren't even on comparable charts of accounts. None of that showed up in testing, because testing used low volume and one happy path. Production doesn't work that way.
Multi-company Odoo isn't hard to configure. It's easy to configure *incompletely*, in a way that looks correct until real transaction volume and real user behavior expose the gaps. The rest of this covers where those gaps usually sit.
Inter-Company Transaction Rules and Journal Configuration Pitfalls
Odoo's inter-company automation lives in **Settings > General Settings > Companies**, where you can enable automatic generation of sales orders from purchase orders (and vice versa) between related companies, along with automatic invoice/bill creation and warehouse synchronization. It's documented on the [Companies page](https://www.odoo.com/documentation/18.0/applications/general/companies.html), and on paper it's exactly what a multi-company group needs: sell from Company A to Company B without re-keying the order.
Where it breaks: these rules fire silently, on save, without asking. A sales rep in Company A adjusts a quantity on an order that's already generated a linked purchase order in Company B. Odoo updates the PO to match — which is usually what you want — but if a buyer in Company B had already manually adjusted that PO for a delivery constraint, that adjustment gets overwritten with no warning banner, no log anyone checks routinely. Run that at even a modest volume — a few hundred intercompany orders a month across three entities is not an unusual number for a group this size, though the exact figure will vary by business — and you get a slow drift between what operations thinks is happening and what's actually on the purchase order.
The second failure is journal assignment. Each company needs its own sales and purchase journals, and the intercompany invoices need to land in journals that your accountant actually reconciles — not the default journal that got left in place from the single-company setup you started with. I've seen intercompany invoices post to a generic "Miscellaneous Operations" journal because nobody explicitly assigned a dedicated intercompany journal per company pair. It doesn't throw an error. It just makes the monthly reconciliation take four hours longer than it should, every month, forever, until someone notices.
If you have more than two trading entities, don't assume the rule that works for A→B works the same for A→C. Configure and test each pair separately.
And sometimes the right call is not to turn this on at all yet. If one of your entities is a recent acquisition still running its own processes and its own chart of accounts, or if intercompany volume between two entities is low enough that a controller can eyeball every transaction, manual intercompany orders are the safer choice until things are actually harmonized. Automating a workflow that isn't stable yet just means the errors happen faster and get discovered later.
User Access and Permission Conflicts Across Companies
Every record in Odoo belongs to a company, and every user has a list of "Allowed Companies" plus a default company, managed through the standard [access rights configuration](https://www.odoo.com/documentation/18.0/applications/general/users/access_rights.html). This is straightforward for office staff switching companies from a dropdown. It's not straightforward for a warehouse worker scanning barcodes on a transfer that touches two adjacent buildings that happen to be two different legal entities.
The recurring failure: a warehouse operator gets added to Company A only, because that's where they were hired and that's the entity on their contract. Then an intercompany stock transfer routes through their scanner, referencing a picking that belongs to Company B. They get an access error mid-scan, at 6am, with a truck idling at the dock. Nobody designed for that scenario because nobody thought about the warehouse floor when they were setting up companies in the settings menu — that decision usually gets made by finance, for finance's own reasons, and operations finds out about the consequences later.
The fix isn't "give everyone access to everything." Broad multi-company record rules create their own mess — sales reps browsing quotations that belong to a sister company they have no business seeing, inventory counts that mix stock from two entities in one view because nobody scoped the rule tightly enough. The fix is mapping actual physical and operational overlap — who touches what, on which side of the legal boundary — before you assign companies to users, not after the first person gets locked out mid-shift.
Inventory and Stock Valuation Method Misalignment
This is the section that causes the most expensive surprises, because the damage doesn't show up until someone runs a report.
If Company A ships stock to Company B and the two use different costing methods — say A runs FIFO and B runs Standard Costing — the valuation layers on each side of that transfer don't reconcile the way people expect. The consolidated inventory value isn't wrong, exactly. It's just built from two different logics stitched together, and reconciling it at month-end means understanding both methods, every time, by hand. The [inventory valuation configuration documentation](https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/inventory/warehouses_storage/inventory_valuation/inventory_valuation_config.html) explains how each method behaves individually. It won't warn you that mixing them across an intercompany chain creates a reconciliation job nobody budgeted for.
A related trap: switching a product category's costing method mid-year. This is a prospective change — Odoo does not go back and recalculate historical valuation layers when you flip a category from Standard to FIFO. If you make that change in Company A in July, January's numbers stay exactly as they were computed under the old method. That's correct behavior, but if nobody documents *when* the switch happened, a consolidated year-over-year report looks internally inconsistent to anyone who doesn't already know the history.
Landed costs add another layer. They're designed to be applied after a receipt is validated, adjusting the value of stock already on the books — that part works well, and it's covered in the [landed costs documentation](https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/inventory/warehouses_storage/inventory_valuation/landed_costs.html). The real risk is timing: if Company B receives goods from Company A and sells or consumes them in production before the freight and duty costs get applied as a landed cost, that COGS is already locked in at the wrong number. You can't retroactively fix the margin on units that are already gone.
If your intercompany trading involves goods where per-unit cost actually varies — imported components with different landed costs per shipment, or serialized parts with different acquisition costs — standard costing will flatten all of that into one fixed number per unit, by definition. Odoo 18 added inventory valuation by lot and serial number specifically for this case. If cost precision at the unit level matters to your intercompany pricing, that's the setting to reach for, not a workaround built on standard costing.
One more thing worth getting straight: purchase price variance handling has changed shape more than once. Price difference accounts were removed for a time, then reintroduced in Odoo 16 — but in 16 and later they're only available for the Standard Costing method, not for FIFO or AVCO. If anyone on your team describes PPV using a workflow that assumes price difference accounts apply universally regardless of costing method, they're working from an outdated mental model, and an intercompany setup built on it will misfire the first time a FIFO-costed product crosses the boundary. (See the [Odoo forum discussion on this exact change](https://www.odoo.com/forum/help-1/where-is-the-price-difference-account-in-odoo-16-212839) for how the current behavior actually works.)
Consolidated Accounting: When Chart of Accounts Differences Break Elimination
Consolidated reporting across companies works well in Odoo when the related entities share the same [chart of accounts](https://www.odoo.com/documentation/18.0/applications/finance/accounting/get_started/chart_of_accounts.html) template, or at minimum use compatible account structures. It works badly, fast, when they don't.
I worked with a group that had a Belgian holding company on a Belgian statutory COA and a Thai manufacturing subsidiary on a Thai localization template. Account 400000 meant something different in each book. Intercompany receivables in Belgium didn't map cleanly to intercompany payables in Thailand, so the elimination entries that should have netted to zero at consolidation didn't — not because the transactions were wrong, but because there was no shared account key to eliminate against. The controller ended up building the elimination in a spreadsheet every quarter, which defeats most of the point of running one ERP across the group.
Odoo doesn't do automatic cross-template consolidation elimination out of the box. If your entities are on different national chart-of-accounts templates, plan for a manual account mapping exercise before you promise anyone a one-click consolidated balance sheet — or budget for a dedicated consolidation tool if the group is complex enough to need one.
How to Audit and Fix Your Inter-Company Setup Before Month Two
Do this before volume ramps, not after the first bad month-end close:
- Walk through the Inter-Company Transactions settings for every company pair individually — don't assume symmetric rules behave the same in both directions.
- Confirm each company has its own dedicated journals for intercompany invoices and bills, and that someone is actually reconciling them monthly.
- Pull the Allowed Companies field on every user, cross-checked against what they physically touch on the floor, not just their job title.
- Check costing methods on every product category involved in intercompany transfers. If they differ across companies, document why, or align them.
- Confirm landed costs are being applied before the related stock is sold or consumed, not after.
- If per-unit cost precision matters for intercompany pricing, evaluate lot/serial valuation rather than forcing standard costing to do a job it can't.
- Compare charts of accounts across all entities before promising a consolidated report. If they diverge, build the account mapping first.
- Run a small, deliberate batch of intercompany transactions — ten or twenty, not two — and trace every one through to the trial balance before you trust the automated flow with production volume. This is the step everyone skips because it feels like busywork after a go-live; it's the one that actually catches the silent failures.
Skip this list during the go-live crunch, and you're not avoiding the work. You're just moving it to month two, with a controller and a spreadsheet standing where an automated close should be.
