Multi-company or separate databases: which fits your group structure
Multi-company suits legal entities that trade with each other and share master data; separate databases suit entities that need hard isolation or their own release timing. If your group's companies sell to or buy from one another and should work from one product catalog and one contact list, Odoo's multi-company setup lets several companies live in one database. Shared records such as products and contacts can be made available to all companies or restricted to specific ones, and inter-company transactions can generate matching sales orders, purchase orders and vendor bills automatically. The choice is a fit decision about how your entities operate, not a race over features, because both models run on the same Odoo product.
Be aware that enabling multi-company on an Odoo Standard plan automatically triggers an upsell to the Custom plan, and according to Odoo's pricing page only Custom can be hosted on Odoo.sh or on-premise and includes multi-company. If you plan to self-host, that plan requirement is a condition of the multi-company route, so confirm the current per-user terms with Odoo before you commit to a design. A separate database per entity avoids that dependency on the plan for multi-company itself, but it does not remove licensing or per-user costs, and each database needs its own administration.
The Odoo upgrade and support rules apply to both models. Standard support covers the first three years after a major release, and security patches are only provided during standard support, so a group that runs several databases must plan one upgrade cycle per database, and each test copy must be checked before production. Ask your implementer to write down which entities must move together, how upgrade windows will be coordinated, and who is responsible for each database's backups and access reviews.
How multi-company and multiple databases compare on the factors that matter
This table compares one Odoo database with multi-company against one database per legal entity across the factors that drive daily work, upgrades, backups and licensing. Read each row for the condition under which that option is the stronger choice. The main takeaway is that multi-company favors shared master data and inter-company flows, while separate databases favor hard isolation and independent upgrade and restore cycles.
| Factor | Multi-company in one database | Database per company | Stronger choice when |
|---|---|---|---|
| Shared master data | Products, contacts and other shared records can be made available to all companies or limited to specific ones | Each database holds its own copy, so shared products or contacts must be maintained separately or synchronized by integration | Multi-company wins when entities share a catalog, supplier list or customer base that should stay consistent |
| Inter-company transactions | Supported natively: one company can buy from or sell to another in the same database, with matching orders and vendor bills generated automatically | Requires an integration layer or manual reconciliation between databases, which you must design, build and test | Multi-company wins when entities trade with each other often and you want automated matching documents |
| Reporting across entities | Consolidated views are possible within one database, subject to how each report is configured and tested for your setup | Consolidation runs outside Odoo, typically through exports or a separate reporting tool that you maintain | Separate databases can suit groups that only need occasional consolidation and prefer to keep reporting outside the ERP |
| Access separation | Users are scoped to companies, but everyone shares one database, one administrator scope and one set of server processes | Strongest isolation: a user in one database cannot reach another entity's data through the application | Separate databases are safer when entities have strict data separation or different administrators and auditors |
| Upgrade effort | One upgrade path and one test cycle covers all entities, but a problem in one company's configuration affects the whole database | Each database is upgraded and tested separately, so entities can move on different schedules but multiply the work | Multi-company suits a single upgrade calendar; separate databases suit entities that must stay on different versions or freeze at different times |
| Backup and restore scope | One backup and one restore point cover every company, so restoring one entity restores all of them | Entities can be backed up and restored independently, with narrower impact on each restore | Separate databases are better when one entity needs point-in-time recovery without affecting the others |
| Licensing and plan requirement | Multi-company is listed as a Custom plan feature on Odoo's pricing page, and enabling it on Standard prompts an upsell to Custom | Separate databases do not depend on the multi-company feature, but each database has its own licensing and hosting considerations to confirm with Odoo | Confirm current plan and subscription terms with Odoo before choosing, since they determine whether multi-company is available to you |
| Effort to add a new entity | Adding a company is a configuration task inside an existing database, though its chart of accounts and sharing rules still need design | Adding an entity means provisioning a new database, configuring it, and building or extending any integration with the others | Multi-company suits frequent acquisitions or new subsidiaries that should join the same processes quickly |
How multi-company shares records and books inter-company trades
Odoo can run several legal entities inside one database, and the multi-company setting is what makes that possible. Each company keeps its own accounting, warehouses and transactions, while records such as products and contacts can be shared with all companies or restricted to specific ones. Before you go further, list every master record your group uses (products, price lists, vendors, customers, employees) and decide per record whether it should be visible to every entity or only to a named subset. Ask your implementer to show you how those visibility rules behave for a user who belongs to two companies, because that is where mistakes in access separation usually appear.
Inter-company transactions are the main reason to keep several companies in one database. When one company buys from or sells to another in the same database, Odoo can generate the matching sales order, purchase order and vendor bill automatically, so the group does not key each side by hand. The trade-off is that both sides live in the same system, so the group must agree on the pricing rules, tax treatment and the approval path for these documents before go-live. Confirm with your finance team how the chart of accounts is structured across entities, which currencies each company books in, and how intercompany prices are set (fixed transfer price, cost-plus or market-based). These choices are configuration decisions, not defaults you can accept by accident.
Some records must stay private even inside a shared database, such as payroll data, bank details, individual customer contracts or cost prices that one entity should not reveal to a sister company. Make a written list of those records and test them with a user from each entity before any data is loaded. If a single entity must be fully isolated from its group for legal, regulatory or contractual reasons, a separate database may be the safer design, and that question should be settled before the data model is built. Ask your implementer to document each access rule and the test cases used to verify it, and check the Odoo multi-company documentation against your own setup.
Where separate databases give stronger isolation
Multi-company keeps several legal entities in one Odoo database, which suits shared records and inter-company trade. The six drivers below mark where a database per company becomes the safer choice, and each one carries a cost in duplicated configuration and consolidated reporting that you should price in before deciding.
Regulatory and data residency separation
Choose separate databases when a regulator or contract requires that one entity's personal or financial records sit in a specific country, region or hosting boundary that the other entities must not share. In one database, every company lives in the same tables and the same backups, so residency is set for the whole instance. Confirm with your compliance lead whether logical separation by company is accepted as evidence, or whether physical separation is required. Ask the Odoo partner or your own team how backups and test copies of each database will be located.
Sale or divestment of one entity
If one entity may be sold, spun off or wound down, a separate database lets you transfer its full history, users and configuration without extracting records from a shared instance. In a multi-company database, splitting out one company means exporting its transactions, contacts and product links while preserving references to shared master data. Ask how much of the historical ledger the buyer needs and whether the data must be delivered in a clean, self-contained form.
Different upgrade timing
Odoo upgrades apply to the whole database, so every company in a multi-company instance moves to the new major version together. If one entity has a regulated change freeze or a slower validation cycle, a separate database lets it stay on its current version while others upgrade. Plan the cost of running more than one upgrade track, including test databases and the Enterprise subscription for each on-premise instance. Check the support window for each version in the Odoo standard and extended support documentation before you set the schedule.
Restoring one entity without touching others
A shared database restores as one unit, so recovering one company from a bad import, a failed close or an accidental deletion can roll back work recorded for every other company. With a database per entity, you can restore that single database to a point in time and leave the rest running. Ask your backup operator to show a restore of one company's data without affecting the others, and agree on recovery time and recovery point targets in writing before you go live.
Administrator access that must not cross entities
In multi-company, a user with access to several companies can switch between them, and database administrators can see every company's records. If a subsidiary's controller, auditor or outsourced team must never view another entity's data, a separate database removes that path entirely. Review who holds the administrator role, how company access rights are assigned and whether directory-based login is used, then test that a user restricted to one company cannot reach another through reports, exports or the API.
Entities with very different module sets
Multi-company shares one installed set of apps across companies, so a manufacturing entity and a services entity both carry the same modules even when one of them does not use them. A separate database lets each entity install only what it needs, with its own chart of accounts, workflows and custom code. The trade-off is that every shared change, such as a pricing rule or a new report, must be made once per database. Confirm which custom modules are needed by each entity and whether any of them would break if installed in the shared instance.
Which model to choose by group situation
A holding company that controls trading subsidiaries usually has shared master data, frequent transactions between entities and a consolidated view for the board. In this situation one Odoo database with multi-company is often the first model to test, because products, contacts and price lists can be shared while each subsidiary keeps its own sales, purchasing and accounting records. Inter-company transactions generate matching orders and vendor bills automatically, which reduces manual reconciliation between entities.
- Shared master data: Products and contacts can be made available to all companies or restricted to specific ones, so the group keeps one catalog without exposing every entity to every record.
- Inter-company flows: Matching sales orders, purchase orders and vendor bills are generated between companies in the same database, which suits group trading.
- Plan requirement: Enabling multi-company on the Standard plan triggers an upsell to the Custom plan, so the licensing cost should be part of the model decision from the start.
- Trade-off: Administrators with broad rights can see more than a single subsidiary should, so role design carries more weight than in separate databases.
Confirm with the group finance and legal teams which entities must keep separate ledgers and which intercompany pricing rules apply, and check with the client's tax advisers how each entity's books must be reported.
A group of entities that share a name or ownership but run independent operations, with no trading between them and little shared master data, gains less from one database. Separate databases give each entity its own upgrade schedule, backup policy, module set and administrators. The cost is repeated administration: each database needs its own patching, backups, user management and reporting consolidation if the group needs a combined view later.
- Isolation by default: Each entity runs its own database, so a configuration error or data issue in one does not touch the others.
- Independent upgrades: Each entity can move to a new major version when its own operations are ready, which matters when Odoo's standard support windows differ from one entity's change calendar.
- Repeated operations: Patching, backups and user administration are repeated for each database, so the team effort grows with the number of entities.
- Consolidated reporting: Group reporting must be built outside Odoo, for example through exports, so the reporting design should be agreed early.
Confirm with the client whether any entities will be sold or merged later, and whether group reporting needs live consolidation or periodic extracts.
A group that expects to sell one or more entities needs the sale to be possible without rebuilding the system. The main question is how easily the entity's records, users and history can be separated later. Separate databases make the carve-out simpler because the entity's data is already contained. In a shared database, the buyer must receive the entity's records without the seller's shared data, and intercompany history must be split correctly.
- Clean extraction: A separate database lets the entity be handed over, copied or moved with its records intact.
- Shared-record dependencies: If products, contacts or accounts are shared across entities, a carve-out requires decisions about which records transfer and which stay with the group.
- Intercompany history: Past inter-company transactions must be reconciled before a sale, which is easier when each entity's ledger is independent.
- Timing: A divestment may be years away, so the choice should be made so that it does not block a later separation.
Confirm with legal and transaction advisers what records the buyer will receive, which data protection terms apply to customer and employee records, and whether the sale agreement requires a transition period for system access.
A regulated group, such as one with banking, insurance or healthcare entities, may need strict separation of customer data, access rights and audit trails between entities. In these cases a database per legal entity is often the safer default, because the boundary between entities is enforced by the database rather than only by roles and record rules. The decision should follow the group's regulatory obligations, not preference for one model.
- Hard boundary: Separate databases keep each entity's data in its own store, which simplifies demonstrating that one entity's records cannot be read by another's users.
- Role-based controls still matter: Multi-company relies on access rules that must be configured and tested, and a misconfiguration can expose records across entities.
- Evidence: Each database produces its own audit and backup records, which can simplify evidence requests from assessors.
- Trade-off: Shared administrators and shared reporting require careful controls in either model, and the team operating separate databases must manage more instances.
Confirm with the compliance team which controls are required for data separation, how the assessor will test access boundaries, and whether any regulator must approve changes to the system of record.
Consolidated reporting and access separation in practice
Consolidated reporting is easier when the entities share one database, because group figures, intercompany balances and shared master data such as products and contacts can be read from the same records. Access separation in that model does not come from the database boundary. It depends on which companies each user is allowed to see and act for, set through user company assignments in multi-company, and on record rules that restrict what a user can read or change within those companies. Shared records can be made available to all companies or limited to specific ones, so the design of that sharing is a governance decision, not just a configuration step. Confirm with Odoo how record rules interact with the reporting views your finance team will use, because a report that aggregates across companies may expose figures a single-company user should not see.
With a database per entity, cross-entity reporting becomes an export or integration task. Each database has its own chart of accounts, master data and users, so a group report means extracting data from each instance, mapping accounts and currencies, and maintaining that pipeline through upgrades. The benefit is a hard isolation boundary: a user in one database cannot reach another entity's records, and a restore or an incident in one entity does not touch the others. That boundary is often what regulators, auditors or a buyer of one entity expect to see. Plan for the recurring cost of the consolidation layer and for who owns it after go-live.
Test access rules with real user roles before design sign-off. Build a test matrix with named users for each entity, finance, sales and external roles, then check what each one can read, create, edit and post in every company, including shared products, contacts and intercompany documents. Repeat the tests after any upgrade. On the commercial side, confirm in writing how the Custom plan is licensed for your user count and company count, and whether any reporting or dashboard add-on your design depends on is an Odoo app, a partner module or a third-party tool, with its own license and support terms. Odoo's pricing page is the starting point, but the quote should name every component the reporting design requires.
Upgrades, backups and administration under each model
This table compares the day-to-day operating work of one multi-company Odoo database against a database per legal entity, covering upgrades, backups, test copies, monitoring and admin skills. Read it as a question of how the work scales: in the separate-database model, most rows multiply with each entity you add. The main takeaway is that the upgrade service and managed-hosting rules apply to the platform, so confirm them for your edition before you count the effort.
| Operating area | One multi-company database | One database per company |
|---|---|---|
| Major version upgrades | One database to upgrade and test. Effort still depends on custom modules and each company's data. | Each database is upgraded and tested separately, so effort grows with entity count and the upgrade schedule must cover all of them. |
| Upgrade service access | On-premise use requires an Enterprise subscription. The Community edition has no access to the upgrade service. | Same rule applies to each database. Every on-premise database needs its own Enterprise subscription and activation. |
| Mandatory upgrades on managed hosting | On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, so one schedule covers all companies. | The same two-year cycle applies to each database, so you must coordinate several upgrade windows and test cycles. |
| Backup and restore scope | A single backup set covers every company. Restoring one company alone is not a simple operation, so confirm how your backup tooling handles partial restores. | Each entity has its own backup and restore job, which narrows the restore scope but multiplies the jobs to schedule, verify and monitor. |
| Test copies | Database duplication with neutralization produces one test copy for the whole group, which is usually cheaper to refresh. | Each entity needs its own duplicated and neutralized copy for testing, so refresh effort grows with each database. |
| Monitoring and alerting | One process, one set of logs and one set of performance metrics to watch. Load from one company can affect the others. | More processes and logs to watch, but a slow or failed database affects only one entity. Confirm your monitoring covers every database. |
| Configuration changes | A change to shared settings or chart of accounts applies across companies, so changes need a review of every company they touch. | Each database is configured separately, which repeats the same change work and risks drift between entities. |
| Admin skills required | Staff need working knowledge of multi-company settings, record rules and shared-record access, plus one upgrade and backup routine. | Staff need the same core skills but must run repeatable procedures across several databases, so scripting and runbook discipline matter more. |
How to decide and what to confirm before build
This sequence turns the multi-company or multiple-database question into a written decision, with each step producing a document or test result that the implementation scope can rely on before any build work starts.
Map legal entities and intercompany flows
Finance and operations leads list every legal entity, its country, currency, chart of accounts and tax registration, then document which entities sell to, buy from or invoice each other and how often. Intercompany flows matter because Odoo's inter-company transactions only generate matching sales orders, purchase orders and vendor bills between companies in the same database. Done means a signed entity map and a flow diagram that the CFO and tax lead have both reviewed.
Define data separation and audit requirements
Compliance, legal and security owners state which records must be fully isolated, which may be shared (such as products or contacts), and which audit trails auditors will request for each entity. Ask whether any entity has a data residency, confidentiality or sale-of-business obligation that would make a shared database hard to justify. Done means a written requirements list that names each shared object and the reason it is shared, approved by the data owner.
Confirm the plan and edition needed
Procurement and the Odoo account owner confirm which plan and edition each option requires. Odoo's pricing page states that multi-company is available only on the Custom plan, and that Custom is the only plan that can be hosted on Odoo.sh or on-premise. Enabling multi-company on a Standard plan triggers an upsell to Custom. If on-premise is chosen, confirm the Enterprise subscription and user count, and whether the upgrade service is part of the subscription. Done means a written quote that matches the entity count, user count and hosting model.
Test access rules with a sample dataset
The implementation partner builds a non-production copy with sample entities, users and records, then runs test cases for each role: one user per entity, a cross-entity accountant, an auditor with read-only rights and an administrator. Each test confirms that shared records appear only where intended and that a user in one entity cannot see another entity's invoices or payments. Done means a signed test log with pass or fail results and an agreed list of open defects.
Validate consolidated and entity reporting
Finance runs the same sample transactions through the reporting the business will use, including entity-level statements, consolidated views, intercompany eliminations and tax returns. The team compares the outputs against figures calculated independently in a spreadsheet. Ask the partner to show exactly which reports can filter by company and which need a custom build or a separate database export. Done means reconciled outputs for every report in scope, with any gap logged as a scope item.
Decide the database model in writing
With the test results, the steering group chooses multi-company in one database or a database per company, and records the reasons, including any entity that needs a separate database for isolation, sale or regulatory purposes. The record also names who would carry the cost and effort of later separation or merger. Done means a signed architecture decision record that the security, finance and IT owners have all approved.
Document the upgrade and backup plan
The platform team writes the plan for major version upgrades, test database validation and restore testing for each option. Odoo's upgrade documentation says upgrades move a database through an upgraded test copy that must be tested before production, and that on-premise use requires an Enterprise subscription. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Confirm the support window for the chosen version in Odoo's standard and extended support documentation, and confirm who restores data, how often, and how long a restore takes in your environment. Done means a runbook that has been tested once end to end.
Questions buyers ask before choosing a database model
How much extra effort does a multi-company Odoo setup add?
Multi-company adds configuration and governance work inside one database, not a second installation. You define each legal entity, decide which records (products, contacts) are shared or restricted to specific companies, and set user access per company. Inter-company transactions, where one company buys from or sells to another in the same database, generate matching sales orders, purchase orders and vendor bills automatically, which removes manual re-keying but requires the chart of accounts, pricing and tax settings to be agreed across entities first. Effort rises with the number of entities, the volume of shared master data and the number of cross-entity processes. Ask the implementer to list each shared object and who approves changes to it.
Do separate Odoo databases double the cost?
Not always, but several cost lines multiply with each database. Odoo Enterprise on-premise use requires a subscription that matches the user count, so users who work in more than one entity may need licensing in each database they access, and this should be confirmed against Odoo's licenses documentation for your case. Hosting, backups, monitoring and admin time scale with each database. Upgrade testing also repeats per database, because Odoo recommends testing an upgraded test database before production. Shared infrastructure can lower some of these costs. Ask for a quote that prices each database separately and lists the recurring items.
Can our team configure multi-company Odoo without an implementation partner?
A capable internal administrator can configure the basics: companies, shared versus restricted records, and user access by company. Inter-company transactions, chart of accounts mapping, tax rules and reporting per entity need more detailed functional knowledge and testing. Odoo's multi-company documentation covers the configuration steps, so review it with your finance and IT leads before deciding. The harder part is usually agreeing on the design: which entities share customers, who owns a product master, and how consolidated reports should look. Ask whether your team has tested these flows on a copy of production data before go-live.
What does the Custom plan requirement mean for on-premise Odoo?
Odoo's pricing page states that enabling multi-company on the Standard plan triggers an upsell to the Custom plan, and that only the Custom plan includes multi-company, Odoo Studio, external API access and custom modules. Only Custom can also be hosted on Odoo.sh or on-premise. For a self-hosted deployment, this means multi-company is tied to the Custom plan's terms, so the plan cost becomes a line item in your total cost of ownership. Confirm current plan terms, per-user pricing and yearly discounts directly with Odoo before budgeting, since pricing can change. Ask your Odoo partner to show the plan that matches your entity count and user numbers.
How long does the design phase for multi-company or multiple databases take?
The design phase length depends on the number of legal entities, how much master data they share, the number of inter-company flows, and how many reporting and approval rules must be agreed. Each decision on shared records, access boundaries and consolidation affects later rework, so time spent here usually shortens testing. Organizations with separate finance teams, different tax regimes or different data-protection obligations per entity typically need more design time. Ask for a written scope that lists the workshops, decisions and deliverables, because a fixed scope makes the effort visible before work starts.
When can we switch from multi-company to separate databases, or the reverse?
Switching is possible but never free, and the direction matters. Moving from a shared database to separate ones means splitting shared records, re-assigning users and rebuilding inter-company links, so plan the data split and reconciliation before cutover. Consolidating separate databases into one means mapping duplicate products, contacts and accounts, which often takes more effort than splitting. Both moves require test copies and upgrade testing. Odoo documents database duplication with neutralization for test copies, which helps rehearse a migration without touching live data. Ask any implementer to estimate the migration as a separate, written scope.
What it costs to switch models after go-live
Moving entities out of a shared multi-company database or merging separate databases later is one of the more expensive changes an Odoo estate can face, and the cost is driven almost entirely by data mapping. Every product, contact, chart of accounts line, journal and tax definition that exists in more than one company needs a decision about which record survives, which becomes a duplicate and how historical documents point to it. Duplicate master records are the usual source of rework: two customer records for the same legal entity split receivables, and two product records split stock valuation. Ask the implementer to produce an itemized mapping workbook for each master object before any data moves, and to state who signs off on each mapping.
Intercompany history is the second driver. Where multi-company inter-company transactions were used, matching sales orders, purchase orders and vendor bills were generated automatically inside one database, so reconciling them after a split means proving that each side of every pair still balances in its new home. Reconciling this history, along with consolidated reporting that once ran across companies, usually takes longer than the data load itself. Re-testing also recurs: any migration that involves a new database or a version change should be rehearsed on an upgraded test copy before production, and Odoo's upgrade documentation describes this test-first approach. Confirm with the implementer whether that rehearsal is priced into the fixed scope.
Before committing to either model, require a written scope that covers migration and rollback, not just the initial build. It should name the cut-over window, the rollback point and the criteria that trigger a rollback, plus who pays for a failed attempt and how long the original database stays available. Ask for a quote that separates one-time mapping, reconciliation and testing work from any recurring hosting, support or upgrade effort, and confirm which Odoo plan and edition the target environment requires. A scope without a rollback clause leaves the organization carrying the full risk of a one-way change.
How DeployOpen scopes multi-entity Odoo deployments
DeployOpen starts with the legal entity map, data separation rules and reporting needs, then agrees a fixed scope in writing before any build work begins. The same written scope settles whether one Odoo database with multi-company or a database per company fits your controls, and what the Custom plan and self-hosting would involve.
How we scope
- Map each legal entity, its shared master data and which records must stay restricted to one company.
- Document inter-company transaction flows, including which sales orders, purchase orders and vendor bills should generate automatically.
- Agree in writing how reporting consolidation, user access and audit trails will be handled per entity before work starts.
How we build
- Configure companies, record rules and access groups in a test environment, then check that restricted records stay hidden from other entities.
- Test inter-company transactions end to end, covering pricing, taxes and currencies for each entity pair in the agreed flows.
- Where a database per company is chosen, set up duplication with neutralization for test copies so production data is not reused unsafely.
How we hand over
- Deliver written configuration records covering companies, shared records, access rules and inter-company settings for your administrators.
- Provide a test plan and results so your reviewers can repeat the access separation and transaction checks after handover.
- Document the upgrade path, including testing the upgraded copy of the database before any production cutover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial engagement.
- Ask any provider to confirm which Odoo edition, plan and support window apply to your version before committing to a design.
- Agree in the quote who maintains entity changes, new companies and access reviews after go-live, and how each is priced.
