You share one upstream provider account and serve many customers behind it—resale buyers, gateway tenants, or workspaces that split cost by organization. Month-end, the provider invoice lands on time. Totals match; discounts look right. Then you need a per-customer usage statement, or someone asks who burned the tokens, and that same invoice barely helps.
The gap is usually not “did we pay?” It is metering granularity. The upstream invoice answers how much your account used. Customer work needs how much each customer used and how cost attaches. Those are not the same table.
Why the provider invoice does not match customer bills
Three mismatches show up often—and they stack.
Pooling. AI products and token resellers fold many customers into a few upstream keys. The provider sees the pool: model, tokens, price lines. Which customer triggered which call is not an invoice dimension. Clean upstream reconciliation makes it easy to assume the downstream split “should just fall out.” It does not.
No customer dimension. Upstream prices by account, project, or subscription. Your commercial unit is customer, tenant, or workspace. Even if logs carry a customer id, the invoice will not invent that axis. Without customer-sliced usage facts, allocation becomes ratios or spreadsheets—until a dispute arrives.
Prices and discounts live upstream. Invoice rates, volume breaks, and credits are your contract with the provider. Downstream you may markup, bundle, or rate tenants differently. Even with a clean volume split, what you owe upstream is not what you charge customers. Treating them as one number guarantees a mismatch.
One adjacent issue needs only a pointer: when the gateway times out or a usage receipt never arrives, you may not know whether an event happened. That receipt problem is in the Architecture post on gateway timeouts. This piece covers the quieter failure: even with complete receipts, a pooled invoice is still not a customer-level usage ledger.
The missing layer: usage event → attributed / priced customer usage line
Aligning the customer side needs an explicit metering fact layer—not another upstream PDF:
usage event → attributed / priced customer usage lineEvent: an observable usage occurrence (tokens, model, timestamp, plus your customer/tenant id).
Attribute: attach it to the right customer (and product or env as needed).
Price (your rules): apply your rate card or cost map; do not paste provider invoice rows as customer truth.
Line: a queryable, aggregable, exportable customer usage line—the input to allocation or a billing system, not the invoice itself.
With that layer, the upstream invoice keeps proving what you owe the provider. The customer side speaks from your usage lines. Cross-check them if you want (model totals should roughly rhyme); do not conflate them. One is the procurement pool; the other is attributed fact.
What this layer solves—and what it does not
It fixes metering and attribution granularity. It does not issue invoices.
| It helps you | It does not replace |
|---|---|
| See tokens and cost per customer | Full subscriptions, invoicing, collections, tax |
| Turn gateway / multi-tenant traffic into attributed usage lines | Stripe, Lago, OpenMeter, or any billing suite |
| Feed allocation, statements, and export | A promise of zero overspend |
| Keep upstream totals and customer detail comparable but separate | Treating HTTP 202 / custody as settlement |
In one sentence: metering stops at the attributed usage line (optionally exported). Invoicing and payment stay in your billing stack. If you read Compare: OpenMeter or Compare: Lago, align the question first—metering layer or billing suite? They can connect via export. They are not the same product story; this post does not rank them or promise a migration.
Where FluxMeter fits
FluxMeter’s positioning is deliberate: Open-source usage metering for AI gateways and multi-tenant products — customer-level tokens and cost, without a full billing suite.
From flux to ledger: ingest usage from a gateway or SDK, move it through custody and stream processing into a queryable ledger, and read attributed, optionally priced customer usage lines from the Usage API. Export is optional—into your own billing logic or Stripe, Lago, Orb, Metronome, and similar systems. FluxMeter does not claim to replace them.
On the wire: a 202 on ingest means custody (usage was durably accepted), not settlement. Meter every token. Attribute every cost. Stop at the usage line; leave invoicing to the billing layer.
Next steps
If “upstream invoice reconciles, customer bills do not” is the stuck point, check for customer-dimension usage lines before asking for a bigger pooled report.
Boundaries and public comparisons: Compare
Touch the stack locally: make demo (see Docs)
Product and path facts: Architecture
Get the metering grain right first. Allocation and invoicing only work cleanly when each sits on its own layer.