If your Azure runs through a CSP partner, your own tenant reports CHF 0 for every hour a reservation or a savings plan covers. You rebuild the distributed view from the raw records yourself, and it takes a handful of fields.
Part one pulled the two metrics apart: actual cost matches the invoice, amortized cost explains what a resource consumed. This part shows where the second number comes from when Azure does not hand it to you.
1. What your tenant shows, and at which prices
Microsoft makes Cost Management available in the customer tenant only once the cost visibility policy is switched on. The default is off.
With the policy on, Azure prices your usage at pay-as-you-go rates, the rates from the Azure pricing calculator, without the terms from your contract.
Commitments come with a second limitation. Covered usage appears at CHF 0, in the actual view and in the amortized one. The purchase shows up as its own line, and never spread across the resources that used it.
Do not go looking for a setting. The amortized view exists in the customer tenant as a toggle with nothing behind it.
2. The terms you will be working with
Everything you need sits in the cost details, the line level export behind Cost Analysis: one line per day, resource, and meter.
Open a month with a running reservation and you meet three kinds of lines. The purchase on the purchase date, covered usage on every day, and nothing at all for the unused share.
| Term | Where it sits | What it means |
|---|---|---|
| ChargeType | every line | Purchase for the buy, Usage for consumption. UnusedReservation and UnusedSavingsPlan exist in the amortized view only, so not in yours. |
| PricingModel | every line | Reservation or SavingsPlan on every line that belongs to a commitment, otherwise OnDemand. |
| Quantity | purchase and usage | The reserved quantity on the purchase line, the hours that ran on the usage line. |
| EffectivePrice | usage | 0 as soon as a commitment covers the line. This is how you spot them. |
| UnitPrice | usage | The on-demand rate from your price sheet, so the value of that hour without the benefit. Not a billed amount. |
| Ratio | AdditionalInfo | Instance Size Flexibility ratio, the relative footprint of a SKU inside its flexibility group. Relative units, not prices. |
| Term, Frequency | purchase | Duration and payment rhythm. Both decide how many days you divide by. |
| ReservationId, BenefitId | purchase and usage | The identifier of the commitment. Reservations carry ReservationId, savings plans carry BenefitId. |
The ratio deserves its own paragraph, because it converts between what you bought and what you ran. A reservation for a DS4_v2 at ratio 8 covers eight DS1_v2 at ratio 1, or two DS2_v2 and one DS3_v2, since 2 plus 2 plus 4 adds back up to 8. Run a DS5_v2 at ratio 16 and the reservation covers half of that machine's compute cost.
Two traps come with it. The raw values do not start at 1 for the smallest SKU, the BS series starts at 0.25 and Ddsv5 at 2. And a different flexibility group does not share the benefit, DSv2 Series High Memory does not belong to DSv2 Series.
Two things have to be right about the export: daily granularity, and billed prices in the invoice currency.
3. How the daily share reaches the resources
The calculation runs per commitment and per day. Amortization is daily, which is why February carries 28 shares and March 31.
- Build the daily share. Purchase amount divided by the days of the term. CHF 12'000 over twelve months gives CHF 32.88 per day. On monthly payment, take the payment for that month divided by its days.
- Determine the weight per line. Quantity times ratio, for every covered line of that day. You need the ratio because a reservation also covers other sizes inside its flexibility group, which makes hours of different sizes incomparable.
- Measure against the reserved quantity. Build the same weight for the quantity on the purchase line. That is the scale for the day, and every resource receives the portion of the daily share that matches its weight.
- Leave the rest standing. Whatever remains was drawn by nobody. It matches what Microsoft reports as UnusedReservation in an EA and in an MCA.
Savings plans have no ratio. There the usage consumes an hourly commitment in Swiss francs, so you build the weight from quantity and unit price.
A day in March from the example in part one shows this. The reservation covers 24 hours of a D4as v5, and two machines draw on it.
| Line | Hours (Quantity) | Ratio (AdditionalInfo) | Weight (hours × ratio) | Share of the scale | Of the daily share |
|---|---|---|---|---|---|
| prod-vm-01, D4as v5 | 9.6 | 4 | 38.4 | 40% | 13.15 |
| prod-vm-02, D2as v5 | 14.4 | 2 | 28.8 | 30% | 9.86 |
| Unused | 7.2 | 4 | 28.8 | 30% | 9.86 |
| Reserved quantity, the scale | 24.0 | 4 | 96.0 | 100% | 32.88 |
prod-vm-02 runs longer and still draws less, because it enters at half the ratio. The scale is the reserved quantity and not the quantity drawn, which is why the unused share stays as its own line.
Across all of March that comes to CHF 713 on resources and CHF 306 with no owner. Over the term every day adds up to CHF 12'000, and that check is your only proof that the distribution is correct.
4. What happens without the distribution, and where it hits limits
Without the reconstruction two paths remain, and both go wrong.
Charge back the numbers from the tenant and you charge back pay-as-you-go rates. Your departments together pay more than the invoice says, and the commitment discount lands on no cost center.
Charge back the purchase in the month it was bought and a single subscription carries CHF 12'000. The department that draws 70% of the reservation in March shows up at CHF 0 for that month.
Five limits are worth knowing before you set the calculation up:
- Microsoft adjusts the ratios from time to time. Prices stay the same, coverage does not, and a hard coded ratio quietly turns wrong.
- The classic CSP offer does not deliver this data. You need subscriptions in the Azure plan on the Microsoft Customer Agreement.
- Marketplace purchases are not amortized. Virtual machine software reservations from the Marketplace are the exception.
- The monthly amounts are not equal. February carries 28 daily shares, March carries 31, and a split into twelve equal months is wrong.
- We only calculated virtual machines here. Other resources behave differently, Azure Cosmos DB is bought as throughput in RU/s across accounts and regions and has no SKU ratio. Every resource type needs its own check before you charge it back.
5. Why you do not have to run this calculation yourself
Chargeback in CSP is harder than in an Enterprise Agreement for three reasons. The distributed view is missing in the tenant, the prices there are not the billed ones, and purchases do not hang off the resource hierarchy that your cost centers hang off.
Then there is the volume. The calculation from chapter 3 runs per commitment, per day, and per resource, and with a dozen commitments across several subscriptions it stops being an Excel job.
The Zation Platform takes that part over. It brings the billing from CSP, MCA, and EA into one cost source and rolls the months up by service, region, cost type, and resource group. Reservations and savings plans come with inventory and utilization.
That puts Zation among the few CSP partners that make the data basis for a chargeback available to their customers at all.
How our Cost Engine turns that into showback and chargeback is what we take apart in the next part of this series.