A growing company adds a second legal entity in Odoo, maybe a new subsidiary, a joint venture, or a separate registration for a new market, and within days something breaks that nobody touches directly. A user updates a supplier's bank details and the change quietly shows up on an invoice for a completely different company. A purchase order created under one entity turns up in another entity's approval queue. Nothing was misconfigured. The custom code simply was never written to know that "company" could mean more than one thing.
Why single-company code breaks first
Most custom Odoo modules start life scoped to a single company, because that is the only reality the client has at the time. Developers add fields, override create and write methods, and build fetch logic that reads records without filtering on company_id, because there is only one company in play and the default behavior looks correct. Odoo's own stock apps (sales, purchasing, accounting) carry built-in multi-company record rules, but custom modules do not inherit those automatically. The moment a second company is registered on the same database, every unscoped read and write becomes a quiet cross-company leak: shared bank details, budgets or purchase orders surfacing under the wrong entity, partner and product records inheriting values meant for a sibling company only.
The fix is retrofitting, not rewriting
The good news is this rarely requires a rebuild. The fix is putting company_id domains and record rules back into the places that skipped them: inherited fields need explicit company-scoped domains, search and fetch logic needs an actual company filter instead of relying on the default company context, and every custom model needs its own multi-company record rule, not just the standard ones. The hard part is finding every place the gap exists, because the bug only shows up once real multi-company data exists to expose it, and by then the client is already running two entities on the same instance.
Our take
This is common enough that it is worth designing for before it is needed: any custom Odoo development should assume a second company is coming, even when the client is confident there will only ever be one. A short multi-company audit of custom logic before a new entity goes live, rather than after, is far cheaper than untangling live data that has already crossed company lines. If your team is adding a legal entity to an existing Odoo instance, this is exactly the kind of problem worth talking through with Majorbird before it surfaces on its own.