Cost accounting
Your AI Usage Receipt Is Not Your Invoice
A usage receipt multiplies recorded token counts by an explicit rate card. It estimates what those counts cost under that card, not what a customer actually paid. The illustrative default receipt below totals $0.0166 from four disjoint token categories. Subscription allowances, negotiated prices, different billing dates, tools, media, taxes, and credits can all require separate treatment when reconciling that estimate to an invoice. Do not present a repriced total as proof of subscription savings.
A receipt is valuable when another person can reconstruct it. A large dollar number without its token categories, rates, and exclusions is difficult to audit, even when the arithmetic is correct.
Build the example usage receipt. Its default values match this article. The values are synthetic, and the rate card does not represent a named provider or an actual billed session.
Four categories, one explicit rate card
The example represents two calls. Their combined usage consists of 1,000 uncached input tokens, 8,000 cache-read tokens, 2,000 cache-write tokens, and 1,000 billed output tokens. The input categories are disjoint: a token is not charged as both uncached input and a cache read in this receipt.
| Category | Tokens | Assumed USD per million | Calculated cost |
|---|---|---|---|
| Uncached input | 1,000 | $2.00 | $0.0020 |
| Cache-read input | 8,000 | $0.20 | $0.0016 |
| Cache-write input | 2,000 | $2.50 | $0.0050 |
| Billed output | 1,000 | $8.00 | $0.0080 |
| Total | 12,000 | Not a single rate | $0.0166 |
Each row is tokens multiplied by its rate, divided by one million. The call count is descriptive; it is not another multiplier because the tokens already cover both calls.
const rows = [[1000, 2], [8000, 0.2], [2000, 2.5], [1000, 8]];
const total = rows.reduce((sum, [tokens, rate]) => sum + tokens * rate / 1e6, 0);
console.log(total.toFixed(4)); // 0.0166Rounding every row to whole cents before adding would distort such a small receipt. Keep sufficient precision internally and round the final display for the purpose at hand.
Separate observed usage from assumed prices
Counts imported from a log are observations only to the extent that the log is complete and correctly interpreted. The editable rate card is an assumption. Changing it does not change the workload that generated the counts.
For example, applying a different model’s rates to the same counts is a price-only counterfactual. It does not prove that model would use the same number of tokens, follow the same tool path, or produce an equally useful answer. Those questions require separate workload evaluation.
Use separate receipts when model versions, pricing tiers, cache-write terms, or billing periods differ. A single flat rate card cannot faithfully reconstruct a history with multiple rates unless you first calculate a properly weighted price for each category and explain that transformation.
Check the shape of the usage record
A per-call usage object and a running cumulative counter are different inputs. Adding consecutive cumulative totals counts earlier work repeatedly. Likewise, duplicated message records must not create duplicated charges.
The receipt importer accepts supported per-call usage shapes and checks for recognized ambiguities. An unsupported or incomplete record should lead you back to the source log, not to a guessed zero. Review any warnings, then confirm that the imported totals agree with the source you intended to measure.
Output can contain subcategories. When a source defines a reasoning count as already included in billed output, adding it again would double count. Do not infer this relationship from field names alone; use the usage format’s documented meaning or enter verified aggregate totals manually.
Reconcile, rather than replace, the invoice
Start reconciliation with the same account, model, time window, and billing units. Then account separately for anything outside token pricing: tool calls, media generation, storage, minimum charges, credits, taxes, or negotiated adjustments. An invoice can legitimately differ from a correctly calculated token receipt.
The same distinction applies to subscriptions. A hypothetical API valuation of usage is not a cash refund, a guaranteed amount of included API credit, or evidence of what the subscription provider spent to serve you.
Share the summary, not the session
The sharing format for this tool contains the numeric assumptions required to reproduce the calculation. It does not include raw prompts or the imported file. Nevertheless, the totals you choose to share can reveal usage or budget information; review them before posting a link or image publicly.
Sources and method
This is a synthetic worked receipt using the tool’s default counts and flat rates. No customer session or provider invoice was used. The arithmetic and default total are checked by an editorial regression test. Source-specific pricing should be verified for the relevant billing period.
Your AI Usage Receipt Is Not Your Invoice. ByteCosts. Updated 2026-09-05. https://bytecosts.com/blog/ai-usage-receipt-not-an-invoice/