A multi-country group should require its ERP to record in each entity's functional currency, revalue and translate to the group currency by rule, support local charts and statutory outputs, enforce approval chains and audit logs per subsidiary, connect to treasury and banks, and consolidate with intercompany eliminations. Requirements should be tested with your own entities.
This guide is for CFOs, VPs of finance and controllers who run subsidiaries in several countries and are comparing platforms or planning a build. It turns the buyer questions into a requirements list and a way to evaluate any vendor without ranking them. For a custom build, see enterprise ERP development. This is general practice, not tax, legal or accounting advice. Statutory and reporting rules differ by country and change; confirm them with local advisers and your auditor.
Key takeaways
- Define the group requirement and the local requirement separately. Group reporting needs one structure; each country also needs local books and outputs.
- Multi-currency means three things: transaction currency, functional currency and group reporting currency, each handled by rule.
- Statutory reporting is rarely one button. Decide what the ERP produces, what it feeds to local accountants, and what stays outside.
- Approval chains and audit logs should be configured per subsidiary, with group-level oversight.
- Central treasury needs bank connectivity, intercompany funding records and exposure reporting, whether inside the ERP or in a connected tool.
- Information-reporting obligations, such as platform reporting rules, vary by country and should be confirmed with advisers, not assumed.
What should a multi-country ERP requirement list include?
It should cover currency, charts and ledgers, statutory outputs, tax, approvals, treasury, consolidation, language and data access, each stated as a testable scenario with a named owner and an expected result. Requirements written as features ("supports multi-currency") cannot be compared. Requirements written as scenarios can.
| Area | Write the requirement as a scenario |
|---|
| Currency | A supplier invoice in a third currency is paid after a rate change; show the entries in the entity and group currency |
| Ledgers | An entity keeps local statutory books and also reports group figures; show how both are kept |
| Statutory reports | List each report per country, the format and who files it |
| Tax | Show tax codes, returns data and e-invoicing needs per country |
| Approvals | Show the approval chain for the same purchase in two countries |
| Treasury | Show cash positions by bank and currency, and intercompany funding |
| Consolidation | Show translation, eliminations and non-controlling interests for the group |
| Language and calendar | Local language documents and different fiscal year-ends |
| Access | A local controller sees only their entity; group finance sees all |
How does multi-currency and revaluation work?
The ERP records each transaction in its own currency, converts it to the entity's functional currency at a stated rate, revalues open monetary balances at period end, and translates the entity's results into the group currency for consolidation. Rates should come from a controlled table with a named source and a rule for each rate type.
Worked example. The figures are illustrative and are not accounting advice. A UK subsidiary keeps books in GBP. The group reports in EUR. The subsidiary raises an invoice for EUR 100,000 when 1 EUR = 0.86 GBP, so the receivable is GBP 86,000. At period end the rate is 1 EUR = 0.84 GBP.
| Step | Entry or result |
|---|
| Initial recording | Receivable GBP 86,000 |
| Revaluation at closing rate | Receivable becomes GBP 84,000; exchange loss GBP 2,000 in the subsidiary's profit or loss |
| Translation to group currency | Closing rate 1 GBP = 1/0.84 EUR, so GBP 84,000 translates to EUR 100,000 |
| Other statement lines | Income and expenses are translated at transaction or average rates, with the difference recorded in equity under general practice |
Standards such as IAS 21 and ASC 830 set out the treatment, including how translation differences are presented. The exact rate types, presentation and exceptions should be confirmed with your auditor. The group-currency value equals the original EUR 100,000 only because the receivable is denominated in EUR; the profit and loss effect arises in the GBP books. In the ERP, the requirement is that revaluation, translation and the resulting differences are separate, reproducible entries.
How should local statutory reporting be handled?
Decide per country what the ERP will produce, what it will export for a local accountant or filing tool, and what stays outside. A local statutory report may require a local chart of accounts, a local accounting basis, local tax codes, a prescribed format and a local-language layout, and each can differ from group reporting.
There are three common designs:
- Local chart in the ERP, mapped to group. Each entity posts to local accounts mapped to the group structure.
- Group chart with local reporting mappings. Entities post to the group chart, and a mapping produces local reports.
- Parallel ledgers. The ERP keeps a local ledger and a group ledger side by side, with adjustments between them where the accounting bases differ.
Ask which design the vendor supports, who maintains the local report formats when rules change, and whether the vendor or a partner is responsible for each country. For a country example on this site, see ERP software in the UAE. Say "designed to support" local requirements, and confirm each against the current rules with local advisers.
How do country-specific approval chains and audit logs work?
Each subsidiary needs its own approval rules, limits, roles and audit log, with a group layer above. A purchase that needs two approvals in one country may need three, or a named legal signatory, in another. The ERP should let an entity administrator maintain local rules within limits set by the group.
Example matrix. The thresholds are illustrative and show the structure only.
| Purchase value (local currency equivalent) | Entity A (UK) | Entity B (Germany) | Entity C (UAE) |
|---|
| Up to 5,000 | Department head | Department head | Department head |
| 5,000 to 25,000 | Finance manager | Finance manager and managing director | Finance manager |
| Above 25,000 | Local director and group CFO | Managing director and group CFO | General manager and group CFO |
Requirements to test: separate roles per entity, delegation when an approver is absent, approval history that survives user changes, no self-approval, and an audit log showing who changed an approval rule. Time to configure the hierarchy depends on the number of entities, rule variations, roles, integrations to HR for reporting lines, and how many scenarios are tested. It is not a fixed number, and we do not quote one. Our multi-entity ERP governance guide covers controls in depth.
What does centralised treasury need from an ERP?
Centralised treasury needs a view of cash by bank account, entity and currency, a way to record intercompany funding, payment execution with controls, and exposure reporting. Some groups do this inside the ERP; others connect a dedicated treasury tool. What matters is that cash, loans and payments reconcile to the ledger.
- Bank connectivity for statements and payments, and the formats supported in each country.
- Cash positioning by entity and currency, with forecast inputs from receivables and payables.
- Intercompany loans and cash pooling records, with interest accrual. Legal and tax rules on pooling and funding vary by country, so confirm structures with advisers.
- Payment controls: approval, limits, dual authorisation and bank file integrity.
- Exposure reporting: open foreign currency receivables, payables and loans by currency.
- Reconciliation of bank balances to the ledger.
How do subsidiaries migrate into one ERP?
Subsidiaries usually migrate in waves around a common template: design the group structure, build and prove it with a pilot entity, then add entities with local variations. Each wave loads master data, open items and balances, reconciles them and sets up local approvals and statutory outputs. Intercompany balances need a plan between live and not-yet-live entities.
Scope each wave using our guide on what to migrate to a new ERP, and plan the intercompany treatment with intercompany transactions and eliminations in ERP.
What should be in a multi-entity vendor quote?
Ask every vendor to state, in writing, what the quote includes for each entity: modules, users by type, entity or subsidiary fees, transaction or invoice volume limits, localisation per country, integrations, data migration, training, support, data export rights and what happens when you add an entity. Do not compare quotes until they use the same scope.
| Quote item | Why to ask |
|---|
| Entity or subsidiary fees | Adding a country should not be a surprise |
| Volume limits | Invoices, transactions, documents or storage may be capped |
| Localisation per country | Who builds and maintains local formats |
| Integration scope | Banks, tax portals, HR, CRM, e-commerce |
| Implementation scope | Which phases and who does what |
| Approval and audit configuration | Included or extra |
| Data export and exit | How you leave with your data |
What should the consolidation step produce?
The consolidation step should produce group statements from entity ledgers in five visible steps: align each entity to group accounting policies, translate to the group currency, eliminate intercompany balances and transactions, account for non-controlling interests, and keep an audit trail from every consolidated figure back to an entity ledger. Each step should be a separate, reproducible entry.
Ask whether the ERP runs a trial consolidation mid-month without posting, whether policy adjustments (for example local GAAP to group basis) are recorded as separate adjustment ledgers, and who owns the elimination rules. Confirm presentation with your auditor under the standards you report. The intercompany mechanics are in intercompany transactions and eliminations in ERP.
Some groups must report information about sellers, customers or accounts to tax authorities. One example is the EU rules on platform operator reporting, known as DAC7 (Council Directive (EU) 2021/514). These obligations attach to defined reporting entities, differ by country and change over time, so confirm them with tax advisers in each country.
Whether a group can file once for several entities depends on how the rules define the reporting operator and where it reports.
Do not assume the ERP decides this. Its role is to hold the right data (seller or customer identifiers, activity by period, entity) and to produce the extract your advisers need. Confirm the obligation, the reporting entity and the format with tax advisers in each country.
When this is the wrong approach
A full multi-country ERP design is the wrong first step if the group has one operating company and a representative office, if subsidiaries are being sold or wound down, or if local statutory reporting is entirely outsourced and the group needs only a consolidation tool. In those cases a lighter consolidation layer on top of local books is simpler. If the group is held back by old systems, assess them first with the legacy software modernization approach.
Glossary: functional currency, the currency of an entity's main operating environment; reporting currency, the currency the group reports in; revaluation, remeasuring open monetary balances at the closing rate; translation, converting an entity's results into the reporting currency; non-controlling interests, the share of a subsidiary's equity not owned by the parent; statutory report, a report required by local law; cash pooling, combining balances across accounts or entities for liquidity.
How Timeline Digital approaches this work
For a group with subsidiaries in several countries, Timeline Digital begins in the Plan step by turning your country, currency and approval requirements into testable scenarios, and the schedule is set from those requirements. Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, delivering remotely. A free pilot of 2 to 3 key modules lets your team test the result before the final agreement. Controls are designed to support your audit needs and confirmed per project, and code ownership passes on full payment.