Part of the Replacing a consolidation or planning system: the complete guide series.
The consolidation system requirements checklist that matters is the one built from your group's own structure - entities, ownership, currencies, calendar - and tested on your own data, in front of the people who will run the close. Every other list starts from a vendor's feature set and works backwards. This article gives you the generic spine; you fill in the specific entries. If you are still deciding whether to replace your current platform at all, one paragraph covers that: see the consolidation system business case guide. If you are moving off Excel, that case is made separately at moving group consolidation off Excel. The wider context for replacing finance systems sits at the pillar hub: replacing finance systems.
Where do you start building the requirements list?
Start at the lowest level of data you will ever need to report, because every other requirement inherits its answer from that level. Before writing a single feature requirement, document three things: the finest grain of entity at which you consolidate (legal entity, sub-group, or segment); the account structure at that level; and the non-financial dimensions - cost centre, project, product line - that management reporting demands. A system that cannot hold data at that grain will fail the group regardless of what its marketing says about everything else.
Write this out as a short data model: n entities, x account segments, y dimensions. Hand it to every vendor before the demo. It is the lens through which every subsequent requirement is read.
What does entity and ownership structure require from a consolidation system?
A consolidation system must be able to represent the ownership structure of your group as it actually exists, including minorities, step acquisitions, disposals mid-year, and changes of control that shift an entity between full consolidation, proportional consolidation, and equity accounting within a single reporting period.
For the demonstration test, give the vendor a real or anonymised version of your most complicated ownership event from the last three years - a disposal partway through a period, or a step acquisition that moved a subsidiary from associate to controlled. Ask them to model it live. Watch how the system calculates the gain or loss, adjusts the minority interest, and restates comparatives. A system that requires manual override at every step is a manual system with a better interface.
How should a system handle currency translation and the CTA?
The system must apply your chosen translation method - closing rate for balance sheet items, average rate for income statement items, historical rate for equity - consistently across every entity and every period, and accumulate the resulting currency translation adjustment in equity with a clear audit trail back to the source movements.
For the test: load a subsidiary with a functional currency different from your presentation currency, run a period with a rate movement, and ask the vendor to show you where the CTA lands, how it is split between the group and the minority interest, and what happens when that subsidiary is disposed of and the CTA is recycled through the income statement. A system that cannot answer that question cleanly is not ready for a multi-currency group.
What does intercompany matching and elimination require?
The system must identify, match, and eliminate intercompany balances and transactions automatically, flag mismatches before they reach the consolidated statements, and route them to the correct entity teams for resolution. For a detailed treatment of why this step sits at the centre of the close, see why intercompany reconciliation matters.
For the test: give the vendor a data set that includes an unmatched intercompany payable, an intercompany sale with a margin in closing stock, and a loan with interest that the two sides have accrued on different bases. Ask them to demonstrate matching, the unrealised profit elimination, and the workflow that tells both entities what to correct.
How does the system handle different charts of accounts across the group?
The system must map multiple local charts of accounts to a single group chart without forcing every subsidiary to adopt the group structure in its own ledger. It must also maintain separate reporting hierarchies for statutory and management views so that a line in the statutory income statement can be traced to a different cut in the management pack without a manual recode. The full treatment of this problem is at consolidating entities with different charts of accounts.
For the test: take two subsidiaries that use materially different local account structures and ask the vendor to load both, apply the group mapping, and produce a consolidated statutory face alongside a management view with a different line structure - without touching either local chart.
What do journals, top-side adjustments, and audit trail require?
The system must allow authorised users to post consolidation journals - acquisition accounting, fair value adjustments, top-side reclassifications - and must record every entry with a preparer, approver, timestamp, and narrative. The audit trail must be uneditable and must survive a period close.
| Requirement | What 'must have' looks like | How to test it |
|---|---|---|
| Journal entry | Preparer and approver are separate roles; journal cannot post without approval | Log in as preparer, post a journal, confirm it sits in pending until a second user approves |
| Audit trail | Every field change is logged with user and timestamp; log cannot be deleted or amended | Post a journal, attempt to delete it, show the log entry persists |
| Narrative | Free-text memo is mandatory before posting | Attempt to post without a memo; system should reject |
What close calendar and workflow capability does the system need?
The system must support a defined sequence of tasks across the close - entity submissions, intercompany matching, consolidation runs, review and sign-off - with dependencies that prevent a downstream step from running until upstream steps are complete, and with visibility of status across all entities in one view.
For the test: configure a simplified version of your actual close calendar - three entities, four task types - and ask the vendor to demonstrate what the group controller sees in real time, and what happens when one entity is late.
What are the requirements for data feeds from multiple ERPs?
The system must be able to ingest trial balance data from every ERP and source system in the group, accommodate the fact that some will send account-level balances and others will send transactional detail, and handle different period calendars where subsidiaries close on different dates.
For the test: provide anonymised trial balance files from at least two different ERPs currently in the group - different formats, different account structures, different period conventions. Ask the vendor to load both and produce a combined consolidated output without manual intervention on the files.
How much history must the system carry?
The system must hold the volume and granularity of historical data that your audit, statutory, and management reporting obligations require, including restated comparatives. For a full discussion of what to carry forward and what to leave behind, see consolidation system migration: how much history.
Does the system need to handle sustainability data within the same consolidation boundary?
Yes, and this is now a legal requirement for groups in scope of CSRD. Commission Delegated Regulation (EU) 2026/1563 - the revised European Sustainability Reporting Standards - states that the sustainability statement 'shall be for the same reporting undertaking as for the financial statements' (EUR-Lex OJ:L_202601563). The finance consolidation boundary and the sustainability reporting boundary must therefore be the same. For the finance-owned implications, see CSRD consolidation: the finance problem.
What security and segregation of duties does the system need?
The system must enforce role-based access at entity, data, and function level: an entity controller must not be able to see data from a peer entity; a preparer must not be able to approve their own work; a read-only auditor role must exist. Document your current segregation requirements before the demo and ask the vendor to demonstrate that the permission model can mirror them exactly.
How should you run the demonstration?
A demonstration on vendor-supplied sample data answers the question of whether the system works in general. The question you need answered is whether it works on your group's particular cases. Run the demonstration on your own data - anonymised where necessary. Bring the people who will operate the system, not only the people procuring it. Give the vendor your awkward cases in advance: the disposal mid-year, the dual-stack ERP environment, the subsidiary with a non-standard chart of accounts. A system that produces consolidated statements cleanly on clean sample data may still fail on the cases that consume most of your close time.
Score each section of this checklist after the demonstration: clear pass, conditional pass with a workaround the vendor must document, or fail. A conditional pass that requires a workaround on your most common scenario is a risk that belongs in your business case, not a footnote.
What should you do before writing these requirements?
Benchmark your current finance function's maturity before committing requirements to paper - it clarifies where the consolidation problem sits relative to the rest of the office of the CFO, and gives you a baseline against which to measure improvement. Start at the Finance Value Score. Once requirements are agreed, plan the project: realistic timelines are covered at how long consolidation system replacement takes.
Common questions
What is a consolidation system requirements checklist?
A consolidation system requirements checklist is a structured list of capabilities a group consolidation platform must demonstrate, organised by functional area: entity and ownership structure, currency translation, intercompany elimination, chart of accounts mapping, journals and audit trail, close workflow, data feeds, history, sustainability boundary, and security. The checklist is written by the group before vendor contact, based on the group's own structure, and each requirement is tested on the group's own data during a demonstration.
What is the most important starting point for consolidation system requirements?
The lowest level of data at which the group needs to consolidate and report determines every other requirement. Document the entity count, account grain, and non-financial dimensions before writing any feature requirement. A system that cannot hold data at that grain will fail the group regardless of its other capabilities.
Why must a consolidation system handle mid-year ownership changes?
Groups that acquire, dispose of, or restructure entities mid-period need a system that can calculate acquisition-date fair values, time-apportion results, adjust minority interests, and restate comparatives within the same platform. A system that requires manual intervention for each ownership event is a source of error and audit risk at every close where a structural change occurs.
Does a consolidation system need to handle sustainability data?
For groups in scope of CSRD, yes. Commission Delegated Regulation (EU) 2026/1563 - the revised ESRS - requires that the sustainability statement cover the same reporting boundary as the financial statements. The consolidation system, or a directly connected platform, must therefore apply the same entity perimeter to sustainability data as to financial data.
How should a group run a consolidation system demonstration?
Run the demonstration on the group's own data, including its most structurally complicated cases - mid-year disposals, dual-ERP environments, subsidiaries with non-standard charts of accounts. The people who will operate the system should be present and, where possible, at the keyboard. Score each requirement area as a clear pass, a conditional pass with a documented workaround, or a fail.