Why transformation benefits get counted twice, and how to stop it

Take an illustrative program with two initiatives. A procurement workstream renegotiates packaging prices and claims the saving as the price reduction multiplied by forecast volume. A warehouse workstream changes carton sizes, uses less packaging per order and claims the saving as units avoided multiplied by the old price. Both claims land on the same ledger account. Added together they can exceed the movement the management accounts show, without anyone making an error inside their own workstream.

The pattern repeats across most programs. An automation initiative claims hours freed in finance while a shared-services initiative claims the same team's cost. A pricing initiative claims margin that a shift in product mix delivered. A supplier consolidation claims a rebate the budget already assumed. Each benefit case was approved on its own merits, and each owner reports progress against their own baseline. The program total is the sum of the claims, and the sum of the claims is larger than the change in the profit and loss account.

Nobody notices until someone compares the benefits report with the ledger, which in many programs happens at the year-end review, after the money has been spent and next year's budget has already absorbed savings that never arrived.

Benefits registers are normally organized by initiative. Each row is a workstream with its benefit, owner, baseline, target and status. That layout answers the first question a program board asks, which is whether each workstream is on track. It cannot show whether two rows describe the same money, because the account the money sits in is not a column.

Published benefits guidance names the problem. The APMG Managing Benefits material gives, as one reason for a portfolio view of benefits, minimizing double counting where the same benefits are claimed by, and used to justify, more than one initiative. The UK Infrastructure and Projects Authority's 2017 guide for major projects separates cash-releasing benefits, which reduce a budget, from non-cash-releasing benefits, which produce an efficiency without necessarily reducing a budget. It also asks for each benefit to be baselined during project initiation, before implementation affects performance.

Private-sector programs often skip both disciplines. Hours freed are converted to pounds at a loaded rate and added to cash savings in one total, although the hours become cash only when a cost line falls: headcount, overtime, agency or contractor spend. Baselines are taken at different times by different owners, so one initiative measures from last year's actuals and another from this year's budget.

The fix is to build the register by ledger line instead of by initiative. Each row is a general ledger account, or a cost center and account pair, that at least one initiative expects to move. Each column is an initiative, and each cell holds that initiative's claim on that account.

Two rules then apply. The first is a cap. The sum of claims on an account cannot exceed the measured movement in that account after adjusting for volume, price and currency. If packaging spend fell by less than procurement and the warehouse claim together, the claims are cut back to the movement under an attribution rule agreed before the work started. The second is a cash test. A benefit counts as cash-releasing only when an account in the ledger shows the reduction. Hours freed stay in a separate capacity column until a decision converts them into a lower cost line or into documented extra output.

The IPA guide describes an organization that introduced signed benefits contracts. Once a contract was signed the benefit was booked and, where it was cash-releasing, finance removed the money from all future budgets. A ledger-based register makes that step routine. The saving leaves the 2027 budget line at the moment it is claimed, and an owner who claims it twice is asked to fund it twice.

The cap works only if the movement in each account is measured the same way every month. Three adjustments do most of the work.

Volume comes first. A cost account that falls because the business shipped fewer orders has not benefited from any initiative, so the baseline is restated at actual volume before anything is attributed. Price comes second. Where an input follows a market price, such as freight, energy or a commodity, the baseline is restated at the current index, so a falling market is not booked as a procurement win and a rising one does not erase a real saving. Currency is the third, for any account with spend in a foreign currency.

The attribution rule for shared accounts has to be agreed before the initiatives start, because afterwards every owner has a reason to prefer a different one. Under sequential attribution the first initiative to deliver keeps its full claim and later ones are measured against the new run rate, which is easy to audit. Proportional attribution splits the movement by each initiative's forecast share. Either can work. Switching rules halfway through a program does not.

In practice the transformation office becomes a monthly reader of the ledger. After the month-end close, finance publishes the adjusted movement for every account in the register. The office applies the cap and the attribution rules, and the benefits report is generated from those figures rather than from owner updates. Owners still report milestones, but a milestone does not move the benefits total. Only the ledger does.

The same principle governs the work itself. Initiatives are written as tasks with acceptance criteria that can be checked in a live system: the warehouse log shows the new carton mix on every order, the purchase ledger shows invoices at the new price, the payroll file shows the agency line closed. A task closes when the system shows the change. This is how we run transformation work, and it is why the team that designs an initiative also builds the integration, automation or reporting it depends on, so the measure and the mechanism stay together.

Specializt partners join where an initiative needs depth in a particular ERP or a local-language rollout. The register, the attribution rules and the monthly reading of the ledger stay with one accountable team.

In November 2026, before 2027 budgets are locked, freeze one baseline per affected account from the latest twelve months of actuals, restated for volume, price and currency, and record the date and the method.

In December, rebuild the benefits register by ledger line, agree the attribution rule for every account touched by more than one initiative, and take claimed cash-releasing savings out of the 2027 budget lines they belong to.

From the January 2027 close, publish the benefits total from the ledger each month, with capacity benefits in a separate column that is never added to cash.

By the end of March, review every benefit that has not appeared in its account after a full quarter of delivery, and either show the mechanism that will move it or retire it from the case.

In June, report the half-year to the board as adjusted ledger movement against the frozen baseline, and set second-half targets from that figure rather than from the original business cases.