Can One ERP Handle Multiple Legal Entities? A Practical Evaluation Checklist

Start with your requirements, not the phrase “multi-entity”

Multi-entity accounting generally concerns managing more than one legal entity in a system. That definition does not tell you how a particular product handles books, transactions, access rules or reports; those workflows vary by product and configuration. (Rillet, “Multi-Entity, Multi-Currency ERP for Scale-Ups”: https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Treat consolidation, simpler close processes and reduced risk as outcomes to test, not automatic benefits. Oracle NetSuite describes those as potential aims of multi-entity accounting, but that framing does not establish what a given implementation will achieve. Managing entities in one system can also add process complexity as an organization grows. (Oracle NetSuite: https://www.netsuite.com/portal/resource/articles/accounting/multi-entity-accounting.shtml; Citrin Cooperman: https://www.citrincooperman.com/In-Focus-Resource-Center/Multi-Entity-Accounting-in-QuickBooks-When-Does-It-Make-Sense-to-Take-the-Next-Step)

Compare a shared environment with your current or proposed separate-system approach using the same real workflows. A shared platform is one approach to managing multiple legal entities, not a guarantee that it suits every organization. (Rand Group: https://www.randgroup.com/insights/services/evaluation-selection/best-multi-entity-accounting-software-and-erp-systems-for-growing-businesses/)

• List every legal entity in scope, its role in the organization and which teams use its records.
• Identify the accounting and operational processes that must work across entities, not just within one.
• Record required outputs: entity-level books and reports, group-level views, audit evidence and any external reporting.
• Mark each requirement as essential, desirable or unresolved. Keep legal and accounting interpretations separate from software configuration questions.

Separate legal entities from locations, departments and currencies

A legal entity is not interchangeable with a department, branch, project, warehouse or currency. These may all be important dimensions in an ERP, but using one in place of another can make it unclear which organization owns a transaction and which books it belongs in.

Prepare a short entity map before demonstrations. For each entity, note the business activities it performs, the records it needs to maintain, and how it relates to the other entities. Then list the non-entity dimensions you need to report by, such as department or location.

Ask the vendor to show how the system represents each concept and what happens when a user enters a transaction. Do not infer legal or accounting treatment from a screen label. Have qualified advisers confirm which entities and reporting treatments your organization needs.

• Can a transaction be assigned to the correct legal entity independently of its department, location or project?
• Can the same location or department be relevant to more than one entity, if that matches your structure?
• How does the system distinguish transaction currency from entity-level and group reporting currency, if those apply?
• Which fields are required to prevent users from recording activity against the wrong entity?

Check what must be separate: books, periods, numbering and access

Do not assume that a shared system means either fully shared or fully separate accounting controls. For each requirement, ask the vendor to identify the setting or workflow that supports it, demonstrate it in a test environment, and explain any limitations or dependencies.

Confirm the required behavior with your accounting team. Whether periods, numbering sequences, ledgers or other controls need to differ can depend on your accounting policies, jurisdictions and reporting obligations.

• Books: Can you identify which records belong to each entity and produce that entity’s required accounting views?
• Periods: Can each entity follow the period controls and close sequence your finance team requires? What happens if one entity is ready to close before another?
• Numbering: Can transaction identifiers follow the policies you need by entity or transaction type? Ask what happens when a number is voided or a record is corrected.
• Permissions: Can users be limited to the entities and records appropriate to their roles? Test what they can view, create, edit, approve or export.
• Audit trail: Ask what evidence is retained for changes to entity assignments, accounting records and user access, and how authorized reviewers retrieve it.

Test shared customers, suppliers, products and other master data

A shared customer or supplier record may reduce duplicate maintenance, but it can also raise questions about ownership, visibility, entity-specific terms and data quality. Do not assume the ERP shares master data automatically, or that shared data is appropriate for every record.

Use representative records from your own business. Ask the vendor to show whether a customer, supplier, product or service can be used by multiple entities, whether entity-specific details can differ, and what a user in one entity can see or change. Confirm the behavior in a test environment.

• Can one party have activity with more than one entity, and how is that activity distinguished in the record and reports?
• Which master-data fields are shared, and which can differ by entity?
• How are duplicate or conflicting records identified and resolved?
• Can access be restricted when a record is shared across entities?
• What is the effect of changing a shared record on existing and future transactions?

Walk through intercompany transactions from start to settlement

Intercompany reconciliation is a relevant area to evaluate in multi-entity accounting, but a general description of a product’s capabilities does not establish how it handles your transaction types. (Rillet, “Multi-Entity, Multi-Currency ERP for Scale-Ups”: https://www.rillet.com/blog/multi-entity-multi-currency-erp-global-expansion)

Evaluate the complete workflow, not just a checkbox or transaction screen. Include the initiating transaction, the corresponding entry or document in the other entity, review and approval, reconciliation, settlement and the reports finance uses to confirm completion. Ask the vendor to distinguish standard behavior from configuration, manual steps, integrations or additional products.

• Test a sale or service provided by one entity to another: who initiates it, what records are created, and how both sides are reviewed?
• Test an expense paid by one entity on behalf of another: how is the allocation recorded, approved and reconciled?
• Test a transfer of inventory, assets or other items if these occur in your organization.
• Ask how exchange rates, timing differences, mismatched amounts and rejected counterpart entries are handled, where relevant.
• Follow the balance through settlement. Identify who owns each step and how unresolved differences are surfaced.
• Ask whether the workflow is automated, partially automated or manual, and which controls remain the customer’s responsibility.

Verify entity-level reports and group views, including eliminations

Ask the vendor to run the same representative report at entity level and across the group. Confirm the scope, filters, currency presentation, source data and timing of each view rather than relying on a polished summary screen.

If you need consolidated reporting, ask how the system treats intercompany balances and transactions, including whether and how eliminations are represented. Do not assume a consolidated view is equivalent to a complete consolidation process. Have your accounting advisers confirm the required accounting treatment, review controls and reporting outputs.

• Can authorized users produce the required reports for one entity without mixing in another entity’s activity?
• Can the group view be traced back to contributing entities and underlying records?
• How are intercompany balances identified, reviewed and reconciled for reporting?
• If eliminations are required, where are they recorded, reviewed and reflected in outputs?
• Can users see the reporting period, entity scope and other filters that shaped a report?
• What does the product not consolidate or calculate without additional configuration or manual work?

Test exceptions, not just the happy path

Routine demonstrations often use clean data and a straightforward workflow. Your evaluation should also show what happens when a record is wrong, late, restricted or already part of a closed process. These cases can reveal operational dependencies that a feature list may not explain.

Use your own policy to define expected outcomes. The questions below are prompts for testing, not assertions that every ERP handles them in a particular way.

• Correction: What steps are available when a transaction was assigned to the wrong entity? Does the correction preserve an understandable history?
• Late entry: How does the system handle a late transaction for a period that has been closed or is being closed?
• Entity change: Can an entity assignment be changed after entry or approval? Who can do it, and what records or reports are affected?
• Restricted access: What happens when a user tries to view, edit, approve or export a record outside their permitted scope?
• Mismatch: How are incomplete intercompany pairs or unreconciled balances identified, assigned and followed up?
• Failure or exception: What evidence is available when a workflow cannot complete as expected?

Use a repeatable evaluation script and keep evidence

Run the same script for each candidate system. Use representative scenarios, realistic roles and sample data that reflect your entity structure. Ask the vendor to demonstrate the workflow, then have your team repeat it in a test environment where possible.

For every requirement, record the result, evidence and open questions. Evidence might include a dated product document, a configuration screen, a test result or a written vendor clarification. Treat verbal statements as unverified until confirmed.

• Create a scenario for each priority workflow: entity-specific entry, shared master data, intercompany activity, reporting and at least one exception.
• For every scenario, document the starting data, user role, expected result, actual result and any manual workarounds.
• Record whether the behavior is standard, configured, dependent on another product or process, or still unconfirmed.
• Capture limitations, required customer decisions, implementation dependencies and the owner of each follow-up.
• Score fit against your requirements, not against feature count. Treat a failed essential workflow as a decision issue, not a minor demonstration gap.
• Ask finance and operations to review the evidence together; send accounting treatment and legal-structure questions to qualified advisers.