Welcome to the Learning FOCUS blog series. If this is your first post, I recommend you start with Introducing an open billing data format to get a high-level picture of what the FinOps Open Cost and Usage Specification (FOCUS) is and what it covers. This week, I’ll describe the 4 different cost columns defined in a FOCUS dataset. These are arguably the most important columns as understanding cost is the principal goal of FOCUS as an open specification.
⮜ Previous post (Intro) · Next post (Charges + pricing) ⮞
How currencies work in Cost Management
Before I jump into the cost columns, it’s important to understand how currencies work in Microsoft Cost Management. This is unrelated to FOCUS, but critical when validating FOCUS and native cost datasets.
If you’ve ever traveled internationally, you might have been asked if you want to pay in the local currency or your native currency (defined by your credit card or bank account). As an example, I live in the US and when I pay for services in Europe with my credit card, I get asked if I want to pay in US Dollars (USD) or Euros (EUR). Even if I pay in USD, the original price was based on EUR.
Restating this, vendors define prices based on a “pricing” currency and customers pay in a “billing” currency. For domestic vendors, these are usually the same. When working internationally – say, a European company working with a US-based cloud provider – you need to internalize how the bill you receive was translated from the price you agreed upon, which may be in another currency.
This is especially critical when you work at the scale of cloud computing. To visualize this, imagine you have steady usage of 24 hours per day but the provider you’re working with updates exchange rates every day to account for daily fluctuations. You might see something like this:
Service |
Date |
Hours |
Original price |
Exchange rate |
Billed price |
Cost |
Cathy’s Cloud Compute Service |
Jan 1 |
24 |
$1.00 |
0.81 |
$0.81 |
$19.44 |
Cathy’s Cloud Compute Service |
Jan 2 |
24 |
$1.00 |
1.02 |
$1.02 |
$24.48 |
Cathy’s Cloud Compute Service |
Jan 3 |
24 |
$1.00 |
0.78 |
$0.78 |
$18.72 |
Cathy’s Cloud Compute Service |
Jan 4 |
24 |
$1.00 |
0.93 |
$0.93 |
$22.32 |
Cathy’s Cloud Compute Service |
Jan 5 |
24 |
$1.00 |
0.85 |
$0.85 |
$20.40 |
Cathy’s Cloud Compute Service |
Jan 6 |
24 |
$1.00 |
1.01 |
$1.01 |
$24.24 |
Cathy’s Cloud Compute Service |
Jan 7 |
24 |
$1.00 |
0.89 |
$0.89 |
$21.36 |
As you can see, even if you have consistent usage with a consistent price, the exchange rate can add an additional layer of complexity that makes it more difficult to predict and manage cost. (Note: Microsoft evaluates exchange rates twice a year.)
If you use an Enterprise Agreement (EA) account, this all happens behind the scenes. Pricing and billing currencies are the same, but the contracted unit price can still change based on global currency fluctuations since the unit price isn’t completely locked. Microsoft Customer Agreement (MCA) and Microsoft Partner Agreement (MPA) accounts on the other hand are more transparent by including both the pricing and billing currency, the exchange rate, and the date the exchange rate was locked. For consistency, the Microsoft FOCUS dataset includes these consistently for EA accounts as well. This includes:
Column |
Source |
Description |
Sample |
BillingCurrency |
FOCUS |
Currency used on the invoice. |
JPY |
x_PricingCurrency |
Microsoft |
Currency used to determine the original price. |
USD |
x_BillingExchangeRate |
Microsoft |
The amount of the pricing currency needed to equal the billing currency. |
147.16 |
x_BillingExchangeRateDate |
Microsoft |
Date the exchange rate was determined. |
2024-01-01T00:00:00Z |
As an example, if I have a charge priced in USD at $1 per unit, but my billing account is paid in Japanese Yen (JPY), then I need to multiply the unit price by the exchange rate to determine my unit price in the billing currency.
(Original price) * (Exchange rate) = (Billed price)
1 USD * 147.16 = 147.16 JPY
Since FOCUS includes all prices and costs in the billing currency, the only reason you would need to do this math is to compare prices in FOCUS with prices in the actual or amortized cost dataset. As an example:
(FOCUS) ContractedUnitPrice / x_BillingExchangeRate = (Actual cost) UnitPrice
Alternatively, you could also use:
(FOCUS) ContractedUnitPrice = (Actual cost) UnitPrice * ExchangeRatePricingToBilling
In general, you should not need to use these. I’m mainly covering them so you are aware of the difference when reviewing prices and costs FOCUS and non-FOCUS datasets.
Different cost metrics
FOCUS defines 4 different variations of the cost metric with and without specific discounts.
ListCost is based on the list or retail unit price without any discounts applied. List unit price is sometimes referred to as the market price or pay-as-you-go price. ListCost maps to PaygCostInBillingCurrency for MCA accounts. EA accounts do not have an equivalent column and should compare FOCUS ListUnitPrice to actual/amortized PayGPrice. We’ll talk more about ListUnitPrice in a future post.
ContractedCost is based on the agreed-upon (aka, “contracted”) unit price for on-demand, uncommitted use within the billing account or billing profile. ContractedCost includes negotiated, enterprise discounts but does not include commitment discounts. Native schemas do not have an equivalent column and should compare FOCUS ContractedUnitPrice to actual/amortized UnitPrice. Please note UnitPrice for on-demand, uncommitted usage may be derived and span multiple levels of tiered or graduated pricing. In this case, the prices may not match exactly. We’ll talk more about ContractedUnitPrice in a future post.
BilledCost is ultimately what you were charged for the line item and what you’ll find on the invoice. Pretty straightforward. BilledCost maps to CostInBillingCurrency for MCA accounts and Cost for EA accounts in the actual cost dataset in Microsoft Cost Management.
EffectiveCost is the amortized cost for the line item after applicable commitment discount purchases have been spread across the commitment term and split across the resources that utilized the benefit. EffectiveCost maps to CostInBillingCurrency for MCA accounts and Cost for EA accounts in the amortized cost dataset in Microsoft Cost Management.
If you’re using an MCA account, you’ll also notice 4 additional extended columns: x_ListCostInUsd, x_ContractedCostInUsd, x_BilledCostInUsd, and x_EffectiveCostInUsd. These are the US Dollar equivalent of the corresponding FOCUS columns to support aggregating costs across accounts with different currencies. Note these columns are also in the EA FOCUS dataset, but they don’t have values.
How amortization works
If you’re new to commitment discounts like reservations and savings plans in Azure, you may not be familiar with amortization. Amortization is the process of breaking down commitment discount purchases, spreading the cost over the commitment term, and splitting the cost across the resources that leveraged the benefit. For example, let’s say you purchase a 1-year commitment discount for $365. The purchase will have a BilledCost of $365 and usage will be $0, since it’s covered by the purchase. Since the EffectiveCost is amortized, the purchase will be $0 and the daily usage will be $1 for each of the 365 days for a total of $365 for the year.
ChargeDescription |
ChargePeriodStart |
BilledCost |
EffectiveCost |
Reservation |
Jan 1 |
$365.00 |
$0.00 |
VM usage |
Jan 1 |
$0.00 |
$1.00 |
VM usage |
Jan 2 |
$0.00 |
$1.00 |
VM usage |
... |
... |
... |
VM usage |
Dec 31 |
$0.00 |
$1.00 |
Sum of 365 days |
(Jan 1-Dec 31) |
$365.00 |
$365.00 |
Of course, this is just a quick intro to amortization to explain how the BilledCost and EffectiveCost columns behave. I’ll discuss amortization in more detail in a future post.
Calculating negotiated and commitment discounts
The last thing I want to cover this week is how to calculate negotiated and commitment discounts per row. Both are pretty straightforward, but there are some important considerations to keep in mind.
Negotiated discounts are the difference between ListCost and ContractedCost. So if the list cost is $100 and you have a 10% negotiated discount, you can expect to see something like the following:
(ListCost) - (ContractedCost) = (Negotiated discount amount) / (ListCost) = (Negotiated discount percent)
$100 - $90 = $10 savings / $100 = 10% discount
Similarly, commitment discounts are the difference between ContractedCost and EffectiveCost:
(ContractedCost) - (EffectiveCost) = (Commitment discount amount) / (ContractedCost) = (Commitment discount percent)
$100 - $40 = $60 savings / $100 = 60% discount
Again, this is straightforward for a single row, but I do need to warn you that calculating savings requires a bit more context to account for amortized purchases, which will be double counted when summing ListCost and ContractedCost. To avoid this, you’ll need to filter out any amortized purchases. I’ll share details about how to calculate savings in a future post.
Reviewing cost in Power BI
Now that we’ve covered aspects of the FOCUS dataset, let’s look at real-world usage scenarios. We’ll use the FinOps toolkit Cost summary report as an example, but you can replicate this in your own reports. For those who aren’t familiar, the Cost summary report offers various breakdowns of cost data to provide a starting point for building out your own reports. As an example, the Summary page shows the accumulated cost over time along with negated and commitment discount savings, which we discussed above.
The report also includes several other breakdowns of your daily costs by service, subscription, resource group, and region. Each page includes a chart with the cost by day or month, depending on how you configure it, and a table with the details. Some offer a hierarchical view and some are flat tables with additional attributes, like the resource type, region, and tags for the Resources page. As an example, the Services page shows a table broken down by ServiceCategory, ServiceName, and ResourceName with the EffectiveCost and total savings by month.
So far, we’ve been mostly focused on EffectiveCost, since that’s the best model for chargeback purposes. But what if you want to see the invoiced amount? If we look at the Purchases page, we’ll find each purchase – these are a few reservation purchases from this test account – that were made during the period with their applicable BilledCost. This is an important distinction since these amounts will be on the invoice for the applicable billing period, but won’t match the EffectiveCost due to amortization. Again, amortization is a more complex topic which we’ll cover in more detail later.
Hopefully, these visuals help demonstrate the usefulness of each of the cost columns. I didn’t show direct use of the ListCost and ContractedCost columns, but those were used to calculate negotiated and commitment discount savings. We’ll dig into the other columns shown here in future posts. To learn more about this and other reports, see FinOps toolkit Power BI reports.
Querying cost in FinOps hubs
With FOCUS costs available in Azure Data Explorer in FinOps hubs 0.7, you now have a powerful and performant query engine that can give you the answers you need faster than ever. I can’t emphasize enough the power of having years of data at your fingertips with answers just seconds away.
This week, we’ll keep it simple since we’ve only covered cost columns. Here’s a query that sums each cost:
Costs
| summarize
x_RowCount = count(),
ListCost = round(sum(ListCost), 4),
ContractedCost = round(sum(ContractedCost), 4),
EffectiveCost = round(sum(EffectiveCost), 4),
BilledCost = round(sum(BilledCost), 4)
by BillingCurrency
I also included the row count here to demonstrate how fast the system is. We were able to summarize over 600,000 rows in 0.7 seconds! While this is a simple query, it does help demonstrate the power Azure Data Explorer makes available.
I do want to call out one part of this query that many might miss: Don’t forget to include BillingCurrency when working with cost columns. There are certain SKUs which may not be available in your billing currency, so this will ensure you don’t end up summing numbers with different currencies.
We could also dig into cost savings, but I’ll save that for a future blog post since it requires other columns. I will throw in one unexpected query that might be interesting for those who have different billing and pricing currencies. The following query looks at the x_BillingExchangeRate over time to monitor changes over time. Exchange rates don’t change often for Microsoft, but you might find it interesting.
Costs
| distinct x_BillingExchangeRateDate, x_BillingExchangeRate, BillingCurrency
| render linechart
Of course, this isn’t very interesting with my USD test account, but your results may differ. Hopefully, this gives you some ideas of interesting insights you can derive from your own account.
We’ll build on top of these columns in each blog post to demonstrate more complex scenarios. Leave a comment if you’d like to see any specific queries and I’ll make sure to cover it.
What next?
As you can see, we’re just getting started and touching on some basic elements that will need to be fleshed out more in future blog posts. Next, I’ll cover how to identify, filter, and summarize costs based on type of charge.
If you want to learn more, the FinOps Foundation offers a free Introduction to FOCUS course. And if you’re ready to dig into your own FOCUS data, check out the Power BI reports in the FinOps toolkit. These reports offer a great starting point that you can customize to meet your needs. And if you’re looking for more advanced analytics, check out FinOps hubs, which offers additional benefits, like pre-calculated savings for EA and MCA accounts.
⮜ Previous post (Intro) · Next post (Charges + pricing) ⮞
Updated Jan 15, 2025
Version 2.0flanakin
Microsoft
Joined October 08, 2019
FinOps Blog
Follow this blog board to get notified when there's new activity