Why a multi-company ERP is a different decision for regulated subsidiary groups
One self-hosted ERP can serve several legal entities, but only when the platform and plan support multi-company operation and the group's regulators and auditors accept shared administration. A group with several subsidiaries typically needs separate books, separate functional currencies, separate access controls and separate statutory reporting, while still sharing customers, suppliers and product records. On platforms, the short answer is this: for self-hosting with multi-company, Odoo's Custom plan is the route the pricing page describes, since only that plan includes multi-company and can be hosted on Odoo.sh or on-premise. ERPNext can run several companies in one site, but the group's company model, approval chain and reporting needs must be confirmed against the current release before anyone commits to it. Separate instances remain the safer choice when an entity must be isolated from the others.
The rest of this page explains the trade-offs behind that answer. The decision turns on four things: how intercompany transactions are posted and eliminated, whether each entity can have its own chart of accounts and currency, which master data is shared and who may change it, and whether a single administrator with rights across entities is acceptable to the group's regulators. Shared administration is the point most often underestimated. A single database means one set of system administrators, one upgrade cycle and one change process, so the group must be able to show segregation of duties per entity and a complete audit trail of who changed what. Ask your implementation partner to map each entity's regulatory obligations to specific roles, record access and logging settings before the platform is chosen.
Which requirements shape a multi-company build in a regulated group
This table maps the requirements that most often shape a multi-company ERP for a group of subsidiaries to their sources and to what each one means for the build. Read it as a checklist to confirm with your compliance team before choosing a platform or plan, since the FTC Safeguards Rule applies to covered financial institutions and the SEC rule applies only to broker-dealer entities.
| Requirement | Source | What it means for the build |
|---|---|---|
| Separate charts of accounts and currencies per legal entity | Entity-level statutory reporting, local accounting rules | Each entity needs its own chart of accounts and functional currency. Confirm in the chosen platform how company-level charts and currency settings behave before mapping subsidiaries. |
| Intercompany transactions and eliminations | Consolidation and group reporting practice | Intercompany invoices, settlements and balances must post in both entities and eliminate on consolidation. Test this with a sample set of transactions during fit-gap, not after go-live. |
| Shared master data with entity-level access | Internal access policy and least-privilege principles | Customers, suppliers and products can be shared while postings and reports are restricted by company. Document which records are global and which are entity-specific. |
| Encryption in transit and at rest, and MFA for every user | 16 CFR 314.4, covered financial institutions | Every subsidiary user, including administrators and service accounts where applicable, needs multi-factor authentication. Confirm how the chosen edition and hosting model support encryption and MFA for each entity. |
| Change management and logging of authorized user activity | 16 CFR 314.4, covered financial institutions | Configuration and code changes need approval records, and user activity needs logs that can be reviewed. Confirm which logs the platform keeps and where they are stored. |
| Annual penetration testing and vulnerability assessments at least every six months | 16 CFR 314.4(d)(2), where continuous monitoring is absent | Plan external and internal testing on the ERP and its integrations on a fixed calendar. Confirm whether continuous monitoring is in place, since that determines the testing obligation. |
| Record preservation for three years, with two years easily accessible | 17 CFR 240.17a-4(b), applies to broker-dealer entities | Only a subsidiary that is a broker-dealer falls under this rule. Confirm which records must stay online for two years and set archive and retrieval procedures for that entity's bills, bank statements and communications. |
| Multi-company feature availability in Odoo | Odoo editions and pricing page | In Odoo, multi-company is included only in the Custom plan, which is also the only plan that can be hosted on Odoo.sh or on-premise. Confirm the plan and hosting model before scoping the group. |
Which open source ERP platforms fit a multi-entity group
A group with several legal entities needs one of three things from its ERP: a single instance that holds every company, a platform that keeps entities separate inside one database, or a separate instance per entity. The cards below set out the license, support window and main fit or risk for each route, so the platform choice follows from how intercompany and reporting needs actually work.
Odoo Community for a single-instance group
Odoo Community is LGPL-3.0 licensed and is the open source core of the Odoo suite. It has no multi-company feature on its own, since the Custom plan of the commercial product is the supplied route to multi-company, so a group that chooses Community must confirm which company, currency and intercompany functions it needs in the core code. Check whether the team can maintain custom modules for each new Odoo release, because Community has no access to the upgrade service.
Odoo Enterprise on the Custom plan
According to Odoo's pricing page, only the Custom plan includes multi-company and can be hosted on Odoo.sh or on-premise. Odoo 20.0 standard support runs until September 2029, covering security updates and bug fixes on Odoo Online, Odoo.sh and on-premise. Confirm the per-user cost, the Enterprise subscription terms and whether intercompany flows, consolidation and currency handling are in the plan before the group commits to the platform.
ERPNext on Frappe 15 or 16
ERPNext is GPL-3.0 licensed and built on the MIT-licensed Frappe Framework. Frappe 15 is supported until the end of 2027 and version 16 until the end of 2029, so a group should select the version it will still have support for through its planned rollout. Confirm how ERPNext handles multiple companies in one site, consolidation and intercompany transactions against the current documentation, since these supplied facts do not describe them. Support warranty requires a matching Frappe Cloud plan.
Apache OFBiz for a custom build
Apache OFBiz is licensed under Apache-2.0 and includes ERP, CRM, ecommerce and supply chain components. It fits a group with a strong internal development team that will own the business logic, the entity model and its upgrades. Expect the group, not a packaged product, to carry the work on company structures, intercompany postings and reporting, so compare the staffing and maintenance cost against the packaged platforms before choosing it.
Separate instances per legal entity
Running one instance per entity isolates each company's data, change approvals and access rights, which can simplify audits and sale or carve-out of a subsidiary. The cost is recurring: separate upgrades, separate chart of accounts maintenance, and a consolidation layer that someone must build and operate. Choose this route when entities have different regulators, data locations or release timing, and when intercompany volume is low enough to settle through reports.
One database, one ERP site or separate instances: how to choose
This model keeps every legal entity inside one database, so customers, products, suppliers and the chart of accounts can be shared where the business needs them. It fits groups with common controls, a central finance team, shared customers that buy from several entities, and entities in the same jurisdiction with compatible access rules. Odoo includes multi-company only on the Custom plan, according to Odoo's pricing page, so confirm that plan level before design starts.
- Upkeep: One database means one upgrade cycle, one set of test runs and one hosting footprint, which lowers recurring effort compared with several instances.
- Shared master data: Customers, products and price lists are maintained once, which reduces duplicate records but requires clear ownership rules per field.
- Risk added: A single access model and a shared database mean a configuration error or broad user grant can reach every entity at once.
- Risk removed: Intercompany postings stay inside one system, so reconciliation between entities is simpler to automate.
- Records: All entities share one retention and backup scope, which may not suit an entity with its own regulatory record rules.
Before choosing this model, confirm with each entity's legal and compliance team whether their records can sit in the same database and under the same administrators.
In this model, several companies run in one ERP site, but each company has its own configuration, roles and reporting boundaries. In ERPNext, companies are set up inside one site, which suits groups that want shared infrastructure while keeping accounting structures separate. This option fits groups where the entities are in the same regulatory family but differ in currencies, tax setup or approval chains.
- Upkeep: One site still means one upgrade path and one hosting stack, but per-company configuration must be retested after each change.
- Separation: Company-level permissions and reports reduce accidental cross-visibility, though they depend on correct role assignment for every user.
- Risk added: Administrators with site-wide rights can still see and change all companies, so privileged access needs strict control.
- Risk removed: Shared infrastructure avoids duplicate hosting and backup pipelines while keeping accounting separate.
- Custom code: Server-side scripts that touch several companies must be reviewed as shared code, and ERPNext disables Server Scripts by default from version 15.
Ask the implementation partner to show how permissions, reports and custom code are scoped by company, and to demonstrate that a user limited to one entity cannot read another entity's ledgers.
Separate instances give each legal entity its own database, users, backups and upgrade schedule. This is often the safer choice when an entity is a broker-dealer or lending business with its own record retention and access boundary. For example, a broker-dealer must preserve certain records for not less than three years under SEC Rule 17a-4(b), and the first two years must be easily accessible, so its retention settings and backup scope may need to differ from the rest of the group. Separation also helps when entities face different regulatory audits.
- Upkeep: Each instance needs its own upgrade test cycle, hosting, monitoring and backups, so recurring effort and cost rise with the number of entities.
- Subscriptions: Odoo Enterprise on-premise or Custom plan licensing may be needed per instance, so confirm the licensing model for each entity with the vendor.
- Risk removed: A compromise, misconfiguration or failed upgrade in one entity does not reach the others.
- Risk added: Shared customers and products must be synchronized between instances, and intercompany flows need integration controls.
- Reporting: Group consolidation requires a separate data pipeline, so plan reconciliation and change control for that layer.
For any entity with its own record retention or access rules, confirm in writing with compliance counsel whether a separate instance is required before accepting a shared design.
How intercompany transactions and shared master data stay consistent
Design the posting logic before anyone configures a company. An intercompany invoice raised by one subsidiary to another should post to both legal entities, each in its own ledger and functional currency, with the exchange rate and rate source recorded on each side. The finance team must also decide how the two sides are matched: which intercompany accounts are used, how payments settle open items in each entity, and where exchange differences land when the invoice and the payment fall in different periods. Run a trial with at least one invoice, one partial payment and one currency movement, then confirm that both ledgers balance independently. Eliminations for group reporting are a separate design decision. Confirm whether the platform generates elimination entries, or whether consolidation happens in a reporting tool fed by the entity ledgers, and document which intercompany balances must net to zero before the group close.
Shared master data needs an owner and a log. Decide who may create or change a shared customer, supplier or product, and restrict those rights through access groups rather than personal exceptions. Every change to a shared record should be traceable to a user and a time, and the trial should show that the audit trail captures both the old and new values. Entity-specific charts of accounts must map to the group chart account by account, including accounts with no direct counterpart, and the mapping table itself should be version controlled and approved by the group controller. Odoo lists multi-company among the features of its Custom plan on the Odoo pricing page, so confirm plan entitlement in writing before design starts. For ERPNext, confirm how companies in one site share or separate customer, item and account records in the version you will run.
Treat configuration as change-controlled, not only code. The change management requirement in the FTC Safeguards Rule at 16 CFR 314.4 applies to changes in intercompany account mappings, tax rules, currency settings, approval workflows and any automation that posts entries. In ERPNext, Server Scripts are disabled by default from version 15 and must be enabled through the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so check the hosting model before you design automation. Your trial should prove that a mapping change is requested, reviewed, tested in a copy of the database, approved and logged, and that an unauthorized user cannot change a shared record. Ask your implementation partner to show this evidence, not only the configuration screens.
Evidence a regulator or auditor will ask for in a multi-entity ERP
This table maps each piece of evidence an regulator or auditor is likely to request from a multi-company ERP to what it proves and the component that produces it. Read it as a checklist to build before the first assessment, since the evidence must be per entity as well as consolidated. DeployOpen prepares these controls and evidence for assessment, but independent auditors and certification bodies issue any audit report or certification.
| Evidence item | What it proves | Component that produces it |
|---|---|---|
| Access reviews per entity and per company | Each user's rights in each legal entity were reviewed and approved by an owner who does not hold the same rights | Odoo or ERPNext role and company assignments, exported on a schedule and signed off by each entity's finance owner |
| MFA enforcement records | Every individual accessing finance systems passed multi-factor authentication, including administrators and service-linked accounts | Identity provider sign-in logs and policy reports, with the ERP login path confirmed to require the identity provider |
| User activity logs for authorized users | Who posted, changed or approved entries in each company, and when, so that activity can be traced to a person | ERP audit trail on documents and configuration, plus database and reverse proxy logs retained centrally |
| Change records for configuration and shared master data | Changes to charts of accounts, currencies, intercompany rules and shared customers or vendors were requested, tested and approved | Change tickets linked to the code repository and to a dated export of configuration and master data values |
| Penetration test and vulnerability assessment reports | The ERP environment was tested against a set schedule, and findings were tracked to closure | Security testing reports and remediation tracker, with the scope covering each entity's environment and integrations |
| Backup and restore test results | Backups of all entity data can be restored, and a restored copy reconciles to the source ledgers | Backup job logs plus dated restore test records showing reconciliation of trial balances by company |
| Retained records for three years for any broker-dealer entity | Records of bills, bank statements and business communications are kept for at least three years, the first two in an easily accessible place | Archive policy and retention settings for that entity's records, confirmed with the compliance lead against the applicable rule |
How a multi-company ERP rollout moves from entity map to cutover
The sequence turns a group's legal entity structure into one tested ERP that goes live at a period end, with evidence at each gate. Durations are set in the written scope, so ask for the schedule in the quote.
Map entities, currencies and the database decision
The team lists every legal entity, its functional and reporting currencies, its statutory calendar, and which entities trade with each other. The output is an entity and currency register plus a recorded decision on whether the group runs one database with several companies or separate instances. That decision rests on intercompany volume, the edition and plan you need (multi-company is included only in the Odoo Custom plan, so confirm it with Odoo), and whether any entity has a regulatory reason to keep its data apart. Sign-off comes from the group CFO and the IT lead.
Design the chart of accounts and intercompany rules
Finance and DeployOpen design the chart of accounts for each entity, a mapping to the group reporting chart, and the rules for intercompany invoices, eliminations, transfer pricing references and settlement. Shared master data is classified here: which customers, suppliers, products, tax codes and employees are global and which are local to one entity. The output is a signed design document with a worked example for each intercompany flow, reviewed by the group controller and local finance leads.
Build configuration and identity integration
The build configures companies, currencies, localization and tax on the chosen Odoo plan or the ERPNext version in use, then sets up user roles and company access so each user sees only the entities they are allowed to post to. Identity integration is built against the directory the group already runs, using the LDAP or social login options that the platform documents, and it is tested for account deprovisioning. Customizations are kept in separate modules so later upgrades stay manageable. The output is a configured non-production environment and a build log.
Trial load opening balances and reconcile per entity
Opening balances, open receivables and payables, and master data are loaded into a test database one entity at a time. Each load is reconciled to the source ledger for that entity and checked for intercompany balances that must net to zero across the group. ERPNext's Data Import tool advises importing only a few thousand records per batch, so large loads are split and repeated. The output is a reconciliation pack per entity, with every difference either fixed or accepted in writing by the entity controller.
Test security and capture change control evidence
Access tests confirm that company restrictions, segregation of duties and role assignments behave as designed, and that intercompany postings cannot bypass approval. Security testing covers the application, its APIs and the hosting environment, and findings are tracked to closure. Every configuration change, custom module and parameter change is recorded with an approver and a test result. The output is a test report, a finding log and a change register, which are the evidence the group's auditors or compliance team will ask for.
Cut over at a period end and run hypercare
Cutover is scheduled at the close of a fiscal period so opening balances align with a closed ledger. The team runs the final load, repeats the reconciliation against the frozen source data, and obtains sign-off from each entity before users switch. A hypercare window follows, with daily review of posting errors, intercompany mismatches and access requests, and a defined handover to the support team. The output is a signed cutover record and a closed hypercare log. The length of the hypercare window is set in the written scope, so ask for it in the quote.
What to ask an implementation partner before a multi-company project
Start by asking how the partner maps legal entities, currencies and charts of accounts before any configuration begins. Ask who in your group signs off each entity's chart of accounts, fiscal calendar, base currency and exchange rate source, and ask for the mapping workbook that shows how each legacy account lands in the target structure. Ask how they will handle entities that report in a different functional currency, and which company record holds the default accounts for intercompany clearing. Then ask who approves the design: the group controller, the local finance leads or both. A partner who cannot name the approver for each decision is not ready to estimate the project.
Next, ask how intercompany postings and eliminations are designed and tested. Ask which intercompany partner, product and tax settings they will apply, how mirror invoices are generated between companies, and how eliminations are produced for consolidated reporting. Request a test plan that runs at least one full close cycle in a non-production copy, with the group's own intercompany balances, and ask who reconciles the differences. Ask also how they will control shared master data such as customers, suppliers, products and price lists: which fields are shared across companies, who may change them, and whether each change is logged with a user, a timestamp and an approval reference. Ask which Odoo plan or ERPNext configuration they recommend, noting that in Odoo multi-company is included only in the Custom plan, and ask how they will confirm that the edition supports your hosting model. Ask how upgrades are scheduled against Odoo's support windows or the Frappe version support dates, and how custom modules are kept upgradable.
Finally, ask how the partner handles security evidence and separate instances. Ask how encryption in transit and at rest, multi-factor authentication for administrators and users, and activity logging will be configured and documented, and which logs they will export for the group's auditors. Ask when they would recommend separate instances for a regulated entity, such as a licensed lender or broker-dealer that must keep its own records, and how they would keep those instances consistent. Ask what support runs after go-live, who answers the first call for a failed close, and what the retainer covers. Request a written scope, a deliverables list with acceptance criteria and a timeline agreed before any work starts, since DeployOpen works on fixed-scope engagements and will provide these in writing.
Multi-company ERP questions buyers ask before hiring help
Which Odoo plan includes multi-company support?
Only the Custom plan includes multi-company, according to Odoo's pricing page. The Custom plan is also the only plan that can be hosted on Odoo.sh or on-premise, and it adds Odoo Studio, external API access and custom modules. The One App Free and Standard plans are limited to Odoo Online. If your group needs several legal entities inside one Odoo database and wants to keep the data in your own infrastructure, the Custom plan is the starting point. Confirm current plan contents directly with Odoo before you sign, because plan features can change between releases.
Can ERPNext run several companies on one site?
ERPNext supports multiple companies in one site, but the setup needs confirmation against your own entity structure before you rely on it. Confirm how intercompany transactions, separate charts of accounts and currencies, and shared master data behave for each entity you operate. Check which ERPNext version you will run, because ERPNext v15 and v16 are the supported major versions according to Frappe's supported versions page. Self-hosting ERPNext is free under GPL-3.0, so the first step is a proof of concept with two or three of your real entity structures, using test data that matches your close calendar.
What drives the cost of a multi-company ERP project?
The main cost drivers are the number of legal entities, the number of currencies and localization rules, the depth of migrated history, the number of integrations, the custom modules you need, and the effort to upgrade them later. Software cost is not the largest line for most groups. Self-hosted ERPNext has no license fee, while Frappe Cloud shared site hosting starts at 5 US dollars per month according to the ERPNext pricing page. Odoo Enterprise is priced per user and must be quoted for your user count. Ask for a quote that separates one-time work (fit-gap, configuration, migration, training) from recurring work (hosting, subscriptions, upgrades, support).
How long does a multi-company ERP implementation take?
The duration depends on the written scope, not on a fixed template. A group with few entities, one currency and clean master data will move faster than one with several charts of accounts, multiple currencies and years of history to convert. Scope, deliverables and timelines are agreed in writing before DeployOpen starts work, since most engagements are fixed-scope. Ask any partner to show the phases, the entity-by-entity cutover order, the number of trial loads, and the period-end at which go-live is planned. Treat any duration without that breakdown as an assumption to test.
What must our group provide for an ERP implementation?
The group must provide the entity data, the approval matrix, named test users and a finance lead who owns the close. Entity data includes legal names, registration numbers, charts of accounts, tax registrations, bank accounts and currencies for each company. Approvers must confirm intercompany pricing and posting rules, and test users must run the close process during trial loads. A finance lead must sign off opening balances and reconciliations before cutover. Without these people available on fixed dates, the schedule and the quote both move, so confirm named owners in the statement of work.
Can our internal team implement multi-company ERP alone?
An internal team can implement a multi-company ERP alone if it has the skills, time and continuity to do so. Self-hosted Odoo Community or ERPNext can be installed and configured without a partner, and ERPNext can be installed on Frappe Cloud, with Docker Compose, or manually with the bench command line tool. The harder parts are intercompany design, opening balance conversion, tax and localization, and upgrade planning, which are where errors are costly. Many groups use a partner for design and cutover while keeping configuration ownership in-house. Decide which parts you will own before you compare quotes.
How DeployOpen scopes and supports a multi-company ERP
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source ERP inside the client's own infrastructure. For a group of subsidiaries, the work starts with agreed written scope covering every legal entity, currency and intercompany flow before any configuration begins.
How we scope
- List every legal entity, its functional currency, chart of accounts and reporting calendar in the written scope.
- Map intercompany flows such as recharges, shared services and intercompany invoices, with the accounts each one posts to.
- Confirm which master data is shared across companies and which stays local, including customers, vendors and products.
How we build
- Configure companies, currencies, shared records and access rules on the chosen platform, and record each parameter decision.
- Customize only where the scope requires it, and keep custom modules separated so they can be carried through upgrades.
- Test intercompany postings, consolidated reports and per-entity access with agreed test scripts before any production load.
How we hand over
- Deliver configuration records, data mapping tables, test evidence and an operating runbook for each entity and shared process.
- Document role assignments and segregation of duties per company so administrators can show who can post where.
- Run handover sessions with finance, IT and the named administrators, and confirm ownership of each system component in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live, scoped separately from the build.
- Plan platform upgrades for the multi-company setup in advance, since Odoo upgrades require a tested copy of the database first.
- Ask any partner which support terms, release cadence and licensing tier apply to your chosen platform before signing.
