TL
The short answer

Identified savings are the projected reduction from a recommendation, calculated before anyone acts. Realized savings are the reduction that actually lands in the bill after the change ships and runs. The two diverge because recommendations expire, get implemented partway, or are swallowed by growth, so a real cut can still read as a flat invoice. Measuring realized savings means comparing actual spend against a defensible baseline of what spend would otherwise have been, attributing each delta to a specific action, and reconciling to the provider bill. Get this right and finance credits your program with a number it can audit; get it wrong and every future savings claim is discounted on arrival.

Here is why the gap opens, how to measure realized savings honestly, and how to report a number that survives scrutiny.

Why do identified and realized savings drift apart?

Several mechanisms pull the realized number below the identified one, and naming them is the first step to closing the gap.

  • Recommendations expire. A rightsizing recommendation from AWS Compute Optimizer, Azure Advisor, GCP Recommender, or the OCI Cost Analysis console reflects a moment in time. Wait a quarter and the workload has changed, so the modelled saving no longer applies.
  • Partial implementation. A plan to move every eligible instance to Graviton or gp3, or to lift commitment coverage to a target, often ships at half the intended scope. Half the action delivers a fraction of the identified saving.
  • Growth masks the cut. Usage almost always rises. A genuine reduction can coincide with a larger bill because the estate grew underneath it, which makes the saving invisible unless measured against a baseline.
  • Commitments shift, not remove, cost. A Savings Plan, Reservation, Committed Use Discount, or Universal Credits purchase lowers the rate but adds a commitment liability. Counting the gross rate cut without netting the commitment is double counting.

None of these means the work was wasted. They mean the headline identified figure was never the realized figure, and reporting it as if it were is what damages trust.

How do you measure realized savings honestly?

Realized savings is a comparison against a baseline, not a raw bill movement. The defensible method has three parts. First, set a baseline: the spend that would have occurred without the action, which usually means holding unit cost at its pre action level and applying actual usage, so growth is separated from optimization. Second, attribute: tie each change in spend to a specific action, using the billing data, the Cost and Usage Report on AWS or the FOCUS aligned export on Azure, GCP, and OCI, so the saving has an owner and a cause. Third, reconcile: confirm the realized number against the actual invoice, including the net effect of any commitment purchased, so the figure ties to money that left the business.

The honest realized number is almost always smaller than the identified estimate, and that is the point. A program that reports a smaller verified number repeatedly is trusted; one that reports large unverified numbers once is not.

What belongs in a savings ledger?

The instrument that holds all of this together is a savings ledger: a running record of every optimization action with its identified estimate, its implementation status, and its verified realized result. Each row carries the action, the owner, the date, the baseline assumption, the cloud and service, the identified figure, the realized figure once it appears in the bill, and the commitment liability if any. The ledger turns savings from an anecdote into an auditable series, lets you compute a realization rate (realized divided by identified) that improves as the program matures, and gives finance one place to verify the number. It is the difference between saying we think we saved a lot and showing exactly what was done, when, and what the bill confirmed.

A worked example

Worked example

A scaling fintech reported a large identified savings figure from a tool's recommendations, but the bill kept rising and finance stopped believing the slides. Rebuilding measurement around a baseline that held pre action unit cost and applied real usage separated growth from optimization for the first time. Attributing each delta to a specific action through tagged billing data and reconciling to the invoice produced a realized number that was smaller than the identified estimate but fully auditable. Tracking it in a savings ledger lifted the realization rate over successive quarters as implementation discipline improved, and the verified results became part of the program that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.

How should realized savings be reported upward?

Report the realized number, against the agreed baseline, net of growth and net of commitment liability, attributed to named actions and reconciled to the bill. Show the identified figure alongside it as the pipeline, and the realization rate as the measure of execution. This framing gives a CIO and a CFO a number they can defend in their own reporting, and it reframes the conversation from how much did you claim to how reliably do you deliver. That reliability is what earns a savings program a durable mandate rather than a one off project, which is the territory of the wider FinOps operating model.

Frequently asked questions

What is the difference between identified and realized savings?
Identified savings are the projected reduction from a recommendation, before any action. Realized savings are what actually appears in the bill after the change ships and runs. The gap between them is where most savings programs lose credibility.
Why do identified savings rarely match the bill?
Recommendations expire, ship partway, or are masked by growth, and commitments shift rather than remove cost. Measuring realized savings means comparing against a baseline that accounts for what usage would otherwise have been.
How should cloud savings be reported to finance?
Report realized savings against an agreed baseline, attributed to specific actions, reconciled to the bill, and net of growth and commitment liability. A savings ledger gives finance a number it can audit rather than a slide it has to trust.

Make your savings number auditable

We help enterprises measure realized savings against defensible baselines across AWS, Azure, GCP, and OCI, and report a number finance will credit. We take zero provider commissions and answer only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis, where our fee is tied to verified savings. Book a strategy call to scope it for your estate, and follow more in The Cloud Spend Navigator.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.