An audit report saves nothing. The execution does.

The report is on the table and it is correct. Unused licences, neatly lined up. Two tools that do the same thing. A maintenance contract that mostly pays for the past. Everything substantiated, down to the line. And still, next month's invoice arrives just as high as last month's. An audit finds the leak. It does not seal it.

That distinction sounds obvious, and yet in practice it almost always goes wrong. An audit delivers a finding: money leaks here, this can go. A saving is something else. A saving is a cancelled contract, a stream of duplicate work that is gone, a run-rate that stands lower than the month before. Between the two sits work that no report does for you.

Why a finding is not yet a saving

The scale of the leak has by now been measured. According to the Flexera State of ITAM report (2024), organisations waste 20% to 30% of their IT spend, and more than half of SaaS licences go unused. More than half. An audit exposes that, down to the licence. But an unused licence you find costs exactly as much as an unused licence you do not find, as long as no one cancels it.

With maintenance it is the same. McKinsey (2020) put technical debt at 20% to 40% of the value of the entire technology estate, and saw 10% to 20% of the budget for new products consumed by clearing it. A FinOps or process audit shows down to the euro where that money goes. The report does not shift that euro. The decision after it does.

And that is usually where it stalls. The report is circulated, everyone nods, and then the quarter begins. The cancellation needs a signature that no one claims. The tool that duplicates still has one department hanging off it. So a measured leak stays a measured leak, quarter after quarter. The figures from the audit change nothing as long as there is no owner and no date attached to them.

The baseline that finance co-signs

This is where most of the money falls to the floor, not in the audit but in the measurement after it. A saving only exists relative to a starting point. If that starting point is soft, then the saving is a story. That is why the baseline, today's run-rate, should be signed by finance before anything changes. Not by IT, not by the vendor. By the people who book the invoices.

What goes into that baseline? The licence cost per system, the maintenance, the infrastructure, the hours attached to running systems. Recorded on a single date, with the source per line. From that point on, only what demonstrably drops counts. An estimate does not count. An assumption does not count. An invoice that arrives lower counts.

Watch too for money that is counted twice. The three audits touch each other: the same tool can turn up in two reports. Count them both and you save more on paper than your ledger will ever show. One baseline, one counter per system. That way the sum stays honest.

From finding to confirmed saving

The path from report to result is no mystery. It is work, in a fixed order.

1. Sort the findings by what can stop today without risk. A licence no one opens, you cancel this month. That needs no migration.
2. Put an owner and a date behind every finding. A finding with no name behind it changes nothing.
3. Measure every saving against the signed baseline, on the invoice, not on the promise.
4. Only switch off the old once the new one proves itself, and count the saving from that moment.

You see the difference on the run-rate, the fixed monthly cost of your platform. Every cancelled licence lowers that cost. Every tool that disappears does too, and every piece of maintenance that falls away. Not in a forecast, but on the invoice of the month after. That is the only saving that counts: one you can point to in the ledger, next to the line it came from.

The easy savings, the unused licences, land within weeks. The big ones sit deeper: duplicate work between systems, a run-rate that stands too high because five tools do what belongs in one platform. You do not reach those with a cancellation. Those require you to replace something, and you do that in waves with a go/no-go at each step. That way the old keeps running until the new one proves itself, and the saving only counts once the switchover is complete.

Paying for what is confirmed

This is also why it pays to hang the model on the result, not on the report. An audit with us has a fixed price, upfront and vendor-neutral. For the execution, YK works with a success fee: 20% of the confirmed savings. Confirmed means measured against the baseline that finance signed, after deducting double running. If no saving lands, there is no fee. That way the bill for the execution sits on the same side as your run-rate.

So do not start with the question of which tool can go, but with the question of who signs the baseline. Without that starting point, every saving is an opinion. With that starting point, it becomes a line in the ledger that stands lower next month than this one.