Every cloud provider bills you in its own dialect. The FinOps Foundation’s FOCUS specification exists to translate those dialects into one schema so that “what did we spend, on what, under which commitment” has a single answer regardless of provider.

The specification is well documented. What is less documented is what happens when you point it at a real enterprise estate and try to answer questions that finance actually asks. These are notes from doing that.

The three questions worth building for

Most commitment-discount reporting collapses into three questions. Everything else is a variation.

Coverage — of the eligible usage we ran this month, what share sat under a commitment? Uncovered eligible usage is money paid at on-demand rates that did not have to be.

Utilization — of the commitment we bought, what share did we actually consume? Unused commitment is money spent on capacity that went nowhere.

Effective savings rate (ESR) — across everything, what did we actually pay versus what the same usage would have cost at on-demand rates? This is the number that survives contact with a CFO, because it is the only one that nets the two failure modes against each other.

Coverage and utilization pull in opposite directions. Buy more commitment and coverage goes up while utilization risks going down. ESR is the referee. Build the first two as diagnostics and the third as the headline.

Where FOCUS earns its keep

The schema’s contribution is that it normalizes the columns you need for all three calculations across providers: a consistent notion of billed cost versus effective cost, a consistent way to identify the commitment a line item was applied to, and consistent pricing fields to reconstruct the on-demand counterfactual.

Before FOCUS, each of those was a provider-specific join against a differently-shaped export, and every new provider meant rewriting the analysis. After, the analysis is one set of expressions over one schema and provider differences move into ingestion, where they belong.

That is the honest scope of the benefit. FOCUS does not tell you what your savings rate is. It makes the query that computes it portable.

The parts that are still hard

The on-demand counterfactual. ESR requires knowing what the usage would have cost without the commitment. That is a reconstruction, not a fact — it depends on which price you consider the baseline, and the answer moves depending on whether you use list price, negotiated price, or the price the same account paid for equivalent uncommitted usage in the same period. Pick one, write it down, and never quietly change it. A savings number whose denominator moved is worse than no savings number.

Overlapping discount mechanisms. Commitment discounts are not the only thing reducing your bill. Hybrid licensing benefits, negotiated agreements, and credit programs all interact with commitment coverage, and attributing a dollar of savings to exactly one of them is a modeling choice rather than a lookup. Correlating license benefit application against FOCUS cost data is its own reconciliation exercise, and it is worth doing explicitly rather than letting the two savings stories double-count each other in separate reports.

Credit burndown is a different shape entirely. Subscription credit pools — the kind attached to developer licensing programs — do not behave like commitments. They are a depleting balance against variable draw, so the useful reporting is a burndown and a projected exhaustion date, not a coverage percentage. Trying to force them into the commitment framing produces a metric nobody can act on. Model them separately.

Scope boundaries. Coverage computed across the whole enterprise hides the fact that one business unit is at 95% and another at 40%. Commitments frequently apply across scopes that do not match the org chart, which means the entity that benefits from a commitment is often not the entity that bought it. Decide early whether your reporting follows the money or follows the org, because retrofitting the other view is expensive.

Making it operational

A monthly report of these metrics is table stakes and is not where the value is. The value is in two things the report cannot do.

Recommendations with a stated assumption set. A savings plan recommendation is a forecast. It should ship with the lookback window it used, the growth assumption baked in, and what happens to the number if that assumption is wrong by a reasonable margin. Recommendations that arrive as a single dollar figure get either accepted uncritically or ignored entirely; ones that arrive with their sensitivity get discussed, which is the point.

Anomaly detection that runs on a schedule, not on demand. Cost problems are cheapest to fix in the week they start. A dashboard someone opens monthly finds them in week four. Running the detection as a scheduled pipeline job — with the alert going to the team that owns the resource rather than to a central FinOps inbox — moves discovery forward by weeks and puts it in front of the only people who can act on it.

The short version

FOCUS is a schema, not a strategy. It removes the tedious, provider-specific part of commitment analysis and leaves you with the genuinely hard parts: choosing a defensible baseline, untangling overlapping discount mechanisms, deciding what scope you report at, and getting findings to the people who can act on them while acting is still cheap.

Those are the parts worth spending engineering time on. The schema just means you only have to solve them once.