Ask any FinOps team where their time goes and the answer is rarely “optimization.” It is data wrangling: reconciling AWS Cost and Usage Reports with Azure exports and Google Cloud billing tables, mapping three different names for the same concept, chasing SaaS invoices that arrive as PDFs, and explaining to finance why the dashboard does not match the invoice. Multi-cloud and AI have only made this worse.
The FinOps Open Cost and Usage Specification, better known as FOCUS, was created to end that problem by giving every provider a common schema for billing data. In 2025 and 2026 it has moved from an interesting idea to a practical foundation, with native exports from the major clouds and a growing list of SaaS and data platforms. This playbook explains what has changed, why it matters, and how to move your cost reporting onto FOCUS without breaking what already works.
What FOCUS Is and Why It Matters Now
FOCUS is an open specification maintained by the FinOps Foundation, part of the Linux Foundation. It defines a standard set of columns, such as BilledCost, EffectiveCost, ListCost, ChargeCategory, ServiceName, ConsumedQuantity and PricingUnit, together with rules for how providers must populate them. A FOCUS-conformant dataset from one provider can be appended to a FOCUS dataset from another and queried with the same logic.
The timing matters because FinOps itself has broadened. According to the FinOps Foundation’s State of FinOps 2026 report, as summarized by USU, 98% of organizations now manage AI spend, 90% manage or plan to manage SaaS spend, 64% manage software licensing, 57% manage private cloud and 48% manage on-premises data center costs. Practitioners in the same survey said they want a single view across all of that spend and are often stitching it together by hand. FOCUS is the most credible route to that single view.
What Changed in FOCUS 1.2 and 1.3
FOCUS launched in 2023, and the FinOps Foundation describes version 1.3, announced in December 2025, as the fifth major release. The two most recent versions are the ones most organizations will implement in 2026.
FOCUS 1.2: SaaS, Invoices and Flexible Granularity
Version 1.2 extended the specification beyond infrastructure to SaaS and platform-as-a-service billing and improved the link between cost data and invoices. AWS made its FOCUS 1.2 export generally available in November 2025. According to the AWS Cloud Financial Management blog, the AWS export adds 14 columns compared with the FOCUS 1.0 export, including an InvoiceId column that ties cost rows directly to invoices, capacity reservation fields that show whether On-Demand Capacity Reservations and EC2 Capacity Blocks for ML are used or unused, commitment discount and SKU price details, and pricing currency columns that support virtual currencies and token-style units. It also supports hourly, daily and monthly granularity, where the 1.0 export was hourly only.
One practical detail deserves attention: AWS notes that the 1.2 export is not backward compatible with 1.0. You need to create a new export, update downstream pipelines and ideally run both in parallel before switching over.
FOCUS 1.3: Shared Costs, Contracts and Data Freshness
The Linux Foundation announcement for FOCUS 1.3 lists four main additions:
- Shared cost allocation columns that show how a provider has split shared costs, for example across Kubernetes pods or database instances, so practitioners can see the method as well as the result.
- A contract commitments dataset that holds terms such as start and end dates, remaining units and descriptions separately from cost and usage rows; the first time FOCUS has extended to an adjacent dataset.
- Recency and completeness metadata, requiring providers to timestamp datasets and flag whether data is final or still subject to revision.
- Service provider and host provider columns that clarify which party to contact for billing or support, which matters for marketplace and reseller purchases.
The same announcement lists Alibaba, AWS, Databricks, Google Cloud, Grafana, Huawei, Microsoft, Oracle Cloud Infrastructure, OVHcloud and Tencent among providers supporting FOCUS, and says that FOCUS 1.4 is in development with future versions expected to expand into data center and AI spending.
FOCUS does not optimize anything by itself. Its value is that it turns weeks of reconciliation into a solved problem, so FinOps teams can spend their time on decisions instead of data plumbing.
The Business Case: What FOCUS Solves
It is easy to treat FOCUS as a technical schema change. In practice, the business case rests on four outcomes that finance and engineering leaders care about.
- One version of the truth across providers. Reports built on FOCUS columns work for every conformant source, so adding a new cloud or SaaS vendor does not require a new reporting stack.
- Invoice reconciliation. Columns such as InvoiceId let finance tie cost data to the documents it pays, which shortens month-end close and reduces disputes.
- Fair allocation of shared and committed costs. The split between billed and effective cost, plus 1.3’s shared cost and commitment datasets, makes amortization and showback more defensible.
- Lower tooling lock-in. Because the schema is open, organizations can move between FinOps platforms, or build their own, without rewriting every transformation.
A Step-by-Step Adoption Playbook
We recommend a phased approach that delivers value early and avoids a risky “big bang” cut-over of existing dashboards.
Step 1: Inventory Your Cost Sources
List every source of variable technology spend: each cloud account structure, marketplace purchases, model API providers, data platforms, observability tools, major SaaS subscriptions and any private cloud or colocation charges. For each, record whether a native FOCUS export exists, which version it conforms to, its refresh frequency and who owns the relationship. This inventory alone often surfaces spend that no one was tracking centrally.
Step 2: Enable Native Exports in Parallel
Turn on native FOCUS exports for the providers that support them, starting with your largest. On AWS that means creating a FOCUS 1.2 export in AWS Data Exports; on Azure, a FOCUS-format cost export through Cost Management; and on Google Cloud, its FOCUS view of billing data. Keep existing native exports running. You will need them for detailed engineering analysis and for validating the new data.
Step 3: Land Everything in One Analytical Store
Choose a single home for cost data, typically your existing lakehouse or warehouse: Databricks, Snowflake, BigQuery, Microsoft Fabric or a cloud data lake with an open table format. Store each provider’s FOCUS data in a raw layer exactly as delivered, then build a conformed layer that unions all sources. Microsoft’s FinOps toolkit, with its FinOps hubs and FOCUS-aligned Power BI reports, is one option for teams centered on Azure; many organizations build the same pattern on their own data platform.
Step 4: Convert Non-Conformant Sources
For providers without a native FOCUS export, write lightweight converters that map their billing data to FOCUS columns. Be explicit about which columns you can populate reliably and which you leave null. A partial but honest mapping is more useful than a complete one built on guesses. Track these converters as code, with tests, because vendor billing formats change.
Step 5: Validate Against Invoices
Before anyone relies on the new reports, reconcile monthly totals of BilledCost per provider against invoices and against your legacy reports. Expect small differences from rounding, taxes, credits and timing. Document each difference and the rule used to explain it. This step is where trust is won or lost.
Step 6: Rebuild Core Reports on FOCUS Columns
Migrate your most used views first: spend by business unit, by environment, commitment coverage and utilization, and top services by growth. Use EffectiveCost for showback and unit economics, since it reflects amortized commitments, and BilledCost for invoice reconciliation. Retire the legacy version of each report only after stakeholders have used the new one for a full close cycle.
Step 7: Layer On Allocation and Unit Metrics
With a common schema in place, apply your allocation rules once, using tags, account hierarchies and the new shared cost columns, and join cost data with business metrics such as transactions, active users or AI tasks completed. This is where FOCUS starts paying for itself: unit economics that span cloud, SaaS and AI become a query rather than a quarterly project.
Architecture Decisions and Trade-Offs
Several design choices recur in almost every FOCUS implementation. Making them deliberately avoids rework later.
- Version strategy. Providers will not all be on the same FOCUS version at the same time. Design your conformed layer around the newest version you consume and treat missing columns from older sources as nullable.
- Granularity. Daily granularity is sufficient for most reporting and is much cheaper to store and query than hourly. Keep hourly data only for the sources and analyses that need it, such as commitment utilization.
- Data freshness. Use the 1.3 recency and completeness flags, where available, to label dashboards so users know whether the current month is provisional.
- Build or buy. Commercial FinOps platforms increasingly ingest FOCUS natively. Building on your own lakehouse gives more flexibility and keeps cost data alongside business data; buying gets you to value faster. Because FOCUS is open, the decision is more reversible than it used to be.
- Access control. Cost data reveals pricing agreements and organizational structure. Apply the same governance you would to financial data.
Worked Example: Three Clouds, Two AI Providers, One Report
Imagine a company running its core platform on AWS, analytics on Azure with Microsoft Fabric, a few workloads on Google Cloud, and two external model API providers for its AI features. Before FOCUS, its FinOps analyst spent the first week of every month exporting data from each source, reshaping it in spreadsheets and reconciling totals.
The team enabled the AWS FOCUS 1.2 export and Azure’s FOCUS-format export, used Google Cloud’s FOCUS billing view, and wrote two small converters for the model providers that mapped token usage to ConsumedQuantity with tokens as the PricingUnit. All five sources landed in the company’s lakehouse in a raw layer and were unioned into a conformed table.
In the first month, reconciliation against invoices revealed that marketplace purchases on one cloud had been missing from the legacy report entirely. In the second month, the team rebuilt its business-unit showback on EffectiveCost, which changed the apparent cost of two teams because commitment discounts were now amortized fairly. By the third month, product leadership had a single report showing cost per active customer across infrastructure, analytics and AI, and month-end preparation had shrunk from days to hours.
Common Pitfalls
- Assuming conformance means identical semantics. FOCUS standardizes columns, but providers still differ in how they describe services and SKUs. Keep a mapping table for service categories you care about.
- Switching off legacy exports too early. Detailed provider-specific fields remain valuable for engineering analysis.
- Ignoring tags. FOCUS carries your tags, but it cannot fix inconsistent tagging. Tag hygiene is still a prerequisite for good allocation.
- Mixing billed and effective cost. Decide which metric each report uses and label it clearly; mixing them is the fastest way to lose finance’s trust.
- Treating it as a one-off project. FOCUS versions will keep evolving. Assign ownership for keeping exports, converters and the conformed model current.
Outlook: FOCUS as the Ledger for All Technology Spend
The direction of travel is clear. FOCUS has grown from cloud infrastructure to SaaS, and the FinOps Foundation has signaled that data center and AI spending are next. As more SaaS vendors and AI providers publish conformant data, the manual effort in multi-source cost reporting should keep falling. Organizations that build their cost data architecture around FOCUS now will be able to absorb new providers, new pricing models and new FOCUS versions with configuration rather than reengineering, and will be ready to extend unit economics across their entire technology portfolio.
Conclusion
FOCUS is the quiet infrastructure upgrade that makes the rest of FinOps easier. Versions 1.2 and 1.3 address real pain points: invoice reconciliation, SaaS coverage, shared cost transparency, commitments and data freshness. Adopt it in phases: inventory your sources, enable native exports in parallel, land them in one analytical store, validate against invoices and rebuild core reports before layering on allocation and unit metrics. The result is a single, trustworthy view of technology spend that frees your FinOps team to focus on the decisions that actually reduce cost and increase value.
How Hanoi Technology Can Help
Hanoi Technology builds FOCUS-based cost data pipelines and reporting on your lakehouse so cloud, SaaS and AI spend share one trusted view.