Why does my Anthropic cost report not equal my invoice total?

The most common reason is rounding. Anthropic computes each charge at full precision, the cost report exposes the unrounded amounts, and the invoice renders each line at cent precision before summing. A sum of rounded lines is not the rounded sum. On the one invoice we have measured (June 2026, USD 64.13 invoiced, provider-reported cost report USD 64.16908715) the gap was USD 0.03908715, and it is bounded by the number of invoice lines times half a cent. A gap larger than that bound is not rounding and needs another explanation: a missing usage record, a rate applied wrongly, or spend the cost report does not carry.

Can I match a single API request to an invoice line?

No. Invoice lines are aggregates. In the exports we work with, one line is one combination of day, model, workspace, API key, usage type, context window and token type, and no per-request identifier appears on it. You can tie requests to a line only through that shared key, which is why the join is done on buckets rather than on requests.

How much residual is normal when reconciling an Anthropic invoice?

Less than line_count x USD 0.005 per bucket, because each line rendered to a cent moves by less than half a cent. On the one invoice we have reconciled, the invoice-line recomputation matched 80 of 81 lines at USD 0.00 difference and left USD 0.01 in total (reconciled, one provider, one list-price invoice, our own account). That is a single measurement, not a benchmark.

Do cache writes show up as a separate cost line?

In the Console CSV exports we ingest, yes: token types are input_no_cache, input_cache_read, input_cache_write_5m, input_cache_write_1h and output. Anthropic documents cache writes at 1.25x the base input price for a 5-minute entry and 2x for a 1-hour entry. Cache-read pricing is a lower multiple that Anthropic lists per model, so read it from the pricing page for the model you use.

Does this method work for OpenAI invoices?

ToTheCent has an OpenAI connector, but it has been exercised only against a synthetic oracle with known answers, not against a real OpenAI invoice. The to-the-cent claim on this site covers Anthropic only.

How to reconcile an Anthropic invoice to the usage that produced it

The invoice has no request ID. Here is the join that works instead: usage report, cost report, invoice line, in that order, with the rounding bound that tells you when a leftover cent is explained.

The short answer

An Anthropic invoice carries no request ID, so you do not match requests to the invoice. You match three layers that share a key: the usage report (tokens, fine grain), the cost report (provider-reported dollars, daily), and the invoice (the document, rounded per line). Recompute cost from usage, tie it to the cost report, tie the cost report to the invoice at the invoice’s own grain, and classify whatever is left over. The leftover has a computable upper bound, so you can tell an explained cent from an unexplained one.

What each layer gives you

Layer	What it is	Grain	Label for its dollars
Usage report	Token counts per model, token type, key	Minute, hour or day (Anthropic documents 1m, 1h, 1d)	No dollars. You price it yourself, so the result is estimated until it is tied out
Cost report	Provider-computed dollars	Day only, USD as decimal strings in cents	Provider-reported, unrounded. Not yet reconciled to the invoice
Invoice	The billing document	One line per billing key	Reconciled only after you tie your recomputation to it

The cost report and usage report are documented in Anthropic’s Usage and Cost API reference (checked 2026-10-27). Two practical limits we hit when we measured it: the cost report cannot group by API key, and the usage report can. If you need per-key attribution you take it from usage and price it yourself.

The join, in order

Pick the grain you will report at. Daily cost report plus hourly usage is enough. Minute grain is useful only for debugging.
Fix the period boundary first. Usage and cost are in UTC days. Your invoice period and your local calendar day are different things. Most “missing” spend at the edge of a month is a boundary mismatch.
Rebuild the price from an effective-dated rate card. A rate card is a table of price by model, token type and the date the price took effect. Mid-month price changes mean one invoice can span two rate cards. Cache writes are priced as a multiple of the base input price: Anthropic documents 1.25x for a 5-minute write and 2x for a 1-hour write (prompt caching docs, checked 2026-10-27). Cache reads are a smaller multiple that Anthropic lists per model, so do not hard-code one number.
Compare your recomputation with the cost report, bucket by bucket. This tests the rate card. Agreement here says the rates you applied are the rates Anthropic applied. It does not yet say anything about the invoice.
Tie the cost report to the invoice at the invoice’s grain. Collapse your buckets to the same key the invoice uses: day, model, workspace, API key, usage type, context window, token type. Compare line by line.
Classify what remains. Rounding, a period boundary, a missing record, a wrong rate, or spend the cost report does not carry. Anthropic’s documentation says Priority Tier spend is billed on a different model and is not in the cost endpoint, so if you use Priority Tier, take that spend from usage.

What the one reconciled invoice looked like

This is the measurement we publish, repeated here so the numbers can be checked against the original write-up. Scope: one provider (Anthropic), one list-price invoice (June 2026), our own account.

Invoice total: USD 64.13 (the document).
Provider-reported cost report for the same period: USD 64.16908715 (unrounded).
The invoice had 82 exported rows, which collapse to 81 billing keys at the invoice’s own grain, and to 79 buckets at the coarser day, model and token-type grain.
Independent recomputation from usage and a rate card reproduced 80 of 81 billed lines at USD 0.00 difference (reconciled, invoice-line grain), leaving USD 0.01 in total.
The USD 0.03908715 between the cost report and the invoice is the cost of rendering each line to a cent.

The reasoning behind the one remaining cent, and the bound that makes it irreducible, is in Why our residual is +$0.01.

Why a sum of rounded lines is not the rounded sum

Anthropic prices each charge at full precision, renders each invoice line at cent precision, then sums the rendered lines. With round(x) the cent-rounded value, the sum of round(line) is not the same as round(sum of lines). No change to your rate card can remove that difference. What you can do is bound it: one line moves by less than half a cent, so a bucket fed by n invoice lines moves by less than n x USD 0.005. If your residual is inside that bound, rounding explains it. If it is outside, rounding does not, and you should look for another cause.

Ten-minute check on your own bill

Export the cost report and the invoice for the same closed month. Do not use an open month.
Sum the cost report. Subtract the invoice total. Write down the difference with its grain (“monthly total” is a grain).
Count the invoice lines. Multiply by USD 0.005. Is the difference smaller than that?
If not, group both by day and model and find the day where they first diverge.
Label every figure you share as estimated, provider-reported or reconciled. Three labels, one word each.

What this does not cover

It does not cover OpenAI invoices (the connector exists but has not been exercised against a real OpenAI invoice), cloud-provider invoices, or Claude Enterprise seat costs. A cost-dashboard view that is built from the cost report alone is provider-reported, not reconciled: it agrees with the provider because it is the provider’s number.