Part of the Replacing a consolidation or planning system: the complete guide series.
A consolidation system replacement takes as long as the group's own reporting cycle demands - and the project cannot be shorter than the closes it has to prove itself through. The two fixed points that determine everything else are the prior-year closing balance the new system must reproduce so that opening balances agree, and the first live close it must survive without the old process running in parallel.
What are the two fixed dates that define the whole programme?
The prior-year closing balance is the first fixed point. Every entity's opening position in the new system must reconcile to the audited close before testing is meaningful. If that date is not named in the project plan, the testing phase has no anchor. The first live close is the second fixed point. This is the date by which the new system must be operational enough to produce a result the board will sign off. Every phase, every resource plan, and every dependency in the project schedule works backwards from these two dates. A plan that offers a duration in months without naming both dates is describing a sales estimate, not a delivery commitment.
What are the phases, and which can overlap?
The sequence has a structure that the software does not change. Requirements and design come first, and they must be substantially complete before build can begin - there is no useful overlap here, because building against incomplete requirements produces rework. Chart of accounts and mapping work sits alongside design but must be finished before build can be tested; a system tested against a provisional chart will need retesting once the chart is finalised, which wastes parallel-run capacity. Build follows, and this is the largest single block of effort. Data and history loads can begin in parallel with the later stages of build, provided the chart work is locked. Testing follows build; it cannot run meaningfully against an incomplete system. Parallel closes - where both the old and new processes run against the same period - follow successful testing. Go-live and hypercare close the sequence.
The phases that can overlap with care are: history loads running alongside late build, and user acceptance testing beginning while the final build items are being signed off. The phases that cannot overlap without creating rework are: requirements with build, chart and mapping work with testing, and the parallel close period with any substantive system change. Introducing changes to the consolidation logic during a parallel close destroys the evidential value of the run.
What stretches the calendar in practice?
Three factors lengthen projects reliably. The first is the number of legal entities and source ledgers. Each additional ledger adds mapping work, intercompany elimination rules, and currency translation logic that must be built, tested, and signed off. Groups running several ERP instances in parallel face a multiplier on the chart and mapping phase that is often underestimated at the outset. The second factor is data quality. If the trial balance extracts from the source systems are inconsistent in structure, currency coding, or intercompany reference, the data and history loads phase becomes iterative. Cleaning that data is work that falls on the finance team, and it competes directly with the normal close cycle. See the separate article on what history to bring across for guidance on scoping the load without extending the timeline unnecessarily. The third factor is subject-matter expert availability. Consolidation knowledge - the elimination rules, the minority interest logic, the statutory adjustments - lives in a small number of people in most groups. If those people are available only part-time, the build phase extends in direct proportion. This is the most common reason a consolidation project runs past its original go-live date.
What can the group's own team take on, and why does it matter?
The group's own finance team is the biggest single lever on cost and calendar. Reports, validation rules, data entry forms, and mapping tables are all areas where a capable finance team can take ownership with appropriate guidance, materially reducing the billable build effort and shortening the overall programme. This is not a minor optimisation - on complex group structures, the split between what is configured by the implementation partner and what is built by the internal team can move the total effort significantly. The team's capacity to absorb this work depends on how the project is phased relative to the close cycle, and on whether the business-as-usual consolidation workload has been accounted for in the resource plan. For a structured way to assess where your finance function currently stands before committing to a replacement programme, benchmark your current state first.
What does AIS's own delivered experience show?
On implementations AIS has delivered, a group consolidation of twenty to thirty entities across several ledgers runs to roughly a hundred build days and five to six months from contract signature to the first live close. The programme runs two parallel closes before the old process is switched off. Build accounts for approximately half the total effort across the full programme. These figures reflect groups with reasonable data quality and subject-matter experts who are materially available to the project. Groups with more entities, more source ledgers, or constrained internal resource should expect the calendar to extend. This experience is offered as a calibration, not a guarantee - the two fixed dates described above remain the only reliable anchor for any specific group's timeline.
How should a CFO pressure-test a vendor or partner timeline?
Ask the implementation partner to name the prior-year closing balance date and the target first live close date in the project plan. Ask which parallel close periods are included and what the exit criteria are for each. Ask where chart and mapping sign-off sits relative to the start of testing. If those questions produce vague answers, the timeline has not been built around the group's own reporting cycle. The replacing finance systems series covers the broader sequencing of a replacement programme, including how to structure the business case before going to market.
Common questions
How long does it take to implement a consolidation system?
The timeline is determined by the group's reporting cycle, not by the software. On implementations AIS has delivered, a group of twenty to thirty entities across several ledgers takes roughly five to six months from contract to first live close, with approximately a hundred build days. Groups with more entities, more source ledgers, or limited internal resource availability should plan for a longer programme.
What are the two fixed dates that drive a consolidation implementation plan?
The first is the prior-year closing balance date - the point from which opening balances in the new system must be reproduced and reconciled before testing is meaningful. The second is the target first live close, the date by which the new system must produce a result the board can rely on. A project plan that does not name both dates is a sales estimate rather than a delivery commitment.
Which implementation phases can run in parallel and which cannot?
History data loads can begin alongside late-stage build work, and user acceptance testing can overlap with final build sign-off. Requirements and design must be complete before build begins, and chart of accounts and mapping work must be locked before testing starts. Parallel closes - where both old and new processes run against the same period - cannot absorb substantive system changes without losing their evidential value.
What most commonly stretches a consolidation project past its planned go-live?
Part-time availability of the subject-matter experts who hold the consolidation logic - elimination rules, minority interest treatment, statutory adjustments - is the most common cause of delay. Poor data quality in source system extracts is the second. Both factors are knowable before the project starts, and a realistic resource plan should account for competition with the ongoing close cycle.
How can a group's own finance team shorten a consolidation implementation?
Finance teams that take ownership of reports, validation rules, data entry forms, and mapping tables reduce both the billable effort and the overall calendar materially. This is the largest controllable lever available to a group CFO. The practical limit is the team's capacity alongside the normal close workload, which the project schedule must plan for explicitly.