Why open source accounting for multi-entity groups needs a different design
The main decision for a group running several legal entities is whether they share one self-hosted instance or each run their own. The platform choice follows from that decision, because edition limits on multi-company functions decide which options are even available. In Odoo, the published pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that multi-company is included only in Custom, so a group that plans a shared Odoo instance must confirm the edition, hosting model and plan in writing before design starts. ERPNext and other candidates handle company separation differently, so the same check applies to each one on the shortlist.
A single-company rollout treats the chart of accounts, tax settings and currency as one set of defaults. A group has to decide, for each entity, which chart of accounts applies, which tax regime and reporting currency it uses, how intercompany balances are booked and eliminated, and who in the finance team can post or approve for which company. Access rights, approval workflows and reporting filters must then be tested per entity, not only for the group as a whole. Your reader should expect that every setting changed for one entity may affect shared master data, such as customers, vendors, products and users, that sits behind all of them.
DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted platforms in the client's own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and the group's external auditors decide whether the setup meets their requirements. Before committing to a design, ask the implementation partner to show how intercompany eliminations, per-entity tax settings and consolidated reports will be tested and documented for the first close.
Which requirements a multi-entity ledger must meet
This table compares the requirements that shape a multi-entity ledger, from entity separation and intercompany matching to access separation and record retention. Each row names its source, either a regulation cited in our researched facts or a plain business constraint, and the build consequence for the implementation. Local tax and currency rules must be confirmed with your tax advisers and auditors before design begins.
| Requirement | What it asks for | Source | Build consequence |
|---|---|---|---|
| Entity separation | Each legal entity keeps its own books, chart of accounts, tax settings and reporting currency | Plain business constraint (legal entity structure) | Decide per entity whether it is a company inside one instance or its own instance, and confirm the edition supports multiple companies on one database |
| Intercompany matching | Transactions between entities are posted on both sides and reconciled to matching balances | Plain business constraint (group close) | Define intercompany accounts, counterpart rules and an elimination process, and test that both sides post in the same period |
| Per-entity tax and currency | Tax treatment and currency rules apply per entity, as set by local requirements | Confirm with your tax advisers and local rules | Configure tax, localization and currency per company, and avoid shared tax codes that carry rules from another jurisdiction |
| Consolidated reporting | Group statements combine entity results and eliminate intercompany balances | Plain business constraint (group reporting) | Choose whether consolidation happens inside the system or in a separate reporting tool, and document the mapping that feeds it |
| Access separation between entities | Users see and post only to the entities they are authorized for, with changes logged | FTC Safeguards Rule at 16 CFR 314.4 (access control, multi-factor authentication, activity logging) where the group is a covered financial institution | Set company-level access rights, require multi-factor authentication for every user, and retain logs of authorized user activity |
| Change control across entities | Changes to shared customizations or configuration are approved and tracked | FTC Safeguards Rule at 16 CFR 314.4 (change management procedures) | A change to a shared module can affect every entity, so test and approve changes once for the whole group |
| Record retention | Records such as bills, bank statements and business communications are kept for a defined period and remain accessible | SEC Rule 17a-4(b) for broker-dealers (three years, first two easily accessible); otherwise the retention periods set by local law | Plan backups and archive storage per entity, and confirm retention periods with counsel for each jurisdiction |
How multi-company ledgers handle intercompany entries and consolidation
A single self-hosted database can hold the books of several companies, but each company needs its own chart of accounts, journals, functional currency, fiscal calendar and tax configuration, and the system must keep those settings from leaking across entities. In Odoo, multi-company is a database-level setting in which each company record carries its own currency and tax defaults, and users are granted access to one or more companies at a time. Before building anything, confirm that every entity's chart can be maintained separately, that tax rules are scoped to the right company, and that a user working in one entity cannot post into another by accident. Odoo's pricing page states that multi-company is included only in the Custom plan, which also carries the hosting options on Odoo.sh or on-premise, so that licensing question must be settled before the design is fixed.
Intercompany transactions are the point where group accounting usually breaks. A sale from one entity to a sister company creates a receivable in one set of books and a payable in the other, and both sides must eliminate on consolidation. Decide early whether intercompany accounts are mapped to dedicated receivable and payable accounts, whether each side posts through an automated counter-entry or a manual journal, and who reconciles the two balances at month end. Intercompany pairs should be tested with a sample transaction in a non-production copy, including foreign currency invoices, since exchange differences often surface only at that stage. ERPNext's multi-company support should be checked against the group's specific intercompany and elimination needs, since the answer depends on the version in use and the group's chart structure.
Consolidated reporting is usually produced outside the transactional ledgers, either by a reporting layer that reads each company's trial balance and applies eliminations and currency translation, or by a group entity that holds the consolidated chart. Confirm in writing which of these your candidate supports natively, what the translation method is for each functional currency, and how eliminations are recorded and audited. Ask the implementation partner to show a full close cycle on test data: intercompany postings, elimination entries, translated balances and the resulting group trial balance. The output should tie back to the entity ledgers without manual adjustments, because that tie-out is the evidence an external auditor will request first.
Which platforms fit a multi-entity group and why
A multi-entity group needs one ledger model that handles separate companies, currencies and tax settings without losing control of intercompany postings. The platforms below differ mainly in whether multi-company is available on the edition you can actually run, what support and upgrade path comes with it, and how much accounting depth the open-source core provides out of the box.
Odoo Community for single-company or test use
Odoo Community is the LGPL-3.0 open source core of the Odoo suite, so the code is free to inspect and modify under its license. Odoo's pricing page places multi-company, Odoo Studio, external API access and custom modules in the Custom plan, not in the open source core, so a group needing several legal entities on one database should not assume Community covers it. Community also has no access to Odoo's upgrade service. Confirm the current feature set against the edition documentation before design work starts.
Odoo Enterprise on the Custom plan
The Custom plan is the Odoo tier that the pricing page lists with multi-company, Studio, external API access and custom modules, and it is the only tier that can be hosted on Odoo.sh or on-premise. For a self-hosted group, the practical question is the subscription scope and who maintains the database. Standard support covers the first three years after a major release, including security updates, and extended support after that is limited to Odoo.sh for select versions and on-premise. Ask for the support end date of each version in the quote.
ERPNext on the Frappe framework
ERPNext is GPL-3.0 licensed and built on the MIT-licensed Frappe framework, and self-hosting it carries no license fee. Its accounting module covers multiple companies in one instance, but intercompany handling, currency and tax configuration should be proven in a test build rather than taken from the feature list. Only supported versions carry Frappe warranty coverage, and the supported-versions policy lists version 15 and version 16 as current. Implementation is available through certified partners, so vet the partner's experience with multi-company setups.
Apache OFBiz for custom ERP builds
Apache OFBiz is licensed under Apache-2.0 and ships framework components and business applications covering ERP, CRM, ecommerce, supply chain and manufacturing resource planning. It suits groups with an in-house development team that will build and maintain their own accounting logic and reporting. Accounting depth, intercompany workflows and consolidation are not something to assume from the component list. Ask the implementation partner to demonstrate the general ledger, multi-entity postings and reporting on your own chart of accounts before committing.
LedgerSMB as a double-entry option
LedgerSMB is a double-entry accounting option that some groups evaluate for a self-hosted general ledger. Its fit for a multi-entity group depends on whether it supports separate company databases or entities, intercompany entries and multi-currency reporting in the version you would deploy. These features are not covered by the research supplied for this page, so confirm each one with the project and in a proof of concept. Check the license terms and the release cadence before adding it to a shortlist.
When each entity should have its own instance
When the entities run one chart of accounts, one group reporting calendar and one set of approval rules, a single instance is usually the simplest model. Intercompany transactions post inside one database, eliminations are easier to automate, and the group close runs once. The main cost is that every entity shares configuration, so a change made for one company can affect the others and must be tested against all of them.
- Administration: one set of users, roles, workflows and customizations to maintain, with one owner for the chart of accounts.
- Access separation: company-level record rules restrict who sees each entity, but a misconfigured rule exposes data across the group, so access reviews must check each company.
- Upgrade coordination: one upgrade covers every entity, which lowers effort but means all companies move on the same date.
- Consolidation effort: intercompany matching and currency translation happen in the same ledger, reducing reconciliation work.
- Edition check: confirm in the vendor's current plan documentation whether multi-company is included in the plan you intend to license.
Confirm with the implementation partner how multi-company access rules, intercompany accounts and per-company tax settings are configured and tested before go-live.
When entities answer to different regulators, or must keep records in different countries, a shared database can conflict with local retention, access and residency requirements. A regulated entity may need its data hosted in a specific jurisdiction, or its administrators may need to be separated from the parent group. In these cases a separate instance, possibly in a separate cloud account or data center, gives a clear boundary that is easier to explain to a regulator.
- Administration: each instance needs its own administrators, backups, monitoring and patching, which multiplies routine work.
- Access separation: administrators of the parent cannot reach the subsidiary's database by default, which supports segregation required by local rules.
- Upgrade coordination: each instance can be upgraded on a schedule that fits its regulator, but the group must track several versions at once.
- Consolidation effort: the group must extract ledgers from each instance and map them into a consolidation tool or a reporting warehouse, with documented controls over the transfer.
- Residency: hosting location is set by the client's infrastructure choice, so confirm where backups and support access happen as well as where primary data lives.
Ask the regulator's guidance or local counsel which records must stay local and which may be shared before drawing the instance boundary.
When an entity is likely to be sold, or is an acquisition that has not yet been integrated, a separate instance keeps its records, access and history cleanly separable. The buyer can take the database, or the seller can keep it, without untangling shared master data. Many groups start an acquired company on its own instance during a transition period and move it later, once the chart of accounts and opening balances are mapped.
- Administration: a temporary instance adds a second system to run until the integration is complete, so the transition period should have a defined end date.
- Access separation: the target's staff and the buyer's staff can be given access without exposing the group's wider ledger.
- Upgrade coordination: an isolated instance can stay on its current version during due diligence, but it must still be brought into the group's upgrade cycle eventually.
- Consolidation effort: until the migration is complete, the group consolidates from extracts, which adds a manual step to each close.
- Separation cost: a sale that requires a database extract needs a documented export, tested restore and agreed data retention terms.
Check with legal and finance whether a transitional service agreement will cover hosting, support and access, and who owns the data at each stage.
When one entity is subject to a financial statement audit, a tax audit or a control assessment that others are not, an instance boundary can limit the scope that auditors must test. Controls such as user access reviews, change management and database access then apply to a smaller system. The trade-off is that controls must be documented and operated separately for each instance, which can duplicate evidence work.
- Administration: each instance needs its own control owner, access review and change log, so evidence is produced per system.
- Access separation: tighter boundaries make it easier to show that only named people can reach the in-scope ledger.
- Upgrade coordination: an in-scope instance may need change approval and testing evidence that a lighter-scope instance does not, which can slow its upgrades.
- Consolidation effort: auditors will still want to trace group figures back to each entity, so reconciliations between instances need their own controls.
- Scope creep: entities that share integrations, service accounts or an identity directory may pull each other into scope, so map these dependencies before drawing the boundary.
Confirm with the external auditor which systems they will treat as in scope and what evidence they expect for each instance.
How a multi-entity rollout runs, phase by phase
The sequence turns a group's legal structure into a working multi-company ledger, with each phase closing on a signed-off artifact that the next phase depends on.
Scope entities, currencies and reporting needs
Start by listing every legal entity, its country, functional and presentation currency, fiscal year end, and the parent-subsidiary ownership chain. Finance leads and the group controller own this list, with DeployOpen running the workshops and recording answers. Confirm early which entities will share one database and which need a separate instance, because that decision drives the edition and licensing questions for the rest of the project. The step is done when a signed scope document lists each entity, its currencies and its reporting obligations, and the group controller has approved it.
Design chart of accounts and intercompany rules
Build a group chart of accounts that maps to each entity's local statutory chart while keeping consolidation accounts consistent. Define which intercompany transactions are posted, how each side is matched, which accounts clear balances, and who approves mismatches. Confirm with the chosen platform, edition and localization how multi-company intercompany features actually behave, since this varies by product and plan. The output is an approved chart of accounts with a mapping table per entity and a written intercompany policy that names owners for every intercompany account.
Configure companies, tax and currency settings
Create each company record with its own currency, fiscal calendar, tax registrations, and localization package, then set up tax codes and rates per jurisdiction. Configure exchange rate sources and revaluation rules, and separate the access rights so each entity's users see only their books unless the policy grants wider access. DeployOpen performs the configuration in a non-production environment and records each setting in a configuration register. The step closes when the tax team has reviewed test invoices for each entity and the register has been signed off.
Migrate data and load opening balances
Extract trial balances, open items, bank balances and master data from each source ledger, then map them to the approved chart of accounts. Load opening balances in a test database first and reconcile each entity's totals back to the source, with the differences logged and explained. Ask the platform partner to confirm the supported import method and any record limits for your data volume. The step is done when every entity's opening trial balance agrees to the signed source statement and the reconciliation workpapers are archived with the project record.
Run parallel close cycles
Run at least one full month-end close in parallel, where the new system and the legacy books both process the same transactions and the outputs are compared line by line. Test intercompany eliminations, currency revaluation, tax returns and the consolidated report against the existing numbers. Each variance is logged with a root cause and an owner, and the fix is retested before the cycle is accepted. The output is a parallel-close variance log with every difference resolved or accepted by the controller, plus a sign-off that the consolidated pack matches expectations.
Hand over runbooks, access and evidence
Transfer ownership of the running system to the group's team, including administration, user access reviews, backup and restore procedures, change management for customizations, and upgrade planning. Document how each entity's close, intercompany matching and tax filing are performed, and set out who approves changes to the chart of accounts. Confirm with the vendor and your hosting team which support arrangements apply to your edition and version. The step is complete when the group team has run a close with minimal assistance and the handover pack, including access records and change logs, has been accepted in writing.
Integration points and deployment pattern for group finance
A multi-entity ledger is only as reliable as the feeds, identities, exports and data paths around it. The cards below cover the connections a group finance team will touch most, and the access questions the hosting partner must answer before go-live. Each one should be designed once for the group, then confirmed per entity and per platform version.
Bank feeds and reconciliation
Each legal entity usually has its own bank accounts, and bank statement imports must land in the right company and currency. Map every account to one entity before the first import, and decide who approves matches for intercompany settlement accounts. Confirm with the chosen platform how bank connectors are supported for your banks, whether they are self-hosted or go through a third-party aggregator, and where the aggregator stores credentials. Test reconciliation with one month of real statements in a copy of the database first.
Identity through LDAP or social login
Finance users should sign in with the corporate directory so that joiners, movers and leavers are handled in one place. Odoo publishes LDAP authentication documentation and ERPNext publishes LDAP integration and social login key documentation, but the exact configuration depends on the version in use. Confirm which directory attributes map to company access and roles, and whether multi-factor authentication is enforced at the identity provider rather than inside the ledger.
Payroll postings from the payroll system
Payroll journals usually arrive as summary entries per entity, with tax withholdings and employer costs split across accounts. Decide whether the payroll provider posts a file, an API call or a manual journal, and who reviews the batch before posting. Confirm that the platform can split one payroll run across entities, cost centers or currencies without manual edits. Keep the batch file as evidence for each period close.
E-invoicing and invoice data exchange
Sales and purchase invoices issued from one entity may need structured e-invoice formats and must be matched to intercompany receivables in the counterparty entity. Decide where invoices are generated, which system holds the legal copy, and how status updates from the e-invoicing network return to the ledger. Confirm how the chosen platform handles national formats and whether an access point is run by your team or by a provider. Tax obligations differ by country, so verify them with local advisers.
Reporting exports and consolidation files
Group reporting usually depends on trial balance exports, intercompany reconciliation reports and mapped charts of accounts sent to a consolidation tool or data warehouse. Define one export schema per entity, with currency, period and account mapping fields fixed. Confirm which reports the platform can export through the interface and which need custom development, because custom reports become part of the change management scope. Keep export logic under version control.
Backups and database access by the hosting partner
Because one database holds several legal entities, a single backup or support session exposes all of them. Agree in writing which people at the hosting partner can read the database, how backups are encrypted and where they are stored, and how restores are tested for each entity. Confirm how database copies for testing are neutralized so that production data is not spread across environments. Under the FTC Safeguards Rule, encryption at rest and logging of authorized user activity apply to these systems.
Evidence auditors ask for from a multi-entity ledger
This table lists the evidence an external or internal auditor typically requests for a group ledger running several companies on one system, the component that produces each item, and who should own it. Read it as a checklist to confirm with your platform and implementation partner before the first group close. Most items depend on configuration and retention choices that you must verify in your own environment.
| Evidence | Producing component | Control owner | What to confirm |
|---|---|---|---|
| Intercompany reconciliation report | Intercompany accounts and matching entries in the general ledger, plus a custom or standard reconciliation report | Group financial controller | Confirm which intercompany matching and elimination features your edition and version include, and whether they need customization |
| Consolidation workpapers | Consolidated reporting or an export of entity trial balances to a consolidation tool or spreadsheet | Group reporting lead | Confirm whether consolidation runs inside the platform or outside it, and how currency translation rates are stored and dated |
| Audit trail of posted entries | Posting history and change log of journal entries, if enabled, plus database-level logs | Controller and IT audit owner | Confirm that posted entries cannot be edited or deleted without a trace, and test this on a copy before relying on it |
| User access by company | User-to-company assignments and role lists exported from the platform's access settings | IT security or access review owner | Confirm how multi-company user rights are reported, and whether one user can post in several entities without separate approval |
| Access review sign-offs | Periodic exports of user rights, reviewed and signed by the entity manager | Entity finance managers | Set the review frequency and retain signed copies outside the system |
| Change logs for customizations | Version control history of custom modules or scripts, plus deployment records from the change process | Platform owner and implementation partner | Confirm that every customization is in source control and that production changes trace to an approved ticket |
| Upgrade and test records | Test database results, sign-off on the upgraded copy, and the release notes applied | Platform owner | Confirm the upgrade path for your edition and that a tested copy precedes each production upgrade |
| Retention copies and backups | Scheduled database backups, archived exports of ledgers, invoices and bank statements, and restore test results | Infrastructure owner with finance records owner | Confirm the retention period for each record type under applicable rules, and that restores are tested and logged |
| Separate-entity tax and currency settings | Company-level configuration records for chart of accounts, tax codes and base currency | Tax manager per entity | Confirm that configuration changes are logged and that tax settings are reviewed before each filing period |
What do multi-entity accounting projects cost and require?
What drives the implementation effort for a multi-entity accounting setup?
Effort follows the number of legal entities, the currencies and tax regimes they report under, and how many intercompany flows must net out. Each entity adds its own chart of accounts mapping, tax configuration, bank connections and opening balances. Customizations for consolidation, approval workflows and reporting usually take the largest share of the work. Ask any implementation partner to price the scope by entity, currency, integration and custom report, in writing, before work starts.
Can our finance and IT team run a multi-entity system internally?
Many teams can run day-to-day bookkeeping internally, but a group setup needs people who can own several skills at once: accounting configuration, database and server operations, security patching and upgrade testing. Check whether you have someone who can maintain intercompany rules and consolidation logic after go-live. If not, a partner can handle the build and hand over runbooks, or stay on a support retainer. DeployOpen offers ongoing support, upgrades and testing as retainers, with fixed-scope implementation agreed in writing.
How do Odoo edition limits affect a multi-company decision?
Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes multi-company, Odoo Studio, external API access and custom modules. A group that plans to self-host and run several companies on one database should therefore confirm the Custom plan and its per-user pricing before choosing Odoo. Community edition is LGPL-3.0 licensed, but its upgrade service and some operational features are not available to it. Confirm the exact edition features with Odoo directly, because plans can change.
How do Frappe support versions affect ERPNext planning?
Support windows determine how long a chosen ERPNext and Frappe version can be patched without a forced move. Frappe's supported versions page states that version 14 reached end of life on January 31, 2026, that version 15 is planned to be supported until the end of 2027, and that version 16 until the end of 2029. Frappe also says customers must run a listed version and hold a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Choose a version whose window covers your planned go-live and first audit cycle, and confirm the current dates on the source page.
How many instances should a group run instead of one shared system?
The right number depends on how separate the entities are, not on a fixed rule. Use one shared instance when entities share a currency regime, chart of accounts logic, approval chain and reporting calendar, because intercompany entries and consolidation stay simple. Consider separate instances when entities sit in different jurisdictions with different data residency or retention rules, face different edition or licensing constraints, or are being acquired and need an isolated close. Document the criteria with your tax and audit advisers before deciding, and treat the choice as a planning input rather than a permanent setting.
What must our client team supply before a multi-entity build starts?
A partner needs decisions and data from your side before design can begin. Typical inputs include:
- A list of legal entities, functional currencies, tax registrations and fiscal year ends
- Charts of accounts for each entity and the intercompany mapping rules agreed with finance
- Opening balances, open items and a clean extract from the current ledger
- Named approvers for each entity, bank account details and reconciliation owners
- Security requirements, hosting location and the people who will hold administrator access
Missing inputs are the most common cause of schedule slips, so confirm each item in the written scope.
How do upgrades affect the month-end and year-end close calendar?
Upgrades can collide with close periods, so plan them outside the window when journals are locked and consolidations run. Odoo documentation states that on Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, and that Odoo recommends testing an upgraded test database before production. Frappe's minor releases for ERPNext arrive frequently, so schedule regular patch windows and test each one against your intercompany and consolidation reports. Ask your partner for a written upgrade runbook, a test environment that mirrors production, and a rollback plan.
What to ask an implementation partner about multi-entity accounting
Start with intercompany setup. Ask the partner to describe a multi-company rollout they have delivered, how they configured intercompany transactions and eliminations, and which entity holds the intercompany clearing accounts. Ask them to show the reporting outcome, not only the configuration screens. Then ask which edition and plan the design requires. Odoo's pricing page places multi-company, Studio, external API access and custom modules in the Custom plan, and Odoo Enterprise source is not publicly available, so the answer should name the edition, the license terms and who holds the subscription. Ask whether any entity needs a feature that sits outside the plan you are quoting.
Next, ask how localization is handled for each entity: chart of accounts, tax codes, currency settings, fiscal calendars and e-invoicing requirements. Ask whether the partner will document each entity's settings separately and how they test tax returns against a reference period. For migration, ask how opening balances are loaded, reconciled to the source ledgers and signed off by the controller of each entity before go-live. Ask for the migration sample they would present to your finance team.
Then cover upgrades, support and hosting. Ask which supported version they will deploy, the end of standard support for that version, and what happens at the next major release. The Odoo support documentation lists dates per version, and Odoo SaaS and Odoo.sh upgrades are mandatory every two years, so ask for a written upgrade calendar. Ask who operates backups, patching, access to the database and the hosting account, and which responsibilities sit with your team. Finally, ask how audit evidence is produced: change logs for customizations, user access reviews by entity, and reconciliation packs. Ask who in your organization signs them off, and whether the partner's deliverables include the evidence or only the configuration.
How do we decide between one instance and several?
Should all our legal entities share one accounting database?
Share one instance when the entities use the same chart of accounts, the same close calendar, the same approval rules and the same people running finance, and when intercompany trading is frequent. A single database makes intercompany matching, eliminations and consolidated reporting simpler because every entry sits in one ledger. The trade-off is that access control, configuration changes and upgrades affect every entity at once. Confirm with the vendor which multi-company features your chosen edition includes, since Odoo's pricing page limits multi-company to its Custom plan.
When does a separate instance per entity make more sense?
Separate instances fit better when entities have different regulators, different audit firms, different retention or data residency rules, or when one entity is being sold or acquired soon. Isolation limits the blast radius of a failed upgrade, a bad customization or a compromised administrator account. The cost is paid repeatedly: each instance needs its own hosting, backups, upgrades, monitoring, access reviews and close process, and intercompany activity must be reconciled across systems. Ask your partner to price the recurring operations work per instance, not only the initial build.
How do intercompany entries and eliminations change the decision?
Intercompany activity is the main technical reason to consolidate. When both sides of an invoice post in one database, matching and elimination can be automated and reviewed in one place. When entities sit on separate systems, you need an interface that exports balances, a documented mapping of intercompany accounts, and a manual or scripted reconciliation step every close. Test how your candidate handles mirrored intercompany invoices, currency differences on intercompany balances and elimination entries before committing to either design.
Can one instance keep separate tax and currency settings for each entity?
Usually yes at the company level, but the details decide whether it works. Each legal entity needs its own functional currency, fiscal calendar, tax registrations, tax rates and localized chart of accounts, and reports must filter cleanly by entity. Check whether your candidate supports per-company tax configuration, multi-currency postings and currency revaluation for each company, and whether tax returns can be produced without manual reshaping. Have your tax advisor confirm the requirements for every jurisdiction before you assume a shared configuration is acceptable.
What does consolidated reporting need from a multi-entity setup?
Consolidated reporting needs a common chart of accounts or a documented mapping to one, consistent period definitions, agreed currency translation rules and a clear elimination process. A single instance gives the simplest path, while separate instances need scheduled data exports and a consolidation layer, which adds effort to every close. Ask the partner to show how the consolidated balance sheet and income statement are produced, who signs off eliminations, and how the audit trail links consolidated figures back to entity-level entries.
Which edition and license limits should we check before choosing multi-company?
Edition and license terms can settle the question before any architecture discussion. For Odoo, the pricing page states that only the Custom plan includes multi-company and can be hosted on Odoo.sh or on premise, and the Enterprise source code requires a subscription or partner access. ERPNext is licensed under GPL-3.0 and supports multiple companies within one site, so confirm the configuration and reporting behavior in a test environment. Also confirm how each candidate's support and upgrade coverage applies to your hosting model, because support windows affect how long one shared instance can stay on a single version.
How do we test a multi-entity design before we commit?
Build a test copy with realistic but anonymized data for at least two entities and run one full close cycle. Include intercompany invoices in both directions, a foreign currency entity, a tax return for each jurisdiction, a consolidated report and a user access review. Measure how many manual steps the close needs and whether the audit trail can answer who changed what. Odoo's on-premise documentation describes database duplication with neutralization for test copies, and the test results should decide whether one instance or several is the right design.
Can our own finance team manage multi-entity books without outside help?
A capable finance team can run the daily books of a multi-entity group, but the design, configuration, integration and upgrade work usually needs specialist skills. Your team needs someone who understands the chosen platform's company model, your tax rules and your close calendar, plus an administrator who can manage access and change control. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a written, fixed scope for most engagements, and offers retainers for ongoing support. Ask any partner to show how it will hand over runbooks and what your team must own after go-live.
How DeployOpen scopes and supports a multi-entity ledger
The sequence moves a multi-entity group from a written scope to a tested, self-hosted ledger with entity structures, intercompany and consolidation outputs checked, and evidence packaged for the auditors who will review it. Each step closes with a named output that the client can verify.
Document entities, currencies and reporting needs
DeployOpen starts with a discovery session led by its consultants and the client's finance and IT leads. The team lists every legal entity, its functional and presentation currencies, its tax regimes, its intercompany flows and the consolidated reports the board, lenders and auditors expect. The output is a requirements register that the client signs off, which becomes the baseline for the written scope. Ask the team to show which entities share a chart of accounts and which need their own.
Agree the written scope before work starts
Because most engagements are fixed-scope, DeployOpen issues a written scope that names the platform and edition, the entities and instances in scope, the localization packages, the integrations, the migration sources and the deliverables. Pricing follows from this document rather than from a published list. The client confirms edition terms with the vendor, including whether multi-company and external API access are included in the plan being quoted. The closing check is a signed scope with named exclusions.
Design the self-hosted environment
DeployOpen designs the deployment inside the client's own cloud accounts, data center or air-gapped network, covering hosting, database, backups, identity integration, network paths and administrative access. Where the platform has a documented container or source installation path, the design states which one is used and why. The client keeps control of the infrastructure, and DeployOpen documents who operates each component. The output is an architecture document and a responsibility matrix that shows the client, DeployOpen and any hosting provider.
Configure companies, intercompany and tax settings
The team configures each company with its own currency, tax and localization settings, then builds intercompany accounts, counterpart rules and elimination logic according to the agreed design. Where one instance serves several companies, the configuration also defines how users are restricted to the companies they may post to. Each configuration change is recorded in the change log. The check that closes this step is a configuration walkthrough in which the client's controllers post sample intercompany transactions in each direction.
Test intercompany and consolidation outputs
DeployOpen prepares a test script covering intercompany invoices, currency translation, eliminations, and consolidated balance sheet and income statement reports. The test runs against a copy of the database with known inputs, and each result is compared with figures calculated independently by the client's finance team. Differences are logged as defects, fixed, and retested. The output is a signed test report that lists each scenario, its expected result, the actual result and the retest outcome.
Migrate opening balances and reconcile
The team loads opening balances and open items for each entity from agreed source extracts, using the platform's import tools where they fit the data volume. Each entity's trial balance in the new system is reconciled to the source ledger before go-live. Exceptions are documented with the cause and the approver. The closing check is a reconciliation pack per entity that the client's controller signs, showing that the new ledger matches the source at cut-over.
Prepare audit evidence and access controls
DeployOpen assembles the evidence an independent auditor will ask for, such as the scope document, configuration records, change records, test reports, user access listings, backup test results and the segregation of duties design. DeployOpen prepares this material but does not issue audit reports, attestations or certifications. The client's auditors decide what is sufficient. The output is an evidence index that maps each item to the control it supports.
Hand over and move into retainer support
At handover, DeployOpen delivers the documentation, runbooks, administrator training and the operating procedures for upgrades and customizations. Ongoing support, upgrades and continuous testing can be covered by a retainer agreed in writing after go-live. The client confirms which tasks the internal team keeps and which the retainer covers. The closing check is a signed handover record and an agreed support schedule.
