Broken or delayed? Why an S/4 programme's real diagnosis starts with the numbers, not the backlog.

Two problems that look identical from the outside

From the steering committee's seat, a delayed S/4 programme and a broken one send the same signals: dates slipping, a backlog that keeps growing instead of shrinking, and a delivery partner asking for more time, more budget or more people. Every one of those signals is consistent with "we're behind schedule," and every one of them is also consistent with "the underlying design doesn't work" — which is exactly why the two get confused, and why the standard response to both tends to be the same: add capacity and extend the timeline.

That response is often right for a delayed programme. It is close to never right for a broken one.

The test that tells them apart

A programme is delayed when the scope and the timeline have slipped but the underlying finance design — chart of accounts, CO structure, the CO–FI bridge, the consolidation and RAR logic — is sound. Once implementation catches up, the close holds, controlling trusts the numbers, and the backlog was genuinely the constraint.

A programme is broken when even catching up on the backlog would not fix it, because the close does not hold on the design that exists today — regardless of how much of it has been built. More implementation capacity delivers more of a design that does not close cleanly, faster. That is the tell: does finishing the plan as written fix the close, or does the close need to be redesigned before finishing the plan means anything.

If S/4 Finance doesn't close clean, the system isn't the problem — the programme is. Recovery starts with the numbers, not the backlog.

Why "more capacity" makes a broken programme worse

Recovery is not sold on an ROI calculator, and for good reason: the value of fixing a broken finance design is qualitative, not something a spreadsheet projects cleanly in advance. What a steering committee is actually buying when it approves "more capacity" for a programme that is genuinely broken is more of the same chart of accounts, the same CO structure, the same consolidation logic — built out further, on the same foundation that does not close. The backlog shrinks. The close still doesn't hold. The next status report looks better for one cycle and worse for the two after that.

The alternative is not automatically "start over." It is a defined diagnosis that establishes, before any more capacity gets committed, whether the foundation itself needs to change.

What a finance-led diagnosis actually checks

Chart of accounts and CO structure — designed, or inherited

A chart of accounts and a controlling structure that were copied from a template, a prior system, or a different business unit will run — right up until profit-centre hierarchies, allocations and margin analysis need to answer a real management question. The diagnosis asks whether the structure was designed for this group's reporting reality, or inherited and never revisited.

Consolidation and RAR — will the group close survive audit

Group Reporting, intercompany elimination, currency translation and — where contract revenue is involved — RAR logic under IFRS 15 / ASC 606 either produce a statutory close that holds up to audit scrutiny or they don't. This is usually where a "delayed" programme reveals itself as "broken": the entity-level books look fine, and the group-level number still doesn't reconcile, for reasons nobody in the programme can fully explain.

Programme governance — one accountable line, or diffuse vendor accountability

A programme where finance, IT and the delivery partner each have a different account of why the close doesn't hold is a governance problem as much as a technical one. Part of the diagnosis is establishing whether there is one line of accountability from the CFO down into the finance workstreams, or whether "whose fault is it" has become a standing agenda item.

The questions that separate delayed from broken

A structured diagnostic conversation tends to answer a small set of questions that, taken together, are more reliable than any single status report:

• Does the period-end close run inside the system, or does it depend on spreadsheet patchwork that only one or two people fully understand?
• Can consolidation and RAR figures be traced back to source transactions without someone reconstructing the logic from memory?
• Has the delivery partner relationship already lost the CFO's trust, or is the friction still about scope and timeline?
• Is the current backlog the actual constraint, or is it a symptom of a design decision made earlier that nobody has revisited?

A programme facing a new S/4 implementation in standard scope, without this kind of finance-depth complexity, is usually better served by a standard delivery partner — recovery is a different conversation for a different situation, not a universal upgrade on regular implementation work.

What stabilization looks like once the diagnosis says "broken"

A recovery engagement is framed as a defined intervention, not an open-ended augmentation: a diagnosis, a realistic re-baseline agreed between CFO, programme and vendors, senior hands-on stabilization of the FI, CO, Group and RAR workstreams until the close actually holds, and a deliberate hand-over back to an internal team once it does. The exit is part of the design from the start, not an afterthought once the invoices stop looking justified.

What this means for a CFO facing the ask for "more capacity"

The next time a steering committee is asked to approve more time, more budget or more people for a programme that keeps missing dates, the question worth asking first is not "how much more do we need" — it is whether the close would actually hold if the current plan were finished exactly as written. If the honest answer is no, the conversation that follows should be about the finance design, not the headcount.