What’s coming in FOCUS 1.5, and what is not

How the dataset works

• Each record carries one unit price and says what kind of price it is, such as a public list price, a list price fixed for a contract, usually when it starts, or another contracted rate. Contract ID is empty for a price that is not specific to a contract and identifies the contract for one that is.
• A data generator includes the dataset when its operating model includes unit pricing, the same condition that governs the SKU columns in Cost and Usage.
• It is delivered as a snapshot of the current price list. History comes from each price’s effective dates, and from keeping successive snapshots where a provider does not deliver past prices.
• Matching a cost row to its price uses the service provider, the SKU Price ID, the charge date against the price’s effective dates, the contract, the currency, and the kind of price being compared.
• SKU Price Eligibility describes which accounts or scopes a price applies to, with inclusions and exclusions, validated by a published JSON schema.

The two supported features

• Catalog Discovery and Price Estimation: the list prices in force at a point in time, the estimated cost of a planned workload, the prices a billing account is eligible for, usage rates separated from purchase fees and credit values, announced price changes and retirements, and list prices compared across regions.
• Rate Optimization and Contract Evaluation: what negotiation reduces a rate by, public and negotiated prices at a given quantity, the quantity tier that applies to observed consumption, the effect of reaching the next tier, the purchase terms offered for a SKU, the effect of moving consumption to a contracted rate, and recorded unit prices compared with published rates.

The properties are ModelDeveloper, ModelFamily, ModelId, and ModelVersion. ModelId is the identifier as it appears in billing and can differ between providers selling the same model; family and version are as the model developer defines them. No columns are added and existing requirements are unchanged, so the change is additive for every data generator. Including these properties is recommended rather than required, so a conformant dataset can omit them.

A worked example covers a model bought directly from its developer and the same model served by a cloud provider, where the service provider and the model developer are different companies.

• TokenCacheAction takes “Uncached”, “Read”, “Write”, or “Other”. TokenDirection takes “Input” or “Output”. They are the first FOCUS-defined SKU Price Details properties with a fixed set of allowed values. Including them is recommended rather than required.
• A price that bills several kinds of tokens on one meter omits the property that would misdescribe them.
• A cached token counted on a “Read” or “Write” row is not counted again on another row, so token totals do not double count.
• Reasoning tokens metered separately carry “Output”. Modality, reasoning effort, cache retention duration, and context window size are not values of these properties.
• A worked example shows two providers that meter caching differently, and two example queries join the Resource Usage supported feature: cache hit rate by model, and the ratio of input to output tokens by model.

The scenarios

• A model developer billing per token, directly.
• Several models on one invoice, each priced separately.
• Cached tokens bought through a cloud provider’s marketplace.
• A cloud provider billing for its own service that serves a third-party model.
• A prepayment drawn down by token usage.
• A multi-model invoice through a cloud marketplace, with cache meters.

The AI Model Billing supported feature adds two queries: effective cost per million tokens by SKU, token direction, and cache action, and token consumption over time. The example rows use the model identity and token properties and the requester columns described on this page. Requested by NatWest, SLB, UK Government Digital Service, Shutterstock, Syngenta, Anglepoint, AWS, and the FinOps Foundation.

The CurrencyFormat attribute previously allowed virtual currency while also requiring an ISO 4217 code on every value, which no provider-issued unit has. Now ISO 4217 applies when a value represents a national currency, and a column must not use an ISO 4217 code for anything else. The glossary adds consumption currency. A SaaS example shows a consumption currency pricing model.

These are recommended values in the Unit Format attribute, which governs how units are written in columns such as Consumed Unit and Pricing Unit.

• The columns are PrincipalId, CredentialId, and RequesterDetails. All three are Conditional, governed by a new operating model condition for requester attribution.
• Principal ID is the attribution dimension: it stays the same while the credentials that authenticate it rotate. Credential ID is the audit dimension: it separates charges that share a principal but came from different keys or sessions.
• Neither ID column may contain a value that authenticates a request, such as the key string itself.
• Neither column identifies who benefits from a charge. A shared workload, a gateway, or an embedded assistant can act for people who never appear in billing data.
• Requester Details is a JSON array of the attributes a provider publishes for the principal and the credential, validated by a published JSON schema. It is populated whenever either ID is, and an entry for the principal or the credential appears only when that ID is populated. Further levels, such as a delegating identity or a client application, can be carried as custom entries.
• A worked example walks through 14 scenarios, from a generative AI API key owned by a user to seat-based SaaS, marketplace purchases, and billing-system charges that carry neither identifier.

The columns are ListCost, ListUnitPrice, ContractedCost, and ContractedUnitPrice. The revision also aligns the pricing currency unit price columns with their billing currency counterparts and consolidates the operating model conditions that decide when these columns must appear.

The column, AllocatedServiceName, is populated on rows a data generator produces through split cost allocation and empty otherwise, and it should match the Service Name the data generator uses for that service. Worked examples and a field mapping for data generators accompany the updated split cost allocation supported features.

The broader expansion of allowed values for on-premises, SaaS, and physical infrastructure is not part of 1.5; see the last section.

This restores a preservation requirement to the Tags column so provider-side normalization cannot silently rename a key.

ContractCommitmentDurationType should use a “number and unit” format, with unit names from the Unit Format attribute from Minute through Year. The compound format rule was also split into separate requirements.

The specification already stated each presence rule, in each column’s own words; the named criteria behind them lived only in the Requirements Model. Each condition is now a defined term, the Conditional columns’ Content Constraints tables name the condition that governs them, and the dataset overview tables use one convention for columns that depend on more than one condition.

The guide is published as supporting content alongside the specification rather than as normative text.

The 1.5 model’s structure, including an entity for operating model conditions, is merged, along with an automated workflow that extracts rules from the specification text. The 1.5 rule additions follow the specification changes they describe.

• A duplicative cost formula requirement removed from Pricing Quantity.
• Feature Level value lists completed in the overview and the contributor guidelines.
• Commitment discount example data reconciled so SKU Price IDs are used consistently.
• Specification components and anchor links validated during the build, and blockquotes delineated in the PDF.
• The contributor guidelines refactored for consistent style and rules.

The draft dataset and its supported feature stay open on GitHub for review.

• Region scope on SKU prices, telling globally served pricing from region-pinned pricing. Postponed in September, with its name and its relationship to the SKU Price dataset still open.
• A feature-level rubric for deciding whether a column is Mandatory or Conditional, so requirements hold across regions and billing models.
• Specification examples checked against the FOCUS Validator, moved so the examples and the validator can both align with 1.5.
• Scoped detail configuration, letting a practitioner choose optional, higher-cardinality detail such as principal-level attribution for parts of a dataset.
• A Consumer ID column alongside the requester columns.
• Broader Service Category allowed values for on-premises, SaaS, and physical infrastructure.
• Tiered pricing glossary terms, held for a later release.

AI pricing dimensions

• Reasoning tokens billed but not returned in the response (FR 2487).
• The standing charge for keeping a context cache (FR 2488).
• Input modality: text, image, audio, and video (FR 2489).
• Prices that change with context window size (FR 2521).
• Priority, standard, and batch inference tiers (FR 2437).
• Provisioned throughput as a commitment (FR 2371).
• Deeper AI service subcategories, including Agentic AI (FR 1943).

New datasets and extensions

• A SKU Properties dataset for normalized attributes such as vCPU and memory (FR 1045).
• The second phase of the Contract Commitment dataset (FR 1938).
• Invoice Detail enhancements for reconciliation (FR 1936).
• A companion Utilization dataset (FR 2654).

Pricing and discount clarity

• An empty List Cost for negotiated-only pricing (FR 1523).
• List price defaulting rules (FR 1832) and tier handling in list prices (FR 1625).
• Pricing categories for SaaS commitments (FR 1933) and a Charge Subcategory (FR 1934).
• Payment currency support (FR 1997) and content requirements for every column (FR 1890).

Classification, defaults, and examples

• IaaS, PaaS, and SaaS service-model classification (FR 959) and defaults for empty name columns (FR 1039).
• Line-item examples for adjustments (FR 1489) and pricing unit conversion (FR 1490).
• Link validation on every pull request, alongside the build-time check (FR 2012).