Adding a New Company That Shares Your Master Data
A growing group eventually needs a new legal entity: a new market, a new subsidiary, a joint venture that needs its own books. The instinct is to treat it as a fresh implementation, re-entering every product, supplier, and customer from scratch. That instinct is usually wrong, and it is also avoidable.
What "shared, but separate" actually means
Odoo's multi-company model lets a new entity sit alongside its siblings and share the master data that does not need duplicating: the product catalog, the supplier list, the customer base. What it keeps separate is exactly what should stay separate: its own chart of accounts, its own journals, its own numbering sequences, its own invoice and document templates carrying its own legal name and tax details. Shared data, separate books.
Where teams get this wrong
The common failure mode is going too far in one direction. Some teams duplicate everything, ending up with two disconnected product catalogs that drift apart within a year because nobody wants to update both. Others share too much, and an accountant discovers a sequence number or a chart of accounts bleeding between entities in a way that makes a statutory auditor very unhappy. Getting the boundary right, what is genuinely shared versus what must stay entity-specific, is the actual design decision, not a configuration afterthought.
Setting it up without re-entering everything
Done well, the new company inherits the group's existing products, vendors, and customers on day one, so sales and purchasing teams are productive immediately. Its accounting stack, chart of accounts, fiscal position, journals, and print layouts get built as their own configuration, scoped to that entity from the start, so a statutory audit for the new entity never has to untangle data that belongs to a sibling company.
Our take
This kind of multi-company setup is a case study in scoping the right thing once instead of the wrong thing twice: get the shared-versus-separate boundary right at the start, and expansion into a new entity becomes a configuration exercise instead of a re-implementation. That is the pattern Majorbird looks for on any multi-entity engagement, since the same boundary question comes back every time a group adds a market or a subsidiary. If your group is about to add a new legal entity and you are not sure where the shared and separate line should sit, that is worth a conversation before the setup starts, not after. Reach out to the Majorbird team at odoo@majorbird.com or www.majorbird.com.