Benefit Recommendations charges vs FOCUS uncovered compute OD what population does 'charges' represent in the recommendation API?

Hello @Shahar Margulis ,

Welcome to Microsoft Q&A.

The Benefit Recommendations API documentation defines usage.charges as the hourly on-demand charges between firstConsumptionDate and lastConsumptionDate that were used to calculate the benefit recommendation. The documentation does not describe it as all charges belonging to a set of service or meter categories.

Microsoft also documents that savings plan recommendations are generated from actual on-demand usage and costs, including negotiated on-demand discounts, but only for savings plan-eligible resources. The recommendation engine evaluates this eligible usage hour by hour and runs multiple simulations to determine a cost-effective hourly commitment.

Because of that, filtering FOCUS only by values such as x_SkuMeterCategory = Virtual Machines, Azure App Service, or Azure Container Apps is unlikely to reproduce the recommendation population exactly. x_SkuMeterCategory identifies the service classification of the meter, while x_SkuMeterId identifies the specific usage meter and pricing construct. A service category can contain meters with different pricing and benefit eligibility.

The broad service filter should also exclude charges that are not covered by a compute savings plan. Microsoft states that Savings Plan for Compute applies to eligible infrastructure costs and does not cover software, networking, or storage charges. Software charges, including applicable Windows software meters, remain separate from the infrastructure discount.

I could not find a documented FOCUS filter or a static public meter list that Microsoft guarantees will exactly match usage.charges. The closest documented method would be to determine eligibility at the meter level rather than the service-category level. Microsoft’s price sheet documentation states that when a meter is eligible for a savings plan, the price sheet contains a corresponding rate with priceType set to SavingsPlan. You could therefore identify the eligible meter IDs from the applicable billing price sheet and join them to FOCUS through x_SkuMeterId.

For the comparison, I would also align the exact billing scope, currency, firstConsumptionDate and lastConsumptionDate returned by the API, and use on-demand usage rows without an applied reservation or savings plan. Since the recommendation documentation says negotiated on-demand discounts are included, comparing public list cost rather than the customer’s discounted on-demand cost could also produce a difference.

Finally, the recommended commitment should not be expected to equal the total uncovered cost divided by the number of hours. The engine evaluates the shape of hourly eligible spend and runs simulations, and Microsoft also documents additional recent-usage simulations intended to avoid recommending an excessive commitment after usage decreases.

Therefore, the difference does not necessarily indicate that the API is omitting eligible usage. It may mean that the current FOCUS query is selecting a broader population than the specific eligible on-demand meters used by the recommendation engine. If a meter-level comparison based on the price sheet still produces a significant discrepancy, I would recommend opening a Cost Management support request and providing the API response, exact FOCUS window, billing scope, currency, and the list of included x_SkuMeterId values.

I hope this helps.

Hi, thanks for the guidance.

I followed the steps you described to try to reproduce usage.charges:

From the Benefit Recommendations API (Compute Savings Plan, Last30Days), I took the hourly usage.charges series for the same billing scope and the same firstConsumptionDate / lastConsumptionDate window. My understanding is that this is the uncovered on-demand usage used to size the recommendation.

From FOCUS, for that same billing scope and window, I kept only uncovered on-demand usage (ChargeCategory = Usage, PricingCategory = Standard, no reservation / savings plan applied).

For eligibility, I used the Retail Prices API (not a local cached subset): Consumption meters that include a savingsPlan section, restricted to Compute Savings Plan services only, and joined to FOCUS on x_SkuMeterId = meterId.

I compared both list cost and effective (negotiated) on-demand cost.

I still cannot reproduce usage.charges - FOCUS remains much higher than the API series.

Can I attach the x_SkuMeterId / meterId list I used for the join? What do you recommend as the next steps?

Thanks.