Savings measurement methodology

Three numbers run through the audit and any engagement that follows. Never combine them.

Number	What it is	Where it comes from
Current cost	What Azure billed, or the amortised cost of consumed commitments, for a defined period.	Your own billing data
Indicative opportunity	The reduction a finding would deliver if implemented, under stated assumptions.	A model, not a measurement
Verified saving	An observed, attributable reduction after an approved change has been implemented.	The post-change billing data, compared with the baseline

An indicative opportunity is never booked as a saving. Figure 1 draws the measurement path; the six steps below add the method.

From baseline to a classified result, noted as a measurement convention, not an audit opinion. Three stages run left to right along a time axis reading before the change, when your team ships, and typically weeks 3 to 4. Stage 1, in a cyan Infralign lane, is the baseline: a representative period before the change, with the scope and cost basis agreed. Stage 2, in an amber lane labelled your team, your estate, is the change implemented: your team implements it and records the date of effect. Stage 3, back in a cyan Infralign lane, is the observation window: post-change billing compared with the baseline, adjusted for unrelated change. An arrow then runs down into a cyan classification band marked done by a person, which carries one label of three: verified with a filled marker, attribution holds; directional with a half marker, attribution incomplete; not verified with an empty marker, reduction absent or unclear. — Figure 1: A result is only ever classified after the observation window, by a person, as verified, directional, or not verified. The three stages compress the six steps below: baseline covers steps 1 and 2, change implemented covers steps 3 and 4, the observation window is step 5, and classification is step 6.

1. Agree the scope and cost basis

Each finding names the subscriptions, resources, services, currency, and time period in scope, and says whether it uses billed cost or effective (amortised) cost. Invoice reconciliation uses billed cost. Operating and commitment decisions may use amortised cost.

Your finance and technical owners agree the scope, currency, cost basis, and exclusions before Infralign reports an implemented result. Tax, credits, refunds, marketplace charges, support plans, foreign-exchange effects, and negotiated discounts count only when the agreed method says how to treat them.

2. Establish the baseline

How long the baseline needs to be depends on how the workload behaves and how much history is available. Infralign records:

start and end dates;
the resources and charges included;
the demand or usage measures the connected data offers;
the commitment, discount, and Azure price assumptions used; and
known one-off events or gaps in the data.

Seasonal, newly launched, or fast-changing workloads may need a longer window. Some will not support a reliable baseline at all.

3. Estimate the opportunity

The estimate compares the current configuration or operating pattern against a defined alternative, naming the pricing source, the utilisation evidence, and the implementation assumptions. Where precision would mislead, it gives a range instead of a single figure.

Reservation and Savings Plan opportunities stay separate from resource-removal and rightsizing opportunities, so the same spend is not counted twice. One-time cost avoidance, recurring run-rate reduction, and commitment discount are also reported separately. An annualised figure is labelled as an extrapolation from the observed run rate, not as twelve months of measured savings.

4. Record your decision

Your technical and financial owners accept, reject, or defer each finding in the app. Accepting a finding authorises change planning under an engagement, not a production change. Your organisation implements the change and records the date it took effect.

5. Observe after implementation

Once enough Azure billing data has landed, Infralign compares the post-change window with the baseline. Where the evidence supports it, it adjusts for:

changes in workload demand or transaction volume;
changes in operating hours;
changes in Azure price, currency, discount, or commitment;
resources added, removed, or moved for unrelated reasons; and
partial-period effects.

6. Classify the result

Classification	What it means
Verified	The change happened, the observation window is long enough, and the cost movement is attributable within the stated method.
Directional	The movement is consistent with the change, but attribution or the observation window is incomplete.
Not verified	The expected reduction did not appear, the change was not implemented, or other changes make the result unreliable.

Every result keeps its baseline, observation dates, adjustments, confidence, and exclusions. Avoided future growth is reported separately from a reduction in the current bill. Your finance owner reviews the calculation before any readout calls a saving verified. This is a measurement convention, not an audit opinion, financial assurance, or a guarantee of future savings.

Timing

The expert-reviewed audit is targeted for week one, which starts once your first nightly run has landed. If you proceed to an engagement and a change is implemented promptly, verified savings are typically measurable in weeks three to four. Azure data latency, billing cycles, change windows, and workload variation all stretch that.

No guaranteed percentage

Infralign does not promise a savings percentage, and does not use an unscoped prior result as a forecast for your estate. The audit establishes what your data, your constraints, and your implemented changes can support.

To agree a method, an exclusion, or a scope in writing before an engagement starts, write to support.

Which steps here are the product’s and which are a person’s is set out capability by capability in available today versus roadmap.