State of FinOps 2026: What 98% Managing AI Spend Means

The number I keep returning to in the State of FinOps 2026 report is not the 98%. It is 53.4%, the share of respondents who name understanding the full scope of AI spending as a challenge, sitting at the top of a chart that is otherwise about value and allocation. Almost every FinOps team now has AI in scope, and more than half are still working out how much AI there is.

This post reads the report's data site directly, including the figures embedded in its charts, then the FinOps Foundation's own pages on FinOps for AI and GenAI token pricing, and the FOCUS specification pages that define the billing columns you would actually query. It is a different angle from my earlier posts on per-task agent budgets and LLM token budgets: this one asks what a 1,192-respondent survey can and cannot tell a platform team about AI spend, and what to change on Monday. I read nothing behind a login, and where the site gives a headline without a figure I say so.

What the survey measured, and who answered

The report is the FinOps Foundation's State of FinOps survey, 2026 edition: 1,192 respondents representing more than $83bn in annual cloud spend. By organisation size, 47% are large enterprises (10,000 or more employees), 33% enterprises (1,000 to 9,999) and 20% SMBs (fewer than 1,000). By region, 35% are in Europe, the Middle East and Africa, 34% in North America, 16% in Asia Pacific and 15% in South and Central America.

The sample size is not constant. Every chart carries its own N: 693 for the AI spend question, 649 for AI challenges, 658 for planned AI investment, 685 for priorities and 622 for FOCUS. So the figure to quote for AI is 98% of 693 answering, not 98% of 1,192. I could not confirm from the pages I read how respondents were recruited, so I treat every number as practitioner-reported rather than a census of companies using AI.

Asia Pacific supplies 16% of respondents. For an Indonesian team that makes the global percentages a reference point rather than a local benchmark, and it is why I attribute each figure to the report instead of restating it as a fact about the market.

98% is a scope statement, not a maturity score

The headline is that 98% of respondents now manage AI spend, up from 63% in 2025 and 31% in 2024; the site words the earlier figure as up from 31% two years ago. In the technology-categories data it sits above every other category the survey asked about.

Read the verb carefully. For SaaS the site says respondents now manage it or plan to in the coming year, while for AI it says 98% now manage AI spend. The page does not say how many of those 98% are already doing it versus planning to, and a team that has put AI on a roadmap plausibly counts. So 98% tells you AI is in scope almost everywhere. It says nothing about whether anyone's visibility is good, and the next section shows it is not.

One respondent quote on the site, from a financial-services company, is more useful than the percentage. The practice you already have for governing public cloud spend should naturally include AI, because AI is simply another bucket of spend that needs the same discipline and governance. That is the report's own framing: AI is not rewriting FinOps, but it is testing how flexible the operating framework is.

The three problems: scope, value and allocation

The prose names three top challenges: visibility into AI costs, allocating AI costs to business units, and determining AI value or ROI. The chart behind it is multi-select with N=649, and its numbers are sharper than the prose.

Two readings. First, the leading problem is not optimisation but not knowing the total: scope at 53.4% beats value at 40.1% and allocation at 39.0%. Second, the problems an engineer would reach for first sit lower down, with forecasting at 20.9%, the move from proof of concept to production at 17.2% and data, ethical or governance risk at 12.2%. One practitioner is quoted on the site: is your AI providing value? No one can answer that question yet. Spend visibility is a data-plumbing problem you can fix this quarter. Value is a different data source entirely, which the Foundation's FinOps for AI page puts plainly: cloud billing holds the cost data, while product analytics or a CRM holds the value data.

AI spend is leaving the cloud bill

The investment chart asks where organisations plan to place future AI investment (multi-select, N=658). Public cloud is still near-universal, but the growth is everywhere else. The site's own reading is that AI is becoming a cross-cutting investment theme rather than a siloed initiative.

That is why a billing standard turns up in an AI report. Respondents who have obtained billing data in FOCUS format or plan to rose from 49.6% to 85.3% in organisations spending $100M or more, from 58.5% to 84.5% in the $15M to $100M band, and from 57.6% to 91.3% below $15M (N=622). Asked which area FOCUS should expand into next, 16.5% chose AI workloads, ahead of data center at 13.9% and PaaS and SaaS at 13.6%. The FOCUS site describes the specification as normalising billing datasets across AI, cloud, SaaS and data center vendors, and lists data generators for AWS, Google Cloud and Microsoft at v1.2 and for Databricks, Snowflake, Vercel and MongoDB at v1.3. It does not mention tokens or token-based billing, so check what your LLM vendor actually exports before you build on it.

What teams ask tools for: tokens, requests and GPUs

Asked what tool capability they would like that does not exist today, respondents put granular monitoring of AI spend, meaning tokens, LLM requests and GPU utilisation, first. Pre-deployment architecture costing was second and a single pane of glass across technology spend third. These are open-ended requests, not shipped features, and the report gives no percentages for them. Read them as a gap in tooling, not a measurement of how many teams have solved it.

The Foundation's token pricing paper explains why raw token counts mislead. Output tokens often cost three to five times as much as input tokens. Most LLM APIs are stateless, so the whole history is resent on every turn: its worked example is a third turn with 6 new tokens after 5 user and 50 bot tokens, billed as 61 input tokens. System prompts are resent too, and an image's cost repeats on every later turn while it stays in history. Its advice is to measure cost per use case, because the cost per unit is not a fixed price but a distribution. The query below gets you the part you can already get from a FOCUS export.

-- DuckDB. focus-export.parquet is a FOCUS Cost and Usage export from your
-- provider. Column names are the FOCUS ones: ChargePeriodStart, ServiceName,
-- ChargeCategory, BilledCost, ConsumedQuantity, ConsumedUnit, Tags.
SELECT
  date_trunc('month', ChargePeriodStart)            AS month,
  ServiceName,
  -- Tags is a JSON column and is nullable by spec. Null means "unallocated".
  coalesce(json_extract_string(Tags, '$.team'), '(untagged)') AS team,
  -- ConsumedQuantity is only populated for Usage charges, and its meaning
  -- depends on ConsumedUnit. Group by the unit; never sum across units.
  ConsumedUnit,
  sum(BilledCost)       AS billed_cost,
  sum(ConsumedQuantity) AS consumed_quantity
FROM read_parquet('focus-export.parquet')
WHERE ChargeCategory = 'Usage'
  -- ServiceName strings are provider-specific. Run SELECT DISTINCT ServiceName
  -- first and edit this pattern to match what your own export contains.
  AND regexp_matches(ServiceName, '(?i)bedrock|vertex|openai|foundry|inference')
GROUP BY ALL
ORDER BY billed_cost DESC;

-- How much AI spend has no team at all? Start here before arguing about ROI.
SELECT
  round(100.0 * sum(BilledCost) FILTER (WHERE Tags IS NULL
        OR json_extract_string(Tags, '$.team') IS NULL) / sum(BilledCost), 1)
    AS pct_unallocated
FROM read_parquet('focus-export.parquet')
WHERE ChargeCategory = 'Usage'
  AND regexp_matches(ServiceName, '(?i)bedrock|vertex|openai|foundry|inference');

That query yields spend by team and service. It cannot give you tokens per request or GPU utilisation unless your provider reports them as ConsumedQuantity and ConsumedUnit, and the spec only requires ConsumedQuantity for Usage charges when the provider measures usage. That gap is exactly what the top tool request describes, and until a tool closes it you log tokens yourself at the call site, as the last section shows.

Priorities are moving from waste to value

The priorities question is multi-select with N=685 and asks about now and the next 12 months. Workload optimisation and waste reduction remain the single top current priority at 42.5%, but FinOps for AI is the top forward-looking one. The combined figures for the rows that matter here:

Large enterprises lean hardest: FinOps for AI goes from 21.8% now to 37.1% next year for them, against 20.7% to 34.2% for SMBs and 19.3% to 26.1% for mid-size enterprises. Unit economics climbing from 12.7% to 20.4% fits the token paper's argument that the unit to track is the outcome, not the call. The report also notes that many organisations are being asked to self-fund AI through optimisation savings, without giving a percentage, which ties the falling optimisation priority to a budget fact rather than a fashion.

What the report cannot tell you, and where it misleads

A survey of practitioners is good evidence of where attention is going and weak evidence of where money is going. Four limits matter before you quote it in a planning document.

• It reports shares of respondents, not dollars. The 98% says nothing about how large AI spend is relative to the rest of the bill.
• Multi-select shares do not sum to 100% and are not comparable across charts with different N. The fall of waste reduction from 42.5% to 25.0% is not abandonment of optimisation; the report states it remains the top current priority and that the other priorities combined outweigh it.
• Several headline claims have no figure on the page: many organisations self-fund AI from savings, and the ranking of requested tool features. Treat those as directional.
• It offers no benchmark for cost per outcome. The Foundation's token paper defers its definition of a successful outcome to a future paper, so there is no external number to compare your own against.

None of this makes the survey less useful. It makes it a map of the problems your finance and platform teams are about to ask you about, which is a different job from a benchmark of what good looks like.

What to do on Monday

These five steps follow the report's own maturity path, visibility first, then planning discipline, then value, and need no new tool.

1. Export a month of billing data in FOCUS format if your provider offers it, and run the allocation query above. The share of AI spend with no team tag is your first real number.
2. Require team, feature and environment tags or labels on every AI project and API key. Make untagged spend somebody's problem by name.
3. Log every LLM call with input, output and cached token counts, the feature, the team and an outcome id shared by its retries, then compute cost per accepted outcome as in the code below.
4. Ask your inference or GPU platform for utilisation as a metric next to cost. Cost without utilisation cannot separate an idle reservation from a busy one.
5. For each AI feature, write one sentence naming where its value data lives, such as product analytics or a CRM. If the sentence cannot be written, the ROI question has no answer yet, and that is worth knowing before the budget review.

// ai-cost-record.ts: one record per LLM call, written next to your app logs.

type Usage = {
  inputTokens: number; // uncached input. Some providers report the total
  outputTokens: number; // instead, so check how yours splits cached reads out.
  cachedInputTokens: number;
};

// Per-million-token rates come from YOUR provider's price page and change.
// Pass them in; never hard-code a number copied from a blog post.
type Rates = { inputPerM: number; outputPerM: number; cachedInputPerM: number };

export function callCost(u: Usage, r: Rates): number {
  return (
    (u.inputTokens * r.inputPerM +
      u.cachedInputTokens * r.cachedInputPerM +
      u.outputTokens * r.outputPerM) /
    1_000_000
  );
}

// A stateless chat API resends the history every turn. The FinOps Foundation's
// worked example: turn 3 adds 6 new tokens after 5 user + 50 bot tokens,
// and is billed as 5 + 50 + 6 = 61 input tokens.
export function turnInputTokens(history: number[], newTokens: number): number {
  return history.reduce((sum, n) => sum + n, 0) + newTokens;
}

type Outcome = "accepted" | "retried" | "abandoned";
export type CostRecord = {
  feature: string;
  team: string; // the same key you put in the FOCUS Tags column
  outcomeId: string; // one id per user-visible result, shared by its retries
  costUsd: number;
  outcome: Outcome;
};

// Cost per SUCCESSFUL outcome, as a distribution, plus what failures burned.
export function costPerOutcome(records: CostRecord[]) {
  const byId = new Map<string, { cost: number; ok: boolean }>();
  for (const r of records) {
    const e = byId.get(r.outcomeId) ?? { cost: 0, ok: false };
    e.cost += r.costUsd;
    e.ok = e.ok || r.outcome === "accepted";
    byId.set(r.outcomeId, e);
  }
  const all = [...byId.values()];
  const costs = all.filter((e) => e.ok).map((e) => e.cost).sort((a, b) => a - b);
  if (costs.length === 0) return { n: 0, p50: 0, p90: 0, failedSpend: 0 };
  const q = (p: number) => costs[Math.min(costs.length - 1, Math.floor(p * costs.length))];
  const failedSpend = all.filter((e) => !e.ok).reduce((s, e) => s + e.cost, 0);
  // p90 and failedSpend are the numbers a per-token dashboard cannot show.
  return { n: costs.length, p50: q(0.5), p90: q(0.9), failedSpend };
}

Run the p90 and failed spend numbers for one feature before you roll this out wider. If p90 is far above p50, a prompt, retry or context change will move your bill more than a price cut will, which is the argument the token paper makes in words.

The rule I take from the report is that AI spend is a scope-and-value problem before it is an optimisation problem. Get every AI charge allocated to a team, measure cost per accepted outcome instead of per token, and keep the survey's percentages for what they are: a record of what 1,192 practitioners say they are working on.