Quick answer
Evaluate consolidation through a controlled demonstration, not a feature checklist. Give each vendor the same entity structure, trial balances, exchange rates and intercompany discrepancy. Require the system to explain the mismatch, apply approved translation rules, produce reviewable eliminations and trace reported figures to their sources. Then rerun the process after a correction to check for duplication and lost adjustments.
For CFOs, controllers and ERP implementation leads, the key question is: Can this configuration produce a group result that finance can explain, reproduce and approve?
The tests below use IFRS principles where accounting requirements matter. They are software-evaluation guidance, not a determination of your accounting policies or a comparison with US GAAP. Have your accounting advisers approve the expected treatment before asking vendors to demonstrate it.
1. Define the reporting group before testing the software
Prepare an entity register containing:
- Legal entity and parent relationship.
- Ownership percentage and relevant effective dates.
- Approved consolidation treatment.
- Functional currency and group presentation currency.
- Fiscal calendar, source system and chart of accounts.
- Required reporting dimensions, including intercompany partner.
Keep legal ownership separate from management reporting. A regional reporting hierarchy should not silently change which entities belong in statutory consolidation. IFRS 10 establishes control as the basis for consolidation, subject to its scope and exceptions; a software ownership field does not make that assessment. (ifrs.org)
Likewise, functional currency is an accounting determination based on the entity’s primary economic environment—not simply its country, invoice currency or preferred dashboard currency. (ifrs.org)
Ask the demonstrator to map two different local accounts into one group account, retain the source entity and identify an unmapped account. Include a reporting-period boundary if subsidiaries use different calendars.
Practical check: Request a completeness report showing every expected entity and source balance, plus exclusions and unmapped accounts. Do not accept a balanced group total as the only evidence of completeness.
2. Identify where consolidation actually happens
“Multi-company reporting” can describe different architectures. Establish whether balances are copied into a consolidation ledger, combined during report generation or transferred through an integration.
Microsoft’s documentation illustrates why product-specific questions matter:
| Documented product or route | Verified distinction | What to test |
|---|---|---|
| Dynamics 365 Finance: Consolidate online | Uses a separate consolidation legal entity; source changes require another consolidation run. | Correct a source balance and demonstrate the refresh process. |
| Dynamics 365 Finance: Financial reporting | Combines companies during report generation rather than transferring ownership of source data. | Trace a consolidated figure back to its originating company. |
| Business Central online | Documents API-based exchange across environments and a Database option within one environment. | Demonstrate the proposed connection and permissions. |
| Business Central online and on-premises | Documents XML export/import as a manual transfer route. | Reconcile an imported file to its source totals. |
These distinctions come from the respective product documentation; they should not be transferred between products or deployment models. (learn.microsoft.com)
Also distinguish a multilevel reporting hierarchy from staged currency translation. Dynamics 365 Finance documentation states that Financial reporting translates each source company’s accounting currency directly into the selected currency; staged translation through intermediate consolidation currencies requires a different setup. (learn.microsoft.com)
Record the demonstrated release, deployment model, license dependencies and extensions. The documentation cited here does not establish what is included in your particular commercial quote.
3. Separate currency processes and approve the rate rules
Test two processes separately:
- Foreign-currency transactions within an entity, such as a USD-functional parent holding a EUR receivable.
- Translation of an entity’s financial statements into the group presentation currency.
For non-hyperinflationary functional currencies, IAS 21 requires presentation-currency translation of assets and liabilities at closing rates and income and expenses at transaction-date rates. An average may approximate transaction-date rates, but is inappropriate when exchange rates fluctuate significantly. Resulting translation differences go to other comprehensive income. (endorsement-board.uk)
Create an approved account-to-rate matrix before configuration. Ask vendors to demonstrate:
- Closing, transaction-date and historical-rate handling.
- How an approved average is calculated and loaded.
- Equity and retained-earnings roll-forwards.
- Rate direction, effective dates and missing-rate exceptions.
- Rate changes, approvals and reproduction of earlier runs.
Do not confuse an ERP’s rate type—a named rate table or category—with its translation method, which determines how rates apply.
Business Central, for example, documents Average Rate, Closing Rate, Historical Rate, Composite Rate and Equity Rate methods. These software labels are configuration choices, not substitutes for an approved accounting policy. (learn.microsoft.com)
Common mistake: Applying one closing rate to every account because the resulting report still balances.
4. Test intercompany matching before eliminations
Use a deliberately mismatched transaction. Require the vendor to show both sides in transaction currency, entity currency and group currency.
For the test dataset, include partner entity, document reference, transaction date, posting period, account and settlement status. Ask the system to distinguish:
- A missing or partially posted invoice.
- A credit note recorded on only one side.
- A posting-period difference.
- An incorrect partner or account.
- A rate difference.
- A payment or settlement difference.
These are proposed acceptance tests; do not assume every ERP supplies a dedicated matching workbench.
In Dynamics 365 Finance, Microsoft documents using a trading-partner financial dimension—or dedicated intercompany accounts—to identify activity for elimination rules. That makes partner identification an important design requirement to test. (learn.microsoft.com)
Require exceptions to have an owner, explanation, resolution status and supporting evidence. Specify your acceptable tolerances rather than adopting demonstration defaults.
Practical check: A matching tolerance should flag or route a difference. It should not silently turn an unexplained discrepancy into an approved adjustment.
5. Evaluate eliminations and consolidation adjustments separately
Ask for separate demonstrations of:
- Intercompany receivable/payable elimination.
- Internal revenue/expense elimination.
- Inventory profit or fixed-asset transfer adjustments, where relevant.
- Investment/equity elimination and non-controlling interests, where applicable.
- Group-policy adjustments that should not change local books.
Keep reconciliation, elimination and group adjustment steps distinct in your test script. A discrepancy between the entities should be investigated before an elimination is accepted.
Automation differs by product. Dynamics 365 Finance documents rules that generate elimination journals during consolidation or through a proposal. Business Central documents consolidation eliminations as a manual process, with a report to assess proposed general-journal lines before posting. (learn.microsoft.com)
For every adjustment, request a reason, preparer, approver, supporting document, applicable period and reversal or carry-forward treatment. Test that ordinary entity reports remain unchanged when the entry is intended only for group reporting.
Common mistake: Treating automatic elimination as evidence that the underlying intercompany transactions matched correctly.
6. Run a worked two-entity test
The following figures and exchange rates are hypothetical test inputs, not market rates or reported company results.
Assume a wholly owned group with a USD-functional parent, a EUR-functional subsidiary and USD group presentation currency. Ignore tax and assume an ordinary trade receivable, not a net-investment item.
Test A: Identify an intercompany mismatch
The parent invoices the subsidiary EUR 10,000 for services. The invoice-date rate is USD 1.10 per EUR, so the parent initially records a USD 11,000 receivable. The subsidiary accidentally records only EUR 8,000.
At period-end, use USD 1.12 per EUR:
| Check | Calculation | Expected amount |
|---|---|---|
| Parent receivable after remeasurement | EUR 10,000 × 1.12 | USD 11,200 |
| Subsidiary payable translated for group reporting | EUR 8,000 × 1.12 | USD 8,960 |
| Unresolved difference | USD 11,200 − USD 8,960 | USD 2,240 |
The transaction-currency discrepancy is EUR 2,000. Investigate and correct the subsidiary’s missing amount through the approved process, then rerun. Both closing balances should equal USD 11,200, allowing a corresponding payable/receivable elimination.
The parent also has a USD 200 exchange gain from remeasuring its receivable. Do not automatically eliminate that gain merely because the receivable is internal: IAS 21 distinguishes the elimination of intercompany balances from the effects of currency fluctuations. (ifrs.org)
Test B: Verify subsidiary translation independently
Use a separate, simplified subsidiary fixture—not the trial balance from Test A:
- Closing assets: EUR 50,000.
- Closing liabilities: EUR 20,000.
- Share capital: EUR 20,000, issued at USD 1.05 per EUR.
- Opening retained earnings: zero.
- Current profit: EUR 10,000, with an assumed appropriate average rate of USD 1.10.
- Closing rate: USD 1.12.
- No distributions or other equity movements.
Expected translated amounts are:
| Component | USD |
|---|---|
| Assets | 56,000 |
| Liabilities | 22,400 |
| Share capital | 21,000 |
| Current profit | 11,000 |
| Translation reserve: credit balance | 1,600 |
The check is 56,000 = 22,400 + 21,000 + 11,000 + 1,600. This is a simplified application of presentation-currency translation principles, not a complete group consolidation. (endorsement-board.uk)
Require the ERP to explain the reserve through its translation calculation—not an unexplained balancing journal.
7. Prove traceability and safe reruns
Select a reported balance and require a reconciliation through:
Group total → entity contribution → account mapping → translation → elimination or adjustment → source evidence.
Distinguish transaction-level drill-back from balance-level provenance. An imported trial balance may require supporting evidence from the external source system rather than transaction detail inside the consolidation application.
Dynamics 365 Finance documentation describes full transaction drill-back for Financial reporting. Verify that the proposed report, permissions and source-data route actually deliver the detail you need. (learn.microsoft.com)
Then perform three controlled reruns:
- Repeat the same run without changing inputs.
- Correct one source transaction and rerun.
- Change one approved rate and rerun.
Record expected differences beforehand. Check for duplicate imported balances, repeated eliminations, overwritten adjustments and unexplained changes to prior results.
Business Central documents reviewing and reusing rates from previous consolidation runs. Include this in testing if reproducibility is a requirement. (learn.microsoft.com)
Also test preparer and reviewer access separately. Demonstrate who can change mappings, rates, journals and published reporting versions.
8. Make acceptance depend on retained evidence
Use a pass/fail log supported by exports, reconciliation schedules and approval records. Before accepting the solution, require evidence that:
- Every intended entity and account is included or explicitly excluded.
- Source totals reconcile to the reporting inputs.
- Rate rules match the approved policy.
- The deliberate mismatch remains visible until resolved.
- Eliminations and adjustments are reviewable and correctly scoped.
- Reruns do not duplicate balances or entries.
- Reported amounts trace to evidence at the required level.
- Access restrictions work for the intended roles.
- Finance can reproduce a previously approved reporting pack.
Assign each failure an owner and remediation plan. Label manual work, extensions and unresolved dependencies plainly.
Choose on the strength of an explainable close process—not the appearance of a consolidated dashboard.