A multi-entity ERP runs several legal entities on one platform. Each entity keeps its own books, currency, tax settings and controls, and the system rolls them up into group reports. Good governance rests on four things: a group chart of accounts mapped to each entity, inter-company transactions that post on both sides automatically, a consolidation process that eliminates inter-company balances and transactions, and access and approval rules set per entity.
This guide is for finance and operations leaders planning an ERP across a group: a holding company with subsidiaries, a business with branches in several countries, or a founder whose second and third companies now share staff, stock or customers. It is vendor-agnostic and covers the accounting mechanics and the controls. It does not give tax advice: where transfer pricing or local rules come up, the right answer comes from your accountants and tax advisers.
What does multi-entity mean in an ERP?
"Multi-entity" gets used for three different things, and the design differs for each.
| Term | What it is | What the ERP must do |
|---|---|---|
| Legal entity | A separately registered company with its own statutory accounts and tax filings | Separate books, tax settings, document numbering and period close per entity |
| Branch or division | Part of one legal entity, such as a city office or a business line | Usually tracked with dimensions (cost centre, location) inside one entity's books |
| Currency | The currency an entity records in (functional currency) versus the currency the group reports in | Multi-currency transactions, revaluation, and translation for group reporting |
A branch that is not a separate company rarely needs its own ledger. A dimension on each transaction gives branch reporting without the overhead of inter-company accounting. Model legal entities as entities and everything else as dimensions, unless your accountants advise otherwise.
Shared versus per-entity master data
Decide which records the group shares and which each entity owns. The usual pattern:
- Shared across the group: item master, units of measure, the group chart of accounts, employee identities, and often the customer and supplier master (one record, extended per entity)
- Per entity: bank accounts, tax registrations and tax codes, payment terms where local practice differs, price lists, opening balances, document numbering, and fiscal calendars where entities have different year ends
Sharing a customer record across entities keeps one view of the relationship. Credit limits, terms and balances still belong to the entity that trades with that customer. Each shared master needs one owner, so two entities cannot change the same record in conflicting ways.
Designing the chart of accounts
Use a group chart of accounts with entity mappings. Every entity posts to accounts from one common structure, and local statutory reporting needs are met through mappings or extra local accounts that roll up to a group account.
- Keep the group account list stable and controlled centrally; changes go through one approval.
- Add local accounts only where statutory or tax reporting requires them, and map each one to a group account.
- Create dedicated inter-company accounts, such as inter-company receivable, payable, revenue and expense. Add a counterparty tag on every posting so balances can be matched by entity pair.
- Use dimensions (department, project, location) instead of creating account codes for every combination.
The result is that group reports read straight from the ledger, without a spreadsheet mapping step every month.
How inter-company transactions work: a worked example
An inter-company transaction is a sale, charge, loan or transfer between two entities in the same group. Each entity records its own side, and the group removes both sides on consolidation, because a group cannot earn revenue from itself.
The figures below are illustrative, including the exchange rates, and are not tax or accounting advice.
The setup. Entity A is based in the UAE and keeps its books in AED. Entity B is based in the UK and keeps its books in GBP. The group reports in GBP. In March, Entity A provides management services to Entity B and invoices AED 48,000. The rate on the invoice date is 1 GBP = 4.80 AED.
Both sides post
| Entity | Entry | Amount |
|---|---|---|
| Entity A (AED books) | Debit inter-company receivable from Entity B | AED 48,000 |
| Entity A (AED books) | Credit inter-company service revenue | AED 48,000 |
| Entity B (GBP books) | Debit management fee expense | GBP 10,000 |
| Entity B (GBP books) | Credit inter-company payable to Entity A (an AED liability) | GBP 10,000 |
A multi-entity ERP should create Entity B's side automatically when Entity A raises the invoice, or at least require it to be matched, so the two sides cannot drift.
FX revaluation of the open balance
At 31 March the invoice is still unpaid and the rate has moved to 1 GBP = 4.70 AED. Entity B owes AED 48,000, which is now GBP 10,212.77. Under IAS 21 (and the equivalent US GAAP topic, ASC 830), foreign currency monetary balances are remeasured at the closing rate, with the difference in profit or loss. Entity B posts:
| Entity | Entry | Amount |
|---|---|---|
| Entity B | Debit foreign exchange loss | GBP 212.77 |
| Entity B | Credit inter-company payable to Entity A | GBP 212.77 |
Entity A has no revaluation to post, because the invoice is in its own currency.
Elimination on consolidation
To build group accounts in GBP, Entity A's figures are translated. Balance sheet items use the closing rate, so the AED 48,000 receivable becomes GBP 10,212.77. Income and expenses use the transaction-date rate or an approximating average, so the revenue becomes GBP 10,000.
| Elimination entry | Amount |
|---|---|
| Debit inter-company payable (Entity B) | GBP 10,212.77 |
| Credit inter-company receivable (Entity A) | GBP 10,212.77 |
| Debit inter-company service revenue (Entity A) | GBP 10,000 |
| Credit management fee expense (Entity B) | GBP 10,000 |
Both sides eliminate exactly here because the same rates were used. In practice, average rates and timing differences leave small residual differences, and group policy decides how they are cleared. The GBP 212.77 exchange loss in Entity B is not eliminated. Under IAS 21, exchange differences on inter-company monetary balances generally remain in consolidated profit or loss, because the group really is exposed to the currency movement. Exceptions exist, for example for balances that form part of a net investment in a foreign operation, so confirm the treatment with your accountants.
When the inter-company sale is of goods rather than services, there is one more step. If the buying entity still holds the stock at period end, the selling entity's profit margin on it is unrealised from the group's point of view and is eliminated too.
Consolidation steps
Consolidation combines the entities' accounts into one set of group financial statements. IFRS 10 (Consolidated Financial Statements) and, under US GAAP, ASC 810 (Consolidation) both require inter-company balances, transactions and the related unrealised profits to be eliminated in full. A typical monthly sequence:
- Each entity completes its close, including inter-company postings and FX revaluation.
- Inter-company balances are matched by entity pair, and differences are investigated and corrected at source.
- Each entity's trial balance is mapped to the group chart of accounts.
- Foreign entities are translated into the reporting currency. Under IAS 21, assets and liabilities use the closing rate, income and expenses use transaction-date or average rates, and the translation difference goes to other comprehensive income.
- Elimination entries remove inter-company balances, transactions and unrealised profit.
- Group adjustments, such as non-controlling interests, are posted.
- Group reports are produced and reviewed.
The ERP should automate steps 2 to 5 as far as the rules allow and record every elimination as a visible, reversible entry, not as an override in a spreadsheet.
Transfer pricing is a matter for your advisers
When entities charge each other, the price matters for tax. Many tax authorities expect inter-company prices to follow the arm's length principle, described in the OECD Transfer Pricing Guidelines, and many require documentation to support them. Rules, thresholds and filing requirements differ by country and change over time. Confirm your approach with your tax advisers.
The ERP's role is supporting, not deciding. It should store the inter-company agreements, apply the rates or mark-ups your advisers approve, tag every inter-company transaction with its agreement, and produce the evidence your advisers ask for without manual digging.
Controls that keep a multi-entity ERP auditable
Segregation of duties per entity
The person who creates a supplier should not be the person who approves payments to that supplier. In a group, apply segregation of duties per entity. A user may be an approver in one company and a preparer in another, and the system should enforce the conflict rules entity by entity. Review conflicts regularly, especially for shared-service staff who work across entities.
Approval matrices
Define approvals by entity, document type and amount: purchase orders, supplier bills, payments, journals, credit notes and new master records. Inter-company charges often need an approver in both entities. Keep the matrix as configuration in the system, not as an email chain, so changes are themselves approved and logged.
Period close per entity and a group close calendar
Each entity closes and locks its own periods. Once a period is locked, nobody posts to it without an approved, logged reopening. A group close calendar then sets the order of work. Dates are set by each group to suit its reporting deadlines.
| Stage | Owner | Output |
|---|---|---|
| Inter-company cut-off | All entities | No new inter-company postings for the period |
| Entity close | Entity accountants | Reconciled, locked entity ledgers |
| Inter-company matching | Group finance with entity accountants | Agreed balances by entity pair |
| Consolidation run | Group finance | Translated, eliminated group trial balance |
| Review and reporting | Group controller | Approved group reports |
Audit trails
Every posting, change to master data, approval and period reopening should record who did it, when, and what changed. Audit trails matter most where a user can act in several entities, and on the consolidation adjustments themselves.
Data access by entity
Users should see only the entities they work for, enforced in the data layer rather than only hidden in menus. Group roles can see across entities; entity roles cannot. Our security and data protection page describes how we design role-based access and audit logging. Responsibility for meeting your own regulatory obligations stays with your organisation and is confirmed by your own assessment.
Reporting currency versus functional currency
Each entity records in its functional currency, usually the currency of the economy it mainly operates in. The group then presents its results in a reporting (presentation) currency. Keep the two separate in the design. Transactions in other currencies are revalued in the entity's books. Whole entities are translated for group reporting. Store the exchange rate type and source used for each, so any figure can be traced back.
Packaged multi-entity suite or custom ERP?
Most established packaged ERP suites offer multi-company, multi-currency and consolidation features, sometimes only in particular editions. A packaged suite is usually the better fit when your entities run similar, fairly standard processes, when your accountants already know the product, and when per-user licensing remains acceptable as the group grows. Check which edition you are being quoted, because group features are not always in the base product.
A custom ERP or a custom group layer tends to fit when:
- entities run genuinely different operations, such as manufacturing in one country and services in another
- some entities must keep existing local systems, and the group needs a consolidation and control layer above them
- inter-company flows, approvals or reporting are specific enough that a package would need heavy customisation anyway
- language, document or regulatory needs, such as bilingual records, are not well served by the packages you have evaluated
Custom has its own costs. You own the system's roadmap and maintenance, and the accounting rules must come from your finance team and advisers, not be invented by developers. Our ERP vs custom development comparison sets out the trade-offs in more detail, and our page on enterprise resource planning development describes what a custom build covers.
How to sequence a multi-entity implementation
Do not switch every entity on in one go. A safer sequence:
- Agree the group design first: chart of accounts, shared masters, entity list, currencies, approval matrix and close calendar.
- Pilot one entity or one process. Take the simplest entity, or a single cross-entity process such as inter-company service billing, and run it end to end, including a month-end close.
- Add entities in waves, each with its own migration, reconciliation and sign-off. Our ERP data migration plan covers the tie-outs for each wave.
- Switch on consolidation once at least two entities are live and inter-company matching works.
This is how we approach group ERP work at Timeline Digital. In our five-step process, the group design is settled before technology is chosen. Then we build 2 to 3 key modules as a free pilot, and the full project starts only after you approve it. If you want to see how we build ERP module by module around a group's real structure, start with our custom ERP software page.