Savings Validation: Prove the Benefit Is Real, Auditable and Still Recurring

Savings Validation sits in the Sustain phase of RDMAICS. Its job is stated plainly in the product: validate reported savings with finance to confirm they are real, auditable, and recurring.

Improvement teams report savings at handover. Finance owns the ledger. The gap between those two views is where credibility is lost. A project can be celebrated in a steering meeting and never appear in a budget line. Savings Validation closes that gap by forcing a named validator, a named method, and a validated amount for every item you claim.

Use the tool after the Control phase, once the new process has run long enough for finance to see it in the numbers. Then use it again. The value of this tool is not the first pass. It is the second and third pass, months after handover, when the validated amount tells you whether the improvement is still alive.

Treat it as a standing review rather than a sign-off form. A number that validated in full at month three and falls short at month nine is telling you something the control chart may have missed.

This guide uses the sample data built into the tool. The case is fictional, and the figures exist only to show how the tool behaves.

The scenario is a finance operations improvement. Four savings items were reported after handover, totalling $121,000. Each one was put to finance for validation with a stated method of proof.

The items are a labour cost reduction of $92K, late-payment penalties of $16K, duplicate avoidance of $8K, and early-payment discounts of $5K. The labour item was validated by the Finance Controller. The other three were validated by Finance.

That mix is typical. One large item carries most of the benefit. Three smaller items carry most of the argument. The tool treats all four the same way, which is the point.

The table takes one row per savings item. Five fields are mandatory: the savings item, the reported amount, who validated it, the validated amount, and the status. Method is the sixth column and is not marked mandatory, but it carries most of the weight in an audit.

Method is where you record how finance proved the number. In the sample data, the labour cost reduction was checked by payroll comparison. The late-payment penalties were checked against the penalty log. Duplicate avoidance was checked by payment audit. Early-payment discounts were checked against a discount report.

Notice what those methods have in common. Each one points to a source a third party could open and re-run. Payroll comparison is a document. A penalty log is a record. A payment audit is a procedure. None of them is an estimate or a model.

Status is the field that carries the judgement. Three items in the sample data are marked Validated. One is marked Validated (adjusted). That second status is the useful one. It records that finance accepted the item but disagreed with the amount, and it preserves that disagreement in the record rather than quietly overwriting the reported figure.

The tool calculates five outputs from the table. Reported total is $121,000. Validated amount total is $120,000. Validated share of reported is 99.2 per cent. Validated in full is 3 of 4. Adjusted is 1.

Below the totals the tool breaks each item down against plan. Labour cost reduction sits at 100.0 per cent of plan, planned $92K and actual $92K. Late-payment penalties sit at 93.8 per cent of plan, planned $16K and actual $15K. Duplicate avoidance and early-payment discounts both sit at 100.0 per cent of plan.

The summary line names the single adjustment directly: late-payment penalties moved from $16K to $15K, with the penalty log as the method. One sentence, one item, one method. That is what an auditor wants.

The tool also offers an AI review that explains the result in plain language. Read it, but read the per-item breakdown first. The per-item view is where the slippage shows.

A validated share of 99.2 per cent reads as a healthy result. It is. But the number on its own is not the signal. The signal is the direction of travel across repeat validations.

Watch the validated in full count. In the sample data it is 3 of 4. If that drops to 2 of 4 at the next cycle, something has changed in the process, not in the paperwork. Items fall out of full validation when the behaviour that produced them stops happening.

Watch the adjusted count the same way. One adjustment is a rounding argument. A rising adjustment count means finance is finding gaps faster than the team is closing them.

Watch the per-item percentages, not just the total. The late-payment penalties item is the only one below 100.0 per cent of plan. A large item at 100.0 per cent can hide several small items drifting underneath it, because the total is dominated by the $92K labour line. Read every row.

The first decision is whether to release the benefit into the budget. A validated amount with a named validator and a named method is defensible. A reported amount without those is not. In the sample data, $120,000 has that backing.

The second decision is where to spend audit effort next cycle. The sample data points at one item. Late-payment penalties validated at $15K against $16K reported. That is the row to re-check first, because it is the only row where the reported and validated figures diverged.

The third decision is whether the improvement still needs an owner. Items validating in full across repeat cycles can move to routine monitoring. Items that keep getting adjusted need the owner to stay in place.

The fourth decision is about estimating. If your reported figures keep landing above validated figures, your estimation method needs work before the next project, not after.

The most common mistake is letting the project team validate its own savings. Every validator in the sample data is a finance role. That is deliberate. Self-validation produces a number nobody outside the team will defend.

The second mistake is leaving the method field blank because it is not mandatory. A validated amount with no method is an assertion. It will not survive an audit and it will not survive a change of finance staff.

The third mistake is adjusting the reported column instead of using the adjusted status. If you had edited the late-payment penalties row from $16K down to $15K, the result would show 4 of 4 validated in full and zero adjustments. The slippage would disappear from the record.

The fourth mistake is validating once. A single pass tells you the saving landed. It does not tell you the saving recurs. Recurrence is the whole purpose of the Sustain phase.

Savings Validation records a judgement. It does not make one. The tool will accept whatever validated amount you type. If a validator signs off without checking the payroll comparison, the tool will still report 100.0 per cent of plan. The discipline lives in the method column, not in the arithmetic.

The tool does not test whether a saving is recurring. It captures the validated amount at a point in time. Recurrence only becomes visible when you run the validation again and compare. The tool does not do that comparison for you.

It does not distinguish cash savings from cost avoidance. Duplicate avoidance at $8K and labour cost reduction at $92K appear in the same total. Those two have different effects on a budget. Your finance function needs to make that distinction outside the tool.

It does not trace causation. The tool cannot tell you whether the $92K labour cost reduction came from your improvement or from an unrelated change in headcount. It records that finance validated the amount by payroll comparison. Attribution is a separate conversation.

Finally, it does not detect a saving you never reported. The totals are bounded by what you entered. A validated share of 99.2 per cent means 99.2 per cent of the four items in the table, not 99.2 per cent of everything the process produced.