Beyond the cloud bill: FinOps scope expansion and the quiet importance of FOCUS

The name has not aged well. “Cloud financial management” was a reasonable description of FinOps when the discipline coalesced around 2019, back when most enterprises were trying to make sense of a single hyperscaler bill and the working hypothesis was that better tagging would fix most of the problem. By 2026 it has become a misleading shorthand. The current FinOps Framework explicitly treats Public Cloud as one Scope among several, alongside SaaS, Data Center, Data Cloud Platforms, and AI. The 2026 mission statement of the FinOps Foundation has dropped the word “cloud” entirely: the discipline is now described as managing “the Value of Technology”.

This is not marketing repositioning. It reflects what the survey data shows. According to the 2026 State of FinOps report, 90% of respondents now manage SaaS or have plans to (up from 65% the previous year); 64% manage licensing (up 15 points); 57% manage private cloud (up 18 points); and 48% manage data centre spend (up 12 points). The story of FinOps in 2026 is not the deepening of public-cloud cost discipline. It is the discovery that public-cloud cost discipline was a rehearsal for a much broader problem.

That broader problem is the subject here, and in particular a piece of plumbing that most non-practitioners have not heard of but that is becoming the most important standard in the field: FOCUS, the FinOps Open Cost and Usage Specification.

What “scope” really means in the new Framework

The 2025 update to the FinOps Framework introduced Scopes as a core element, formally approved by the Technical Advisory Council in October 2024. The 2026 update added Technology Category pages: structured guidance for applying the Framework within Public Cloud, SaaS, Data Center, Data Cloud Platforms, and AI. The intent is easy to miss if you are not following the Framework’s quarterly releases. It is to acknowledge that the same FinOps capabilities apply differently depending on the kind of technology spend in front of you.

The clearest demonstration of this is in the 2026 survey’s priority data. Optimisation, for years the canonical top priority of every FinOps team, was the top priority for Public Cloud spend. It was not in the top five priorities for SaaS, AI, Licensing, or Data Centers. The reason becomes obvious as soon as you state it: a SaaS contract is not “optimised” by right-sizing instances; it is renegotiated, consolidated, or cancelled. A licensing position is not “optimised” by autoscaling; it is harmonised across business units to avoid double-purchase. Data centre capacity is not “optimised” on a weekly cadence; it is planned on a multi-year horizon.

If you take the FinOps capabilities (visibility, allocation, optimisation, forecasting, anomaly management, sustainability, and unit economics) and ask “how does each of these look in SaaS?” or “how does each of these look in a private cloud?”, you start to see why a single playbook cannot cover the territory. The capabilities are the same in name. The motions inside them are different.

This matters most for organisations whose total technology spend is heavily weighted away from public cloud. A regulated enterprise running 70% of workloads on private infrastructure and 30% in public cloud will get most of its value from FinOps capabilities applied to data centre and licensing scopes, even if all the case studies and tool marketing it sees are about AWS. The Framework now reflects that reality. Tools and practices have not entirely caught up.

The data problem

The harder thing about expanding scope is that the data does not, by default, fit together. A public cloud bill is structured (variably), tagged (incompletely), and exportable in some machine-readable format. A SaaS contract is a PDF. A data centre cost is a depreciation schedule with overhead allocations stapled on. A software licence position lives in a procurement system that may not even share an identity model with the engineering systems consuming the licences.

The natural instinct of a maturing FinOps practice is to put a tool over the top of all this: a “single pane of glass” that normalises across sources. That instinct is correct as far as it goes. The reason it has historically delivered disappointing results is that there has been no common schema. Every vendor’s normalisation has been proprietary, every export format has been bespoke, and the same conceptual field (say, “the service that produced this charge”) has had a different name and meaning in every system.

This is the problem FOCUS is designed to solve.

What FOCUS actually is

FOCUS is an open technical specification that defines a common format for technology billing data. It sets out what columns must exist, what they must mean, what units they must use, and how they must behave under common edge cases (refunds, credits, multi-currency, taxes, and discounts). The version 1.3 specification was ratified by the FOCUS Steering Committee on 5 December 2025 and is the basis for production exports from the major hyperscalers in 2026.

The point of FOCUS is mundane and powerful. It means that a cost record from AWS, a cost record from Azure, a cost record from Google Cloud, and a cost record from Oracle Cloud Infrastructure can sit in the same table with the same columns and the same semantics. Cross-cloud queries become arithmetic rather than ETL. Cost dashboards become portable. Tooling vendors compete on analysis rather than on data wrangling.

In 2026, FOCUS is no longer an aspiration. AWS and Azure both offer production-ready FOCUS-compatible exports. Google Cloud and OCI have rolled them out. The leading FinOps tools either ingest FOCUS natively or are racing to do so. The Foundation’s working groups are pushing the specification into newer territory: top requests for the next iteration include richer support for AI workloads, data centre data, and broader SaaS/PaaS coverage.

For practitioners evaluating tools in 2026, “Do you support FOCUS?” is now a baseline question rather than a leading-edge one. A vendor whose answer is hesitant is signalling that its data model is proprietary, which in a multi-scope, multi-cloud world is a meaningful strategic risk.

What FOCUS does not solve

The specification has clear limits. FOCUS standardises the shape of billing data; it does not standardise the underlying pricing models, the granularity of usage records, or the quality of metadata that producers attach. A FOCUS export from a hyperscaler that does not yet emit per-service-call granularity for its AI products is still going to be coarse. A FOCUS export from a SaaS vendor that charges per-seat and does not track which seats are actively used is not going to give you the data you need for utilisation analysis.

The more honest framing is that FOCUS is necessary plumbing. It does not by itself give you visibility into SaaS waste; it makes it possible to build that visibility without first spending four months wrestling with vendor-specific export formats. It does not by itself produce sensible AI cost attribution; it gives the eventual AI cost attribution work a stable substrate to land on. A relational schema does not produce business intelligence, but the absence of one makes business intelligence prohibitively expensive. FOCUS sits in the same place: foundational rather than revolutionary.

The political economy of scope expansion

The technical expansion of scope is the easier half of the story. The harder half is organisational. FinOps teams that grew up inside cloud centres of excellence, or as adjuncts to a cloud platform team, now find themselves asked to participate in SaaS renewal cycles run by procurement, data centre capacity planning run by infrastructure, and software licence true-ups run by legal or finance. Each of those organisations has its own established cadence, its own toolset, and its own definition of who has authority to act on the data.

The 2026 survey hints at the consequence: practices reporting into the CTO or CIO organisation (now 78% of respondents, up from 60% in 2023) tend to navigate these cross-functional pieces more effectively than practices reporting into the CFO. The Foundation’s reading is that FinOps under technology leadership has more credibility to challenge architectural decisions across the stack, and more direct access to the engineering organisations that own most of the levers. The CFO line, by contrast, tends to produce excellent reporting and limited operational impact.

The uncomfortable implication is that scope expansion is partly an organisational fight. A FinOps practice that wants to take a meaningful position on SaaS spend is, in effect, asking to insert itself into a process that has historically belonged to procurement. The 2026 data shows practitioners are aware of this, with “expanding FinOps into additional technologies” now a leading stated priority, but the political work of actually doing so is not yet documented in the same detail.

What this looks like in practice for a maturing organisation

The first move is to bring public cloud cost data into a FOCUS-compatible structure, regardless of whether the team is using the hyperscaler exports directly or a tool that ingests them. This is the cheapest and most consequential piece of foundational work, because everything downstream depends on it.

The second move is to extend that data substrate to include the largest non-cloud scopes. For most organisations that means SaaS first, given how rapidly SaaS spend has grown as a proportion of total technology cost. For regulated or hardware-heavy organisations it means data centre and private cloud spend at parity with public cloud. The goal is not to recreate the cloud-cost dashboards in a new scope; it is to make it possible to ask “what does it cost us to serve a customer”, “what does it cost us to operate this product”, or “what is the gross margin on this line of business” across all the technology that goes into the answer.

The third move is more uncertain and depends on how the AI cost picture stabilises over the next 18 months. AI workloads will need to slot into the same data substrate, but the granularity required (per-token, per-call, per-model) is finer than current FOCUS profiles cleanly support. The working groups are addressing this, but production-grade AI cost analytics at FOCUS-level uniformity is more 2027 work than 2026 work.

What has actually changed

The temptation, looking at a year as eventful as 2026 has been for FinOps, is to declare that the discipline is being reinvented. That is overstated. The capabilities listed earlier remain the right ones. What is changing is the surface area they are applied to, and the data infrastructure that makes that application feasible.

FOCUS, a dull plumbing standard on the surface, may end up being the most consequential single development of this period. A discipline that historically lost most of its energy to data wrangling now has a credible path to spending that energy on the analytical and organisational work instead. That advantage compounds.

The risk is that practices and tools push aggressively into expanded scope before the underlying data is genuinely interoperable, and end up with multi-scope reporting that is wider but not deeper. The opportunity is to do the foundational work properly, in the right order, and let the analytical and organisational maturity follow. The 2026 data suggests most practices are still earlier in this transition than their public-facing stories admit. That is not a reason for pessimism; it is a reason to treat the coming year and a half as the window that matters.

References

1. FinOps Foundation. State of FinOps 2026 Report
2. FinOps Foundation. FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines
3. FinOps Foundation. Framework 2025 reflects the addition of Scopes as a core element of the FinOps Framework
4. FinOps Foundation. A One Word Change: How the FinOps Community Made Our Mission Evolution Inevitable
5. FOCUS. FinOps Open Cost & Usage Specification
6. FOCUS. What is FOCUS? Understand the FinOps Open Cost and Usage Specification
7. FOCUS. FOCUS Specification (current version)
8. Microsoft Learn. What is FOCUS?
9. Amnic. FOCUS: The Complete Guide for 2026
10. Holori. State of FinOps 2026: FinOps Got a Promotion. Here’s What Comes With It
11. Flexera. FinOps enters its technology value era: Insights from the State of FinOps 2026