To track and prove cloud cost savings, run a simple loop: baseline, action, evidence. First set a baseline, the spend and licence position before you change anything. Then take an action and record the saving you expect it to produce. Then measure the same figures afterwards on a like-for-like basis, so the difference is the saving rather than the noise. Savings claims fail when any one of these is missing: no baseline means nothing to compare against, a growing estate hides the saving inside a rising total, and price changes make last month and this month look different for reasons that have nothing to do with your work. Close the loop every month and the saving becomes a number you can defend to finance, not a story you have to tell.
Cost control is not the hard part for most teams. Proving it is. The change was real, the bill still went up because the business grew, and the saving disappears into the total where nobody can see it. Here is how to make each saving visible and keep it that way.
Why savings claims fail
Three failures account for most disputed savings.
No baseline. If you did not record what you were spending before, you have nothing to measure against afterwards. The saving becomes an estimate, and an estimate is easy to wave away when finance asks how you arrived at it.
Estate growth masks the saving. You right-size a fleet of virtual machines and cut their cost, but the business onboards a new team the same month and total spend rises anyway. The saving is real, it is just buried under growth. Without a like-for-like comparison, the headline number tells the opposite story to the truth.
Price changes muddy the comparison. Rates move, currency shifts for some agreements, a service tier is retired. Compare a raw invoice from March against one from June and part of the difference is priced by Microsoft, not earned by you. A defensible saving has to hold the price constant so the change you are claiming is the change you actually made.
Set a defensible baseline
Everything rests on the baseline. Before you touch anything, capture three things and store them somewhere you can return to.
Spend by service. Not just the total, but the breakdown by service and resource. A single total moves for a hundred reasons; a per-service baseline lets you point at the exact line you changed and show it fell.
Licence purchased versus assigned counts. For Microsoft 365, record how many of each licence you have bought against how many are actually assigned, and ideally how many assigned seats are genuinely in use. The gap between purchased and assigned is money already spent on seats nobody holds, and it is one of the clearest baselines to move.
Tagged ownership. Tag resources by owner and environment so cost is attributable rather than anonymous. A baseline that says "the platform costs this much" is far weaker than one that says "this team's production environment costs this much", because the second one has someone who can confirm the before and stand behind the after.
The loop is the point. A one-off cleanup fades, but a monthly baseline-to-report cycle turns cost control into a habit with evidence attached.
Record every action with its expected saving
A cloud cost baseline is only half the picture. The other half is a log of what you changed. Every time you take an action, right-size a machine, reclaim a dormant licence, delete an orphaned disk, apply an auto-shutdown schedule, write down five things: what you changed, when, who owns it, the saving you expect per month, and how you will verify it later.
This log does more than track cost savings. It sets the expectation up front, so when you measure afterwards you are checking a prediction rather than reverse-engineering a story. It also protects the saving. Cloud resources drift back: a machine gets resized up again, a licence gets reassigned. If the action is logged with an owner, you can spot the reversal and re-apply the change instead of quietly losing the saving you already claimed.
Measure after on a like-for-like basis
After the change has settled, measure the same figures you baselined, and hold everything else constant. Like-for-like means comparing the same scope, the same services, and the same prices, so the only variable left is the action you took.
If the estate grew, isolate the resources you actually touched rather than comparing whole-estate totals. If prices changed, apply the same rate to both the before and after so you are not crediting yourself with a discount Microsoft handed everyone. Savings measured this way are directional by nature, they depend on your estate and your usage, but they are defensible, which matters far more than being precise to the penny.
Cost avoidance versus cost savings
The single most useful distinction in this whole exercise is between realised savings and cost avoidance, and it is worth defining both clearly because finance will ask.
Realised cost savings are an actual reduction in your bill against a like-for-like baseline. You were spending a certain amount, you changed something, and now you spend less for the same work. It shows up as a lower invoice. Reclaiming ten unused licences or right-sizing an oversized machine that keeps running produces realised savings.
Cost avoidance is spend you stopped before it ever reached the bill. It does not make last month's invoice smaller, it stops a future increase. Switching off development machines overnight so they never accrue those hours, right-sizing before a planned scale-out, or committing to a reservation instead of paying on demand: these avoid cost rather than removing it. The saving is real, but it lives in the bill you would otherwise have had, not the one you did.
Report the two separately. Mixing them lets a sceptic dismiss the whole figure, because avoided cost never appears as a falling invoice line and looks invented when it sits next to realised savings. Kept apart, both are credible: one is money the bill lost, the other is money the bill never gained.
Report a savings ledger to finance and leadership
Pull the actions, their realised savings, and their avoided cost into a single running ledger, and report it on a fixed cadence. A savings ledger is simply the list of every action with its verified outcome, a cumulative realised total, and a cumulative avoided total, updated each month. Finance gets a number they can trace back to specific changes with named owners, and leadership gets a trend rather than an anecdote.
The cadence is what makes it stick. A monthly review keeps the baseline fresh, catches drift before it erases a saving, and turns cost control from an annual panic into a routine. It also compounds: this month's after becomes next month's before, and the ledger grows into a track record that speaks for itself when budgets are set.
The managed-service angle
For a managed-service provider, proving savings is not just good hygiene, it is the commercial case for the engagement. A customer paying a monthly fee wants to see it earn its keep, and a savings ledger per customer tenant does exactly that: it shows this environment cost less this month because of these specific actions, with the evidence attached.
Done at scale across many tenants, that same discipline becomes a retention engine. Savings that are visible, attributable, and reported on a steady cadence build the kind of trust that renews contracts, because the value is a documented number rather than a claim made at review time. The provider who can prove the saving keeps the account; the one who only asserts it competes on price.
Where EtherInsights fits
Running the baseline-action-evidence loop by hand across a growing estate, or across dozens of customer tenants, becomes a job in itself, and it is where a savings-tracking discipline usually breaks down. EtherInsights is built to hold the loop together: it captures the baseline, surfaces the waste, records each action, and tracks the before-and-after so every saving lands in a ledger with evidence behind it rather than in a spreadsheet nobody trusts.
That evidence trail runs across the estate. On the Azure side, Azure VM right-sizing turns utilisation into owner-backed resizing actions with the numbers to prove each one. On the licensing side, Microsoft 365 licence management and offboarding tracks the purchased-versus-assigned gap so reclaimed seats show up as realised savings rather than guesswork. And because a defensible saving depends on measuring at a sensible cadence, it is worth reading why monthly cloud reporting leaves spend unchallenged when the report only describes the bill instead of driving action against it. See how the whole picture comes together in EtherInsights.
A saving you cannot prove is a saving finance will not credit. Set the baseline, log the action, measure like for like, keep realised and avoided separate, and report the ledger every month.
Explore cloud cost optimisation to turn cost cutting into a proven, repeatable savings ledger across Microsoft 365 and Azure.