Introducing FOCUS 1.4: Invoice Reconciliation, Commitment Details, and Specification Maturity
Shawn Alpay
Matt Cowsert
June 10, 2026 - 10-minute read
Key Insight: With the release of FOCUS 1.4, the specification evolves beyond basic cloud consumption, taking a major step forward in our ongoing journey to tell the broader Technology Value story. It builds a critical bridge to finance, introducing the Invoice Detail dataset so FinOps and Accounts Payable teams can tie usage directly to the physical bill. It exposes the anatomy of the deal by expanding the Contract Commitment dataset and adding eligibility tracking to reveal what was coverable. Crucially, 1.4 establishes rigorous standards of data integrity, wrapping the new Billing Period dataset with clear rules for corrections, data delivery, and completeness to build trust in FOCUS as a system of record. Together, these updates lay the vital groundwork for FOCUS 1.5, which will bring unit and token economics into view by introducing the Price Sheet and tracking inference value at the AI frontier.
The FOCUS Steering Committee ratified the FOCUS version 1.4 specification on June 4, 2026. The release adds 2 datasets, 47 columns, 6 attributes, 17 glossary entries, and 2 supported features. The improvements help satisfy these primary use cases:
What You Can Do with FOCUS 1.4
Build the bridge to finance: Reconcile usage directly to invoices using the new Invoice Detail and Billing Period datasets.
Expose the anatomy of the deal: Compare commitment structures across providers with 17 new columns.
Track commitment eligibility: Measure exactly what was coverable to identify real savings opportunities.
Recognize costs consistently: Use standardized rules for covering/covered charges to eliminate double-counting across providers.
Enforce standards of integrity: Leverage FOCUS as your system of record with strict, standardized rules for corrections, delivery, completeness, and configuration.
Upgrade without breaking what you built: zero incompatible changes, clearer requirements.
Conformance program advances: FOCUS Validator now supports 1.3 conformance testing to validate 1.3 implementations. Validator support for FOCUS 1.4 will be available later in Q3 2026.
Build the Bridge to Finance
Problem: The Cost and Usage dataset helps answer “what did we use?” not “what’s on the invoice?” Accounts payable teams cannot always tie invoice line items to usage records. FinOps practitioners cannot catch invoice errors before payments are made.
Change in 1.4: FOCUS 1.4 introduces two new datasets and a supported feature dedicated to reconciliation:
The Invoice Detail dataset carries the financial record of charges as they appear on issued invoices, including payment currency, payment terms, due date, and purchase order number.
The Billing Period dataset provides invoice-issuer-aware billing period boundaries and status, enabling accurate period-over-period analysis when billing periods do not align with calendar months.
The new Invoice Reconciliation supported feature joins Invoice Detail to Cost and Usage on Invoice ID, with Invoice Detail ID enabling line-item reconciliation and Payment Currency Invoice Detail ID linking records when billing and payment currencies are tracked at different grains.
Rounding tolerance: A new Rounding Variance Tolerance appendix entry defines a formula for precision differences between high-decimal-place cost data and two-decimal-place invoice totals. Sums match invoices within a statistically grounded tolerance rather than failing on rounding noise.
Why this matters: This is the first FOCUS release that lets FinOps teams interface with accounts payable and finance work from the same billing facts. Accounts payable gets payment terms, due dates, and PO numbers on Invoice Detail. Finance gets tax line items that are typically excluded from Cost and Usage, plus multi-currency settlement lineage through PaymentCurrencyInvoiceDetailId. FinOps gets consumption records that join to invoices through standard identifiers regardless of provider. Together, these shorten the monthly close cycle and eliminate the manual stitching that previously sat between AP, finance, and FinOps tooling.
Who benefits: Accounts payable, finance teams managing month-end close, FinOps practitioners reconciling consumption to invoices.
Compare Commitment Structures
Problem: The Contract Commitment dataset shipped in 1.3 with 13 columns. That was enough to know a commitment existed, but not enough to understand how it was structured, what it cost, or where it was in its lifecycle.
Change in 1.4: The dataset grows from 13 to 30 columns, organized across four key groups: identification, lifecycle and periods, commitment structure, and cost and quantity. Separately on Cost and Usage, the existing Contract Applied column gains a formalized JSON Object Schema in 1.4, replacing the looser inline structure used in 1.3 and allowing its contents to be parsed without provider-specific knowledge.
Why this matters: Practitioners can now compare commitment structures across providers from a single dataset. Questions like “what’s the payment schedule?”, “is it usage-based or spend-based?”, and “what discount rate does it carry?” have standard columns instead of requiring portal lookups or contract PDF reviews.
Who benefits: Procurement, finance teams evaluating commitment performance, cost optimization leads comparing reservation and savings plan options across providers.
Track Commitment Eligibility
Problem: Practitioners could see which charges were covered by a commitment, but not which uncovered charges were eligible for one. Calculating true coverage rates or identifying savings opportunities meant reverse-engineering eligibility rules from provider documentation.
Change in 1.4: A new Commitment Program Eligibility Details column on Cost and Usage, paired with a supported feature of the same name. The column contains a JSON object with a CommitmentPrograms array, where each entry identifies a ProgramType the charge qualifies for, regardless of whether a commitment is currently applied.
The structure covers both discount-bearing programs (Flexible Spend Plans, Resource Reservations) and capacity-reservation programs (Advance Resource Commitments) in one place. SaaS providers that don’t itemize commitment discounts at the row level can still surface eligibility through this column.
Why this matters: Practitioners can now calculate eligibility-adjusted coverage rates, identify uncovered savings opportunities, and compare commitment options across providers without building provider-specific eligibility logic.
Who benefits: FinOps teams running commitment optimization, practitioners benchmarking commitment coverage across providers.
Recognize Costs Consistently Across Providers
Problem: To read Billed Cost and Effective Cost correctly, FinOps Practitioners had to learn each provider’s commitment rules. Prepaid commitments, marketplace credits, and amortization schedules each followed provider-shaped requirements, so aggregating across providers could double-count or undercount depending on who reported which row.
Change in 1.4: FOCUS replaces those rules with one provider-agnostic constant: across a covering charge and everything it covers, Effective Cost and Billed Cost sum to the same total, within the covering charge’s charge period. Two definitions make it precise:
A covering charge is a purchase that pays for other charges (for example, a reserved instance prepayment or a marketplace credit pool).
A covered charge is consumption that draws against a covering charge (for example, hourly compute consuming a reservation).
Recognized cost moves from the covering charge to the charges it covers, and every per-category rule follows from that:
A covering purchase has an effective cost of 0; its cost flows to the covered usage as that usage is consumed.
Usage covered by a covering charge carries the recognized share of that cost.
Everything standalone (uncovered usage; purchases that neither cover nor are covered; Tax and Credit) has effective cost equal to billed cost.
Adjustment charges may differ, to reflect post-charge corrections.
One more rule prevents double-counting: when FOCUS dataset instances are merged, charges generated by entities that did not originate the cost and usage data have an effective cost of 0.
Why this matters: FinOps Practitioners aggregating across providers, dataset instances, or billing accounts get the same answer no matter where the underlying charges originated. One auditable model replaces self-maintained provider-specific commitment and marketplace rules.
Who benefits: FinOps Practitioners building cross-provider accrual reports, finance teams validating cost recognition, data generators conformantly implementing FOCUS.
Standards of Integrity: Trusting the Data
Problem: Before 1.4, FOCUS left key operational behaviors undefined. FinOps Practitioners had no standard way to know how a data generator surfaces billing corrections, how its deliveries arrive, or whether a FOCUS dataset even carried every column they needed. Those gaps forced provider-specific logic and parallel pipelines, keeping FOCUS a supplement rather than a replacement.
Change in 1.4: Four attributes give these behaviors explicit, single-purpose definitions.
Correction Handling provides three documented styles: Replacement (a complete snapshot overwrites the prior one), Delta (additive records carry the net change), Ledger (explicit reversals and re-entries preserve a full audit trail). Generators must document which they use.
Delivery Handling is now explicitly stated. Overwrite delivers a complete snapshot, Append adds records while preserving prior deliveries. They combine in practice (overwrite an open billing period, append once it closes). The spec explicitly bars any implementation that would make practitioners deduplicate records.
Dataset Completeness mandates that data generators carry native dataset columns as custom (x_) columns, dropping one only with a documented, justified reason, so the FOCUS dataset can stand on its own.
Dataset Configuration allows FinOps Practitioners to trim a dataset to just the columns a workflow needs, cutting storage and processing cost; it stays conformant because every included column still meets its full requirements.
Completeness guarantees the column is available; Configuration lets FinOps Practitioners decide whether to pull it.
Why this matters: For FinOps Practitioners, corrections, deliveries, and column coverage behave predictably across providers, so FOCUS can serve as the system of record. For data generators, each attribute owns a single, testable concern, so they get unambiguous conformance targets and the Validator can check them mechanically.
Who benefits: FinOps Practitioners and platform teams who want FOCUS as their primary source, and data generators implementing conformance.
Upgrade Without Breaking What You Built
Beyond the feature work above, FOCUS 1.4 completes the deprecation lifecycle started in 1.3 by removing Provider Name and Publisher Name, whose roles are now filled by Service Provider Name, Host Provider Name, Invoice Issuer Name, and Data Generator metadata. Several specification-level improvements also help the standard scale:
Attribute consolidation: three attributes retire in 1.4, and none of their requirements disappear. Column Handling splits into FOCUS Column Handling and Custom Column Handling, separating standard columns from x_ extensions. Discount Handling moves to a dedicated appendix entry. Invoice Handling‘s requirements move into Delivery Handling and Dataset Completeness, with related guidance in the new Invoice and Billing Period Handling appendix entry. Nothing was lost; the requirements just got better homes.
Format and unit standardization:Numeric Format now mandates allowed data types and precisions. Unit Format gains normative rules for base units, compound units, ratio units, and unit quantities.
Keyword standardization: FOCUS 1.4 aligns normative language with BCP-14, replacing the deprecated ‘RECOMMENDED’ with ‘SHOULD’. The payoff: requirements are clearer to read, easier to implement, and simpler for the FOCUS Validator to test, with no change to the strength of any requirement.
Conformance Program Update
The FOCUS Validator now supports 1.3 conformance testing, enabling data generators to validate their 1.3 implementations today. Validator support for FOCUS 1.4 will be available later in Q3 2026, opening certification for data generators that produce FOCUS 1.4 datasets.
Looking Ahead to FOCUS 1.5
Active work on FOCUS 1.5 has begun. Highlights of the next release include:
Native AI support. FOCUS 1.5 is scoped to surface AI model identity and token consumption (input and output) in the Cost and Usage dataset, with worked examples for token- and generation-based AI billing.
Price Sheet dataset. A standardized representation of provider list pricing, separate from the consumption record. Practitioners gain a stable reference for unit price analysis, contract benchmarking, and commitment optimization without parsing each provider’s pricing API.
Migration Guide. A new resource to help organizations move between FOCUS versions, easing adoption of each release.
The FOCUS specification benefits the entire FinOps community. Whether or not your organization is a Contributing Member, several actions accelerate adoption:
Request FOCUS adoption from SaaS, PaaS, and on-premises vendors that have not yet shipped FOCUS exports. Provider participation in 1.5 starts with 1.4 customer demand.
Adopt FOCUS 1.4 terminology organization-wide. Update internal documentation, dashboards, and training materials to use covered and covering charge concepts.
Request Invoice Detail and Billing Period exports from your current providers. Connect accounts payable workflows to FinOps tooling using the new datasets.
Validate existing dashboards against the Effective Cost baselines for each Charge Category. Confirm accrual reports continue to behave as expected after data generators implement the new requirements.
