Cloud Cost

FOCUS 1.3 and the FinOps Foundation spec: what changes for practice

Jorge de los Santos, CTO & Co-Founder · May 14, 2026 · 13 min read

FOCUS 1.3 ratified December 5. Split cost allocation, contract commitments, and recency/completeness land as first-class fields across AWS, Azure, GCP, Oracle, and SaaS vendors. The 2026 conformance program turns it into a procurement criterion.

FOCUS 1.3 and the FinOps Foundation spec: what changes for practice

Cloud Bills Were Always Going to Have a Standard

For the first decade of public cloud, every provider’s billing export was a snowflake. AWS Cost and Usage Reports, GCP Detailed Billing Export, Azure Enterprise Agreement billing, Oracle Cloud Usage Reports — each had its own column names, its own granularity, its own cost-allocation model, its own quirks for committed-use discounts. FinOps teams spent more time normalizing the inputs than analyzing them. Every multi-cloud cost dashboard contained a private translation layer that nobody outside the team trusted.

The FinOps Foundation’s FOCUS specification — FinOps Open Cost and Usage Specification — is the standard that finally collapses that translation layer. FOCUS defines a common schema for billing data: standardized column names, standardized cost-allocation semantics, standardized handling of credits, commitments, and shared resources. A FOCUS-conforming bill from AWS and a FOCUS-conforming bill from Azure can be unioned in a single SQL query and analyzed without a translation step.

FOCUS 1.0 ratified in 2024. FOCUS 1.1 and 1.2 followed. FOCUS 1.3 ratified on December 5, 2025, and is the version that the 2026 FinOps practice runs on. The 2026 conformance certification program — also new in 2026 — is the procurement leverage that makes the spec stick.

What FOCUS 1.3 Adds

FOCUS 1.3 closes three real gaps that practitioners had flagged as 1.x must-fix:

  • Split cost allocation. Shared infrastructure — a Kubernetes cluster running multiple teams’ workloads, a shared Snowflake warehouse, a multi-tenant database — was historically a black hole in billing exports. Each provider had its own ad-hoc way of representing it, or no representation at all. FOCUS 1.3 defines first-class fields for shared-cost allocation: which resource was shared, which consumers used it, what method was used to split it (proportional usage, equal split, custom). The fields make chargeback for shared infrastructure tractable in the same SQL that handles per-tenant resources.

  • Contract commitments. Reserved Instances, Savings Plans, Committed Use Discounts, Azure Reservations — every provider had a custom representation of how a commitment is applied to usage. FOCUS 1.3 defines standard fields for the commitment itself, the unit applied, the discount captured, and the unused commitment. The standardization makes commitment utilization a single dashboard rather than four parallel dashboards.

  • Recency and completeness dimensions. Billing data is time-shifted: a March cost line item may not appear in the export until early April, and a refund may not appear until June. Practitioners historically had no machine-readable way to know whether the export they were looking at was the final word on a given period. FOCUS 1.3 adds explicit recency and completeness columns: when was this row first generated, has the period it represents been finalized, what is the confidence the dollar amount won’t change. The fields turn “is this data trustworthy yet?” from a vendor-specific guess into a typed query.

None of these three are exotic. They are the columns FinOps practitioners had been adding to their internal pipelines for years; FOCUS 1.3 standardized the names so that every vendor’s export plugs into the same dashboards.

The 2026 Conformance Certification Program

The FinOps Foundation announced in early 2026 that it is launching a conformance certification program. The mechanics: vendors that emit FOCUS-format billing data publish sample datasets that validate against the spec, document any conformance gaps, and receive a public conformance certification for a specific FOCUS version. The certification is renewable per major spec revision.

The certification turns FOCUS from a “we support FOCUS” marketing line into a procurement criterion. A FinOps team writing a 2026 RFP can require FOCUS conformance certification at a specific version, with documented gap reports for any unsupported fields, as a hard requirement. Vendors who skip the certification self-disqualify from RFPs that include the requirement; vendors who pass put their conformance gaps on the table up front instead of leaving them as a post-purchase surprise.

The 2026 expansion targets — published by the FinOps Foundation alongside the conformance program — list the data sources that are not yet covered well: AI / model-inference workloads, datacenter and colo, and broader SaaS / PaaS billing. These are the areas where 2026-2027 spec revisions are likely to land, and where vendor adoption will follow.

Adoption Status: Cloud + SaaS in 2026

The cloud providers are mostly there. AWS, Azure, and GCP each export FOCUS-formatted data; OCI followed; Alibaba Cloud and Tencent Cloud are in process. The exports are not always at the latest spec version, and not always with full field coverage, but the path from any export to a unified FOCUS table is now a one-time engineering project rather than a permanent translation tax.

The third-party FinOps tool category — Apptio Cloudability, CloudHealth (now VMware Tanzu), Vantage, Anodot, ProsperOps, Spot.io, Kubecost — has converged on FOCUS as the input format. Most vendors will ingest a customer’s FOCUS export and skip their own custom-import path entirely.

The SaaS category is more mixed. Snowflake, Databricks, Datadog, MongoDB, and a growing list of high-spend SaaS vendors have shipped FOCUS-formatted billing. The long tail of SaaS vendors — particularly seat-based products and usage-based products with bespoke unit economics — is still being mapped, and the 2026 conformance program is the lever that will accelerate it.

The AI workload gap is the most-cited 2026 expansion priority. Token-based pricing, model-version cost differences, fine-tuning storage, vector storage, retrieval cost — none of these have natural homes in the current FOCUS schema, and the per-customer AI bill is one of the fastest-growing line items at most companies. Expect the spec to grow in this direction in 2026-2027.


See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →


What FOCUS Now Enables That Wasn’t Possible Before

Three things become tractable that historically required a custom data team:

  • True multi-cloud rollups. “How much did we spend on Postgres-class workloads across AWS RDS, Azure Database for PostgreSQL, and GCP Cloud SQL last quarter, by team?” — a query that used to require three distinct SQL dialects and a private translation table is now a single query against a unified FOCUS table. The same applies to network egress, object storage, compute, and committed-use discounts.

  • Trustworthy chargeback. Internal chargeback to engineering teams was historically a politically explosive exercise because the numbers depended on which translation table was used. FOCUS 1.3’s split-cost-allocation fields make shared infrastructure attributable in the same data structure that handles per-team resources, and the recency / completeness columns make “is this number final?” a typed answer instead of an argument. The combination collapses most of the political surface area around chargeback.

  • Cost agents that read one schema. Every previous generation of cost-optimization tooling had to hard-code per-vendor parsers, and the parsers broke every time a vendor changed an export format. A FOCUS-native cost agent reads the standardized schema, runs the same logic against AWS and Azure and GCP and Snowflake, and adds support for new vendors as they reach FOCUS conformance — without per-vendor parser maintenance. The agent’s surface area shrinks; its coverage grows.

What FOCUS Still Doesn’t Cover (and Why It Matters)

The 2026 expansion priorities are themselves the answer to “what’s still missing”:

  • AI workloads. Token-priced inference, fine-tuning storage, vector indexing, retrieval cost. These are growing 50-100% year-over-year at most large customers, and the schema for representing them in FOCUS is still being designed. Expect a significant 1.4 / 1.5 contribution here.
  • Datacenter and colo. On-prem workloads, hybrid deployments, and colocation contracts. The FinOps practice has been edging into “FinOps for everything” rather than “FinOps for cloud only,” and the schema needs to grow to match.
  • Broader SaaS and PaaS. Seat-based pricing, usage-based pricing with bespoke units, hybrid commit models. The long tail of SaaS billing is harder to standardize than the cloud category was.

Until the spec covers these areas, FinOps practice will continue to maintain a hybrid pipeline: a unified FOCUS table for the covered surface, plus per-vendor parsers for the uncovered surface, plus a roadmap-aware plan for migrating each line item from the second pipeline into the first as the spec catches up.

How IAN Helps: The Cost Agent in a FOCUS-Native World

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents. The cost agent is one of those agents and is built FOCUS-native: every cost analysis, every rightsizing recommendation, every commitment-utilization report runs against the unified FOCUS schema rather than against the per-vendor exports.

The cost agent runs the Observe-tier checks continuously: per-team chargeback, commitment utilization, anomaly detection, idle-resource attribution. Findings post to the team channel and to the audit trail; the chargeback report is generated against the FOCUS-1.3 split-cost-allocation columns rather than a private translation. The Operate-tier actions — rightsizing, idle-resource cleanup, commitment-purchase recommendations — run when in policy and reversible, and gate to a human approver otherwise. The Administer-tier actions — committing to a multi-year savings plan, modifying the chargeback policy itself, changing the team-to-cost-center mapping — always require explicit approval.

Because the cost agent runs against FOCUS data rather than vendor exports, adding a new cloud or a FOCUS-conformant SaaS vendor is a connector setup rather than a parser project. The customer’s coverage grows as their vendors’ FOCUS conformance matures.

Pricing is BYOK and usage-based with a monthly minimum. The pricing model is itself a FinOps story: customers pay inference costs to their model provider directly, and IAN charges for the orchestration layer per agent action, per cloud account, per operation class. Usage scales with the customer’s cloud footprint, which is the same footprint the cost agent is optimizing.

The Three-Phase Rollout

Phase 1 — Land FOCUS-format ingestion. Stand up the FOCUS exports for every covered cloud and SaaS vendor. Build the unified table in the warehouse (Snowflake, BigQuery, Databricks, or whatever the team already runs). Cut the existing per-vendor dashboards over to the FOCUS view. Two-to-six weeks; mostly engineering work that pays back fast.

Phase 2 — Migrate chargeback to FOCUS 1.3 split-cost-allocation. Replace any private shared-cost translation tables with the FOCUS 1.3 split-cost-allocation columns. Re-run last-quarter’s chargeback and reconcile against what the team already shipped to make sure the numbers are right. Use the recency / completeness columns to set the “is the period closed” semantics for chargeback finalization. Two-to-three months of chargeback policy work.

Phase 3 — Stand up the cost agent against the FOCUS schema. Wire the cost agent into the FOCUS table. Configure capability tiers and approval gates. Let the agent run the Observe-tier checks continuously and the Operate-tier actions when in policy. Add an analytics-aware feedback loop so the agent learns which recommendations land and which get rejected. Six-to-twelve months for a meaningful share of cost-agent automation; ongoing thereafter as the FOCUS coverage grows.

The compound: by the time Phase 3 lands, the FinOps practice is one query language wide and one agent layer deep, instead of one query language per vendor and a full-time team translating between them. As the FOCUS spec covers AI workloads, datacenter, and broader SaaS over the next two cycles, the same architecture absorbs the new sources without restructuring.


Get a free infrastructure audit → | See pricing →

Next step: talk to the team

30 minutes. We'll look at your cloud together and scope what we'd take off your plate — see pricing.

Related Posts