Cost Management Benefit Recommendations API "uncovered" charges don't match FOCUS export (consistently 7–21% lower)

Question

Here's the full write-up, ready to paste into Microsoft Q&A:

Title: Cost Management Benefit Recommendations API "uncovered" charges don't match FOCUS export (consistently 7–21% lower)

Body:

I'm comparing two numbers that should represent the same thing — hourly uncovered (no discount applied) on-demand cost for Compute Savings Plan-eligible usage, same org, same billing profile, same date range:

1. Azure's number - the charges array from Microsoft.CostManagement/benefitRecommendations (Compute Savings Plan, Shared scope).
2. My number -calculated independently from my own FOCUS export.

Every day in the comparison window, my FOCUS-based number is 7–21% higher than Azure's API number. Details of how each side was built below.

How I built the "eligible meters" list

Source: the MCA Price Sheet API (my own negotiated contract pricing — not the public Retail Prices API). Filters applied:

1. Keep only Compute categories: Virtual Machines, App Service, Functions, Container Apps, Container Instances, Dedicated Host, Spring Apps/Cloud.
2. Keep only Consumption and SavingsPlan price rows (drop ReservedInstance rows).
3. A meter is "eligible" only if it has a SavingsPlan row at all - no Savings Plan rate available = dropped.
4. Result: one row per eligible meter, with meter_id + contracted_price (my negotiated on-demand $/unit).

How I calculated "uncovered on-demand $/hr" from FOCUS

1. Pull FOCUS usage rows (ChargeCategory = 'Usage') for the org/profile/date range.
2. Deduplicate -FOCUS re-exports the same billing period multiple times, so I keep only the latest export revision per unique charge (otherwise costs get counted multiple times over).
3. Inner-join to the eligible-meters list on meter ID — only usage on an eligible meter is included.
4. Filter to uncovered rows only: CommitmentDiscountType IS NULL and PricingCategory = 'Standard'.
5. For those rows, FOCUS's own x_ContractedCostInUsd field is the negotiated on-demand cost — used directly.
6. Sum per day, divide by 24 → focus_unc_od_hr_usd, compared directly against Azure's charges value.

What I've already ruled out

• Duplicate FOCUS export revisions (fixed via dedup above).
• Wrong eligibility list -tested two different eligible-meter sources; totals were identical either way, so this isn't the cause.

Question: what pricing basis and filters does benefitRecommendations.usage.charges use internally that could explain it being consistently 7–21% lower than the FOCUS-based figure? Specifically:

1. Is the internal basis contracted/negotiated pricing, or list/retail pricing?
2. Does it apply extra scoping (subscriptions, resource types, charge categories) beyond meter-level Compute-SP eligibility that wouldn't be visible from FOCUS alone?
3. Could there be a timing/latency difference — a different usage snapshot than what's already in my FOCUS export?Here's the full write-up, ready to paste into Microsoft Q&A: Title: Cost Management Benefit Recommendations API "uncovered" charges don't match FOCUS export (consistently 7–21% lower) Body: I'm comparing two numbers that should represent the same thing — hourly uncovered (no discount applied) on-demand cost for Compute Savings Plan-eligible usage, same org, same billing profile, same date range:
   1. Azure's number — the charges array from Microsoft.CostManagement/benefitRecommendations (Compute Savings Plan, Shared scope).
      1. My number — calculated independently from my own FOCUS export.
   Every day in the comparison window, my FOCUS-based number is 7–21% higher than Azure's API number. Details of how each side was built below. How I built the "eligible meters" list Source: the MCA Price Sheet API (my own negotiated contract pricing — not the public Retail Prices API). Filters applied:
   1. Keep only Compute categories: Virtual Machines, App Service, Functions, Container Apps, Container Instances, Dedicated Host, Spring Apps/Cloud.
      1. Keep only USD rows (drop the CAD duplicate rows for the same meters).
         1. Keep only Consumption and SavingsPlan price rows (drop ReservedInstance rows).
            1. A meter is "eligible" only if it has a SavingsPlan row at all — no Savings Plan rate available = dropped.
               1. If a meter appears more than once, keep the cheapest tier / most recent effective date.
   Result: one row per eligible meter, with meter_id + contracted_price (my negotiated on-demand $/unit). How I calculated "uncovered on-demand $/hr" from FOCUS
   1. Pull FOCUS usage rows (ChargeCategory = 'Usage') for the org/profile/date range.
   2. Deduplicate — FOCUS re-exports the same billing period multiple times, so I keep only the latest export revision per unique charge (otherwise costs get counted multiple times over).
   3. Inner-join to the eligible-meters list on meter ID — only usage on an eligible meter is included.
   4. Filter to uncovered rows only: CommitmentDiscountType IS NULL and PricingCategory = 'Standard'.
   5. For those rows, FOCUS's own x_ContractedCostInUsd field is the negotiated on-demand cost — used directly.
   6. Sum per day, divide by 24 → focus_unc_od_hr_usd, compared directly against Azure's charges value.
   What I've already ruled out
   • Duplicate FOCUS export revisions (fixed via dedup above).
   • Wrong eligibility list - tested two different eligible-meter sources; totals were identical either way, so this isn't the cause.
   Question: what pricing basis and filters does benefitRecommendations.usage.charges use internally that could explain it being consistently 7–21% lower than the FOCUS-based figure? Specifically:
   1. Is the internal basis contracted/negotiated pricing, or list/retail pricing?
   2. Does it apply extra scoping (subscriptions, resource types, charge categories) beyond meter-level Compute-SP eligibility that wouldn't be visible from FOCUS alone?
   3. Could there be a timing/latency difference -a different usage snapshot than what's already in my FOCUS export?

Answer 1

Hello Shahar Margulis,

Based on the currently published documentation, Savings Plan recommendations are generated using actual** on-demand usage and costs, including negotiated customer **pricing, rather than public retail rates. As a result, the usage.charges values returned by the Benefit Recommendations API are expected to be based on contracted pricing applicable to your billing scope.

Regarding the variance you're observing between the Benefit Recommendations API and the FOCUS export, there are a few areas worth considering:

Eligibility** **determination

Your calculation determines eligibility by identifying meters that have a corresponding Savings Plan price entry in the MCA Price Sheet. While this is a reasonable approach, Microsoft documentation describes recommendation generation in terms of Savings** Plan-eligible usage and **resources and doesn't publicly document the exact internal eligibility mapping used by the recommendation engine. As a result, the recommendation service may apply eligibility criteria that aren't directly exposed through the Price Sheet or FOCUS data.

https://learn.microsoft.com/en-us/azure/cost-management-billing/savings-plan/purchase-recommendations

Scope** **alignment

It's important to verify that the billing scope used for the recommendation (Shared, Subscription, or Resource Group scope) matches the scope used when aggregating the FOCUS export. Differences in scope can lead to variances even when the same date range is being analyzed.

Data** processing **timing

Recommendation data is refreshed periodically and is generated from historical usage snapshots used by the recommendation engine. Depending on when the comparison is performed, the usage dataset reflected in the recommendation may not be perfectly synchronized with the latest FOCUS export data available to you.

https://docs.azure.cn/en-us/cost-management-billing/savings-plan/choose-commitment-amount

1.** Is the internal basis contracted/negotiated pricing, or list/retail **pricing?

Based on Microsoft documentation, recommendations are generated using actual** on-demand costs, including negotiated **discounts, rather than public retail pricing.

2.** Does it apply extra scoping or filtering beyond meter-level **eligibility?

Microsoft documentation confirms that recommendation calculations are based on Savings Plan-eligible usage and recommendation modeling, but it doesn't publicly document the complete filtering and eligibility logic used to derive the usage.charges values.

3.** Could timing or latency differences **contribute?

Yes. Recommendation data and billing exports are generated through different processing pipelines and refresh cycles, so timing differences can contribute to discrepancies between the two datasets.

Therefore, based on the available documentation, the most likely explanation is not the pricing basis itself, but rather differences in internal eligibility, coverage calculations, recommendation-specific filtering, and/or data refresh timing between the Benefit Recommendations service and the FOCUS export.

Answer 2

The Benefit Recommendations API’s “uncovered cost” is an optimization estimate, not necessarily a direct sum of every matching FOCUS usage row. To reconcile it, align the billing scope, currency, benefit type, recommendation lookback period, and the API’s data timestamp with the export. Apply the same eligibility rules and hourly pay-as-you-go normalization used by the recommendation model, and exclude charges such as tax, refunds, Marketplace items, and usage that the benefit cannot cover. Also allow for Cost Management ingestion timing and for recent purchases or scope changes to take time to appear in recommendations. Requery both datasets after the next refresh and compare by resource, meter, region, and hour rather than only by monthly total. If a stable difference remains, open Microsoft support with the API request, response timestamp, billing scope, sample resource a