# The AI spend report leadership actually reads

URL: https://infro.io/blog/ai-spend-report-for-leadership
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-13
Last modified: 2026-10-13
Last reviewed: 2026-10-13 (next review due 2026-11-12)
Topic: Cost and FinOps
Format: Guide

> A leadership AI report answers four questions: how much are we spending against budget and where will it land, is it working, is it governed, and what needs a decision. Send a short weekly summary of what moved and a monthly report of the closed calendar month, state every figure as an estimate of provider cost with its unpriced share, route alerts to whoever acts on them, and give finance budget rights without engineering access.

Key takeaways:
- A leadership report answers four questions on one page: spend against budget and its forecast, reliability, governance, and what needs a decision.
- Weekly is for what moved; monthly is the record of a closed calendar month. Rolling windows are for engineers, calendar periods for anything finance books.
- Every figure is an estimate of what the providers will bill, with the unpriced share beside it and the provider's own figure where one is available.
- Route each alert to the person who acts on it, in the place they already watch; page only for what cannot wait until morning.
- Finance can own budgets without keys, providers or routing, and project leads can see their projects without the organization's totals.

The AI cost tooling most companies have was built for the engineer who configured it: request logs, token counts, a chart per model. A CFO, a CTO or a project manager opens the same screens with different questions. How much are we spending on AI, and where will it land? Is it under control? Is it working? What do I need to decide? This guide covers what a weekly summary and a monthly report should contain to answer those four, which period each figure should use, who should receive which alert and where, and how to give finance control of budgets without handing them engineering access.

## Why the engineering dashboard is not the report

The gap is well documented in 2026 surveys, with the usual caveat that they are self-reported. Harness's survey of 700 engineering leaders and practitioners, run by Sapio Research in May and June 2026, found that 72% had an unexpected AI cost spike or bill in the past year, that only 20% could identify the cause within hours if spend doubled overnight, that 52% have no single accountable owner for AI cost, and that 56% say their AI spend forecasts rely on guesswork[1]. Harness sells cost management software, so read that as a vendor survey.

KPMG's Q2 2026 pulse of 204 U.S. leaders at companies with at least $1 billion in revenue found that only 26% say the operating costs of their AI systems are fully visible today; 66% have cost-monitoring dashboards and 36% use usage or token budgets[2]. Dashboards exist, in other words, and still do not produce visibility. Futurum's survey of 1,636 technology decision makers, published in September 2026, puts 46.9% of organizations over their AI spending plan, and among those, 43.3% absorb the overrun and reconcile it later[3]. Futurum's Mitch Ashley summarized it as the budget having "stopped being a control"[3].

The FinOps Foundation's State of FinOps 2026 reports that 98% of respondents now manage AI spend, up from 63% a year earlier, and lists the main AI challenges as seeing costs clearly when every provider prices differently, allocating them to business units, and proving value[4]. None of those is solved by another chart. They are solved by a report someone reads on Monday and a clear owner for every number in it.

## The four questions a report must answer

A leadership report is short because it is organized around decisions, not around the data model. Four questions cover it:

1. **Spend.** How much have we spent this period against the budget, and where will we land at the end of it?
2. **Reliability.** Are requests succeeding, and is any provider failing?
3. **Governance.** Is access controlled: who can sign in, which credentials are live and unused?
4. **Coverage.** How much of the spend can we attribute and price at all?

The fourth is the one most reports leave out, and it decides whether the first can be trusted. If a third of spend has no project, the per-project figures describe two thirds of the business. If 5% of requests have no known rate, every total is a lower bound.

Give each question a status and a sentence. A traffic light with no reason invites a meeting to find the reason; a sentence with the arithmetic in it ends that meeting before it is booked. Resist a single composite health score: it averages away the one area that needs attention.

> **Example: A status with its reason**
> Spend, amber: "$31,800 so far, projected $41,200 of the $45,000 monthly budget by 31 October. Largest increase: the support project, up $6,100 on the same days last month." The reader knows the state, the margin, the date and where to look, without opening anything.

[Diagram: What each report carries. Weekly is for movement and decisions; monthly is the record of a closed month.]

## What belongs in the weekly summary

The weekly summary exists so nobody has to open a console to know whether to worry. Keep it to what fits on a phone screen:

- **The last seven days and the change on the week before**, as estimated provider spend.
- **The period so far and the projection to its end**, against the budget, with the method stated once. A projection that adds the recent daily average for each remaining day catches a busy last week better than a straight-line extrapolation from the first of the month.
- **Status per area with its reason**, as above.
- **The largest projects and models, and the biggest movers.** A leader needs to know that one workload doubled, not every row.
- **What needs a decision**: budgets close to their limit, failing provider connections, open findings without an owner.

Every line should link to the screen where it is acted on. A weekly email that cannot be acted on becomes a weekly email that is filtered.

## What belongs in the monthly report

The monthly report is a record. It is filed, forwarded and compared with an invoice, so it must use a calendar month and must not change after it is sent. Include:

- **Total estimated provider spend for the calendar month**, and the change on the month before.
- **Spend by project, by provider and by model.** Project is the dimension finance allocates; provider is the dimension the invoices arrive in; model is the dimension engineering can change.
- **Forecast against the next month's budget**, if one is set.
- **Reliability**: success rate, how many requests were recovered by failover, which providers failed.
- **Governance**: sign-in policy, credentials unused for 30 days, membership changes.
- **The unpriced share**, stated beside the total rather than in a footnote.
- **Estimate against provider-reported cost.** A gateway estimates cost from rates; the provider's own cost API or invoice is authoritative. Where you can read both, print both and the variance. The [reconciliation guide](https://infro.io/blog/reconcile-llm-spend-provider-invoices) covers why they differ.

Two rules keep the report honest. First, provider spend and the subscriptions you pay for tooling are different money and never one total. Second, unpriced is not zero: a request with no known rate is counted and labelled, never added as $0. For booking these amounts to teams, see [showback and chargeback](https://infro.io/blog/ai-spend-showback-chargeback).

## Calendar periods for finance, rolling windows for engineers

Most engineering dashboards default to "last 7 days" or "last 30 days". Those are good for spotting change and wrong for anything finance books, because a rolling 30 days never lines up with an invoice or a budget. Use calendar periods (this month, last month, this quarter) for spend against budget and for the monthly report, and keep rolling windows for diagnosis.

The comparison matters as much as the window. "This month" on the 10th compared with all of last month shows a drop that is not there. Compare month-to-date with the same number of days last month, and a closed month with the whole month before.

[Diagram: Pick the window for the question. Calendar periods for anything booked; rolling windows for change.]

If your budgets reset on a day other than the 1st, say so on every figure. A "budget cycle" running from the 15th and a calendar month are two different clocks, and a report that mixes them without labels will be argued about.

## Who gets which alert, and where

Reports are pulled once a week; alerts are pushed when something cannot wait. The rule that keeps them useful is to route each alert to the person who acts on it, in the place they already watch.

- **Email** suits finance and anything that can wait for the working day: a forecast that will exceed a budget, an estimate drifting from what the provider reports.
- **A chat channel** suits the team that owns a workload: spend anomalies, traffic changes, a project close to its limit. Slack incoming webhooks post to one channel through a unique URL that contains a secret, so treat the URL like a password[5]. Microsoft Teams now builds the same thing with Workflows: a webhook template posts to a chosen channel, and both Adaptive Card and Message card formats are supported[6].
- **Paging** suits only what needs a person now: every provider connection failing, or a blocking budget about to refuse production traffic. PagerDuty's Events API v2 ties repeated events to one alert through a `dedup_key`, so an alert that is sent again updates the open incident rather than opening a second one[7].

[Diagram: A starting routing table. Adjust the owners to your organization; keep paging for what cannot wait.]

Two practical details. Send an alert once per period for a forecast, and once more only if it worsens, or people learn to ignore it. And remember that an end-customer id in a chat message may be personal data; channel messages are read by more people than the console is.

## Budget rights without engineering access

Finance usually owns the budget in the plan and has no rights to the budget in the system. The fix is a role that can set and change spend limits and read every cost figure, and cannot create credentials, change providers, edit routing or call the API. That separation lets finance act on a forecast the same day instead of filing a ticket with the platform team, and it keeps the blast radius of a finance account small.

Keep one control above it. The organization-wide hard cap is the last line against a runaway workload or a leaked key, and it should stay with the account owner. The [spend controls guide](https://infro.io/blog/llm-spend-controls-budgets) covers how to layer budgets and ceilings.

## Shared views instead of screenshots

A board pack built from screenshots is stale when it is sent and cannot be checked. A saved view (a named screen with its period, project, environment and grouping) does the same job and stays current. Two properties make it safe to share: it stores the filters, never the figures, and opening it re-reads the data under the reader's own permissions. A link to "Board: this quarter" then shows each reader exactly what they are allowed to see.

## Project leads see their projects, not the company

The reverse problem is the project lead who needs their own numbers and should not see the organization's total spend, other teams' workloads or the budget table. Scope their access to projects: their requests, analytics and findings, and the credentials inside their projects, with everything organization-wide closed. Then keep them off the organization-wide report, because it describes spend they are not meant to see.

## The leader console in INFRO: Summary, reports, alerts and access

INFRO's console has a **Summary** page built for these four questions. It shows the current budget cycle's estimated provider spend against the budget and its projection, four status lights (Spend, Reliability, Governance, Coverage) each with the sentence that explains it, what needs a decision, where the spend went by project and model against the same days of the last cycle, reliability and governance. Every amount is an estimate of what your own providers will bill you, from list or negotiated rates; INFRO's subscription is never part of it, and a request with no known rate is counted as unpriced, never as $0. Finance and analyst members open the console on the Summary by default.

[Diagram: The thresholds behind INFRO's four status lights, as documented. There is no combined score.]

The budget behind the Spend light is the organization's hard cap when one is set, otherwise its monthly target. The projection is spend so far plus the average of the last seven days for each day left in the budget cycle.

The **weekly summary** is emailed on Mondays from 08:00 UTC: the last seven days and their change, the cycle so far and its projection, the four lights with their reasons, and the largest projects and models. The **monthly report** is emailed on the 2nd of each month from 08:00 UTC for the calendar month before, and is also a page in the console for any past month, ready to print or save as a PDF. Reports go to members of the organization only. Each member chooses for themselves under Settings, Account, Email reports; owners and finance members start with both on, everyone else with both off, and every email has a link that turns it off without signing in.

Periods in the console include calendar ranges (This month, Last month, This quarter) beside the rolling ones. This month is compared with the same days last month, and Last month with the whole month before.

**Alerts** cover spend anomalies, budget forecasts, budget thresholds, cost drift against the provider's own cost API, unpriced traffic, failing connections and traffic changes. Findings appear in the console on every plan. A notification rule sends an event, at or above a severity and optionally for one scope, to a channel: an email list, a Slack incoming webhook, a Microsoft Teams workflow, a PagerDuty Events API v2 integration, or a signed webhook. Email channels are on every plan; Slack, Teams, PagerDuty and webhook channels from the Startup plan. PagerDuty events use the finding's id as the `dedup_key`, and Slack, Teams and PagerDuty messages leave out end-customer ids unless the rule allows them.

The **Finance** role reads billing status and every cost figure and sets budgets (the monthly target, the budget cycle day, project and member limits, end-customer caps), maintains cost centers, and closes and corrects monthly statements. It cannot set the organization-wide hard cap, which stays with the owner, create keys, change providers, routes or other policies, or call the API.

[Diagram: What each role can read and change, from INFRO's members documentation.]

**Saved views** keep any console screen with its period, project, environment and grouping under a name, for yourself or shared with the organization, and **Copy link to this view** copies its address. A view holds filters, never a figure, and is read again through the reader's own role and project access. **Project access** lets an owner or admin limit a developer or analyst to some projects: they read those projects' requests, analytics, jobs and findings and manage the gateway keys in them, and everything organization-wide, including the Summary and the reports, is closed to them. They never receive the weekly summary or the monthly report.

None of these is tied to a plan tier, but a finance or project-limited member is a seat: Developer has one, Startup three, Team ten and Business unlimited. Comparing estimates with OpenAI's and Anthropic's own cost APIs is [cost reconciliation](https://infro.io/docs/cost/reconciliation), included on the Business plan. The details are in the [Summary and reports](https://infro.io/docs/observability/summary) and [Alerts](https://infro.io/docs/observability/alerts) docs.

## A checklist for the first report

- [ ] One owner named for AI spend, and one for each project.
- [ ] A budget per period, and the period's reset day written on every figure.
- [ ] Calendar periods for the report; rolling windows only for diagnosis.
- [ ] Every request attributed to a project, and the unattributed share printed.
- [ ] A rate for every model in use, and the unpriced share printed beside the total.
- [ ] The provider's own figure beside the estimate, where you can read it.
- [ ] A routing table: each alert, who acts, which channel, how fast.
- [ ] Finance able to change budgets without engineering access; the hard cap with the owner.

## Sources

1. New Harness Report Reveals Enterprise AI Spend Has Outgrown the Systems Built to Track It — Harness. https://www.harness.io/press-and-news/new-harness-report-reveals-enterprise-ai-spend-has-outgrown-the-systems-built-to-track-it (accessed 2026-10-13)
2. AI Quarterly Pulse Survey, Q2 2026 — KPMG LLP. https://kpmg.com/kpmg-us/content/dam/kpmg/pdf/2026/aipulsesurvey-q2.pdf (accessed 2026-10-13)
3. 46.9% of Enterprises Report AI Spend Over Budget in 2H 2026 — Futurum Group. https://futurumgroup.com/press-release/46-9-of-enterprises-report-ai-spend-over-budget-in-2h-2026/ (accessed 2026-10-13)
4. State of FinOps 2026 — FinOps Foundation. https://data.finops.org/ (accessed 2026-10-13)
5. Sending messages using incoming webhooks — Slack. https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/ (accessed 2026-10-13)
6. Create incoming webhooks with Workflows for Microsoft Teams — Microsoft. https://support.microsoft.com/en-us/office/create-incoming-webhooks-with-workflows-for-microsoft-teams-8ae491c7-0394-4861-ba59-055e33f75498 (accessed 2026-10-13)
7. Send an Alert Event (Events API v2) — PagerDuty. https://docs.pagerduty.com/developer/send-alert-event (accessed 2026-10-13)