TOTHECENT — tothecent.ai/blog/estimation-is-not-reconciliation
blog

Estimation is not reconciliation

Every AI cost tool shows you a dollar figure. Almost none of them will tell you the one thing a finance team actually needs to know about that figure: whether anyone has checked it against the bill.

The distinction sounds pedantic until the first month it isn't — the month the dashboard says one number, the invoice says another, and nobody in the room can explain the gap. This piece is about why that gap exists structurally, why it grows silently, and what checking against the bill actually involves.

How the standard approach works

Most AI cost tooling prices your usage from a public price sheet: count the tokens your telemetry saw, multiply by the published rate per million, sum. This is estimation. It is fast, it needs no access to your billing account, and for day-to-day awareness it is genuinely useful.

The problem is the quiet assumption underneath it: that the invoice is a linear function of the price sheet. Provider billing does not work that way, in at least four specific mechanisms.

Four mechanisms that pull the invoice away from the price sheet

Cache-write multipliers vary by time-to-live. On Anthropic, writing to the prompt cache is billed at a multiplier of the base input rate that depends on how long the cache entry lives: 1.25× for five-minute cache writes, 2.0× for one-hour writes. An estimator that prices all input tokens at the base rate — or all cache writes at one multiplier — will drift in proportion to how cache-heavy the workload is, and modern agentic workloads are very cache-heavy.

Mid-month price changes split the month. When a provider changes a rate mid-cycle, one billing period spans two effective rate cards. An estimator using "the current price" misprices every unit of usage on the far side of the change date.

Usage restatements rewrite the past. Provider usage data can be revised for up to 30 days after the fact. An estimate computed on day two is computed against data that may no longer exist by day thirty. If nothing re-checks the figure after restatement, the drift is permanent and invisible.

Batch, service tiers, and context-window pricing change the applicable rate for otherwise identical requests. Two requests with the same token counts can be billed at different rates depending on how and when they were submitted. A price-sheet estimate has no way to know which rate applied unless it models the full billing structure.

None of these mechanisms is exotic. All of them are documented provider behavior. And each one drives a wedge between "tokens × price sheet" and the number on the invoice.

The structural point: drift that is not measured is assumed away

Any one of these effects might be small in a given month. That is precisely the trap. An estimate built from a price sheet can drift from the invoice without anyone noticing, because nothing in the estimation pipeline is positioned to notice — the pipeline never looks at the invoice at all.

Reconciliation is the discipline of measuring the drift instead of assuming it away: independently recompute the cost from usage quantities and an effective-dated rate card, then tie that recomputation to the provider's cost report and to the invoice document itself, at the grain the invoice discloses. Where the numbers agree, you now know they agree — bucket by bucket, not in aggregate. Where they disagree, the disagreement is a finding with a location, not a vague sense that the dashboard "runs a little low."

The difference shows up in the evidence. When we reconciled a real Anthropic invoice from June 2026 this way, 80 of its 81 billing lines tied out at exactly $0.00 difference, and the one remaining cent was traced to a specific bucket and explained by the invoice's own rounding structure — the full arithmetic is on our methodology page. That statement — this many lines, exactly zero, residual located and explained, at the invoice-line grain — is a different kind of statement than "our estimates are usually close." (Scope, stated plainly: that measurement covers one provider, Anthropic, on a real list-price invoice. Our OpenAI reconciliation is implemented but so far verified only against a synthetic oracle with known answers, so the claim does not yet extend to OpenAI.)

What estimation is still good for

None of this makes estimation worthless. Real-time estimates are the right tool for engineering feedback loops: catching a runaway job today, comparing two prompt designs, alerting on anomalies before the month closes. Estimation answers "what is happening right now, roughly?" faster than any reconciliation can.

What estimation cannot answer is "is this figure safe to put in front of finance, a diligence process, or a board?" — because that question is about the relationship between the figure and the bill, and estimation never inspects the bill. There is a reason this blind spot survives across otherwise careful teams: the discipline's shared vocabulary stops one step short of the bill. Practitioners can name a dozen ways to slice, allocate, and project AI spend — and have no everyday word for checking the sliced total against what the provider actually charged. Teams inherit the vocabulary, and with it the blind spot.

What to do

Three practical steps, in increasing order of rigor:

  1. Label your numbers. Every AI cost figure that circulates internally should carry one word: estimated or reconciled. The label costs nothing and immediately exposes which processes are running on unverified figures.
  2. Diff your estimate against the invoice monthly. Even a coarse, manual, total-level comparison converts silent drift into a visible number with a trend.
  3. When the number starts mattering — fundraising, diligence, margin reporting — reconcile properly. Independent recomputation, effective-dated rates, tied to the invoice at its own grain, exceptions surfaced. At that point the question is no longer "roughly what did we spend?" but "can we show our AI cost figures survive contact with the bill?"

Step three is where ToTheCent does its work: the invoice tie-out as a routine, deterministic monthly artifact instead of a quarterly forensic project.