Why our residual is +$0.01 — and provably irreducible

When a cost reconciliation lands within a cent, most people stop asking questions. We think the last cent is where the interesting questions start — because whether that cent is explained or merely small is the difference between a measurement and a coincidence.

This note walks through one real reconciliation, ending in a residual of one cent, and shows why that cent cannot be removed by any correction on our side. Along the way it makes a point we now treat as a reading rule: a residual figure without its grain is incomplete.

The problem: residuals get absorbed, not explained

Reconciling an AI provider invoice means recomputing the cost independently — usage quantities multiplied by an effective-dated rate card — and tying the result to the invoice document. When the two disagree by a small amount, the common responses are to round it away, absorb it into a total, or declare victory at "close enough."

All three responses destroy information. A small residual can mean rounding noise, or it can mean a rate applied incorrectly on a small volume, or missing usage records. You cannot tell which without knowing where the residual sits and what bound the invoice's own structure places on it.

Our claim is deliberately worded to keep that information intact: "Reconciled to the cent at the finest grain your provider's invoice discloses, with any residual shown — never hidden." What follows is what "shown, never hidden" looks like in practice.

The mechanism: a sum of rounded numbers is not a rounded sum

The measurement covers a real Anthropic invoice from June 2026, totaling $64.13. (Scope matters here, so we state it up front: this measurement is one provider, one list-price invoice. Our OpenAI reconciliation is implemented but has so far been exercised only against a synthetic oracle — a test harness with known correct answers — so the to-the-cent claim does not yet extend to OpenAI.)

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 of ordinary decimal arithmetic:

Σ round(line) ≠ round(Σ line)

This is not a defect on anyone's part, and it is 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.

Three grains, three numbers, one mechanism

The June invoice has 82 exported rows, which collapse to 81 distinct billing keys at the invoice's own grain — one key per combination of day × model × workspace × API key × usage type × context window × token type, so two exported rows sharing the same combination merge on aggregation — and to 79 buckets at the coarser grain shared with the usage side (day × model × token type). The same invoice therefore yields three different residual figures — not competing measurements, but one mechanism observed at three grains:

Invoice-line grain (81 keys): our independent recomputation reproduces 80 of 81 billed lines at exactly $0.00 difference, with +$0.01 left over in total.
Bucket grain, unrounded (79 buckets): the provider's exact amounts sum to $64.16908715; the rendered invoice sums to $64.13. The difference, +$0.03908715, is the full cost of cent-rendering — visible only because the provider publishes unrounded amounts alongside the invoice.
Bucket grain, cent-quantized (79 buckets): round each bucket's exact amount to a cent and compare, and the residual collapses to +$0.01, in exactly one bucket.

Quoting the second number as "the residual" would overstate the gap; quoting only the cent would hide that the gap was measured at all. Each number answers a question the others cannot, which is why we publish all three, each with its grain.

The bound comes from the invoice's own structure

A single line rendered to a cent moves by less than half a cent. A bucket fed by n lines can therefore move by less than n half-cents:

|residual(bucket)| < line_count × $0.005

Every bucket in the measurement satisfies this. The largest bucket residual, $0.007176, actually exceeds half a cent — and it is the one bucket the invoice splits across two separately rendered lines (2026-06-02, claude-sonnet-4-20250514, input tokens). A flat half-cent bound would be false there; the line count is what makes the bound correct. That detail matters: the bound is derived from the invoice's structure, not asserted from ours.

Two independent paths, one cent, same bucket

The strongest part of the measurement is convergence. The cent-quantized bucket comparison starts from the provider's cost report. The line-grain measurement never touches the cost report at all: it recomputes cost from usage quantities and a rate card, and rounds at the invoice's own grain. Both paths end at +$0.01, in the same bucket — the one where the invoice shows $2.15 + $1.78 = $3.93 against an exact $3.937176.

That agreement is the substance of the claim. The irreducible remainder is a single, identified, explained cent — 0.016% of the invoice — and it sits exactly where the invoice's own structure predicts it must.

What to do with this

If a tool or a team hands you a reconciliation result, three questions extract most of the truth:

At what grain was the residual measured? A number without a grain is incomplete by construction.
What bound does the billing document itself place on rounding effects? If the residual exceeds that bound, rounding is not the explanation.
Does an independent recomputation converge on the same figure in the same place? Agreement that is a result is worth more than agreement that is an assumption.

If the answer to any of these is unavailable, the residual has not been explained — it has been tolerated.

ToTheCent exists to make this kind of reconciliation — grain-explicit, bound-checked, residual shown rather than absorbed — a routine monthly artifact instead of a one-off forensic exercise.