Monthly AI Cost Report for the CFO: Contents, Data Sources and Audit Evidence
A monthly AI cost report for the CFO should keep spend, usage and exposure in separate sections, add attribution to business units and applications, and show variance against forecast. Each figure needs a named data source and a stated attribution rule. Spend comes from provider invoices and internal cost records. Usage and attribution fields come from technical systems. Policy outcomes such as blocked, redacted, rate-limited or escalated interactions come from runtime enforcement evidence, which gives finance a record to reconcile against.
Questions to answer before the report is signed off
- Can every cost line be traced to a provider, model, application, business unit and session or user identifier?
- Is there a written rule for direct versus shared AI costs, applied consistently from month to month?
- Which system produces the record of policy outcomes, and how is it reconciled to billing and usage data?
- Are baselines and thresholds for variance and abnormal-spend alerts documented, with a named owner?
- What documentation supports each figure, how long is it retained, and who can access it for audit?
Why AI spend needs its own reporting structure
AI spend rarely arrives in one place. It is spread across model providers, internal applications, agents, tools and coding assistants, and the usage data finance receives from each is often in a different shape. The result is a report that totals correctly but cannot be traced to a business unit, a model or a use case.
The remedy is not a larger report. It is a defined structure in which spend, usage and exposure are reported separately, because they answer different questions. Spend is what the organization paid. Usage is what the AI systems did. Exposure is what those systems were permitted to do, what was stopped, and what required review. Mixing them hides the gaps between them.
Treat this as a finance and evidence-quality problem. A figure that cannot be tied to a source record is hard to defend to an auditor, regardless of how carefully it was calculated.
Report sections, data sources and the control behind each
Each section below names the system that should supply the data and the control that makes the figure trustworthy. Finance owns the rules and the reconciliation. Technical systems own the underlying records.
- 1. Spend by provider and model: Source: provider invoices and internal cost records. Control: reconciliation of reported totals to invoiced amounts each month.
- 2. Usage volumes: Source: token counts, request counts and tool-call records captured at the point of execution. Control: consistent model and provider identifiers on every record.
- 3. Attribution: Source: application, team and user or session identifiers on usage records. Control: a written allocation rule for direct and shared costs, applied the same way each month.
- 4. Variance against forecast: Source: finance forecast and actuals. Control: a stated baseline, method and threshold, with a named owner.
- 5. Policy events: Source: records of policy outcomes (allowed, redacted, blocked, rate-limited, escalated). Control: a defined event taxonomy and a reconciliation to usage data.
- 6. Supporting documentation: Source: retained records behind each figure. Control: defined retention and access for audit.
Attribution: rules finance sets, fields engineering supplies
Accurate attribution depends on identifiers recorded when the interaction happens. OWASP guidance for AI agents lists tracking token usage and cost per session and user under monitoring and observability. Reconstructing that detail from monthly invoices is rarely possible, so the fields need to be captured at the point of execution: provider, model, application, team, user or session, and tool calls.
The allocation rule is a finance decision. A useful reference is the cost principle in 2 CFR Part 200, which governs costs charged to federal awards. It is not an AI reporting rule and does not apply to general enterprise AI spend, but its logic transfers well. Direct costs are those identifiable with a particular cost objective, or assignable to it relatively easily with a high degree of accuracy. Costs incurred for the same purpose in like circumstances are treated consistently as direct or indirect.
Applied here, decide in writing which AI costs are direct to an application and which are shared, such as a coding assistant licence used across teams. Then apply the rule identically every month. Inconsistent treatment is the usual cause of double-counted or orphaned costs, and a documented rule is what lets an auditor follow the allocation.
The same reference suggests a unit-cost view, comparing cost to a unit of output or usage. Include one only where the unit is defined and measurable, and state the definition in the report.
Variance and exposure: state the baseline, define the events
Variance against forecast is only as credible as its baseline. NIST AI 800-4 describes post-deployment monitoring as difficult, citing the overhead of longitudinal tracking and the challenge of establishing baselines and thresholds. For the CFO report, that means each variance line should state its forecast basis, its method and the threshold that triggers explanation. Abnormal spend alerts need the same treatment and a named owner. OWASP recommends circuit breakers or kill switches for abnormal cost, latency or tool-call spikes, and any resulting events belong in the exposure section, not blended into spend.
The exposure section should be short. NIST AI RMF Map 3.2 calls for potential costs from AI errors and trustworthiness issues, including non-monetary costs, to be examined and documented in relation to organizational risk tolerance. NIST AI 600-1 includes an action to compile statistics on actual policy violations for generative AI systems. Together these support a compact table of policy event counts by application and by outcome: blocked, redacted, rate-limited and escalated.
These counts are only reliable if the organization has defined its policies and its event categories first. Without a taxonomy, two teams will count the same event differently, and the trend line will mean nothing.
What runtime policy enforcement evidence adds to the report
Billing data shows what was charged. It does not show what an AI system was allowed to do or what it did. That gap is where reconciliation breaks down: finance sees a cost spike, and no shared record explains which interactions caused it or which were stopped.
Policy enforcement in the execution path closes part of that gap. Trussed enforces policy across models, agents, tools, MCP servers and coding assistants, applying allow, redact, block, rate limit or escalate decisions to individual interactions and tool calls. Because enforcement happens at runtime, not in review after the fact, each decision produces an audit-ready evidence record. Finance can use those records as the source for the policy event section and as a cross-reference when a usage figure is questioned.
The scope matters. Enforcement evidence covers interactions and policy outcomes. It does not replace provider invoices, and it does not set the allocation rule. The CFO report still reconciles spend to billing and attributes cost by finance-defined rules. The evidence supplies a durable record of permitted and actual behavior that those figures can be checked against.
Self-managed deployment in the customer cloud, with configurable retention and data residency, lets the organization set how long evidence is kept and where it is stored. Retention periods should be set with audit and legal teams.
Sections of the monthly AI cost report
Spend
Cost by provider, model and cost type, reconciled to invoices.
Usage
Token and request volumes, and tool-call counts.
Attribution
Cost assigned to business units, applications and use cases by a stated rule.
Variance
Actuals against forecast, with the baseline and method stated.
Exposure
Policy events, kept separate from spend.
Evidence
Supporting records behind each reported figure.
Make AI spend traceable to what the systems did
Talk with Trussed about how policy enforcement in the execution path produces audit-ready evidence that finance and audit teams can reference.
Talk to an Expert