Part of the Replacing a consolidation or planning system: the complete guide series.
A group that has never had a consolidation system faces a specific problem: there is no end-of-support notice, no incumbent product to replace, and no obvious forcing event. The decision drifts until someone - usually a vendor - frames it for you. That framing tends to reflect what the vendor sells. This page is for the finance director who wants to frame it first.
You have decided to move - what now?
If you are still weighing whether the moment is right, the signs that a group has genuinely outgrown spreadsheet consolidation are covered in detail at outgrown spreadsheet consolidation: the signs and at outgrowing your systems. This page starts where those end: you have decided to act, and the question is how to specify what you are buying.
What does a first consolidation system have to do on day one?
A first consolidation system must be able to run the eliminations and FX translation rules your group already applies, handle entity and ownership changes, and produce a clear audit trail from each entity trial balance to every group line - and nothing more is required at the outset.
That list is shorter than most vendor demonstrations imply. Intercompany elimination - loans, trading balances, dividends - is the mechanical core. FX translation needs to follow the policy you already use: closing rate for the balance sheet, average rate for the income statement, and the translation reserve treated consistently. Entity and ownership changes matter even for relatively stable groups: a disposal or a mid-year acquisition will happen, and the system needs to handle the arithmetic without a manual workaround. The audit trail requirement is non-negotiable for any group subject to external audit: an auditor should be able to trace every consolidated number back to a specific entity submission without relying on your memory of how the spreadsheet was built.
That is day-one scope. Allocations, intercompany profit elimination on inventory, minority interest waterfalls, and sophisticated planning integration are real needs for some groups - but they are not day-one needs for a group migrating off Excel for the first time. Scope creep at requirements stage is how implementations become slow and expensive. Agree the day-one list in writing before a single demonstration.
What stays in Excel - and should?
Analysis, one-off board schedules, and the model the CFO actually thinks in should stay in Excel because a consolidation system is not a thinking tool.
A consolidation system is a controlled production environment. It runs the same rules every period and produces numbers an auditor can follow. It is not the right place to build the bridge analysis that explains why revenue moved, or the scenario the board asked for on Thursday afternoon, or the three-year model that the CFO uses to test strategic assumptions. Those outputs need flexibility, speed, and the ability to change a formula without a change-control process. Excel is the correct tool for them. The migration goal is to move the mechanical consolidation into a controlled system - the analytical layer stays where it already works.
What should you fix before migrating?
Two things need to be resolved before any data moves: the group chart of accounts and the intercompany matching rules.
If your entities report on different local charts of accounts, the mapping to the group chart must be documented and agreed before migration - not discovered during it. A system can only be as clean as the mapping you feed it. The practical decisions involved are covered at consolidating entities with different charts of accounts. Separately, intercompany eliminations only work if both sides of every transaction are identified and matched. If your current process relies on email chains and manual reconciliation, migrating that process into a system produces faster manual reconciliation, not clean eliminations. The discipline required is explained at why intercompany reconciliation matters. Fix both before you go to market, because any vendor who sees unresolved mapping and intercompany chaos will scope the implementation around it - at cost to you.
A broader guide to the decision to replace a finance system sits at replacing finance systems if you need the wider context.
How do you tell a demo from your actual requirements?
Run last quarter's hardest consolidation through the system during the demonstration - not a vendor-supplied dataset.
Every consolidation system looks capable when it runs clean, pre-loaded data. The test that matters is your data, your ownership structure, and the period that caused the most pain last quarter. If there was a mid-year acquisition, test that. If there were disputed intercompany balances that took three rounds of email to resolve, show the system the problem and ask how it surfaces and resolves the difference. Ask where the audit trail lives for that specific adjustment. If the vendor needs additional time to set up your scenario, that is useful information. A system that handles your hardest period cleanly is worth more than a system that handles any period elegantly in a controlled environment.
Prepare your requirements list before the first meeting. A vendor demonstration is a sales event; your requirements list is a specification. They are not the same document, and the vendor's agenda should not be allowed to become yours.
How do you benchmark your current state before you commit?
Before signing anything, establish an honest baseline of where your finance function stands today - because the business case for any system depends on understanding the gap it closes.
The Finance Value Score exists for exactly this purpose: it produces a structured view of your current maturity across consolidation, close, and reporting, and expresses the gap to a higher level of capability in pounds. Run it before any procurement decision so the business case is yours, not the vendor's. Start at the value report overview.
Common questions
What must a first consolidation system be able to do on day one?
A first consolidation system must handle the intercompany eliminations and FX translation rules the group already applies, accommodate entity and ownership changes, and produce an audit trail from each entity trial balance to the consolidated group number. Those are the day-one requirements. More complex features - such as intercompany profit elimination on inventory or sophisticated minority interest waterfalls - are real needs for some groups but are rarely required at the point of first migration off Excel.
What is the right way to test a consolidation system before buying it?
The most reliable test is to run the previous quarter's hardest consolidation through the system using your own data and your own ownership structure, not a vendor-supplied dataset. Ask specifically how the system handles the period that caused the most pain, and trace the audit trail for a specific adjustment from entity submission to consolidated number. A system that handles your most difficult scenario cleanly is more reliable evidence than any demonstration using clean, pre-loaded data.
What should stay in Excel after a group moves to a consolidation system?
Analysis work, one-off board schedules, and strategic models should remain in Excel after a group consolidation system is implemented. A consolidation system is a controlled production environment designed to run repeatable rules consistently and support audit. It is not a flexible analytical tool. The goal of the migration is to move the mechanical consolidation process into the system, not to replace every spreadsheet in the finance function.
What data problems should a group fix before migrating to a consolidation system?
Two problems need to be resolved before migration: the mapping between entity-level charts of accounts and the group chart of accounts, and the rules for identifying and matching intercompany transactions. Migrating unresolved mapping or undisciplined intercompany processes into a system does not fix them - it embeds them in a more expensive environment. Both need to be documented and agreed before any vendor is engaged, because unresolved data problems will be scoped into the implementation at the group's cost.
Why do groups without an existing consolidation system tend to make the move late?
Groups that have always consolidated in Excel have no end-of-support deadline and no incumbent vendor relationship to prompt a review. The trigger is usually pain - audit queries, a failed close, a new acquisition - and the decision is often framed by whoever is selling at the time. Without an internally defined set of requirements, the vendor's product features tend to become the specification by default, which rarely produces the tightest or most cost-effective scope.