Estimated Savings Are Not Savings Until the Bill Agrees

Every cost tool has a savings number.

It's usually large, usually on the first screen, and usually an estimate.

That isn't a criticism. You can't act on a recommendation without some idea of what it's worth. The problem starts later, when the estimate quietly turns into the number people report upward as "what we saved."

An estimate tells you what should happen. A saving is what did happen. They come from different places, and the gap between them is where trust in cost reporting goes to die.

Two numbers, two sources

Estimated savings come from a model. Take the resource's cost, apply the recommended change, price the result. Sometimes at list price, usually assuming usage stays exactly as it was.

Realized savings come from the bill. What did this resource cost before the change, what did it cost after, and is the difference real or just noise?

The first is a forecast. The second is a measurement. Both are useful. Forecasts belong in budgets and business cases. Only one belongs in a report of realized savings.

How established FinOps tools measure savings

I went through the public documentation for the native cloud tools and several well-known cost platforms. This is what each one documents, as of October 2026. Where a doc doesn't say something, I've said so rather than guess.

A few things stand out.

The native tools mostly forecast. AWS prices its estimates with your own discounts, Savings Plans and Reserved Instances, and still says plainly that the figure is an approximation. Azure warns that rightsizing forecasts use retail rates, so they "vary based on your actual rates." Google does report a realized figure. It can be accurate within its scope, but that scope leaves out idle resource cleanup, one of the most common actions there is.

Commitments are the easy case. Vantage and ProsperOps measure commitment savings from what you actually paid, and that is the right way to do it. But a savings plan is a pricing change on usage you already have, so the comparison to on-demand is well defined. Rightsizing, deleting and resizing don't have that luxury.

Counterfactual models answer a different question. CAST AI compares what you pay against a model of what you would have paid without it, built from your cluster's history because workloads change and an old bill stops being a fair comparison. A counterfactual asks what the workload would have cost without the change. A before and after asks how the billed cost moved once the change was made. Neither proves cause on its own, and each has limits.

CloudZero is the closest to a real before and after. It compares a resource's 30-day cost before the change with its cost since, starts counting from the first day after the recommendation is addressed, and recalculates daily. That's a different set of choices about windows, not a wrong one.

So measuring from billing data isn't unique. What varies is the rules around it: when you're allowed to measure, what counts as proof, and what you do when the numbers don't say anything.

The rules CostOptix uses

When you mark a recommendation as implemented, CostOptix doesn't count anything yet. It shows the badge as pending, with the date verification is due. Then it waits.

1. Compare two full windows of billed days

CostOptix takes the 14 days before the change and the 14 days after. For each side it works out the average daily cost over the days that were billed, takes the difference, and multiplies it by 30 to get a monthly figure. The day of the change is excluded from both sides, because it's half old and half new.

Fourteen days is two whole weeks, so each side holds every weekday twice and a weekday or weekend pattern doesn't tilt the result. It's a consistent window, not a promise that the workload behaved the same on both sides. A job that peaks once a month can land in one window and not the other.

An example. A rightsizing finding estimates $400 a month. Before the change the resource averaged $30 a day, after it $22. The difference is $8 a day, or $240 a month. CostOptix reports $240, not $400.

Both sides come from the provider's billed cost records, as they stand when the check runs. Not from the recommendation's own estimate, which is recalculated every night and so is a moving target.

2. Wait for the bill to settle

Cloud billing data gets restated for days after the fact. Measuring the after window too early means measuring numbers that will change.

So the after window is held back: five days for orphaned resources and commitments, one day for Kubernetes, whose daily ledger only writes completed days. Five days is the longest billing lag among the clouds CostOptix supports (Azure, where AWS and Google Cloud are three), applied to all of them. A finding implemented on the 1st is due on the 21st for cloud resources.

The wait is a policy that lowers the risk of measuring incomplete data. It doesn't guarantee a provider will never restate a day later.

That's slower than counting from day one. It's also the difference between a number you report once and a number you have to correct.

3. Require a real difference

A saving has to clear a floor before it's verified: $5 a month for most findings, matching the threshold that let the recommendation be raised in the first place. A finding can't be verified at a value lower than the one needed to show it.

Orphaned resources are the exception. A forgotten disk costing $1.69 a month is still worth deleting, and still worth crediting, so the floor there is one cent.

4. Check that the action actually happened

Cost going down doesn't prove the recommendation caused it. Traffic drops. Teams migrate. Workloads get deleted.

For commitments, CostOptix checks the evidence directly: the daily spend billed at committed rates has to rise by more than 5% of the total daily spend before the change. On $100 a day, that's more than $5 a day of new committed usage. If the bill fell but coverage didn't move, nobody bought anything, and the finding stays inconclusive.

For Kubernetes rightsizing, the workload has to exist on both sides. If it vanished, it was deleted or renamed. That's a different action, and its zero cost isn't a rightsizing saving.

For orphaned resources, the opposite is true. No billed days after the change is exactly what a deletion should look like, so it counts.

5. Say when you can't prove it

Every implemented finding ends up in one of four states:

• Verifying: the windows aren't complete yet. The badge shows the date it's due.
• Verified: the bill shows a saving above the floor.
• Cost rose: cost went up by more than 5%. The change made things worse, and you should know.
• Unconfirmed: the data doesn't support a claim either way. That doesn't mean the change failed. It means the bill can't show it.

Unconfirmed findings are re-checked daily for up to 90 days. If the evidence never shows up, the finding never gets credit.

Until a finding is verified, CostOptix shows its projected saving, clearly labelled as projected. Once it's verified, the measured figure replaces it. The savings totals show one or the other, never the two added together.

What verified means, and what it doesn't

Verified means the bill for that resource moved by enough, after the windows settled, with evidence the action happened. It doesn't prove the recommendation was the only cause. If traffic fell by a third in the same two weeks, part of a rightsizing saving is really lower demand, and two billing windows can't separate the two.

The checks above narrow that gap. They don't close it. So treat a verified saving as an observed reduction that passed defined rules, not as proof of cause.

Why this matters

None of the tools above are doing anything dishonest. Estimates are useful, counterfactual models have their place, and commitment savings measured against on-demand rates are real.

The risk is in the reporting. A quarter's worth of "savings" built mostly from forecasts looks great until finance asks which of it shows up in the bill. The total bill can't answer that on its own. It can rise while real savings happen, because new services launch and demand grows. That's why a saving has to be measured on the resource it came from. Once reported savings and demonstrable savings drift apart, every number you show gets discounted.

A smaller number that holds up against the bill is worth more than a bigger one that doesn't.

That's the standard CostOptix holds itself to: wait for the bill, measure both sides, check the action happened, and say so when it can't tell.

Trust, but verify against the bill.

CostOptix brings cloud, Kubernetes, host and AI tool costs into one view, with recommendations whose savings are verified against what you were billed. Flat pricing, never a percentage of your spend. Try it on your own spend or explore the demo.

Sources: AWS Cost Optimization Hub, Azure Advisor, Google Cloud FinOps hub, Vantage, CAST AI, ProsperOps, CloudZero. Checked October 28, 2026.