Group Reporting

The consolidation doesn't get a phased go-live

Three go-live waves across five regions, one entity on a non-calendar fiscal year, and a group close that still has to land every single quarter in between. The rollout phases. The consolidation does not.

CR Srini · Independent SAP S/4HANA Finance Architect

The client was already live on SAP S/4HANA Group Reporting. That is worth stating up front, because it changes the problem entirely. Nobody was building a consolidation. The consolidation existed, it worked, and it produced statutory numbers on a fixed calendar. What was changing was everything underneath it — the transactional systems feeding it, region by region, over roughly twelve months.

Entities sat in Asia, the Indian sub-continent, the Middle East, Europe and North America. One of them ran an April–March fiscal year while the group consolidated on the calendar year. Go-live was planned in three waves: August 2027, May 2028 and August 2028.

Look at those dates against a December year-end and the shape of the problem is immediate. Every one of them lands mid-year.

The temptation, and why we refused it

The instinct on a project like this is to switch each entity to the integrated method the moment it goes live. The wave is done, the data is in the universal journal, so release it to consolidation and move on. It feels like progress and it demos beautifully.

It also means that in August 2027 you are running two different collection methods inside a single reporting year for the same set of consolidation units — file-based for January to July, integrated from August onward. Every comparative, every rollforward, every variance investigation now has a seam in the middle of it. Auditors find that seam immediately, and they are right to.

That single rule drove the rest of the design. It is not a technical constraint — S/4HANA will happily let you switch mid-year. It is a comparability constraint, and comparability is the entire point of a consolidation.

What that means in practice

If a unit's fiscal year is split across two systems, that whole year is submitted by file. Not the legacy portion by file and the S/4HANA portion by release — the whole year, one method, from a trial balance assembled outside the consolidation. The integrated release from the universal journal is switched on effective period 001 of the first fiscal year the unit spends entirely on S/4HANA.

Applied to the three waves, that produces this:

FY2028 is the interesting row. Wave 1 is technically eligible to switch to the integrated method — it has a clean twelve months on S/4HANA. We recommended against it, and the client agreed.

Running one third of the group on release-from-journal while the other two thirds are still submitting files means the close team is operating two processes in parallel, on different timetables, with different failure modes, in the same period. During the most exposed year of the program. The gain is one year of slightly cleaner lineage for a third of the entities. The cost is a close team learning two methods at once while two go-lives are still in flight.

So: everything stays file-based through the end of FY2028. All three waves flip together at period 001 of FY2029. One change, one date, one set of parallel-run tests, one rehearsal.

The non-calendar entity is the genuinely hard one

Group Reporting consolidates by the group's fiscal year and period. A unit posting on an April–March local year has to be mapped onto that calendar for consolidation, and the mapping is where the thinking goes.

Its August 2028 go-live falls in month five of its local year, which began in April 2028 and runs to March 2029. That local year straddles two group calendar years. Which means that even in FY2029 — the group's first clean, fully integrated year — the opening position for that unit is carried out of a local fiscal year that was half legacy and half S/4HANA.

The unit's first fully clean local year does not start until April 2029, three months after the group has already declared itself integrated. Two calendars, two definitions of "clean," and they do not line up.

Our position: the group calendar governs consolidation, full stop. The unit submits on group periods throughout, the local fiscal year variant stays a local reporting concern, and the period mapping is documented and tested well before the first submission rather than discovered during a close. Separately, do not let anyone use the phrase "calendar period" in a design document without defining whether they mean the group's or the entity's. We had to unpick that ambiguity more than once.

The trap: year-to-date versus periodic

This is the one that nearly went unnoticed, and it is the reason the split-year rule has to be written down carefully rather than assumed.

A split-year design is naturally described in periodic terms: legacy movements for January to July, S/4HANA movements for August to December, stack them, submit the year. Clean and obvious.

But many groups load year-to-date trial balances into Group Reporting, not periodic movements. If that is how your data collection is configured, then every file submitted from period 008 onward has to carry the full cumulative January-to-date position — including the seven months that were never posted in S/4HANA. The new system simply does not hold them, unless the go-live migration loaded current-year profit and loss by period rather than an opening balance sheet alone.

Most migrations do not. Most load an opening balance sheet.

There are only two honest answers. Either migrate current-year profit and loss by period so the cumulative position exists in S/4HANA, or assemble the full-year trial balance outside the system and submit it whole. We took the second, which is exactly what the file-based interim already does — and that consistency is a large part of why the design held together.

Sequencing the rest

Two mechanics follow the same logic and should move on the same date as the method switch, not ahead of it:

• Currency translation and net income calculation. Run these on the new basis only once every unit is on one method. Introducing them while half the group is still file-based means debugging translation differences and collection differences at the same time, in a live close.
• Reconciliation, in both directions. The common failure is a one-legged tie-out: transaction data reconciled forward into the consolidation, with nothing checking the consolidated result back against source. Build both legs. During a phased rollout the back-leg is what catches a wave that quietly stopped submitting.

Add to that a defined legacy retention period — we set twenty-four months, read-only — because restatements and audit questions on FY2027 and FY2028 will arrive well after the last legacy system was due to be switched off. If nobody owns that decision, the systems get decommissioned on the infrastructure team's timetable, not finance's.

What to settle before you build

1. Is data collection periodic or year-to-date? Everything else depends on the answer.
2. Does the migration load current-year profit and loss, or only an opening balance sheet?
3. Which fiscal year is the first with every unit on the target system for all twelve periods? That is your switch date, and it is usually one year later than the plan assumes.
4. For any non-calendar entity, whose periods govern the consolidation — and is that written down?
5. How long does legacy stay readable, who pays for it, and who signs off switching it off?

None of these are exotic. All five are routinely left until the first close after go-live, at which point they are no longer design questions. They are incidents.