methodology

How reconciliation works

Claim scope: invoice reconciliation only. This page defines exactly what ToTheCent claims, how it is computed, what evidence backs it, and where the claim ends.

Reconciled to the cent at the finest grain your provider’s invoice discloses, with any residual shown — never hidden.

This is an operational definition, not a slogan. Three commitments:

1. To the cent — we recompute your cost independently and tie it to the invoice at cent precision. Where a residual exists, we show it and explain it.
2. At the finest grain the invoice discloses — providers bill in line items and buckets, not per request. We reconcile at exactly the grain the invoice exposes. We do not claim finer precision than the billing document itself supports.
3. Any residual shown, never hidden — unmatched amounts, unrecognized billing lines, and untracked spend are surfaced as first-class outputs, not absorbed into totals.

Most AI cost tools price your usage from a public price sheet. Provider invoices don’t work that way:

• Cache-write multipliers vary by TTL (e.g. 1.25× for 5-minute cache writes, 2.0× for 1-hour writes on Anthropic).
• Reasoning tokens are billed but not always surfaced the way telemetry assumes.
• Mid-month price changes mean one month can span two effective rate cards.
• Restatements — usage data can be revised by the provider for up to 30 days.
• Batch, service tiers, and context-window pricing change the applicable rate for otherwise identical requests.

An estimate built from a price sheet can drift from the invoice without anyone noticing. Reconciliation means the drift is measured, not assumed away.

Some tools ingest the provider’s own cost reports and display them back — a mirror of the provider’s ledger. A mirror is internally consistent by construction: it agrees with the provider because it is the provider’s number.

ToTheCent verifies instead. We independently recompute cost from usage quantities and an effective-dated rate card maintained from published pricing, then compare that recomputation against the provider’s cost report and the actual invoice. Agreement is a result, not an assumption. Disagreement is a finding.

Level A — rate reconciliation (Δ_rate). Usage quantities × verified rate card, compared against the provider’s cost report, bucket by bucket. Answers: are the rates being applied the ones published?

Level B — commercial reconciliation (Δ_commercial). The provider’s cost report tied out to the invoice document itself — line by line, including credits, discounts, and per-line rounding. Answers: does what you were charged tie to what the usage says, to the cent?

Both levels are computed by a deterministic SQL engine. No language model participates in any cost calculation. The narrative layer of reports is generated separately and every number in it must resolve to an engine-computed value — a hard gate, not a convention.

Every dollar of AI spend lands in exactly one verification tier:

Three quantities describe how the total ties out — they are deliberately distinct:

• Coverage — the share of the invoice reconciled per request (the T1 share).
• Residual — the reconciliation error on tracked spend. Near zero means tracked dollars tie to the invoice to the cent.
• Untracked — invoice spend your telemetry did not capture. A near-zero residual does not imply full coverage; these are different quantities, and we report both.

The identity that closes to the invoice:

Every term is reported. Nothing is folded silently into another.

The claim is backed by measurement on a real provider invoice, not a synthetic benchmark:

• Anthropic invoice, June 2026, $64.13 total. 80 of 81 invoice lines — the finest grain the invoice discloses — reconciled at exactly $0.00 difference.
• Total residual at invoice-line grain: +$0.01 (0.016%). Provably irreducible: it arises because the provider rounds each line before summing, and the sum of rounded lines is not the rounded sum. No rate change on our side can remove it — so we display it instead. At the coarser bucket grain, the same precision gap is +$0.03908715 across all 79 buckets before our side rounds anything; quantized to a cent per bucket, it collapses to the same +$0.01, in exactly one bucket. A residual figure without its grain is incomplete — we report each at the grain it was measured.
• Blind rate test: an independent recomputation using only the provider’s public pricing page — no access to our rate card — reproduced the same result.

The full reconciliation of these figures — the complete arithmetic chain across all three grains — is in One invoice, three grains below. That section is the canonical statement; any residual figure quoted elsewhere resolves to it.

Measurement records available on request.

The same June invoice yields three different residual figures. They are not competing measurements and none supersedes another — they are one mechanism observed at three grains. Publishing only one of them would be the misleading choice, because each answers a question the others cannot.

The single mechanism

The provider computes each charge at full precision, renders each invoice line at cent precision, and then sums the rendered lines. The cost report exposes the unrounded amounts; the invoice document exposes the rounded ones. Everything below follows from one fact:

This is ordinary decimal arithmetic, not a defect on anyone’s part. It is also not removable: no change to our rate card can make a sum of rounded numbers equal the rounded sum. So it gets reported rather than absorbed.

The three grains

The June invoice has 82 exported rows, which collapse to 81 distinct billing keys at the invoice’s own grain (day × model × workspace × api key × usage type × context window × token type) and to 79 buckets at the coarser grain shared with the usage side (day × model × token type).

The arithmetic chain

Each step below is a computed value, not an illustration:

1. Exact amounts. The provider’s cost report, summed over the 79 buckets: $64.16908715.
2. Rendered amounts. The invoice, summed over the same 79 buckets: $64.13. Every one of the 79 buckets differs from its exact amount — and not one differs by as much as a cent.
3. The difference is grain 2: $64.16908715 − $64.13 = +$0.03908715. This is the full cost of cent-rendering, before anyone rounds anything on our side.
4. The difference is bounded, and the bound is derived from the invoice’s own structure. A single line rendered to a cent moves by less than half a cent, so a bucket fed by n lines can move by less than n half-cents: |residual(bucket)| < line_count × $0.005. Every bucket satisfies this. The largest residual, $0.007176, exceeds half a cent — and is the one bucket the invoice splits across two separately-rendered lines (2026-06-02, claude-sonnet-4-20250514, input). A flat half-cent bound would be false here; the line count is what makes the bound correct.
5. Quantize our side at the same grain — round each bucket’s exact amount to a cent, then compare — and the residual collapses to +$0.01, in exactly one bucket: the same two-line bucket from step 4.
6. An independent path reaches the same place. The line-grain measurement never touches the cost report at all: it recomputes cost from usage quantities × rate card and rounds at the invoice’s own grain. It ties 80 of 81 lines at exactly $0.00, with +$0.01 left over — in that same bucket, where the invoice shows $2.15 + $1.78 = $3.93 against an exact $3.937176.

Why three numbers is the honest answer

Steps 5 and 6 arrive at +$0.01 in the same bucket from two directions — one starting from the provider’s cost report, one from our own recomputation of usage. That agreement is the substance of the to-the-cent claim: the irreducible remainder is a single, identified, explained cent, and it sits exactly where the invoice’s own structure predicts.

Step 3’s +$0.03908715 is not a competing result. It is the precision that cent-rendering discards, and it is only visible because the provider publishes unrounded amounts alongside the invoice. Quoting it as “the residual” would overstate the gap; quoting only the cent would hide that the gap was measured at all. Both are reported, at their stated grain, with the bound that explains them.

Reading rule: a residual figure without its grain is incomplete. Every residual we publish carries the grain it was measured at.

Stating limits is part of the methodology. Three apply today:

1. Evidence base is one provider, one list-price invoice. No discounted, committed-use, or batch-heavy invoice has been reconciled yet. If a discounted or commitment-based invoice ever proves structurally impossible to close at invoice grain, we will say so publicly — the claim is falsifiable by design.
2. The claim covers Anthropic invoices. OpenAI reconciliation is implemented but not yet verified against a real OpenAI invoice; until it is, the to-the-cent claim does not extend to OpenAI.
3. The claim covers invoice reconciliation, not showback. Reconciling a bucket to the cent does not prove how cost is attributed to features or customers inside that bucket — offsetting errors can misattribute a material share of a bucket while the bucket total still ties out perfectly. Showback is reported as attribution, never as “to the cent.”

• No silent fallbacks: an unrecognized billing line is quarantined and reported, never guessed.
• No language model touches a number in the cost path.
• No claims about your providers: a residual is a finding about data, not an accusation about billing.
• No prompt or response content is stored — only token counters, hashes, and business metadata.