A finance-ready report answers four questions without a meeting: how much did we spend, who spent it, how does it compare to plan, and why did it move? Getting there is mostly plumbing — but the plumbing differs by platform, and the allocation structure has to be built before the month you want to report on.
Structure allocation first: workspaces and their equivalents
On the Claude API, the allocation unit is the workspace: workspaces separate projects, environments, or teams while keeping billing and administration centralized, and an organization can have up to 100 of them. If teams share the Default Workspace, their usage is one undifferentiated blob (it appears with workspace_id: null) — so create a workspace per team or product line before you need the report, and map each workspace to a GL code or cost center in a small lookup table you own. Workspaces also support spend limits below the organization cap, which turns each row of your report into an enforceable budget.
On the cloud platforms the equivalent is your cloud's own allocation machinery: separate accounts/projects/resources per team, plus the provider's cost-management tooling. On Microsoft Foundry, note the shape of the data: Azure Cost Management shows a single Claude Consumption Unit (CCU) line, while per-model token and request detail lives in the Foundry portal's Monitoring tab — your report will need both. Claude Platform on AWS similarly bills CCUs through AWS Marketplace, metered hourly and invoiced monthly in arrears, and does not offer Anthropic spend limits — AWS billing controls play that role.
Pull actuals programmatically where you can
On the first-party Claude API, the Admin Cost API (GET /v1/organizations/cost_report) returns costs in USD at daily granularity, groupable by workspace_id and description — values arrive as decimal strings in cents, so convert deliberately. The companion usage endpoint breaks token consumption down by model, workspace, and service tier. Two documented caveats belong in your report's footnotes: Priority Tier costs use a different billing model and are not included in the cost endpoint (track them via the usage endpoint's service_tier field), and data typically appears within about 5 minutes, so a month-end pull on the 1st is safe. These Admin endpoints require an Admin API key and are not available on Bedrock, Vertex AI, or Claude Platform on AWS — there, the cloud invoice plus your own request-level logs are the actuals.
The report itself
| Section | Contents |
|---|---|
| Summary | Total spend, month-over-month change, variance to forecast, one-line cause |
| By team / GL code | Workspace (or account/project) totals mapped through your lookup table; unallocated remainder shown explicitly |
| By model and mechanism | Spend split by model and by standard / batch / cache-read buckets — this is where optimizations become visible |
| Actuals vs. forecast | Plan number, actual, variance %, and updated run-rate forecast |
| Commentary | Three to five sentences: volume changes, price changes, optimizations shipped, known one-offs |
Write the commentary like an accountant, not a marketer. Useful trend explanations are concrete and checkable: "support-bot volume up 22%," "moved nightly enrichment to batch at 50% pricing," "Sonnet 5 intro pricing ($2/$10 per MTok) ends August 31, 2026 — September forecast uses standard $3/$15 rates." That last class — scheduled price changes — is exactly what CFOs expect you to have foreseen, so date-stamp them in the forecast the month you learn of them.
Reconcile before you publish
The report's credibility rests on the actuals matching the bill. Run the invoice reconciliation pass first, then publish; a report that finance later catches disagreeing with the marketplace invoice loses trust for quarters. Where numbers legitimately differ — metering lag, timezone boundaries, marketplace private-offer discounts applied at conversion — say so in the footnotes rather than letting readers discover it.
Where to go next
See chargeback models, showback, growth forecasting, and FinOps for LLMs for the wider practice.