FOCUS 1.3 Decoded: What Changed, What It Governs, and What It Means for Your FinOps Stack

FOCUS 1.3 was ratified on 5 December 2025. It solved three problems that enterprise FinOps teams have lived with for years: how to understand shared cost allocation methodology rather than just receive the output number, how to track contract commitments without maintaining a separate system, and how to know whether billing data is actually final before building reports 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 expanded from a cloud infrastructure billing standard covering a handful of columns to a 77-column, 14-category schema governing cloud infrastructure, SaaS, PaaS, AI token billing, shared cost allocation, contract commitments, and multi-currency normalisation. Ten providers — including AWS, Azure, Google Cloud, Oracle, Alibaba Cloud, and Databricks — now produce native FOCUS-format billing exports. 93 of the Fortune 100 participate in FinOps Foundation programmes.

This post is the technical reference guide to FOCUS versions 1.0 through 1.3: what changed in each release, which columns matter for which FinOps capabilities, how the Conformance Programme validates genuine FOCUS support versus a marketing claim, and what FOCUS-native architecture means for the enterprise FinOps stack.

---

Executive Summary

• FOCUS 1.3 (December 2025) introduced the Contract Commitment dataset, five shared cost Allocation columns, and mandatory data freshness metadata — the three capabilities most consistently requested by enterprise practitioners since 1.0
• FOCUS 1.2 (May 2025) was the Cloud+ unlock: SaaS and PaaS billing data in the same schema as cloud spend, virtual currency lifecycle tracking for AI tokens, invoice reconciliation, and multi-currency normalisation
• The FOCUS column library now contains 77 columns across 14 categories, including four distinct cost metrics — BilledCost, EffectiveCost, ListCost, ContractedCost — that replace the dozens of ambiguous cost columns in AWS, Azure, and GCP native formats
• Azure reports 49% fewer rows and ~30% smaller data files when using FOCUS exports versus combined native billing datasets — a direct reduction in data processing costs that compounds at enterprise scale
• The FinOps Foundation is launching a formal Conformance Programme in 2026 that will produce auditable gap reports for every provider’s FOCUS implementation — ending broad “we support FOCUS” claims without specificity
• FOCUS-native architecture is the only design that eliminates the normalisation layer entirely; platforms built on proprietary schemas that translate to FOCUS cannot deliver consistent cost metric semantics across all providers

---

FOCUS Version Timeline: The Problem Each Release Solved

The FOCUS specification is not an academic standards project. Every version release has addressed a specific, documented pain point that FinOps teams had reported to the Foundation working group. Understanding what each version solved is the fastest way to understand why the specification matters and why the version of FOCUS your platform supports determines your governance ceiling.

FOCUS 1.0 — Production Readiness (2023)

FOCUS 1.0 was the first stable release — the milestone that gave cloud providers a concrete, ratified target to implement. Before 1.0, the specification existed as a preview and working draft. The 1.0 release 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 would mean the same thing whether it came from AWS or Azure.

FOCUS 1.1 — ETL Depth and Multi-Cloud Granularity (November 2024)

FOCUS 1.1 (ratified 7 November 2024) deepened support for cloud provider billing data and addressed a specific practitioner pain point: the ETL metadata needed to build reliable, maintainable data pipelines. The release added new columns that enabled more granular multi-cloud analysis and improved the metadata fields that downstream ETL processes depend on for schema evolution and pipeline monitoring. For organisations building FOCUS data infrastructure, 1.1 reduced the brittleness of pipeline code that had to infer provider intent from undocumented column behaviour.

FOCUS 1.2 — The Cloud+ Unlock (May 2025)

FOCUS 1.2 (ratified 29 May 2025) was the most consequential release since 1.0 — the version that transformed FOCUS from a cloud billing standard into a full technology estate schema. Five capabilities defined the release, and each one addressed a governance gap that had been accumulating as FinOps scope expanded.

Cloud+ unified reporting folded SaaS and PaaS billing data into the same schema as cloud spend for the first time. A single SQL query against a FOCUS 1.2 dataset can now return costs from AWS EC2, Azure OpenAI, and Databricks in the same result set, using the same column names, the same ServiceCategory taxonomy, and the same cost metrics. The query that previously required three normalisation pipelines and a mapping table now requires none.

Virtual currency lifecycle introduced the columns needed to govern AI token billing, SaaS credit consumption, and any provider-defined unit of account that maps to a monetary value. ConsumedQuantity, ConsumedUnit, PricingCurrency, and PricingCurrencyEffectiveCost together give practitioners the ability to track Databricks DBU burn-down, Azure OpenAI token consumption rates, and Snowflake credit purchases against committed spend — in the same schema used for cloud infrastructure.

Multi-currency normalisation resolved the multi-national enterprise problem: billing data arriving in USD, EUR, GBP, and provider tokens simultaneously. FOCUS 1.2 introduced separate PricingCurrency and BillingCurrency columns with auditable exchange rates, allowing finance teams to produce P&L-accurate cost reports in their reporting currency without manual FX reconciliation.

Invoice reconciliation added an InvoiceID column that links every charge row directly to its provider invoice. Month-end close and chargeback processes that previously required manual reconciliation between cost data and invoice documents can now be automated against the InvoiceID field.

Unit-cost and density metrics provided the column structure needed for cost-per-unit analysis across providers — enabling cost-per-GB, cost-per-request, cost-per-user, and AI cost-per-inference calculations that translate infrastructure spend into business-meaningful metrics.

Three providers announced FOCUS support at the 1.2 release: Alibaba Cloud, Databricks, and Grafana — expanding the specification from its hyperscaler origins into data platforms and SaaS observability.

FOCUS 1.3 — Shared Costs, Contracts, and Data Integrity (December 2025)

FOCUS 1.3 (ratified 5 December 2025) addressed the three enterprise FinOps problems that had persisted through every prior version. Each one is architectural — the kind of gap that cannot be patched at the analytics layer because it requires the data generator to expose information that was previously opaque.

The full anatomy of these three capabilities is covered in the dedicated section below.

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, normative column
                            changes for existing fields

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 of the FOCUS specification for multi-cloud FinOps practitioners is the four-metric cost model. Before FOCUS, every cloud provider defined “cost” differently — not just using different column names, but using structurally different accounting logic that produced incomparable numbers for the same analytical question.

AWS’s Cost and Usage Report alone contains lineItem/BlendedCost, lineItem/UnblendedCost, lineItem/NetUnblendedCost, reservation/EffectiveCost, savingsPlan/SavingsPlanEffectiveCost, and pricing/publicOnDemandCost as distinct cost fields, each correct for a different purpose and each requiring practitioner knowledge to use appropriately. Azure and GCP carry their own analogous set of cost columns with different names, different semantics, and different adjustment logic.

FOCUS replaces this provider-specific proliferation with four authoritative metrics that carry consistent semantics across every provider that implements the specification.

BilledCost is the raw invoice amount — the charge that appears on the provider’s bill for a specific charge period, before commitment amortisation or discount adjustments. BilledCost maps to the number that accounts payable will see on the provider invoice and is the appropriate metric for cash flow analysis and AP reconciliation. It is not appropriate for resource-level cost allocation because large commitment purchases distort the billing period view.

EffectiveCost is the amortised, discounted cost of a resource after all commitment-based discounts have been applied and spread proportionally across the commitment period. When an organisation purchases a one-year AWS Reserved Instance, the EffectiveCost of compute resources covered by that reservation reflects the daily amortised cost of the commitment — not the upfront purchase amount that hits BilledCost in the month of purchase. EffectiveCost is the primary metric for cost allocation, chargeback, showback, unit economics, and all analytical work that requires a stable, time-consistent view of what a resource genuinely costs. For teams working with AI workloads where token-based pricing introduces significant cost variation, EffectiveCost provides the normalised view that makes trend analysis and anomaly detection reliable.

ListCost is the on-demand list price — what the resource would have cost with no commitments or negotiated discounts applied. ListCost is the baseline for calculating the total value of an organisation’s commitment portfolio and enterprise agreements. Comparing EffectiveCost to ListCost at scale quantifies the savings generated by commitment management programmes.

ContractedCost is the cost based on contractual pricing terms, distinct from both list price and commitment discounts. For organisations with enterprise agreements, private pricing arrangements, or negotiated rate cards, ContractedCost captures the price tier the contract entitles them to. Comparing ContractedCost to BilledCost validates that contracted terms are being correctly applied by providers — a reconciliation task that previously required manual review of contract documents against billing line items.

The practical implication is significant for every FinOps team managing multi-cloud commitments. Before FOCUS, calculating EffectiveCost equivalents across AWS, Azure, and GCP required different query logic for each provider, different handling of amortisation windows, and different interpretations of what counts as a commitment. With FOCUS, the same query returns EffectiveCost from all three providers using the same definition. The calculation is performed once, not three times.

---

FOCUS 1.2 Decoded: The Cloud+ Schema in Practice

The structural importance of FOCUS 1.2 extends beyond the individual capabilities introduced. FOCUS 1.2 is the release that validated the specification’s central architectural premise: that a single schema can govern technology billing data across fundamentally different pricing models — per-hour compute, per-token AI inference, per-query data warehousing, and per-seat SaaS subscriptions — without collapsing into the lowest common denominator that makes each category ungovernable.

The virtual currency lifecycle capability demonstrates this most clearly. SaaS and data platform providers — Databricks, Snowflake, MongoDB — do not bill in simple dollar amounts per resource hour. They bill in provider-defined units of account: Databricks Units (DBUs), Snowflake credits, MongoDB Atlas processing units. A Snowflake credit has a dollar value that varies by contract tier and is denominated in a pricing currency that may differ from the organisation’s billing currency. FOCUS 1.2 provides a column structure that handles this complexity without requiring custom schema extension.

The example in the FinOps Foundation’s 1.2 release documentation shows a Snowflake consumption of 25 credits priced in USD but billed in EUR. The FOCUS 1.2 data model captures PricingCurrency (USD), PricingCurrencyListUnitPrice (the per-credit list rate in USD), BillingCurrency (EUR), BilledCost (the EUR invoice amount), and the FX exchange rate used in the invoice. Finance teams receive a dataset that preserves both the contractual pricing logic and the actual cash paid, with auditable exchange rate documentation — in the same format as every other cost row in the organisation’s technology estate.

For AI cost governance, virtual currency lifecycle tracking is the column infrastructure that makes token-level attribution possible. An Azure OpenAI charge row in a FOCUS 1.2 dataset carries ServiceCategory: AI, ServiceName: Azure OpenAI Service, ConsumedQuantity: [token count], ConsumedUnit: tokens, EffectiveCost: [amortised token cost]. A platform engineering team can write a single query against this dataset to calculate cost-per-inference across Azure OpenAI, AWS Bedrock, and Google Vertex AI — using the same column set, the same cost metric, and the same aggregation logic — because all three providers produce FOCUS 1.2 billing data in the same schema.

90% of FinOps teams now govern SaaS spend, and 98% govern AI spend (FinOps Foundation State of FinOps 2026). FOCUS 1.2 is the specification release that makes both governable from a single query surface.

---

FOCUS 1.3 Decoded: Three Persistent Problems Solved

The Shared Cost Allocation Problem

Every multi-tenant infrastructure environment — a shared Kubernetes cluster, a managed database instance serving multiple teams, a shared API gateway — creates an allocation problem. Before the charge can be assigned to a cost centre, team, or product, the shared resource’s cost must be split across its consumers using some methodology. Before FOCUS 1.3, providers made that split, reported the allocated number, and documented the methodology nowhere in the billing data.

Practitioners received the output of an allocation calculation without any information about how it was derived. Platform engineering teams could not verify whether a provider’s Kubernetes cost allocation used CPU-hours, memory-hours, or a hybrid approach. Finance teams could not audit the allocation methodology because it was not in the data.

FOCUS 1.3 introduces five Allocation columns that change this fundamentally. AllocatedMethodID provides a provider-defined identifier for the allocation method used. AllocatedMethodDetails contains a human-readable description of that method — whether it is resource-based, usage-based, or a hybrid of both. AllocatedResourceID and AllocatedResourceName identify the shared parent resource being split. AllocatedTags carries the cost allocation tags applied at the point of splitting.

Platform engineering teams running EKS, AKS, or GKE clusters can now receive cluster-level cost splits that document the allocation methodology alongside the cost number. When the provider’s methodology matches the internal chargeback model, the split is accepted. When it does not, the discrepancy is visible in the data — not inferred from unexplained cost variances at month-end.

The Contract Commitment Problem

Reserved Instances, Savings Plans, Committed Use Discounts, and enterprise contract terms create a commitment landscape that most organisations track in spreadsheets, procurement systems, and FinOps platform commitment management modules — all separate from the cost and usage data that reflects those commitments’ consumption. Tying commitment terms back to cost rows has required joining billing data against separately maintained commitment records, with no standardised schema defining how commitment terms should be structured.

FOCUS 1.3 addresses this by introducing the Contract Commitment dataset — a new, supplemental FOCUS dataset entirely separate from the cost and usage dataset. The Contract Commitment dataset contains 13 dedicated columns: ContractCommitmentID, ContractID, ContractCommitmentType, ContractCommitmentCategory, ContractCommitmentDescription, ContractCommitmentPeriodStart, ContractCommitmentPeriodEnd, ContractCommitmentQuantity, ContractCommitmentUnit, ContractCommitmentCost, ContractApplied, ContractPeriodStart, and ContractPeriodEnd.

The practical implication is significant. A single query against the Contract Commitment dataset returns all active commitments — their terms, remaining units, expiration dates, and cost basis — without requiring a join to the main cost and usage dataset. The dataset is designed to be permissioned separately from cost and usage data, enabling procurement and finance teams to query commitment terms without access to the full cost dataset. This also marks the first instance of the FOCUS specification extending its schema to an adjacent dataset — a structural signal that the specification’s scope will continue to expand beyond the primary cost and usage dataset in future versions.

The Data Freshness Problem

Automated governance systems — budget alerts, anomaly detection engines, commitment optimisation triggers — act on billing data. If that billing data is incomplete, preliminary, or stale, automated actions based on it are wrong. Before FOCUS 1.3, practitioners had no standardised way to determine whether a billing dataset was final or subject to revision. Providers updated cost data retroactively for days after a billing period closed — applying commitment discount recalculations, credit adjustments, and pricing corrections — but nothing in the data schema indicated that these updates had occurred or were pending.

FOCUS 1.3 requires providers to include dataset-level metadata with two properties: a last-updated timestamp indicating when the dataset was last modified, and a completeness status flag indicating whether the data is final or subject to further revision. Practitioners can query these metadata fields before running analytical workloads or triggering automated governance actions. An anomaly detection system that would previously have fired on preliminary billing data — before commitment discount recalculations were applied — can now check completeness status first and defer processing until data is confirmed final.

The Reseller and Host Provider Problem

FOCUS 1.3 also introduces two columns — ServiceProviderName and HostProviderName — that distinguish between the provider making a resource available for purchase and the provider on whose infrastructure it runs. For enterprises working with resellers, marketplace vendors, or managed service providers, this distinction is essential for accurate cost attribution. A managed Databricks environment purchased through a cloud marketplace reseller has a different ServiceProviderName (the reseller or ISV) than HostProviderName (the underlying cloud infrastructure it runs on). Before these columns, practitioners had to infer reseller relationships from indirect signals in billing data. FOCUS 1.3 makes them explicit.

---

The FOCUS Column Library: 77 Columns, 14 Categories

As of FOCUS 1.3, the specification defines 77 columns across 14 categories and two datasets. Understanding the category structure is the fastest way to assess a FinOps platform’s implementation depth — whether it has mapped the full specification or only 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 in the Service group deserves specific attention. It carries the normalised technology category for every charge row — Compute, Storage, Database, Networking, AI, Analytics, Security, Developer Tools, and others — across all providers. A charge from AWS EC2, Azure Virtual Machines, and GCP Compute Engine all carry ServiceCategory: Compute in a FOCUS dataset. A charge from Azure OpenAI, AWS Bedrock, or Google Vertex AI carries ServiceCategory: AI. No mapping table required.

This single column eliminates one of the most labour-intensive parts of multi-cloud reporting: building and maintaining a service taxonomy mapping that normalises AWS service names, Azure meter categories, and GCP SKU descriptions into a common hierarchy. FOCUS replaces that custom mapping with a specification-defined field that providers populate directly.

The Commitment Discount category — seven columns covering commitment type, status, utilisation quantity, and category (compute, spend) — gives practitioners a standardised way to track Reserved Instance and Savings Plan coverage across all providers using the same schema. Before FOCUS, analysing commitment coverage across AWS and Azure required entirely separate query logic because the two providers structured their commitment data in fundamentally different ways.

---

The FOCUS Conformance Programme: What Certification Actually Means

The FinOps Foundation is launching a formal Conformance Programme in 2026 that creates an auditable, public record of each provider’s FOCUS implementation level. The programme addresses the most significant gap in the current FOCUS ecosystem: the inability to verify what “FOCUS support” actually means for a specific provider without reviewing their billing export documentation manually.

The Conformance Programme produces three outputs for every participating provider. First, sample data validating conformance — actual billing data samples that demonstrate which columns the provider populates, which columns are present but empty, and which are absent entirely. Second, a formal mapping document from the provider’s native billing format to the FOCUS schema, specifying for each FOCUS column whether it is a direct one-to-one mapping from a native field, a transformation of native data using documented logic, or not supported in the current implementation. Third, a Conformance Gap Report that formally documents the provider’s support level for each column and attribute requirement, categorised by FOCUS specification version.

The procurement implication for enterprise buyers is direct. A FinOps platform vendor claiming FOCUS support should be able to provide its Conformance Gap Report when the programme launches. A report showing full column coverage with one-to-one mappings from native billing data is materially different from a report showing partial column coverage with transformation-derived fields and several columns not supported. Both could claim “FOCUS support.” Only the Conformance Programme makes the difference visible.

For enterprise procurement teams, requesting the Conformance Gap Report should be a standard part of FinOps platform evaluation — alongside the FOCUS architecture question (is FOCUS your primary data model or an export layer?) that determines whether the platform’s claim to FOCUS support represents genuine schema equivalence or a translation approximation.

---

FOCUS-Native vs FOCUS-Compatible: What Your Platform’s Architecture Determines

The FOCUS specification’s practical value for enterprise FinOps buyers depends entirely on how the FinOps platform ingests and stores data — not on whether the platform’s marketing materials mention FOCUS.

A FOCUS-compatible platform takes billing data from providers, processes it through its proprietary internal schema, and surfaces FOCUS-labelled fields in its reporting layer. The EffectiveCost column a practitioner queries in this platform is a field derived from the platform’s internal cost model — which may have been constructed from AWS’s reservation/EffectiveCost, Azure’s amortised cost column, and GCP’s credited cost field using the platform vendor’s own mapping logic. The FOCUS label is applied after the 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 billing data, the EffectiveCost in the platform’s datastore carries the value that AWS placed in that column — with FOCUS-defined semantics, not the platform vendor’s interpretation of those semantics. The same applies to Azure, GCP, Databricks, and every other FOCUS-supporting provider. There is no intermediate schema. The FOCUS column library is the datastore schema.

This architectural difference produces consequences at every layer of the FinOps stack.

For allocation consistency, a FOCUS-native platform applies ServiceCategory taxonomy from the provider’s FOCUS export directly. A compatibility layer derives ServiceCategory from the platform’s internal service mapping, which may lag provider-side FOCUS updates or interpret edge cases differently. In both cases the column is present. In only one case is the value guaranteed to be the provider’s FOCUS-specified answer.

For new provider onboarding, a FOCUS-native platform adds a new FOCUS-supporting provider as a data source to an existing schema. A compatibility layer adds a new ETL mapping from the provider’s native billing format to the platform’s proprietary schema, then re-derives the FOCUS-labelled fields. The engineering work sits inside the platform, invisible to the customer — until the mapping produces an error that surfaces as a cost variance.

For regulated deployments, a FOCUS-native platform can operate in a self-hosted BYOC architecture while maintaining full schema integrity. The data model is defined by the open specification, not the vendor’s proprietary format. Platform engineers deploying DigiUsher in a private banking environment via BYOC work against the same FOCUS schema as teams using the managed SaaS deployment. The specification is the contract between the data and the analytics layer, independent of the deployment model.

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
──────────────────────────────────────────────────────────────────────────────

---

What FOCUS 1.3 Means for Enterprise FinOps Platforms

FOCUS 1.3 arrived at a moment when 90% of FinOps teams govern SaaS alongside cloud, 98% govern AI spend, and practitioners describe the expansion of their scope in terms of one domain added after another with no common data foundation connecting them. The specification’s three 1.3 capabilities — shared cost allocation, contract commitments, and data freshness — are not incremental refinements. They are the columns that make automated, auditable governance possible at the scale enterprise FinOps teams are now operating at.

Platform engineering teams running shared Kubernetes infrastructure can now receive allocation data that documents how the provider split costs, not just the output numbers. Finance teams can query all active commitment terms from a single, permissioned dataset without joining to cost and usage data. Anomaly detection and budget enforcement systems can verify data completeness before acting on preliminary billing records.

DigiUsher implements FOCUS 1.3 natively across the full technology estate it governs — multi-cloud infrastructure on AWS, Azure, GCP, OCI, and Alibaba Cloud; Kubernetes clusters across EKS, AKS, GKE, and OKE; AI workloads on Azure OpenAI, AWS Bedrock, Google Vertex AI, and Databricks; and SaaS providers supporting FOCUS exports. The Contract Commitment dataset, Allocation columns, and data freshness metadata are available as first-class fields in the DigiUsher query surface — not as derived approximations, but as the provider-specified values that arrive in the FOCUS 1.3 export.

For regulated enterprises — including banking and financial services organisations running DigiUsher in self-hosted BYOC deployments — FOCUS 1.3 schema integrity is maintained whether the platform runs in DigiUsher’s managed cloud or inside the organisation’s own infrastructure perimeter. The specification is the data contract. The deployment model does not change it.

Global SI partners — including Infosys and Wipro — deliver DigiUsher-powered FinOps implementations to enterprise clients at scale. Those delivery teams work against the FOCUS column library, not a proprietary vendor schema, which means the implementation knowledge they bring is portable across the FinOps ecosystem and is not deprecated when DigiUsher releases a new version.

DigiUsher is available on AWS Marketplace (AWS ISV Accelerate Partner), Azure Marketplace (Azure ISV Co-Sell Ready, MACC-eligible), and GCP Marketplace. SOC 2 Type II certified. GDPR compliant.

---

Frequently Asked Questions

What is FOCUS 1.3 and what problems does it solve?

FOCUS 1.3, ratified December 5, 2025, addresses three specific enterprise problems that persisted through prior versions. First, shared cost allocation: five new Allocation columns let data generators expose how they split shared infrastructure costs across workloads, making the methodology auditable rather than opaque. Second, contract commitment tracking: a new supplemental Contract Commitment dataset isolates contract terms from cost and usage rows, enabling a single query to return all active commitments with their terms and remaining units. Third, data freshness: mandatory dataset-level metadata requires providers to timestamp billing data and flag whether it is final or subject to revision, enabling automated governance systems to verify data completeness before acting.

What is FOCUS 1.2 and why was it significant?

FOCUS 1.2 (ratified May 2025) expanded the specification from cloud infrastructure billing to the full Cloud+ technology estate — SaaS, PaaS, and AI workloads in the same schema as cloud spend. It introduced virtual currency lifecycle tracking for AI tokens, SaaS credits, and platform-specific billing units; invoice reconciliation through an InvoiceID column; and multi-currency normalisation. Alibaba Cloud, Databricks, and Grafana announced FOCUS support at the 1.2 release. For enterprises where 90% of FinOps teams now govern SaaS and 98% govern AI spend, FOCUS 1.2 is the release that makes unified reporting over their full scope technically possible.

What are the four FOCUS cost metrics and when should each be used?

FOCUS defines BilledCost (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 value), and ContractedCost (contract-tier pricing, for enterprise agreement validation). EffectiveCost is the primary metric for most FinOps analytical work — cost allocation, chargeback, showback, AI unit economics, and trend analysis — because it provides a time-consistent view of resource cost that is not distorted by lump-sum commitment purchases.

Which providers support FOCUS and at what version?

As of FOCUS 1.3 (December 2025): AWS (FOCUS 1.2 GA at re:Invent 2025), Microsoft Azure, Google Cloud Platform, Oracle Cloud Infrastructure, Alibaba Cloud, Databricks, Grafana, Huawei, OVH Cloud, and Tencent. AWS and Azure have the most mature production implementations. The FinOps Foundation’s Conformance Programme, launching in 2026, will provide auditable gap reports for each provider’s implementation level.

What is the FOCUS Conformance Programme?

A formal certification programme launching in 2026 that validates data generator compliance with the FOCUS specification. It produces sample data validating conformance, a mapping document from native billing to FOCUS format, and a Conformance Gap Report documenting support levels per column and attribute. Enterprise buyers should request this report from any FinOps vendor claiming FOCUS support — “we support FOCUS” without a Conformance Gap Report is an unverified claim.

How does FOCUS handle Kubernetes and shared infrastructure costs?

FOCUS 1.3’s five Allocation columns — AllocatedMethodID, AllocatedMethodDetails, AllocatedResourceID, AllocatedResourceName, and AllocatedTags — let providers document the methodology used to split shared Kubernetes cluster costs, not just the output allocation number. Platform engineering teams can now verify whether provider allocation logic (CPU-based, memory-based, or hybrid) aligns with internal chargeback models, rather than reconciling unexplained cost variances at month-end.

What is Cloud+ FinOps and how does FOCUS enable it?

Cloud+ FinOps is the governance of the full technology estate — cloud infrastructure, SaaS, PaaS, AI workloads, data platforms, and private cloud — from a unified billing schema. FOCUS 1.2 enabled it architecturally by including SaaS and PaaS billing data in the same schema as cloud infrastructure, so a single SQL query using FOCUS columns can return costs from AWS, Azure, Databricks, and a SaaS provider in one result set without any intermediate normalisation.

What should practitioners do now to prepare their FinOps stack for FOCUS?

Enable FOCUS-format exports from all providers that support them — AWS, Azure, Databricks at minimum. Evaluate whether the FinOps platform is FOCUS-native or FOCUS-compatible by asking whether FOCUS is the primary data model or a translation layer. Map the internal cost allocation taxonomy to FOCUS dimensions — ServiceCategory, ChargeType, BillingAccountType — before migrating allocation logic. Monitor the FOCUS 1.4 working group roadmap. Request Conformance Gap Reports from platform vendors when the programme launches in 2026.

---

References

1. FinOps Foundation — What is FOCUS? Specification Releases — Primary source for version history: FOCUS 1.0 (2023), 1.1 (November 2024), 1.2 (May 2025), 1.3 (December 2025); use case descriptions per version
2. FinOps Foundation — FOCUS Column Library — Primary source for 77-column count, 14-category structure, column names, and FinOps capability mappings per column
3. FinOps Foundation — Introducing FOCUS 1.3 — Primary source for FOCUS 1.3 capabilities: Allocation columns (×5), Contract Commitment dataset, data freshness metadata, ServiceProviderName / HostProviderName, and Conformance Programme launch details
4. FinOps Foundation — Introducing FOCUS 1.2 — Primary source for FOCUS 1.2 capabilities: Cloud+ unified schema, virtual currency lifecycle, invoice reconciliation, multi-currency, unit-cost density metrics; Alibaba Cloud, Databricks, Grafana adoption
5. Linux Foundation Press — FOCUS 1.3 Launch — Source for full provider list at FOCUS 1.3: Alibaba, AWS, Databricks, Google Cloud, Grafana, Huawei, Microsoft, OCI, OVH Cloud, Tencent; 93 of Fortune 100 in Foundation programmes (December 2025)
6. Microsoft Azure — What is FOCUS? Cost Management Documentation — Source for Azure FOCUS dataset efficiency: 49% fewer rows, ~30% smaller data size versus native actual-plus-amortised billing datasets
7. FinOps Foundation — AWS re:Invent 2025 FinOps Updates — Source for AWS FOCUS 1.2 GA announcement at re:Invent 2025; virtual currency SaaS integration confirmation
8. FinOps Foundation — State of FinOps Report 2026 — Primary source for 90% SaaS governance (up from 65%), 98% AI spend governance (up from 63%), scope expansion practitioner context
9. FinOps Foundation — State of FinOps Report 2025 — Primary source for 57% FOCUS adoption intent; 54% targeting pipeline integration as adoption method
10. FinOps Foundation — Adopting FOCUS: The FinOps Open Cost and Usage Specification — Primary source for FOCUS adoption guidance, implementation workflow, and enterprise best practices (updated December 2025)
11. FinOps Foundation — FOCUS Specification v1.2 — Specification text: Snowflake virtual currency example (25 credits, PricingCurrency USD, BillingCurrency EUR); FOCUS mission as SDO for open consensus billing standard
12. FinOps Foundation — FOCUS 1.1 Release Notes — Source for FOCUS 1.1 capabilities: new columns for granular multi-cloud analysis, improved ETL metadata, normative column changes (November 2024)

---

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

---

See FOCUS 1.3 running in production across your full technology estate

DigiUsher implements FOCUS 1.3 natively — every column, every cost metric, every Allocation field, every Contract Commitment record — across multi-cloud, Kubernetes, AI workloads, and SaaS in a single query surface. In 30 minutes, we will walk you through a live FOCUS-native query against your estate architecture and show you what shared cost allocation, AI token attribution, and commitment tracking look like when the platform is built on the specification rather than translated to it.

Available on AWS Marketplace (AWS ISV Accelerate Partner), Azure Marketplace (Azure ISV Co-Sell Ready, MACC-eligible), and GCP Marketplace. SOC 2 Type II certified. GDPR compliant. BYOC deployment available for regulated industries.

Request a 30-minute session → digiusher.com/request-a-demo

---

Related Posts

The Broken Cost Schema Problem: Why Every FinOps Team Is Solving the Same Problem from Scratch · 12 May 2026 The strategic foundation for this post — the market-level argument for why a universal billing standard matters and what the hidden ETL tax costs enterprise organisations before FOCUS.

Why DigiUsher Rebuilt Its Cost Engine on FOCUS — and Why That Decision Is Now an Enterprise Advantage · 26 May 2026 The architectural pivot story — how DigiUsher committed to FOCUS-native from the ground up and why that decision produces outcomes that FOCUS-compatible platforms cannot replicate.

FOCUS in Production: How DigiUsher’s FOCUS-Native Engine Delivers Real-Time Allocation, AI Token Governance, and €1M in 45 Days · 2 June 2026 The production outcomes proof — what FOCUS 1.3 shared cost allocation, AI token attribution, and contract commitment tracking actually deliver when built on the specification natively.

FOCUS Is the New Procurement Standard: How the FinOps Industry’s Billing Specification Became a Vendor Evaluation Weapon · 9 June 2026 The evaluation framework — seven procurement questions every enterprise buyer should ask their FinOps vendor about FOCUS architecture, and why the answers separate native platforms from compatibility wrappers.

Cloud Cost Optimisation Is Dead: Why FinOps Must Now Govern the Full Technology Estate · 14 April 2026 The scope expansion context — why governing a Cloud+ estate demands a unified billing standard rather than category-by-category normalisation pipelines.