FOCUS: The Common Language Cloud Billing Has Been Missing - a.k.a. Why I Care About FOCUS

After spending years working across Azure, AWS, and GCP, I can tell you the most frustrating part of FinOps is rarely the optimization itself. The hard part is getting everyone in the room to agree on what the data actually means before anyone can act. Every provider exports billing differently, every tool invents its own abstraction layer on top of that, and every dashboard ends up starting with translation instead of analysis. You spend the first hour of every cost conversation reconciling vocabulary, and by the time everyone agrees on what a "cost" even is, the meeting is over. It's exhausting.

That is the exact problem FOCUS set out to solve, and it is why it earned a permanent spot in how I think about multi-cloud reporting. The FinOps Open Cost and Usage Specification (FOCUS for short) is not trying to replace cloud billing or become yet another tool you have to buy. It's an open specification that defines a vendor-neutral schema for cost and usage data, so that a row from Azure, a row from AWS, and a row from GCP all use the same column names, the same definitions, and the same semantics. If you have ever maintained a pile of brittle mapping logic just to make three billing exports comparable, you already understand why a shared grammar matters more than any single feature.

The way I describe it to clients is that FOCUS gives us a common language for billing data the same way that SQL gave us a common language for relational queries. You still have provider-specific depth underneath, and you still need to know your own environment, but the surface you report against stops shifting every time a provider renames a column or restructures an export. That stability is the whole point, and it's worth more than most people realize until they have lived without it.

What FOCUS Actually Is Under the Hood

Before getting into the fun reporting examples, it helps to be precise about what the specification gives you, because the design decisions are where the real value hides. FOCUS defines a set of standardized datasets made up of columns, and every column is either a Dimension or a Metric. Dimensions are the descriptive attributes you group and filter on, so things like ServiceName, RegionId, ResourceId, and ChargeCategory. Metrics are the things you actually measure and sum, so things like BilledCost, EffectiveCost, and ConsumedQuantity. Once that split clicks, a huge amount of cross-cloud reporting becomes mechanical instead of artisanal (yay!), because you'll always know which columns belong in your GROUP BY and which columns belong in your SUM.

The second design choice that matters is the difference between what is standardized and what stays provider-defined. Categories in FOCUS are standardized enumerations, so ChargeCategory will always be one of a known set of values like Usage, Purchase, Tax, Credit, or Adjustment, no matter which cloud produced the row. The more specific Type-style columns underneath stay provider-defined, because nobody wants the spec to pretend that an Azure SKU and an AWS SKU are the same thing when they are not. This is the right tradeoff, and it is the part people miss when they assume FOCUS is going to flatten away all provider nuance. It standardizes the shape of the question and leaves room for the provider-specific answer, which is exactly what you want when you are trying to compare apples to apples without lying to yourself about the oranges.

There is also a quiet but important commitment to data integrity baked into the columns themselves. Every charge carries a ChargeClass that flags corrections to previous charges, a ChargePeriodStart and ChargePeriodEnd that tell you exactly what window the charge applied to, and a ChargeFrequency so you know whether a line is one-time, recurring, or usage-based. When you start building real pipelines, those metadata columns are the difference between a report you trust and a report you constantly have to apologize for in front of finance. I have learned to appreciate these the hard way, which is usually how anyone learns to appreciate good metadata!

The Cost Columns That Actually Matter

If you only learn one thing about FOCUS, learn the cost columns, because they encode the single most expensive misunderstanding in cloud finance. FOCUS gives you four distinct cost figures for a charge, and each one answers a different question. ListCost is the public retail price with no discounts applied, calculated as ListUnitPrice multiplied by PricingQuantity. ContractedCost is the price after your negotiated contractual discounts, like an enterprise agreement or a private pricing deal, but before any commitment-based discounts get layered on. EffectiveCost is the amortized cost after everything has been applied, including commitment discounts and the appropriate slice of any prepaid purchase that covered the charge. BilledCost is the amount that actually landed on the invoice for that billing period.

The reason this matters so much is that "How much did this cost?" is a genuinely ambiguous question, and most billing arguments are really four people each answering a different version of it. Finance usually wants BilledCost, because that's what hits the bank account and ultimately what the invoice says. Engineering trends and showback usually want EffectiveCost, because it smooths out lumpy upfront purchases and reflects the true run-rate of a workload. Savings reporting wants everything, because the gap between them is literally where your savings live. Once you have these columns sitting side by side in a consistent schema, you stop having the "well, it depends what you mean by cost" conversation, and you start having a far more productive conversation about which number is appropriate for which decision.

The savings math falls right out of these columns, and this is the part that tends to make finance teams light up. Your negotiated savings are ListCost minus ContractedCost, which tells you what your enterprise agreement and private pricing are actually worth. Your commitment savings are roughly ContractedCost minus EffectiveCost, which tells you what your reservations and savings plans are buying you on top of that. Your total savings are ListCost minus EffectiveCost, the full distance from sticker price to what you really paid. Being able to express all three in one query, across three clouds, with the same column names, is the kind of thing that used to take a custom spreadsheet per provider and a very patient analyst.

The Amortization Trap, and How FOCUS Handles It

Here is an example that breaks more cost dashboards than any other, and it's worth walking through slowly because FOCUS handles it cleanly once you understand the mechanics. Say you buy a one-year reserved instance or a savings plan with an upfront payment. In a naive billing export, that purchase shows up as a big lump in the month you bought it, and then the usage it covers shows up as zero-cost rows for the next twelve months. If you chart raw invoice amounts, you get a giant spike followed by a year of artificially cheap-looking usage, and anyone trying to read a trend from that chart is going to draw the wrong conclusion every single time.

FOCUS gives you the tools to see through this without writing your own amortization engine. The upfront purchase carries a ChargeCategory of Purchase, while the usage it covers carries a ChargeCategory of Usage with a BilledCost of zero (because you already paid for it) but an EffectiveCost that is not zero (because the amortized slice of your prepayment is allocated to that usage). So if you sum BilledCost, you see the real cash-flow picture with the lump intact, which is what finance reconciles against. If you sum EffectiveCost and exclude the Purchase rows to avoid double counting, you get a smooth accrual-style trend that actually reflects how much that workload costs to run. Same dataset, two completely different and equally valid views, no custom code, no per-provider hacks.

That single capability is worth the price of admission for a lot of teams I feel, and it's one of those things that sounds academic until the first time it saves you from a very awkward conversation. I have watched practitioners spend weeks building amortization logic that FOCUS hands you for free, and the relief on their faces when they realize the spec already solved it is genuinely fun to witness. The lesson I keep coming back to is the column definitions are not bureaucratic detail, they are the product, and the people who internalize them get disproportionately more value out of every dataset they touch.

Reading the Same Data Across Azure, AWS, and GCP

The promise of FOCUS is only as good as provider support, so it is worth being honest about where things actually stand, because the gap between the spec and any given provider's implementation is where reality lives. As of right now, every major cloud has shipped FOCUS exports, but they are at slightly different versions and with different known gaps, which is exactly the kind of thing you want to check before you build a pipeline on top of an assumption.

On AWS, you get FOCUS-formatted data through Cost and Usage Report 2.0, which can emit FOCUS-conformant Parquet files into an S3 bucket that you then query with Athena. AWS was the first major provider to ship native FOCUS exports, and to their credit they publish a conformance report that documents exactly where their implementation deviates from the spec. I want to point out how much I respect that move, because no provider hits one hundred percent conformance yet, and knowing precisely where the gaps are is infinitely more useful than pretending they do not exist. When you are reconciling AWS data, that conformance report should be open in another tab.

On Azure, FOCUS datasets come out of Cost Management exports, and Microsoft has documented the mapping pretty thoroughly over on Microsoft Learn. One nice Azure-specific touch is that the export populates an InvoiceId column once an invoice is generated for Microsoft Customer Agreement accounts, which makes invoice reconciliation a lot less painful than it used to be. Microsoft has also been one of the more vocal adopters, and at FinOps X this week they announced plans to support FOCUS 1.4 during 2026, which tells you the investment is not slowing down. If you live in Azure billing the way I often do, the FOCUS export is a meaningfully better starting point than wrangling the older Cost Management schema by hand.

On GCP, FOCUS data is available through the billing export into BigQuery, which fits naturally into how most GCP shops already do their cost analysis. Google has been leaning into the openness angle as a competitive position, betting that consistency across platforms becomes an advantage rather than a threat in a multi-cloud world. The practical upshot is that you can stand up a FOCUS view in BigQuery, an Athena table over your AWS Parquet, and an Azure export, and then write reporting logic that targets the same column names against all three. The data still has to be loaded and the gaps still have to be understood, but the reporting surface finally stops fighting you, and that is a real shift from where we were even two years ago.

Reporting Examples - Where the Payoff Shows Up

Abstract schema talk is fine, but the reason FOCUS earns its keep is that real questions get dramatically easier to answer. Let's walk through a few that come up consistently.

The first example being the deceptively simple "what did we spend by service last month," which historically meant writing three different queries against three different schemas and hoping you mapped the service concepts correctly. With FOCUS, it collapses into one shape that runs against any conformant dataset:

SELECT
  ProviderName,
  ServiceCategory,
  ServiceName,
  SUM(EffectiveCost) AS effective_cost
FROM focus_data
WHERE ChargePeriodStart >= DATE '2026-05-01'
  AND ChargePeriodEnd   <  DATE '2026-06-01'
  AND ChargeCategory     =  'Usage'
GROUP BY ProviderName, ServiceCategory, ServiceName
ORDER BY effective_cost DESC;

Because ServiceCategory is a standardized dimension, you get a clean cross-provider rollup that groups compute against compute and storage against storage, instead of a jumble of provider-specific service names that nobody outside the platform team can interpret. This feat alone changes who can self-serve a cost report, which is usually the real organizational win.

The second example is the savings breakdown I mentioned earlier, and this is where having all four cost columns in one place pays off in a way that feels almost unfair after spending years piecing this together. You can show negotiated savings, commitment savings, and total savings in a single pass, sliced by whatever dimension your audience cares about:

SELECT
  ProviderName,
  SUM(ListCost)                        AS list_cost,
  SUM(ContractedCost)                  AS contracted_cost,
  SUM(EffectiveCost)                   AS effective_cost,
  SUM(ListCost - ContractedCost)       AS negotiated_savings,
  SUM(ContractedCost - EffectiveCost)  AS commitment_savings,
  SUM(ListCost - EffectiveCost)        AS total_savings
FROM focus_data
WHERE ChargePeriodStart >= DATE '2026-05-01'
  AND ChargePeriodEnd   <  DATE '2026-06-01'
  AND ChargeCategory     =  'Usage'
GROUP BY ProviderName;

When you put that table in front of a finance partner, the conversation shifts from "are we even saving money" to "where should we commit next," which (to me) is a much better conversation worth having. The reason it works is entirely down to the columns being defined consistently, and it's a good example of how the boring schema decisions translate directly into better executive discussions.

The third example is the amortization-aware trend, which is where you prove to yourself that smoothing actually works. You chart EffectiveCost over time while filtering out the Purchase rows so you don't double count your prepayments, and you get a run-rate that tells the truth:

SELECT
  DATE_TRUNC('month', ChargePeriodStart) AS month,
  SUM(EffectiveCost)                      AS amortized_spend
FROM focus_data
WHERE ChargeCategory <> 'Purchase'
GROUP BY DATE_TRUNC('month', ChargePeriodStart)
ORDER BY month;

Run the same query swapping EffectiveCost for BilledCost while removing the Purchase filter, and you will see the lumpy cash view side by side with the smooth accrual view. Showing both to stakeholders, from the same table, with a one-line change between them, is the kind of thing that quietly builds trust in your data, and trust is the currency the whole FinOps discipline runs on.

What FinOps X 2026 Reinforced

I am writing this after FinOps X 2026 just wrapped up in San Diego, and the theme this year leaves no ambiguity about where the discipline is headed. The whole event was organized around AI value, token economics, and what the industry is calling agentic FinOps. The opening keynote framed tokens as the atomic unit of AI the same way that a compute hour or a stored gigabyte has been the atomic unit of cloud. The growth and variability of token usage is creating a brand new class of cost-management problems, and the community is clearly treating it as the next major frontier rather than a side topic.

A few concrete things came out of the keynote that matter for anyone building on FOCUS. Microsoft announced plans to support FOCUS 1.4 in 2026, which signals that provider investment in the spec is accelerating rather than plateauing. The Foundation also announced the intent to form a Tokenomics Foundation, uniting token consumers and suppliers to build open standards for AI billing, which is essentially the FOCUS playbook being run again for a new category of spend. And in a sign of just how central AI has become, the event itself is folding into a broader Tokenomicon conference in 2027. Practitioners from companies like SAP, Prudential, and Shutterstock shared their AI cost journeys, and the honesty about trade-offs and false starts was refreshing compared to the usual conference polish.

This all connects back to the 2026 FinOps Framework, which expanded the discipline well beyond public cloud into AI, SaaS, licensing, data center, and data platforms. The number that stuck with me is that ninety-eight percent of FinOps teams now manage AI spend, up from thirty-one percent just two years ago, which is one of the fastest scope expansions I have seen in any practice. The Framework formalized Technology Categories like FinOps for AI, FinOps for SaaS, FinOps for Data Center, and FinOps for Data Cloud Platforms, giving practitioners actual guidance for spend that used to fall outside the playbook entirely. When your remit grows that fast across so many categories, a standardized cost format stops being a nice-to-have and becomes the only realistic way to keep up, which is precisely why FOCUS adoption is climbing.

Certification Takeaways

My biggest takeaway from going through the certification was not memorizing column names, and if that is all you walk away with, you have missed the point. The thing that actually stuck was understanding why the specification was designed the way it was, because once you grasp the intent, the column definitions stop being trivia and start being a model you can reason from. Categories are standardized while Types stay provider-defined, Dimensions describe while Metrics measure, and EffectiveCost tells you what you actually paid after commitments rather than what the list price pretends. Those are small decisions on paper, and they are the difference between cross-cloud reporting that is mechanical and cross-cloud reporting that is a perpetual negotiation.

What I appreciated most is that the spec is opinionated in the places that need opinions and flexible in the places that need flexibility. It refuses to pretend that two providers' SKUs are identical, but it insists that the question you ask about them looks the same regardless of source. That balance is hard to get right, and the fact that the community landed on it through real practitioner feedback rather than committee abstraction is a big part of why it works in production. If you spend your days in cloud cost data, the certification is worth the time...less for the credential itself and more for the way it rewires how you think about every billing export you will ever touch again.

Where This Is Going

FOCUS has shipped several major versions in a short span, and the current release is 1.3, ratified in December 2025. That version added a dedicated Contract Commitment dataset that isolates contract terms like start and end dates and remaining units from your cost and usage rows, new columns for splitting shared costs along with visibility into how a provider allocated them, and data recency and completeness flags so you know whether a dataset is final or still subject to revision. If you have ever made a decision on data that turned out to be incomplete, you understand why those flags are quietly one of the best additions in the whole spec. You can read the full release notes in the FOCUS 1.3 announcement.

The momentum is not slowing down either. Version 1.4 is already in active development, the Foundation is standing up a conformance certification program for data generators so that provider claims become verifiable rather than aspirational, and the pressure to extend the spec deeper into AI and data center spend is intense given where the discipline is heading. Roughly sixty-eight percent of organizations spending one hundred million dollars or more annually are already using or experimenting with FOCUS-formatted data, which tells you this is well past the early-adopter phase and into the part where not having a strategy starts to look like a liability.

If you want to go deeper, the FOCUS specification itself is readable in a way that specs usually are not (huzzah!), the 2026 FinOps Framework writeup is the best summary of how the scope expanded, and the FOCUS GitHub repository is where the working drafts and validation tooling live if you want to follow the sausage being made. My honest recommendation is to pull a real FOCUS export from whichever cloud you spend the most in, write the three queries above against it, and feel for yourself how much friction disappears. That hands-on hour will teach you more about why this matters than any amount of reading (inclusive of everything I just wrote) and it's the fastest way I know to turn FOCUS from a concept you have heard of into a tool you would actually reach for in the future.