FOCUS 1.3 Decoded: What Changed, What It Governs, and What It Means for Your FinOps Stack (Blog 2/5 Series)

FOCUS 1.3 was ratified on 5 December 2025. It solved three problems enterprise FinOps teams have lived with for years: how to understand shared cost allocation methodology rather than just receive an output number, how to track contract commitments without maintaining a separate system, and how to know whether billing data is actually final before building a report on it. None of those capabilities existed in any prior version of the specification.

In the 30 months since FOCUS 1.0 shipped as a stable release, the specification has grown from a cloud infrastructure billing standard covering a handful of columns into a 77-column, 14-category schema governing cloud infrastructure, SaaS, PaaS, AI token billing, shared cost allocation, contract commitments, and multi-currency normalisation. Ten-plus providers — AWS, Azure, Google Cloud, Oracle, Alibaba Cloud, and Databricks among them — now produce native FOCUS-format billing exports, and 93 of the Fortune 100 participate in FinOps Foundation programmes.

This is the technical reference to FOCUS versions 1.0 through 1.3 — what changed in each release, which columns matter for which capability, how the Conformance Program will validate a genuine implementation against a marketing claim, and what FOCUS-native architecture means for an enterprise FinOps stack.

The version timeline: the problem each release actually solved

FOCUS isn’t an academic standards project — every version has addressed a specific, documented pain point practitioners reported to the working group, and understanding what each release solved is the fastest way to see why the version your platform supports sets your governance ceiling.

FOCUS 1.0 (2023) was the first stable release — the milestone giving cloud providers a concrete, ratified target to implement. It defined the core schema: billing account dimensions, commitment discount columns, the four-metric cost model, service category normalisation, resource identification, and timeframe alignment. For practitioners, 1.0 meant the end of per-provider cost column ambiguity for cloud IaaS — EffectiveCost meant the same thing whether it came from AWS or Azure.

FOCUS 1.1 (November 2024) deepened support for cloud provider billing data and addressed a specific practitioner pain point — the ETL metadata needed to build reliable, maintainable pipelines. It added columns enabling more granular multi-cloud analysis and improved the metadata downstream ETL processes depend on for schema evolution and pipeline monitoring, reducing the brittleness of pipeline code that previously had to infer provider intent from undocumented column behaviour.

FOCUS 1.2 (May 2025) was the most consequential release since 1.0 — the version that turned FOCUS from a cloud billing standard into a full technology-estate schema. Five capabilities defined it: Cloud+ unified reporting folded SaaS and PaaS billing into the same schema as cloud spend for the first time, so a single query against AWS EC2, Azure OpenAI, and Databricks now returns comparable results with no mapping table required. Virtual currency lifecycle columns gave practitioners the ability to track Databricks DBU burn-down, Azure OpenAI token consumption, and Snowflake credit purchases in the same schema used for cloud infrastructure. Multi-currency normalisation resolved the multinational billing problem, with separate PricingCurrency and BillingCurrency columns and auditable exchange rates. Invoice reconciliation added an InvoiceID column linking every charge row to its provider invoice, automating what used to be manual month-end reconciliation. And unit-cost and density metrics gave the column structure needed for cost-per-unit analysis across providers — cost-per-GB, cost-per-request, cost-per-inference. Alibaba Cloud, Databricks, and Grafana announced FOCUS support at this release, expanding the specification well past its hyperscaler origins.

FOCUS Specification Version Timeline
──────────────────────────────────────────────────────────────────────────────
Version   Ratified          Primary Enterprise Capability Unlocked
──────────────────────────────────────────────────────────────────────────────
1.0       2023              Core cloud billing schema - stable, production-ready
                            EffectiveCost, BilledCost, ServiceCategory,
                            CommitmentDiscount columns across cloud providers

1.1       Nov 2024          ETL metadata depth - granular multi-cloud analysis,
                            improved pipeline support columns

1.2       May 2025          Cloud+ unified schema - SaaS + PaaS in same schema
                            as cloud. Virtual currency lifecycle (tokens, credits,
                            DBUs). Invoice reconciliation. Multi-currency. Unit
                            economics density metrics

1.3       Dec 2025          Shared cost allocation methodology exposure.
                            Contract Commitment supplemental dataset.
                            Data freshness + completeness metadata.
                            ServiceProviderName + HostProviderName
──────────────────────────────────────────────────────────────────────────────
Providers at 1.3:  AWS - Azure - GCP - OCI - Alibaba - Databricks -
                   Grafana - Huawei - OVH Cloud - Tencent (10+ total)
──────────────────────────────────────────────────────────────────────────────

The FOCUS cost model: four metrics that replace dozens of columns

The most practically significant contribution FOCUS makes for multi-cloud practitioners is its four-metric cost model. Before FOCUS, every provider defined “cost” differently — not just different column names, but structurally different accounting logic producing incomparable numbers for the same analytical question. AWS’s Cost and Usage Report alone contains blended cost, unblended cost, net unblended cost, reservation effective cost, savings plan effective cost, and public on-demand cost as distinct fields, each correct for a different purpose. Azure and GCP carry their own analogous sets, under different names, with different adjustment logic.

FOCUS replaces this proliferation with four metrics carrying consistent semantics across every implementing provider. BilledCost is the raw invoice amount for a charge period, before commitment amortisation — the right metric for cash flow analysis and accounts payable reconciliation, but not for resource-level allocation since large commitment purchases distort the billing-period view. EffectiveCost is the amortised, discounted cost after commitment discounts are applied and spread proportionally across the commitment period — the primary metric for allocation, chargeback, showback, unit economics, and any analytical work needing a stable, time-consistent view of what a resource genuinely costs; for AI workloads where token pricing introduces real variation, EffectiveCost is what makes trend analysis and anomaly detection reliable. ListCost is the on-demand list price with no commitments applied — the baseline for calculating how much value a commitment portfolio is actually generating by comparing it against EffectiveCost. And ContractedCost reflects contractual pricing terms distinct from both list price and commitment discounts, letting an organisation with a negotiated rate card validate that a provider is correctly applying its contracted terms.

The practical implication: calculating EffectiveCost equivalents across AWS, Azure, and GCP used to require different query logic, different amortisation handling, and different interpretations of what counts as a commitment, for each provider separately. With FOCUS, the same query returns EffectiveCost from all three using the same definition — calculated once, not three times.

FOCUS 1.2 in practice: the Cloud+ schema

FOCUS 1.2’s structural importance goes beyond its individual capabilities — it validated the specification’s central premise, that a single schema can govern billing data across fundamentally different pricing models (per-hour compute, per-token AI inference, per-query data warehousing, per-seat SaaS) without collapsing into a lowest common denominator that makes each category ungovernable.

Virtual currency lifecycle demonstrates this most clearly. SaaS and data platform providers don’t bill in simple dollar amounts per resource-hour — Databricks bills in DBUs, Snowflake in credits, MongoDB Atlas in processing units, each with a dollar value varying by contract tier and potentially denominated in a different currency than the organisation’s billing currency. FOCUS 1.2 handles this without custom schema extension: a Snowflake consumption of 25 credits priced in USD but billed in EUR gets captured through PricingCurrency (USD), the per-credit list rate in USD, BillingCurrency (EUR), the EUR invoice amount, and the FX rate used — preserving both the contractual pricing logic and the actual cash paid, with auditable exchange-rate documentation, in the same format as every other row in the estate.

For AI cost governance specifically, this is the column infrastructure making token-level attribution possible. An Azure OpenAI charge row in a FOCUS 1.2 dataset carries ServiceCategory: AI, ServiceName: Azure OpenAI Service, consumed quantity in tokens, and effective cost — meaning a single query can calculate cost-per-inference across Azure OpenAI, AWS Bedrock, and Google Vertex AI using the same column set and aggregation logic, because all three now produce FOCUS 1.2 data in the same schema. 90% of FinOps teams now govern SaaS spend and 98% govern AI spend — FOCUS 1.2 is the release that makes both governable from a single query surface.

FOCUS 1.3 decoded: three persistent problems solved

Shared cost allocation. Every multi-tenant environment — a shared Kubernetes cluster, a managed database serving multiple teams, a shared API gateway — creates an allocation problem: before a charge can be assigned to a cost centre, the shared resource’s cost has to be split across consumers using some methodology. Before 1.3, providers made that split, reported the resulting number, and documented the methodology nowhere in the billing data. Practitioners received the output with no information about how it was derived, and finance couldn’t audit the allocation because it simply wasn’t in the data. Five new Allocation columns change this: AllocatedMethodID provides a provider-defined identifier for the method used, AllocatedMethodDetails gives a human-readable description (resource-based, usage-based, or hybrid), AllocatedResourceID and AllocatedResourceName identify the shared parent resource being split, and AllocatedTags carries the cost allocation tags applied at the point of splitting. Platform teams running EKS, AKS, or GKE clusters can now receive cluster-level cost splits documenting the methodology alongside the number — when it matches an internal chargeback model, the split is accepted; when it doesn’t, the discrepancy is visible in the data rather than inferred from an unexplained variance at month-end.

Contract commitment tracking. Reserved Instances, Savings Plans, Committed Use Discounts, and enterprise contract terms create a commitment landscape most organisations track in spreadsheets and procurement systems entirely separate from the cost data reflecting their actual consumption — tying commitment terms back to cost rows has always meant joining billing data against separately maintained records with no standard schema for how commitment terms should even be structured. FOCUS 1.3 introduces a Contract Commitment dataset — a new, supplemental dataset entirely separate from the cost and usage dataset, with 13 dedicated columns covering commitment ID, type, category, description, period, quantity, unit, cost, and whether the contract’s been applied. A single query against this dataset now returns every active commitment — terms, remaining units, expiration, cost basis — with no join to the main cost dataset required, and it’s designed to be permissioned separately, so procurement and finance can query commitment terms without needing access to the full cost dataset.

Data freshness. Automated governance — budget alerts, anomaly detection, commitment optimisation triggers — acts on billing data, and if that data is incomplete, preliminary, or stale, the automated action based on it is simply wrong. Providers routinely update cost data retroactively for days after a billing period closes (commitment discount recalculations, credit adjustments, pricing corrections), and before 1.3 nothing in the schema indicated whether those updates had happened or were still pending. FOCUS 1.3 now requires dataset-level metadata with a last-updated timestamp and a completeness status flag, so an anomaly detection system that would previously have fired on preliminary data can check completeness first and defer processing until the data is confirmed final.

FOCUS 1.3 also adds ServiceProviderName and HostProviderName, distinguishing the provider making a resource available for purchase from the provider whose infrastructure it actually runs on — essential for enterprises working through resellers or marketplace vendors, where a managed Databricks environment bought through a cloud marketplace reseller previously required inferring the reseller relationship from indirect signals; now it’s explicit in the data.

The FOCUS column library: 77 columns, 14 categories

As of 1.3, the specification defines 77 columns across 14 categories and two datasets — understanding the category structure is the fastest way to assess how deep a FinOps platform’s implementation actually goes, versus just mapping the most commonly referenced columns.

FOCUS 1.3 Column Library - Category Reference
──────────────────────────────────────────────────────────────────────────────
Category              Columns   What It Governs
──────────────────────────────────────────────────────────────────────────────
Contract              13        Contract Commitment dataset: terms, start/end
                                dates, remaining units, commitment types

Billing               9         BilledCost, EffectiveCost, ListCost,
                                ContractedCost + consumption quantity/unit
                                and pricing currency columns

Commitment Discount   7         CommitmentDiscountID, Category, Name,
                                Quantity, Status, Type, Unit

Pricing               7         PricingCategory, PricingCurrency,
                                Pricing Currency cost variants,
                                PricingQuantity, PricingUnit

Account               6         BillingAccountID/Name/Type,
                                SubAccountID/Name/Type

Charge Origination    6         HostProviderName, InvoiceID,
                                InvoiceIssuerName, ProviderName,
                                PublisherName, ServiceProviderName

Allocation            5         AllocatedMethodDetails, AllocatedMethodID,
                                AllocatedResourceID/Name, AllocatedTags

Charge                4         ChargeCategory, ChargeClass,
                                ChargeDescription, ChargeFrequency

Resource              4         ResourceID, ResourceName, ResourceType, Tags

SKU                   4         SKUID, SKUMeter, SKUPriceDetails, SKUPriceID

Timeframe             4         BillingPeriodEnd/Start,
                                ChargePeriodEnd/Start

Location              3         AvailabilityZone, RegionID, RegionName

Service               3         ServiceCategory, ServiceName,
                                ServiceSubcategory

Capacity Reservation  2         CapacityReservationID, Status
──────────────────────────────────────────────────────────────────────────────
Total: 77 columns across 14 categories + Contract Commitment supplemental
dataset (13 Contract columns included in count above)
──────────────────────────────────────────────────────────────────────────────

The ServiceCategory column deserves particular attention — it carries the normalised technology category (Compute, Storage, Database, Networking, AI, Analytics, Security, and others) for every charge row across every provider. EC2, Azure VMs, and GCE all carry ServiceCategory: Compute. Azure OpenAI, Bedrock, and Vertex AI all carry ServiceCategory: AI. No mapping table required — a single column eliminates one of the most labour-intensive parts of multi-cloud reporting, the custom service taxonomy that used to normalise AWS service names, Azure meter categories, and GCP SKU descriptions into a common hierarchy by hand.

What the Conformance Program actually means for procurement

The FinOps Foundation is launching a formal Conformance Program in 2026 producing an auditable, public record of each provider’s actual FOCUS implementation — addressing the biggest current gap in the ecosystem, which is that “we support FOCUS” has been an unverifiable claim without a manual review of a provider’s export documentation. The programme will produce sample data validating conformance, a formal mapping document specifying whether each FOCUS column is a direct one-to-one mapping, a documented transformation, or unsupported in the current implementation, and a Conformance Gap Report documenting support level per column, categorised by specification version.

The procurement implication is direct: a FinOps vendor claiming FOCUS support should be able to produce its Conformance Gap Report once the programme launches. A report showing full column coverage with one-to-one mappings is materially different from one showing partial coverage with transformation-derived fields and several unsupported columns — and both platforms could currently claim “FOCUS support” with nothing distinguishing them. Requesting this report, alongside the direct architecture question of whether FOCUS is the primary data model or an export layer, should become a standard part of any FinOps platform evaluation.

FOCUS-native versus FOCUS-compatible, in practice

A FOCUS-compatible platform takes provider billing data, processes it through its own proprietary internal schema, and surfaces FOCUS-labelled fields in its reporting layer — the EffectiveCost a practitioner queries is derived from the platform’s own internal cost model, possibly constructed from AWS’s, Azure’s, and GCP’s different native cost fields using the vendor’s own mapping logic. The FOCUS label is applied after translation; the semantics are approximated, not specified. A FOCUS-native platform ingests provider billing data directly into FOCUS columns — when AWS exports FOCUS 1.2 data, the EffectiveCost in the platform’s datastore carries the exact value AWS placed there, with FOCUS-defined semantics rather than the vendor’s interpretation of them. There’s no intermediate schema; the FOCUS column library is the datastore schema.

Platform Architecture and FOCUS - Evaluation Criteria for Enterprise Procurement
──────────────────────────────────────────────────────────────────────────────
Evaluation Question               FOCUS-Native             FOCUS-Compatible
──────────────────────────────────────────────────────────────────────────────
Is FOCUS the primary              Yes - FOCUS is the       No - proprietary schema
data model from ingestion?        datastore schema         + FOCUS translation

Single query across all           One query, FOCUS         Query against
providers - no joins?             columns natively         mapped/derived fields

EffectiveCost semantics           Provider-specified       Platform-interpreted,
consistency across providers?     per FOCUS spec           mapping-dependent

New FOCUS version upgrade         Schema update at         Translation layer update
impact on your data?              data layer only          + possible downstream
                                                           dashboard migration

New FOCUS-supporting              Zero engineering         New ETL mapping
provider onboarding effort?       work if provider         required regardless
                                  exports FOCUS            of FOCUS support

BYOC / self-hosted                Full FOCUS schema        Proprietary schema
deployment schema integrity?      preserved                in self-hosted
──────────────────────────────────────────────────────────────────────────────

That architecture difference shows up at every layer. For allocation consistency, a native platform applies ServiceCategory from a provider’s FOCUS export directly; a compatibility layer derives it from an internal mapping that can lag provider updates or handle edge cases differently — the column looks identical in both cases, but only one is guaranteed to carry the provider’s actual FOCUS-specified value. For new provider onboarding, a native platform adds a new provider as a data source to an existing schema; a compatibility layer needs a new ETL mapping from that provider’s native format into its own proprietary schema, invisible engineering work that only surfaces to the customer once a mapping error appears as an unexplained cost variance. And for regulated deployment, a native platform can run self-hosted BYOC while keeping full schema integrity, since the data model is defined by the open specification rather than the vendor’s own format.

FOCUS isn’t a reporting enhancement. It’s a schema replacement. The difference between a platform that translates data to FOCUS and one built on FOCUS from the start is the difference between a map drawn from memory and one surveyed from the ground.

See FOCUS 1.3 running natively against your own estate. Book a 30-minute session and we’ll walk through a live query — shared cost allocation, contract commitments, and AI token attribution together — against your actual data. Request a demo →

Frequently asked questions

What is FOCUS 1.3, and what problems does it solve? Ratified December 2025, it addresses three specific enterprise problems: shared cost allocation, through five new Allocation columns letting providers expose how they split shared infrastructure cost rather than just the output number; contract commitment tracking, through a new supplemental Contract Commitment dataset isolating contract terms from cost and usage rows; and data freshness, through mandatory dataset-level metadata timestamping billing data and flagging whether it’s final or subject to revision.

What is FOCUS 1.2, and why was it significant? Ratified May 2025, it expanded FOCUS from cloud infrastructure billing into the full Cloud+ technology estate — SaaS, PaaS, and AI workloads in the same schema as cloud spend, plus virtual currency lifecycle tracking for tokens and platform-specific billing units, invoice reconciliation, and multi-currency normalisation. Alibaba Cloud, Databricks, and Grafana all announced FOCUS support at this release.

What are the four FOCUS cost metrics, and when should each be used? BilledCost (the raw invoice amount, for AP reconciliation), EffectiveCost (amortised discounted cost after commitments, for allocation and unit economics), ListCost (on-demand list price, for quantifying commitment savings), and ContractedCost (contract-tier pricing, for validating enterprise agreement terms). EffectiveCost is the primary metric for most FinOps analytical work, since it gives a time-consistent view of resource cost that isn’t distorted by a lump-sum commitment purchase.

Which providers support FOCUS, and at what version? As of FOCUS 1.3: AWS, Microsoft Azure, Google Cloud Platform, Oracle Cloud Infrastructure, Alibaba Cloud, Databricks, Grafana, Huawei, OVH Cloud, and Tencent. AWS and Azure currently have the most mature production implementations, and the Conformance Program launching in 2026 will provide auditable gap reports for each provider’s actual implementation depth.

What is the FOCUS Conformance Program? A formal certification programme launching in 2026 validating a data generator’s compliance with the specification — producing sample conformance data, a formal mapping document from native billing to FOCUS, and a Conformance Gap Report documenting support level per column and attribute. Enterprise buyers should request this report from any vendor claiming FOCUS support, since “we support FOCUS” without one is currently an unverified claim.

How does FOCUS handle Kubernetes and other shared infrastructure cost? Through the five Allocation columns introduced in FOCUS 1.3, letting providers document the methodology used to split shared cluster cost rather than reporting only the output number. Platform teams can now verify whether provider allocation logic (CPU-based, memory-based, or hybrid) actually matches their internal chargeback model, rather than reconciling an unexplained cost variance at month-end.

References

1. FinOps Foundation — What is FOCUS? Specification Releases
2. FinOps Foundation — FOCUS Column Library
3. FinOps Foundation — Introducing FOCUS 1.3
4. FinOps Foundation — Introducing FOCUS 1.2
5. Linux Foundation Press — FOCUS 1.3 Launch
6. Microsoft Azure — What is FOCUS?
7. FinOps Foundation — State of FinOps Report 2026

Related reading

• The Broken Cost Schema Problem: Why Every FinOps Team Is Solving the Same Problem from Scratch — May 19, 2026
• Why DigiUsher Rebuilt Its Cost Engine on FOCUS — and Why That Decision Is Now an Enterprise Advantage — June 2, 2026
• FOCUS in Production: How DigiUsher’s FOCUS-Native Engine Delivers Real-Time Allocation, AI Token Governance, and €1M in 45 Days — June 9, 2026
• FOCUS Is the New Procurement Standard — June 18, 2026

© 2026 DigiUsher. All rights reserved. Privacy Policy · Terms of Service · Trust Center