FOCUS Spec Explained: The Billing Standard Behind 2026 FinOps

FOCUS is an open specification maintained by the FinOps Foundation that defines a common set of column names, data types, and semantics for cloud billing and usage data. A provider that publishes a FOCUS-conformant export is agreeing to label the same concepts the same way a competitor does, in the same table shape, so a query written against one export mostly works against another.

It exists because the FinOps practice outgrew single-cloud tooling years before any single cloud vendor had an incentive to make cross-cloud reporting easy. The FinOps Foundation itself now counts over 12,000 FinOps Certified Practitioners across more than 3,500 organizations, up from roughly 6,000 practitioners in 2024 — a practitioner base large enough, and multi-cloud enough, to force a standard rather than wait for one. FOCUS is the result: not a product, not a tool, just an agreed-upon shape for the data every FinOps tool and dashboard already needs.

Practically, you consume FOCUS as a table — a FOCUS-shaped export sitting in a data warehouse or query engine, generated by the provider (or by a tool that reshapes a native export into FOCUS columns). You query it like any billing table. The difference is that the same query, aimed at an AWS FOCUS export and an Azure FOCUS export, returns comparable numbers without a translation layer in between.

Before FOCUS, "what did we spend on compute last month, across all three clouds" was three separate queries against three separate schemas, each using a different word for the same concept, and each with its own quirks for discounts, credits, and amortization. Here is the same handful of concepts across native exports:

None of those native names are wrong — each makes sense inside its own provider's model. The cost is entirely downstream: every team building a cross-cloud report writes three versions of every query, three sets of discount-handling special cases, and three slightly different definitions of "service," then maintains all of it forever as each provider tweaks its export format. That maintenance burden, multiplied across an industry where the average organization uses 3.4 cloud providers, is the actual problem FOCUS is solving.

A handful of FOCUS columns carry most of the analytical weight. Understanding what each one means — and which sibling column it's easy to confuse it with — is most of what you need to start building reports on FOCUS data.

• BilledCost, EffectiveCost, ListCost, ContractedCost. Four views of the same charge. BilledCost is what actually appears on the invoice for that billing period. EffectiveCost amortizes commitment discounts evenly across their term instead of showing them as a lump sum. ListCost is the public, undiscounted list price — useful for measuring how much a negotiated discount is actually saving you. ContractedCost applies your negotiated rate without commitment amortization. Picking the wrong one of these four for a given report is the most common FOCUS mistake.
• ChargeCategory. Classifies the row — usage, purchase (like a commitment buy), tax, credit, adjustment. Filtering or grouping by this is how you separate "what we consumed" from "what we prepaid for" without guessing from the description text.
• ChargePeriodStart / ChargePeriodEnd. The time window the charge applies to. Matters because a single invoice line can represent usage spread across a period different from the invoice date itself — critical for building accurate monthly trend lines.
• ServiceName / ServiceCategory. ServiceName is the specific product (e.g. a managed database service); ServiceCategory is the broader grouping (e.g. "Databases"). Reporting at the category level is usually what makes cross-cloud rollups readable, since exact service names rarely match one-to-one between providers.
• ResourceId. The specific resource instance that generated the charge, when the provider exposes one. The join key for attaching cost to infrastructure inventory.
• SkuId / SkuPriceId. Identify the exact billable item and the exact price point applied to it. Two rows with the same SkuId can still have different SkuPriceId values if different pricing (on-demand vs a negotiated rate) applied.
• CommitmentDiscountId / CommitmentDiscountStatus. Identify which commitment (a specific reservation or savings-plan-equivalent) covered a charge, and whether that commitment is used, unused, or expired. This is what lets you trace EffectiveCost back to the specific commitment responsible for the discount.
• PricingQuantity vs ConsumedQuantity. ConsumedQuantity is the raw usage amount; PricingQuantity is the quantity actually billed, which can differ when a provider bills in blocks or rounds up. A mismatch between the two is often the first sign a pricing tier boundary is being crossed.
• Tags. Carried through as a structured field rather than invented per provider, but FOCUS does not require — or enforce — any particular tag key naming convention. That part is still on you.

This is the single most-misread pair in the spec, and it is entirely about timing. BilledCost reflects when money actually left the bank; EffectiveCost spreads a commitment's value evenly across the period it covers. A prepaid annual commitment makes the two diverge hard in month one, then stay diverged in opposite ways for the rest of the term.

Take a simple case: a team prepays a one-year commitment in January. BilledCost for January shows the full prepayment — a massive one-month spike. BilledCost for every month after that shows roughly zero for the covered usage, because the money already moved. EffectiveCost, by contrast, divides the prepayment by twelve and shows the same flat monthly number from January straight through December — because that flat number is what the commitment is actually worth to you, month by month, regardless of when you paid for it.

Which one belongs in which report is not a matter of taste. BilledCost belongs in cash-flow and invoice-reconciliation reporting — finance needs to know what actually left the account and when. EffectiveCost belongs in unit-economics, forecasting, and showback/chargeback reporting — anything where you're trying to answer "what does running this actually cost per month" needs the smoothed number, not the lump sum. Build a monthly cost trend dashboard on BilledCost and a one-time prepayment will look like a permanent cost explosion followed by a mysterious collapse to zero — neither of which reflects reality.

This is the honest limits section, and it matters more than the feature list. FOCUS standardizes column names and semantics. It does not standardize everything underneath them, and treating a FOCUS export as a finished multi-cloud cost model will leave real gaps.

• Commitment amortization semantics still differ in substance. FOCUS gives you one EffectiveCost column, but the underlying commitment products — reservations, savings-plan-style commitments, committed-use discounts — still have different terms, different flexibility, and different edge cases around partial utilization. The column matches; the economics behind it don't.
• Kubernetes shared-cost splitting is not in scope. FOCUS describes a billing line, not how to divide a shared cluster's cost across namespaces, teams, or workloads. That allocation logic is a separate layer you build on top.
• Tag and label naming is still yours to govern. FOCUS carries tags through as a structured field but enforces no naming convention, so "team," "Team," and "owning-team" can still all show up across your estate meaning the same thing. A real tagging strategy is still a prerequisite for clean allocation — see our guide to building a cloud tagging strategy that actually sticks.
• SKU taxonomy is not unified. A FOCUS SkuId is still provider-specific; FOCUS doesn't map "a medium general-purpose VM" across AWS, Azure, and GCP into one canonical SKU. Comparable-instance mapping remains a separate, ongoing exercise.

None of this is a knock on the spec — it was never trying to solve these problems. The risk is adopting FOCUS and assuming the multi-cloud allocation problem is now solved, when what actually happened is that the column-naming layer of the problem got solved and the semantic layer is exactly where it was.

In general terms, the major cloud providers and billing-adjacent platforms now offer some form of FOCUS-conformant export, and the trend among mid-size platforms is to add one rather than resist the standard — adoption pressure from FinOps teams managing multi-cloud estates is real enough that it's become close to table stakes for any billing export product. The FinOps Foundation's State of FinOps 2026, which represents organizations responsible for over $83 billion in cloud spend, reports 57% of organizations are planning FOCUS adoption and that 66% find multi-cloud management challenging overall (80% of enterprises, 47% of SMBs) — a gap FOCUS is aimed squarely at closing. For the fuller set of findings behind those numbers, see our breakdown of the State of FinOps 2026 report.

The practical gotcha: "this export is FOCUS-conformant" describes the schema, not a guarantee every row is populated correctly or every optional column is present. Conformance levels and optional-column coverage vary, and a provider can ship a technically conformant export where a column you expected is sparsely populated or absent for certain charge types. Validate a new FOCUS export against a few known invoice totals before trusting it in a report — the same way you'd sanity-check any new data source. Exact conformance details and per-provider coverage change often enough that checking the current FinOps Foundation conformance documentation before committing to a column is worth the five minutes.

Worth noting while you're validating: 98% of FinOps teams now manage AI costs, up from 63% in 2025 and 31% in 2024, which means newer AI/ML service line items are exactly the category most likely to be a recent addition to a provider's FOCUS export — and the most worth double-checking for completeness.

Don't rip out existing provider-specific reports and rebuild everything on FOCUS in one pass. A staged migration catches the gaps described above before they reach a dashboard finance actually relies on.

1. Turn on the export and leave existing reporting untouched. Get the FOCUS-conformant export flowing into your warehouse or query engine alongside your current native exports. Nothing downstream changes yet.
2. Validate it against known totals. Reconcile BilledCost sums against actual invoice totals for a couple of recent months. Check that the columns you plan to rely on — EffectiveCost, CommitmentDiscountId, Tags — are actually populated for your account's charge types, not just present in the schema.
3. Rebuild one report on FOCUS columns first. Pick something low-stakes and genuinely cross-cloud — a "top services by spend" summary is a good choice — and rebuild it against FOCUS instead of the native exports. Compare outputs side by side for a full billing cycle.
4. Migrate allocation logic next. Once the basic report checks out, move showback/chargeback and tag-based allocation onto FOCUS columns. This is where gaps in tag coverage or commitment mapping tend to surface, so budget real time for it.
5. Retire the provider-specific queries last. Only after FOCUS-based reports have run in parallel with the old ones for at least one full billing cycle without unexplained drift should the native-schema queries actually get deleted.

Example 1: one query, three clouds. Consider the question "what are our top 10 services by effective cost last month, across all clouds." Written natively, that's three different queries with three different discount-handling quirks:

The win isn't just fewer keystrokes. It's that the team stops maintaining three separate sets of discount-handling logic — the RI/savings-plan join on AWS, the reservation-row handling on Azure, the credit-array unnesting on GCP — and the cloud-specific branching that glues those three query results into one dashboard. Consolidating onto FOCUS means deleting two of the three query definitions entirely and retiring whatever transformation layer previously reconciled their different "service" groupings.

Example 2: BilledCost vs EffectiveCost on a real prepaid commitment. A team prepays $120,000 for a one-year commitment in January. $120,000 ÷ 12 months = $10,000/month of amortized value. Here's how the first six months look under each column:

A dashboard built on BilledCost tells a very misleading story in February. January already looked like a budget emergency — a $120,000 one-month spike against a normal baseline. Then February shows $0, which reads just as alarming in the other direction: did the team stop using the service, did an outage drop usage to zero, did billing break. Neither read is true. The real number — the one that should drive a CFO conversation, a forecast, or a unit-economics calculation — is EffectiveCost's flat $10,000 a month, which is exactly what the commitment costs to run every single month, independent of when the invoice happened to post. Organizations that build their reporting discipline around getting this kind of distinction right are, per the FinOps Foundation, 2.5x more likely to meet their cloud ROI expectations than those that don't.