Invoice Reconciler

Compares an invoice total against your own logged usage, with credits and tax, and tells you which direction the gap runs.

Invoice totalThe number on the bill, before you argue with it

Credits and discounts on the invoiceSubtracted from what you expected to owe

Tax on the invoiceVAT, sales tax — added after the usage total

Paste your own usage log for the same periodCSV or TSV, with a header row. It never leaves this page and is never put in the URL — see below. The rows here are invented example data.

ToleranceHow far apart the two may be before you care

Rate, if your log has tokens but no costUS dollars per 1,000,000 tokens. Ignored on rows that carry a cost.

$/1M

The invoice is over your logs by

$11.97

2.9% of the $416.03 your log implies. The invoice is higher than your logs account for. Look for a day your logging missed, a second key, or a line item that is not per-token.

Rows parsed: 14
Cost column: cost_usd
Rows with neither a cost nor a token count: 0
Usage total from your log: $416.03
Less credits and discounts: $0
Plus tax: $0
What the invoice should say: $416.03
What the invoice says: $428.00
Difference: $11.97
Difference as a share: 2.9%
Inside a 1% tolerance?: no
Rate the invoice implies: $3.60 per 1M tokens
Tokens in your log: 118,860,000
Requests in your log: 52,060

What this assumes: Nothing you paste leaves this page. The parsing and the arithmetic run in your browser; there is no upload, no request and nothing stored. Check the network tab, or turn the connection off before you paste — the tool keeps working. The pasted text is also the one field kept out of the shareable URL, so a link you send carries the settings and not your usage. Your log and the invoice are assumed to cover the same period, which is the single most common reason two totals disagree — billing periods rarely end at midnight in your timezone. Credits are treated as reducing the amount owed and tax as added on top of usage; if your provider applies tax before credits, the two orders differ by the tax on the credit. The implied rate divides the whole invoice by all tokens, so it blends input, output, cached and reasoning tokens into one figure — useful as a sanity check against the rate you think you are paying, not as a per-token price.

Reconciling is mostly about finding what you did not log

An invoice and a usage log almost never match to the cent, and the interesting question is which direction they miss in. If the invoice is higher, the usual causes are usage you are not logging — a second API key, a batch job on a different account, a background evaluation harness, a colleague's script — followed by charges that are not per-token at all, like storage for uploaded files, fine-tune hosting, or a minimum commitment. If your log is higher, look at the period boundary first, then at credits applied silently, then at requests you logged as intended but which failed before they were billable.

The implied-rate line is the fastest diagnostic in the breakdown. Divide the whole invoice by all the tokens you logged and you get one blended price per million. Compare it against the rate you think you are on. If it is far higher, you are probably paying output rates on more tokens than you assumed, or something is being billed at a premium tier — the reasoning tokens on a model that thinks before answering are the usual answer. If it is far lower, a cache discount or a committed-use rate is doing more work than you realised, which is worth knowing before you plan around the list price.

A note on cents. Providers round per request, not at the end, and thousands of tiny roundings do not cancel out neatly — a fraction of a percent of drift between a log and an invoice is normal and is not worth an email. That is what the tolerance field is for: set it to the difference you would actually act on, and let everything inside it go.

Invoice Reconciler

Reconciling is mostly about finding what you did not log

The reasoning behind this

Related tools