DEV Community

Nobody audits their OpenAI invoice

Every team running LLMs in production has two numbers for last month's spend: the one in their tracking tool, and the one on the invoice the provider sent. They almost never match, and the reasons are documented: providers report cached tokens differently, the community pricing data is an estimate by its own admission, the tools themselves treat deltas under roughly 10% as normal, and the calls you never instrumented don't show up in your numbers at all. I've spent the past few weeks reading up on this, and the surprise was where the evidence lives. It's mostly in the docs of the tools doing the estimating, written against their own interest. Why the numbers diverge OpenAI and Anthropic report cached tokens differently OpenAI folds cache reads into the reported input token count. Anthropic reports cache fields separately from regular input. Both choices are documented and both are reasonable, but any tool that computes cost through a single path across both providers will be wrong on one of them. This isn't theoretical: Langfuse issue #12306, opened February 2026, Anthropic cache tokens double-counted, roughly 2x inflated cost. LiteLLM has its own family of cache accounting issues. The pricing registries call themselves estimates Pydantic maintains genai-prices, a community pricing registry of the kind most estimation tools depend on. Its README has a warning section literally titled "these prices will not be 100% accurate". Providers don't publish exact pricing for the direct OpenAI, Anthropic and Gemini APIs in any reliably machine-readable format, which is the whole reason the registry has to exist. (Azure, AWS and GCP do publish machine-readable SKU prices for their hosted variants, so this is about the direct APIs.) A 10% gap is treated as normal The closest thing to a published drift number I found is a troubleshooting band. LiteLLM's cost-discrepancy doc says deltas under roughly 10% between tracked spend and the bill are commonly explained by rounding and boundary effects, and bigger ones usually mean something got miscounted, dropped or categorized differently. "Usually". That's a heuristic in a troubleshooting doc, not a measurement, and it's still the best public number there is. Untracked calls still get billed Everything above assumes the call went through your tracking in the first place. The one-off script, the teammate's experiment, the key that leaked. Your tracking shows you the calls it saw. The invoice shows everything. What can you use to reconcile LLM costs? I'm building a product in this space, so discount everything that follows, and check it against the vendors' own pages. | Option | What it gives you | The limit | |---|---|---| | Trackers (Langfuse, Helicone, LiteLLM) | Traces, evals, per-request cost estimates | Cost is estimated from tokens, not checked against the bill | | Gateways (OpenRouter, Vercel AI Gateway) | Authoritative cost for routed traffic | It's the biller's own receipt, and only for traffic through it | | Spend and cloud cost platforms | The provider's number, organized and forecasted | One source, nothing to check it against | | Enterprise audit services | Recovered overcharges, at enterprise scale | A project, not a product | | DIY with the provider cost APIs | A real reconciliation, once | Breaks down at per-key, per-feature granularity, every month | | Kenda (mine) | Both numbers and the delta, labeled by evidence | Early, I'm building it | If you're on Langfuse, Helicone or LiteLLM: they're great at what they're actually for, and to their credit, their own docs are where I learned most of what's in this post. Checking the invoice was never their job. If your traffic goes through a gateway, the gateway's figure is authoritative for that traffic, because the gateway is the one charging you. That's also the limit: a receipt is not an audit, and calls that don't go through it don't exist to it. The spend management and cloud cost platforms mostly read the provider's billing APIs, so they give you the provider's number back, organized. Useful, but you can't check a number against itself. The few products that hold both a client-side measurement and the billing data don't, as far as I can find, show you the difference between the two as a first-class view. If you know one that does, tell me in the comments, I'd like to be wrong about this. And the spreadsheet genuinely works at small scale. OpenAI exposes an organization costs endpoint, Anthropic a cost report. Pull both, export your tracked spend, join by hand. If the numbers match within noise, you're done. The pain shows up when you want the answer per key, per feature, per customer, across billing-cycle boundaries instead of calendar months, every month. What is Kenda? Kenda is an AI spend reconciliation tool: it compares the LLM costs your own code logged against the dollars the provider actually billed, and shows the difference, line by line. On one side, the events your code produced, priced at provider rates. On the other, the spend the provider itself asserts. Both numbers side by side, with the delta, per billing period. That's what I'm building at kenda.app. The design decision I care most about: every figure says how far the evidence goes. Reconciled means the provider asserted dollars at that scope. Priced means the provider asserted the tokens and Kenda applied the rates. Allocated means only Kenda's own events exist there. Whatever can't be attributed shows up as its own visible line instead of getting smeared across the rest. If a cost tool never shows you a residual, it's hiding one. It's boring infrastructure. Reconciliation always is. I spent six years reconciling money nobody could account for, in healthcare billing and fintech, and this is the same discipline pointed at AI spend. FAQ How far off is tracked LLM spend from the real invoice? Nobody has published a measured distribution. The closest public reference is LiteLLM's troubleshooting doc, which treats deltas under roughly 10% as commonly explained by rounding and boundary effects. If you've measured your own gap, that number is more valuable than anything in this post: leave it in the comments. How do I check my OpenAI or Anthropic bill programmatically? OpenAI exposes an organization costs endpoint that breaks spend down by project, API key and line item. Anthropic exposes a cost report at workspace level. Pull those, export what your tracking recorded for the same billing period, and compare. The billing period matters: provider cycles don't always align with calendar months. Why is my OpenAI bill higher than my tracking shows? The usual suspects, in order: calls that never went through your tracking (scripts, experiments, leaked keys), cached tokens counted differently than your tool assumes, and stale pricing data. Whatever is left after those is the residual, and the residual is the part worth investigating, not smearing across the rest. If you've ever compared your tracked LLM spend against the actual invoice, I want two data points: how far off it was, and whether you could explain the difference. Rough numbers are fine. "We never checked" is a genuinely useful answer, and I expect it to be the most common one. Top comments (1) The residual is the part most dashboards hide, and it is also where retry and fallback failures tend to surface. I’m starting to treat estimated spend as a reservation before dispatch, then keeping it UNKNOWN until a timeout or provider response is reconciled. That separates β€œwe priced the tokens we saw” from β€œthe provider actually billed this request.” The per-key and per-feature scope matters too: a monthly total can be correct while one runaway worker or leaked key is still invisible. Your distinction between reconciled, priced, and allocated is a useful way to keep those evidence levels honest.

Read on DEV Community ↗ ← Back to News

Comments

No comments yet. Start the discussion.