By Most writing about the FinOps Open Cost and Usage Specification explains what it is and why standardised billing data is better than proprietary billing data. Both points are true and neither helps a finance or platform lead decide whether to spend this quarter's capacity on it.
The decision needs three numbers that are rarely put together: what the specification costs to license, what the pipeline costs to run, and what the migration costs in work that nobody budgets for. The first two are small and public. The third is the whole decision.
The specification is free. The pipeline is nearly free.
There is no licence fee. FOCUS is published openly by the FinOps Foundation and any organisation may implement it.
The pipeline that carries FOCUS data on AWS has three cost lines, all published. The export lands in Amazon S3, so there is a storage line that scales with the size of the estate and the retention period. Queries against it are typically run through Amazon Athena, which as published in August 2026 charges $5 per TB of data scanned. Visualisation, where AWS Cloud Intelligence Dashboards or a custom equivalent is used, runs on Amazon QuickSight, which as published in August 2026 charges $24 per author per month and $3 per reader per month on the Standard tier, or $40 and $20 respectively on the Pro tier.
For a mid-market estate, those lines add up to a number that does not require a business case. A ten-person reporting audience with two authors on the Standard tier is $78 per month before storage and queries.
If the pipeline is this cheap, and the specification is free, why is adoption not universal?
The cost is rework, and it lands in the reporting layer
Everything your organisation has built on top of billing data was written against a specific schema. Allocation rules that key off AWS cost categories. Chargeback models that join on resource tags in a particular shape. Finance reports that expect a column called one thing and not another. Anomaly rules. Budget alerts. The spreadsheet a controller maintains and nobody has looked at closely in two years.
FOCUS changes the column names, the cost definitions and the allocation conventions those artefacts depend on. The specification is explicit that this is the point: distinguishing billed cost from effective cost from list cost is one of its central contributions. That precision is exactly what breaks a query written when those three were treated as interchangeable.
So the migration cost is not paid in dollars. It is paid in the engineering and finance hours needed to inventory what exists, decide what still matters, rewrite it, and reconcile the new output against the old until people trust it. That reconciliation step is usually the longest, because trust in a cost number is slow to move.
None of that work is reduced by the specification, and none of it appears in the pipeline cost above.
The version gap that is not in anyone's pitch
Here is a fact worth checking before committing, because neither the standards body nor the provider has an interest in foregrounding it.
The FOCUS Steering Committee ratified version 1.4 on 4 June 2026. That release added two datasets, 47 columns, six attributes, 17 glossary entries and two supported features.
As of August 2026, AWS Data Exports offers FOCUS 1.2 with AWS columns, and FOCUS 1.0 with AWS columns. There is no 1.3 or 1.4 option.
Adopting FOCUS on AWS today therefore means adopting 1.2. That is a perfectly reasonable thing to do. It is a problem only if the reason you are adopting is something that arrived after 1.2:
| Added in | Capability | In the AWS export as of August 2026 |
|---|---|---|
| 1.4 | Invoice reconciliation, via new Invoice Detail and Billing Period datasets | No |
| 1.4 | Contract Commitment dataset expanded from 13 to 30 columns | No |
| 1.4 | Four data integrity attributes: correction handling, delivery handling, dataset completeness, dataset configuration | No |
| 1.3 | Contract commitments, split cost allocation, recency and completeness dimensions | No |
| 1.2 | Current AWS export level | Yes |
The FinOps Foundation stated that validator support for 1.4 would arrive later in Q3 2026, which is a reasonable indicator of how the certification and provider support cycle trails ratification.
The practical rule: decide which columns your use case needs, then confirm they exist in the version your provider exports, before the work is scheduled. A migration justified by invoice reconciliation would, on AWS in August 2026, deliver a schema that cannot do invoice reconciliation.
When adoption does not pay this year
Three conditions, and the case weakens when all three hold together.
You run one provider. Normalisation across clouds is the specification's primary benefit. With one provider there is nothing to normalise. What remains is vocabulary alignment with the wider industry, tool portability, and a shorter onboarding path for practitioners who already know the schema. Those are genuine and they are not urgent.
Your current allocation model already answers the questions asked of it. If finance gets the numbers it needs, in the shape it needs, on time, then FOCUS improves the plumbing behind an output nobody is complaining about. Cleaner data going into an unchanged decision produces an unchanged decision.
No downstream consumer is waiting. This is the sharpest test. If a tool, a partner, a reporting obligation or an acquirer needs your cost data in a schema they did not have to learn, the work has a due date and a beneficiary. If the honest answer is that nobody is waiting, the project will be deprioritised repeatedly, and a half-migrated reporting layer is worse than either end state.
Where the case is strong, it is usually strong for an obvious reason: a second provider has appeared, a FinOps tool expects FOCUS input, or a group function needs comparable numbers across entities that buy differently.
What the money buys when it does pay
The return is not a lower bill. FOCUS does not change what is provisioned or what is paid for it.
What it changes is the distance between a question and an answer. A single allocation model that holds across providers instead of one per provider. Cost definitions precise enough that two teams arguing about a number are arguing about the business, not the column. Tooling that connects without a bespoke adapter. New practitioners who can read the data on their first day because it looks like the data at their last employer.
Those compound quietly, which is also why they are easy to defer. The organisations that benefit most are the ones with enough cost conversations happening in parallel that the translation overhead has become visible.
A defensible sequence
Adopt the export first and change nothing else. AWS Data Exports supports running multiple exports from the same billing data, so a FOCUS export can sit alongside the existing Cost and Usage Report at the cost of a second copy in S3.
Then rebuild in order of consumption, not in order of complexity. The report someone actually reads on Monday morning moves first, and its output is reconciled against the old version until the difference is explained rather than tolerated. A variance nobody can explain is the point at which FinOps credibility is lost, and it is much cheaper to explain in the first report than the tenth.
Retire the old schema only when nothing queries it. Dual-running has a cost, it is small, and it converts a cutover risk into a line item.
The sequence matters more than the speed. A migration that stalls halfway leaves two schemas, two sets of numbers and no clarity about which is authoritative, which is the one outcome worse than not starting.
A worked example, using published August 2026 prices
The numbers below are an illustration built from public list prices, not an observed engagement. They exist to show which line dominates, because that is the part people get wrong.
Take a mid-market estate reporting to a finance audience of ten, with two people building dashboards and eight reading them, and a cost dataset that a month of queries scans two terabytes of in total.
| Line | Basis | Monthly |
|---|---|---|
| FOCUS specification | open standard, no licence | $0 |
| Athena queries | $5 per TB scanned, 2 TB | $10 |
| QuickSight authors | $24 per author per month, Standard tier, 2 authors | $48 |
| QuickSight readers | $3 per reader per month, Standard tier, 8 readers | $24 |
| S3 storage for the export | scales with estate size and retention | small relative to the above |
| Recurring total | roughly $82 plus storage |
Now put the one-time rework beside it. If migrating the reporting layer occupies a data engineer and a finance analyst for even a fortnight between them, that fortnight costs multiples of a full year of the pipeline above.
That ratio is the entire decision. Optimising the recurring line is pointless; it is already noise. The only number worth estimating carefully is how much reporting logic exists, how much of it still matters, and how long reconciling the two versions will take. Organisations that skip that estimate are not underestimating the cost of FOCUS. They are underestimating the size of what they already built.
Prices above were read from the AWS Athena and QuickSight pricing pages in August 2026 and will move.
The question to answer before you schedule it
Not "should we adopt FOCUS", which has an obvious and unhelpful answer. The useful question is narrower: which specific consumer of cost data is waiting for a normalised schema, and does the version our provider exports today contain what that consumer needs?
If both halves have a concrete answer, the rework is justified and the sequence above applies. If either half is speculative, the specification will still be there next year, at a higher version number, with more of it available in the export.
TechNative is a FinOps Foundation Implementation Partner and works with European organisations on cost allocation, chargeback and reporting design on AWS. If you want a second opinion on whether a FOCUS migration is worth scheduling in your estate, get in touch.
