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 guesswork1. 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 budgets2. 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 later3. 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 value4. 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:
- Spend. How much have we spent this period against the budget, and where will we land at the end of it?
- Reliability. Are requests succeeding, and is any provider failing?
- Governance. Is access controlled: who can sign in, which credentials are live and unused?
- 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.
What moved, what to decide
Weekly summary
- Last seven days of estimated provider spend, and the change on the week before
- Budget cycle so far and the projection to its end
- Status per area, each with the reason in one sentence
- Largest projects and models, and the biggest movers
- Open findings that need an owner
The record of a closed month
Monthly report
- Calendar month total and the change on the month before
- Spend by project, provider and model
- Reliability: success rate, failover, failing providers
- Governance: sign-in policy, unused credentials
- Unpriced share, and the provider-reported figure where you have one
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 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.
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.
| Which window answers which question | Answers | Compare it with | Watch out for |
|---|---|---|---|
| This month (to date) | Are we on pace for the month finance books? | The same number of days last month | Comparing ten days with a whole month reads as a drop |
| Last month | What did the closed month cost? | The whole month before | Late usage records still landing in the first days |
| This quarter (to date) | Will the quarter land on plan? | The same days of last quarter | One unusual month hiding inside the total |
| Last 7 or 30 days (rolling) | Did something change recently? | The previous 7 or 30 days | Never use it for a figure finance books |
| Budget cycle | How much room is left before the limit resets? | The budget itself | A cycle day that differs from the calendar month |
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 password5. 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 supported6.
- 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 one7.
| Route by who acts, not by who is interested | Who acts | Where | When |
|---|---|---|---|
| Forecast over budget | Budget owner, finance | Email or the team's chat channel | Days before the limit, once per period |
| Spend anomaly, critical | The team that owns the workload | Chat channel; paging only for blocking budgets | The same day |
| Provider connection failing | On-call engineer | PagerDuty or the incident channel | Immediately |
| Unpriced traffic | Whoever maintains rates | Email or the platform channel | Within days: every total is a lower bound until fixed |
| Estimate drifting from the provider's figure | Finance and the platform owner | Within the week | |
| Traffic change with no error | The workload owner | Chat channel | Within the week, with the cost impact |
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 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.
| INFRO Summary, docs 2026-10-13 | Green | Amber | Red |
|---|---|---|---|
| Spend | Projected below 90% of the budget | Projected at 90% of the budget or more | Projected above the budget, or the budget is reached |
| Reliability | At least 99% of requests succeeded, no provider key out of rotation | Below 99%, or some keys out of rotation while others serve | Below 95%, or every key of a provider is failing |
| Governance | Two-factor or SSO for every member, no key unused for 30 days | A member without two-factor, or an unused key still works | ○red state |
| Coverage | 80% of spend has a project and 99% of requests are priced | Less than either | ○red state |
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.
| INFRO roles, docs org/members 2026-10-13 | Reads | Can change | Cannot |
|---|---|---|---|
| Owner | Everything | Everything, including the organization-wide hard cap and the plan | — |
| Finance | Billing status and every cost figure | Budgets, project and member limits, end-customer caps, cost centers, statements | Set the organization hard cap, create keys, change providers, routes or policies, call the API |
| Analyst | Usage, request history, policies, audit log | Their own saved views and report emails | Create keys or call models |
| Developer or analyst limited to projects | Their projects' requests, analytics, jobs and findings | Gateway keys inside their projects (developer) | Anything organization-wide: Summary, reports, budgets, members, settings |
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, included on the Business plan. The details are in the Summary and reports and 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.