The FinOps Open Cost and Usage Specification (FOCUS) is the most important standardisation effort in cloud financial management since the FinOps Foundation framework itself. It promises to end the era where every hyperscaler has its own billing format, its own column names, its own assumptions about what counts as "spend". For organisations operating on AWS, Azure, or GCP (and especially those operating on more than one), FOCUS removes a category of work that has consumed FinOps teams for years.
Specification adoption alone, however, does not produce FinOps outcomes. A standardised data set in the hands of teams that lack the culture to act on it is just cleaner data going to waste.
What FOCUS actually is
FOCUS is a vendor-neutral specification for cloud cost and usage data. It is published and maintained by the FinOps Foundation, currently at version 1.2, with active contributions from AWS, Microsoft, Google, Oracle, IBM, and a growing list of ISVs and end users.
The specification defines three things.
A common schema for billing and usage records. Column names like BilledCost, EffectiveCost, ResourceId, ServiceName, ProviderName, and dozens of others, each with a precise definition of what the value represents. Where AWS calls a service "EC2" and Azure calls it "Virtual Machines", FOCUS provides a unified ServiceName column that uses normalised values. Where AWS bills in different time granularities than GCP, FOCUS specifies how usage periods are reported.
Strict definitions of cost concepts. The specification distinguishes between billed cost (what appears on the invoice), effective cost (what the customer actually pays after discounts and credits), and list cost (the undiscounted public price). These distinctions matter for chargeback, showback, and rate optimisation analysis. Without them, FinOps teams have spent years arguing about which cost is the "real" cost.
Allocation and tagging conventions. FOCUS standardises how resource attributes (tags, labels, cost categories) are exposed in the data, so that allocation logic written for one cloud works for another with minimal modification.
The practical effect: a FinOps team working on a FOCUS-compliant data set can write a single chargeback model that applies across AWS, Azure, and GCP, instead of three parallel models with provider-specific transformations.
The major hyperscalers all support FOCUS exports natively. AWS provides FOCUS-compliant Cost and Usage Report exports through the standard CUR mechanism. Microsoft Azure exports FOCUS data through Cost Management exports. Google Cloud Billing supports FOCUS through BigQuery exports. SaaS vendors are following: Datadog, Snowflake, MongoDB, and others are publishing FOCUS-compliant cost feeds, which collapses third-party software spend into the same analytical surface as raw cloud spend.
For organisations on a single cloud, FOCUS still matters, but the urgency is lower. The specification mainly removes future migration friction (if and when a multi-cloud strategy emerges) and aligns internal terminology with industry-standard vocabulary.
For multi-cloud organisations, FOCUS is the difference between a FinOps practice that scales and one that drowns in data engineering.
Why FOCUS alone is not enough
Specification provides direction. Direction is necessary, but it is not behaviour.
The teams that struggle with cloud cost are rarely struggling because their data is in the wrong format. They are struggling because the data, however well-formatted, does not change what happens in their organisation. Engineering teams continue to provision oversized resources because that is what they have always done. Finance teams continue to receive surprising bills because they are not invited into architecture decisions. Procurement teams continue to negotiate without usage data because nobody hands it to them.
FOCUS does not solve any of these problems by itself.
What FOCUS does is remove a specific class of friction: the friction of getting clean, comparable data into the hands of people who could act on it, if they were structurally able to. Once that friction is gone, the question shifts from "can we see what is happening" to "are we willing and able to do something about it". And that question is cultural, not technical.
The diagnostic is straightforward. An organisation that adopts FOCUS, builds dashboards on top of it, and finds nothing changing in cost trajectory has a culture problem, not a data problem. The data is now telling them clearly what was previously fuzzy. The fact that nothing changes means the data was never the bottleneck.
Two failure modes are common. Some organisations adopt FOCUS, produce beautiful dashboards, and treat the dashboards themselves as the deliverable. Cost reviews happen, charts are presented, and nobody is empowered to make changes. The dashboards become a status ritual rather than a decision tool. Other organisations adopt FOCUS, identify cost optimisation opportunities, and find that engineering teams cannot or will not act on the recommendations because the incentive structure rewards feature delivery over cost discipline. In both cases, the specification did its job; the culture did not.
Five cultural enablers that make FOCUS work in practice
Five behaviours determine whether FOCUS adoption produces change. These are not optional extras; they are prerequisites for the specification to deliver value beyond cleaner reports.
Specification and behaviour must align. A standardised data format is direction; team behaviour is what follows direction. If the data shows that team A is overspending by 30 percent but team A faces no consequences and receives no support to change, the data is decorative. Alignment means leadership commits to acting on what the data reveals, even when acting is uncomfortable. This is the foundational enabler. Without it, the others are exercises in form over substance.
Focus means saying no. The word "focus" is not accidental in the specification name. To focus is to choose, and choosing requires excluding. Teams adopting FOCUS need to develop the cultural muscle to deprioritise things that the data shows are not worth the cost. This is harder than it sounds, because saying no often means refusing requests from peers, leaders, or other teams. Organisations where saying no is socially expensive will struggle to act on FOCUS data even when the data is clear.
Psychological safety to challenge scope. When FOCUS data reveals that a planned project will cost more than its expected return, someone needs to be able to say so without career risk. The same applies in reverse: when FOCUS data reveals that an under-funded project is delivering disproportionate value, someone needs to be able to advocate for more investment. Both directions require that team members can challenge decisions without being labelled as obstructionist or insufficiently committed. Without psychological safety, FOCUS data becomes politically inconvenient and quietly ignored.
Decision-making clarity. Who decides what is in scope and what is not. Who has the authority to deprioritise a project the data shows is unprofitable. Who can approve an investment the data shows would pay back. Most organisations are vague about this, and vagueness becomes a vacuum where decisions either default to "continue as before" or escalate endlessly. FOCUS surfaces decisions that need to be made; the organisation needs a clear answer about who makes them.
Outcome metrics, not output metrics. Output metrics measure activity (number of dashboards built, percentage of resources tagged, number of cost reviews held). Outcome metrics measure result (change in unit economics, accuracy of cost forecasting, percentage of cloud commit retired efficiently). FOCUS makes outcome measurement possible because the data is consistent across periods and providers. Organisations that continue to measure FinOps maturity by output metrics after adopting FOCUS are missing the point of the adoption.
These five enablers reinforce each other. An organisation with strong alignment but weak psychological safety produces compliance behaviour that drains creativity. An organisation with strong psychological safety but unclear decision-making produces lots of debate without resolution. The five together produce a FinOps culture that can actually use what FOCUS provides.
How does FOCUS implementation work in AWS environments?
For AWS-centric organisations, the path to FOCUS adoption runs through three artifacts.
The Cost and Usage Report (CUR) is the foundational data export. AWS now provides FOCUS-compliant CUR exports as a standard option. New CUR configurations can be set up directly in FOCUS format; existing CURs can be re-configured. The data lands in S3 in standardised Parquet or CSV format, ready for ingestion into analytical tools.
AWS Cloud Intelligence Dashboards are the canonical visualisation layer for AWS cost data. The dashboards (CUDOS, Cost Intelligence Dashboard, KPI Dashboard) are open-source, maintained by AWS, and increasingly aligned with FOCUS column names. Organisations that adopt the Cloud Intelligence Dashboards on FOCUS-compliant CUR exports get a working FinOps reporting environment with relatively little custom development.
For multi-cloud organisations, the architectural pattern is to land FOCUS-compliant exports from each provider in a common analytical store (typically S3 or another object store), use a query engine like Athena or BigQuery on top, and build dashboards that operate on the unified schema. Because all providers expose data in FOCUS format, the query layer does not need provider-specific logic.
Three implementation considerations matter for AWS organisations.
Cross-account FOCUS data access requires careful IAM design. CUR exports land in a single S3 bucket in a designated payer account, but FinOps teams typically need to query the data from a separate analytics account. This is a standard cross-account data access pattern, but it must be designed before the analytical work begins.
Athena and Parquet remain the cost-optimal query layer for FOCUS data on AWS. CSV exports work but are slower and more expensive at scale. Parquet exports with partitioning by billing period reduce query cost by orders of magnitude.
The AWS Marketplace dimension matters for organisations using Marketplace SaaS purchases against PPA commit retirement. Marketplace spend appears in CUR with specific identifying fields; FOCUS-compliant CUR preserves these. The combination allows FinOps teams to track Marketplace contribution to PPA retirement directly, which is critical for the strategic work covered in our guide on AWS Marketplace governance.
What is the accountability gap in FinOps FOCUS adoption?
FOCUS does something subtle that is easy to miss in the technical excitement: it makes accountability possible at a much finer granularity than before.
Before FOCUS, allocating cost to a specific team or product required custom transformations, often with assumptions baked in. With FOCUS, the data exposes cost per resource, per tag, per allocation dimension in a standardised way. A team can be shown, with high precision, what their share of the cloud bill is.
This precision is necessary, but not sufficient.
Showing a team their cost is only useful if the team has authority to act on the cost. If engineering teams see their EC2 spend but cannot make instance-type decisions, the visibility produces frustration rather than optimisation. If product teams see their feature-level cost but cannot deprioritise expensive features, the visibility produces resentment rather than realignment.
The accountability gap is the distance between visibility and authority. FOCUS adoption that closes the gap produces results. FOCUS adoption that widens the gap (more visible cost, no more authority to act) produces FinOps theatre.
Closing the gap requires explicit decisions in three areas.
Where in the organisation does decision authority over cloud spend actually sit. Engineering, finance, product, platform; usually all four claim partial ownership. FOCUS data forces the question because the data is now precise enough to assign cost to specific teams.
What incentives reward acting on cost data. Bonus structures, performance metrics, team objectives. If engineering performance is measured purely on feature velocity, no amount of cost transparency will change behaviour.
How escalation works when cost decisions are contested. The team that wants to optimise a service often differs from the team that owns it. FOCUS data exposes these conflicts; the organisation needs a clear path to resolve them.
Organisations that do this work alongside FOCUS adoption see real outcomes. Organisations that adopt FOCUS hoping the data alone will drive change tend to be disappointed.
When does partner support add value in FOCUS adoption?
The technical work of adopting FOCUS on AWS is not the hard part. CUR configuration, dashboard deployment, and query layer setup are well-documented patterns that competent cloud engineering teams can execute in a few weeks.
The harder work is the cultural and organisational work that makes FOCUS adoption produce results. This is where partner support typically adds the most value, particularly for European mid-market organisations where dedicated FinOps capability is often absent in-house.
The TechNative partnership model has three layers, and FOCUS adoption typically engages all three.
The reseller layer, where TechNative is the contract counterparty for AWS spend. For organisations on a Partner-Led PPA, FOCUS-compliant data is part of the standard reporting that TechNative provides, and the cultural enablers are reinforced through quarterly cost reviews and FinOps coaching.
The managed services layer, where TechNative operates the AWS estate. This is where FOCUS data becomes operational: monitoring on cost trajectory, anomaly detection on spend patterns, automated alerts when teams approach budget thresholds. The data is only useful if someone is paid to watch it daily; managed services partners are typically that someone.
The consultancy layer, where TechNative delivers FinOps Foundation Implementation Partner work. This includes the cultural and organisational work that makes FOCUS adoption stick: skill gap analysis, decision-making framework design, training (FinOps Foundation Certified Practitioner and FinOps Fundamentals), measurement methodology for outcome metrics, change management support during the cultural transition.
A common engagement pattern: an organisation adopts FOCUS technically (often in a few weeks of engineering effort), then engages TechNative consultancy to design the cultural and organisational changes that turn the data into outcomes. The technical work is one-off; the cultural work is ongoing.