Part of the Finance systems at end of life series.
A consolidation system business case fails at the board when it is built around licence-cost comparisons rather than the cost of the problem being solved. The sequence that works is: baseline first, process diagnosis second, benefit sizing third, then - and only then - system selection.
What baseline data do I need before I talk to a single vendor?
The baseline is the foundation of the entire case: without it, every benefit claim is a vendor's estimate rather than your own evidence. Capture four things before any system conversation begins.
Days to close. Record your group consolidated close time end-to-end, from period-end to board pack sign-off. Track it across at least four periods so the board sees the average and the variance, not just a good month. Variance is often more damaging than a long average - it signals that the process is fragile.
Effort in hours. Log the total finance hours consumed per close cycle across all entities, including manual reconciliations, intercompany eliminations, journal corrections and rework. This converts days on a calendar into capacity on a headcount plan.
Error and restatement history. Catalogue every material restatement, audit adjustment and management-account correction over the past two to three years. The pattern of where errors originate - which entities, which eliminations, which manual steps - is the most persuasive slide in the deck. It is also the one that auditors and NEDs understand immediately.
Key-person dependency. Map how many people in the team can run the end-to-end consolidation unsupported. If the answer is one or two, document that explicitly. Key-person risk is a governance issue, not just an operational one, and boards take it seriously once it is named.
These four data points define your current maturity level on the Finance Value Score Maturity Matrix. Use them as the 'as-is' anchor for every benefit claim that follows. Our finance function benchmarks give you the comparator figures to measure your baseline against.
How do I know if this is a process problem or a software problem?
The most common reason consolidation business cases are rejected - or succeed and then disappoint - is that the root cause was a process problem, not a technology problem. Buying a system to fix a broken process automates the broken process.
Run a structured diagnostic before the system selection begins. Ask: if you had unlimited spreadsheet capacity and no system constraints, could a competent team run this close cleanly? If the answer is no, the problem is process design - unclear ownership, inconsistent chart of accounts across entities, undisciplined intercompany matching, or absent close calendars. None of those are solved by a new platform; they must be resolved before implementation, or the implementation will inherit them.
If the answer is yes - the team understands the process but the tooling prevents them from executing it efficiently - then the problem is genuinely a software constraint. That is the only condition under which a system replacement is the correct first move.
Boards ask this question even when you do not raise it. Pre-empt it with a one-page process assessment in the appendix showing which problems are process-driven (and how they will be addressed) and which are system-driven (and how the new platform resolves them). This is what turns an IT spend request into a finance transformation case.
How do I size the benefit in terms a CFO can defend?
The benefit case should be denominated in four currencies that a CFO can stand behind in a board meeting: cycle time, assurance, capacity released, and risk retired. Licence-cost comparisons do not belong in the executive summary.
Cycle time. State the target close duration in days and describe what that enables - earlier board packs, faster management decisions, better investor-relations cadence. If your current close is materially longer than peer-group benchmarks, the gap is the opportunity. Finance Value Score benchmarks provide the comparator.
Assurance. Quantify the number of manual touch-points where errors have historically originated. A reduced error rate translates directly into audit fee risk, restatement cost, and CFO time spent on explanations rather than analysis. If your restatement history shows a recurring pattern, the cost of that pattern - in hours, in audit scope, in delayed sign-offs - is a legitimate line in the benefit case.
Capacity released. Convert the hours saved per close cycle into a full-time-equivalent figure, then describe what that capacity will be redeployed on. Boards respond to 'two analysts shifted from close to FP&A' more readily than they respond to an abstract efficiency percentage. Do not overstate; describe the shape of the release and let management confirm the redeployment plan.
Risk retired. Quantify key-person dependency explicitly. If one departure would materially impair the close, that is an operational risk with a cost - recruitment, interim cover, audit delays. The business case should name it and describe how the new operating model reduces it.
What does a realistic implementation timetable do to the case?
A realistic timetable strengthens the case rather than weakening it, because it prevents the board from approving a benefit profile that collapses on first contact with delivery. State the implementation phases plainly: data migration and chart-of-accounts harmonisation, parallel-run period, cutover, and the stabilisation period before full efficiency is achieved.
Benefits do not start on go-live day. A parallel-run phase, by definition, increases short-term effort before it reduces it. The board needs to understand the J-curve: additional cost and resource demand during implementation, then the realisation of the benefit case once the team is running confidently on the new platform.
If your organisation has recently completed an acquisition or is mid-integration, factor that into the timetable explicitly. Consolidation system implementations during entity restructuring carry higher execution risk, and the business case should reflect that honestly rather than assume a clean run.
The three outputs a sound business case delivers align directly with the Finance Value Score model: a maturity diagnosis (the Matrix), a scored view of where the function stands today, and a costed gap to the level-5 AI-embedded frontier - the value at stake, in pounds. That structure is what makes the case board-ready.
Common questions
What is the most common reason a consolidation system business case is rejected by the board?
The most common reason is that the case is built around licence-cost comparisons rather than the cost of the problem being solved. Boards approve investments when the benefit is expressed in terms they can defend - cycle time, assurance, capacity released and risk retired - not when the case rests on a vendor price comparison. Establishing a robust baseline before any system is discussed is the structural fix.
How do I establish a baseline for a consolidation business case?
A sound baseline captures four things: days to close (average and variance across multiple periods), total finance effort in hours per cycle, a log of errors and restatements with their root causes, and a map of key-person dependencies. These four data points define your current maturity and anchor every benefit claim in your own evidence rather than vendor assertions.
How do I tell whether the consolidation problem is process or software?
Ask whether a competent team, given unlimited spreadsheet capacity, could run the close cleanly. If no - because ownership is unclear, the chart of accounts is inconsistent, or intercompany matching is undisciplined - the problem is process design, not technology. Implementing a new system before fixing process errors embeds those errors in the new platform. Process problems must be resolved first; system replacement is the correct move only when the tooling is the genuine constraint.
How should I account for implementation time in the benefit case?
Benefits do not start on go-live day. A parallel-run period increases short-term effort before reducing it, and stabilisation takes additional time after cutover. The business case should model the J-curve explicitly - showing the period of higher cost before the benefit is realised - so the board approves a realistic profile rather than one that collapses at the first programme review.
What comparator data should I use when sizing the benefit?
Use finance-function benchmark data to compare your close duration, effort and error rates against peer-group norms. The gap between your current position and the benchmark is the opportunity; the gap between your current position and the level-5 AI-embedded frontier is the full value at stake. Finance Value Score benchmarks are built for exactly this purpose and give you defensible, external comparators for the board pack.