Key Takeaways<\/h2>\n\n- Coverage doesn’t measure what most people think:<\/strong> A high coverage ratio doesn’t say anything about how much of the load was actually qualified for a commitment. Without the eligibility basis, the number is a ratio to an unknown quantity.<\/li>\n
- FOCUS 1.4 separates coverable from covered:<\/strong> Since June 4, 2026, the CommitmentProgramEligibilityDetails column has shown which programs a position is qualified for, regardless of whether a commitment applies. For the first time, standardized across providers.<\/li>\n
- The leverage lies before the purchase:<\/strong> Those who calculate eligibility-adjusted coverage rates see untapped savings potential before signing the next three-year reservation, rather than searching for it in the dashboard afterwards.<\/li>\n<\/ul>\n
Related:<\/span>Cloud Broker vs. Multi-Cloud Costs<\/a> \/<\/span> When Cloud Repatriation Pays Off<\/a><\/p>\nThe Number Everyone Reports, But Few Question<\/h2>\n
Commitment coverage is one of the first key figures that a FinOps team puts on the slide. It describes what proportion of eligible usage was actually covered by Reserved Instances, Savings Plans, or comparable commitments. Sounds clear. The problem lies in the word “eligible”.<\/p>\n
A coverage of 94 percent, like in the example above, is only as meaningful as the basis it refers to. Spot capacity, certain managed services, individual license models, and workloads outside the commitment regions often don’t count as eligible at all. If this basis shrinks, the quota increases, without a single euro being spent less. A team can be proud of this quota, while a significant part of the bill runs through at full on-demand tariff and simply doesn’t appear in the key figure.<\/p>\n
Until now, this gap was difficult to close because each provider defines and exports eligibility differently. Those who operated AWS, Azure, and Google Cloud side by side built their own logic for each provider to determine what was coverable. This logic became outdated with every new instance type. The more honest key figure, the eligibility-adjusted coverage rate, remained an estimate for most teams.<\/p>\n
\n13 to 30<\/div>\nThis is how much the contract commitment dataset grows with FOCUS 1.4.<\/strong> From 13 to 30 columns, to make payment models, term status, and discount logic comparable across providers.<\/div>\nSource: FinOps Foundation, FOCUS 1.4 (June 2026)<\/div>\n<\/div>\nThese 17 new columns in the contract commitment dataset alone are not an end in themselves. They are an acknowledgment that commitment decisions were previously made based on half-knowledge without this structure.<\/p>\n
What FOCUS 1.4 inserts between coverable and covered<\/h2>\n
FOCUS, the open specification for cloud cost and usage data, ratified version 1.4 on June 4, 2026. Two new datasets, 47 new columns. The key innovation for this discussion is a single field on the Cost-and-Usage dataset: CommitmentProgramEligibilityDetails.<\/p>\n
This field is a JSON object that lists, for each position, which commitment programs this position was qualified for. Each entry specifies a ProgramType, regardless of whether a commitment is currently applied. For the first time, this provides direct access to the raw data on what was coverable and what was not. The eligibility-adjusted coverage rate can be calculated from this, rather than estimated, although aggregation still occurs in your own tooling. Practitioners can identify untapped savings potential and compare commitment options across providers without maintaining their own eligibility logic for each provider.<\/p>\n
A calculation example illustrates the difference. If a cluster runs 60 percent on spot capacity, this share is not commitment-eligible at all. A reported coverage of 90 percent then only refers to the remaining 40 percent. The high spot load is completely excluded from consideration. The eligibility-adjusted view turns the question around. It measures how much of the actually coverable load is covered and reveals which part of the bill was never in the commitment game. If you only bring the first number to the slide, you are optimizing a metric that misses your own cost structure.<\/p>\n
The second block concerns the bridge between engineering and accounting. FOCUS 1.4 supplements an invoice detail dataset with the fields that appear on the invoice issued, from payment currency to payment deadline to order number. Additionally, a billing period dataset is added, which knows the actual billing boundaries of the invoicer. Anyone who has ever tried to accurately calculate a month-end close, despite a provider’s billing period not starting on the first of the month, knows the value of this seemingly dry addition.<\/p>\n
Taken together, this shifts what is considered a reliable source. Usage telemetry shows what technically happened. Only the comparison with the invoice detail shows what was actually billed. For a FinOps team, this is the difference between a plausible number and a verifiable one.<\/p>\n
What Platform Teams Should Change Before the Next Reservation<\/h2>\n
The obvious consequence is a change in the key performance indicator. It’s not just about the raw coverage that should be on the slide, but rather the eligibility-adjusted coverage rate plus the absolute Euro amount that still runs at on-demand conditions despite eligibility. This second number is the uncomfortable one. It represents the money left on the table before someone justifies a new three-year reservation.<\/p>\n![\"What](\"https:\/\/www.cloudmagazin.com\/wp-content\/uploads\/2026\/06\/post-iav0-hero-7.jpg\")
FOCUS 1.4 converts potential into actual contractual obligations.<\/figcaption><\/figure>\nThe second step is architectural. As long as the platform derives its cost decisions solely from usage data, invoice details remain a downstream accounting process. It’s more sensible to draw invoice data as an equal source into the cost pipeline and match it against telemetry. Only then does Shift-Left in FinOps carry more than just a buzzword, because the numbers that development teams react to match the invoice that arrives at the end of the month.<\/p>\n
A note on expectations is in order. The specification has been ratified, and the tools will follow.<\/p>\n
\nFOCUS 1.4 Roadmap<\/div>\n\n\nJune 4, 2026<\/div>\nFOCUS 1.4 ratified, with Invoice Detail, Billing Period, and the Eligibility column.<\/div>\n<\/div>\n\nQ3 2026<\/div>\nCompliance validator for FOCUS 1.4 will be available; until then, validation against 1.3 applies.<\/div>\n<\/div>\n\nAfterwards<\/div>\nProviders will add the new fields to their exports, and tooling and own pipelines will follow.<\/div>\n<\/div>\n<\/div>\n<\/div>\nThose who are already preparing commitment decisions should now request the eligibility view, even if it is temporarily still composed of provider-specific fields. The standard provides the language for this. The expensive confusion of coverable and covered can now be clearly identified, and that’s the prerequisite for addressing it.<\/p>\n
Frequently Asked Questions<\/h2>\n\nWhat is the difference between Coverage and Eligibility?<\/strong><\/summary>\nEligibility describes which usage qualifies for a commitment in the first place. Coverage describes what proportion of this qualified usage was actually covered. High coverage on a small eligibility basis can mask large on-demand costs.<\/p>\n<\/details>\n\nWhat exactly does the CommitmentProgramEligibilityDetails column do?<\/strong><\/summary>\nIt is a JSON field in the Cost and Usage dataset that lists, for each item, the commitment programs for which it was eligible, regardless of whether a commitment applies. This allows the eligibility-adjusted coverage rate to be calculated directly from the data, without provider-specific logic.<\/p>\n<\/details>\n\nWhat is the purpose of the new Invoice Detail and Billing Period datasets?<\/strong><\/summary>\nInvoice Detail maps the fields of the issued invoice, such as payment currency, payment deadline, and order number. Billing Period knows the actual billing periods of the provider. Together, they enable a clean comparison between usage and invoice, even if billing periods do not follow the calendar month.<\/p>\n<\/details>\n\nWhen can FOCUS 1.4 be tested productively?<\/strong><\/summary>\nThe specification has been ratified since June 4, 2026. The compliance validator for 1.4 is expected in the third quarter of 2026; until then, the formal check will be against FOCUS 1.3. The data fields can be used as soon as the respective provider exports them.<\/p>\n<\/details>\n\nDo we need to adjust our FinOps tools now?<\/strong><\/summary>\nNot immediately. It makes sense to introduce the eligibility-adjusted coverage rate as an additional key performance indicator and to treat the invoice reconciliation as an equivalent data source. Both can be done temporarily with provider-specific fields; FOCUS 1.4 just standardizes them.<\/p>\n<\/details>\n
\nEditor’s Reading Recommendations<\/p>\n
Related:<\/span>Cloud Broker vs. Multi-Cloud Costs<\/a> \/<\/span> When Cloud Repatriation Pays Off<\/a><\/p>\n Commitment coverage is one of the first key figures that a FinOps team puts on the slide. It describes what proportion of eligible usage was actually covered by Reserved Instances, Savings Plans, or comparable commitments. Sounds clear. The problem lies in the word “eligible”.<\/p>\n A coverage of 94 percent, like in the example above, is only as meaningful as the basis it refers to. Spot capacity, certain managed services, individual license models, and workloads outside the commitment regions often don’t count as eligible at all. If this basis shrinks, the quota increases, without a single euro being spent less. A team can be proud of this quota, while a significant part of the bill runs through at full on-demand tariff and simply doesn’t appear in the key figure.<\/p>\n Until now, this gap was difficult to close because each provider defines and exports eligibility differently. Those who operated AWS, Azure, and Google Cloud side by side built their own logic for each provider to determine what was coverable. This logic became outdated with every new instance type. The more honest key figure, the eligibility-adjusted coverage rate, remained an estimate for most teams.<\/p>\n These 17 new columns in the contract commitment dataset alone are not an end in themselves. They are an acknowledgment that commitment decisions were previously made based on half-knowledge without this structure.<\/p>\n FOCUS, the open specification for cloud cost and usage data, ratified version 1.4 on June 4, 2026. Two new datasets, 47 new columns. The key innovation for this discussion is a single field on the Cost-and-Usage dataset: CommitmentProgramEligibilityDetails.<\/p>\n This field is a JSON object that lists, for each position, which commitment programs this position was qualified for. Each entry specifies a ProgramType, regardless of whether a commitment is currently applied. For the first time, this provides direct access to the raw data on what was coverable and what was not. The eligibility-adjusted coverage rate can be calculated from this, rather than estimated, although aggregation still occurs in your own tooling. Practitioners can identify untapped savings potential and compare commitment options across providers without maintaining their own eligibility logic for each provider.<\/p>\n A calculation example illustrates the difference. If a cluster runs 60 percent on spot capacity, this share is not commitment-eligible at all. A reported coverage of 90 percent then only refers to the remaining 40 percent. The high spot load is completely excluded from consideration. The eligibility-adjusted view turns the question around. It measures how much of the actually coverable load is covered and reveals which part of the bill was never in the commitment game. If you only bring the first number to the slide, you are optimizing a metric that misses your own cost structure.<\/p>\n The second block concerns the bridge between engineering and accounting. FOCUS 1.4 supplements an invoice detail dataset with the fields that appear on the invoice issued, from payment currency to payment deadline to order number. Additionally, a billing period dataset is added, which knows the actual billing boundaries of the invoicer. Anyone who has ever tried to accurately calculate a month-end close, despite a provider’s billing period not starting on the first of the month, knows the value of this seemingly dry addition.<\/p>\n Taken together, this shifts what is considered a reliable source. Usage telemetry shows what technically happened. Only the comparison with the invoice detail shows what was actually billed. For a FinOps team, this is the difference between a plausible number and a verifiable one.<\/p>\n The obvious consequence is a change in the key performance indicator. It’s not just about the raw coverage that should be on the slide, but rather the eligibility-adjusted coverage rate plus the absolute Euro amount that still runs at on-demand conditions despite eligibility. This second number is the uncomfortable one. It represents the money left on the table before someone justifies a new three-year reservation.<\/p>\n The second step is architectural. As long as the platform derives its cost decisions solely from usage data, invoice details remain a downstream accounting process. It’s more sensible to draw invoice data as an equal source into the cost pipeline and match it against telemetry. Only then does Shift-Left in FinOps carry more than just a buzzword, because the numbers that development teams react to match the invoice that arrives at the end of the month.<\/p>\n A note on expectations is in order. The specification has been ratified, and the tools will follow.<\/p>\n Those who are already preparing commitment decisions should now request the eligibility view, even if it is temporarily still composed of provider-specific fields. The standard provides the language for this. The expensive confusion of coverable and covered can now be clearly identified, and that’s the prerequisite for addressing it.<\/p>\n Eligibility describes which usage qualifies for a commitment in the first place. Coverage describes what proportion of this qualified usage was actually covered. High coverage on a small eligibility basis can mask large on-demand costs.<\/p>\n<\/details>\n It is a JSON field in the Cost and Usage dataset that lists, for each item, the commitment programs for which it was eligible, regardless of whether a commitment applies. This allows the eligibility-adjusted coverage rate to be calculated directly from the data, without provider-specific logic.<\/p>\n<\/details>\n Invoice Detail maps the fields of the issued invoice, such as payment currency, payment deadline, and order number. Billing Period knows the actual billing periods of the provider. Together, they enable a clean comparison between usage and invoice, even if billing periods do not follow the calendar month.<\/p>\n<\/details>\n The specification has been ratified since June 4, 2026. The compliance validator for 1.4 is expected in the third quarter of 2026; until then, the formal check will be against FOCUS 1.3. The data fields can be used as soon as the respective provider exports them.<\/p>\n<\/details>\n Not immediately. It makes sense to introduce the eligibility-adjusted coverage rate as an additional key performance indicator and to treat the invoice reconciliation as an equivalent data source. Both can be done temporarily with provider-specific fields; FOCUS 1.4 just standardizes them.<\/p>\n<\/details>\n Editor’s Reading Recommendations<\/p>\nThe Number Everyone Reports, But Few Question<\/h2>\n
What FOCUS 1.4 inserts between coverable and covered<\/h2>\n
What Platform Teams Should Change Before the Next Reservation<\/h2>\n
Frequently Asked Questions<\/h2>\n
What is the difference between Coverage and Eligibility?<\/strong><\/summary>\n
What exactly does the CommitmentProgramEligibilityDetails column do?<\/strong><\/summary>\n
What is the purpose of the new Invoice Detail and Billing Period datasets?<\/strong><\/summary>\n
When can FOCUS 1.4 be tested productively?<\/strong><\/summary>\n
Do we need to adjust our FinOps tools now?<\/strong><\/summary>\n