Customer billing · The fourth dimension
Meter once. Bill your customers anywhere.
Tokenality already meters every token and attributes it across your people, projects, and budgets — the control plane that saves you money internally. Customer billing is the same meter pointed outward: the tokens you serve become revenue you rate, reconcile, and bill — across every provider, processor-neutral, without touching how you call models.
One meter, two sides of the ledger
People. Projects. Budgets. Now — Customers.
Cost plane
People
Who spent it? SSO identity signed into every token.
Cost plane
Projects
What for? Task, memo, and URL on every commit.
Cost plane
Budgets
Within limits? A hard cap enforced before the call.
Revenue plane
Customers
Who do we bill? Rate it, reconcile it, invoice it.
The first three dimensions answer what did we spend? The fourth answers what do we bill? — turning the same telemetry from a CFO-defense into a revenue engine.
How a token becomes an invoice line
Six steps, none of them in your hot path.
- 1
Meter
One immutable, idempotent record of every token, per customer, across every provider — tailed from your existing usage table or emitted in one line. Audit-grade, not a batch estimate.
- 2
Rate
A rate card turns provider cost into customer price — markup, flat, or tiered — for every provider you run. Versioned and deterministic, so a price change is a diff, not a mystery.
- 3
Accrue
Rated usage rolls into billing periods per customer, up the hierarchy (platform → tenant → end-user). Roll up the tree; rate at any level.
- 4
Govern
Bill overage automatically, or burn down prepaid credits with correct deferred-revenue treatment. Alerts fire before a customer runs dry — no eaten overages, no manual true-ups.
- 5
Reconcile
Prove events-generated equals invoiced before you close the month. A non-zero delta is a leakage alarm, surfaced — not a surprise your auditor finds later.
- 6
Project
Send the invoice to Stripe, NetSuite/Intacct, or a CSV — a swappable projection chosen per customer. We compute what's owed; your processor collects. We never touch the money.
Integrate the way that fits — in days.
The lowest-touch path is the one most platforms qualify for: if you already write a usage row per call, we read it. No changes to how you call models.
Recommended
Ledger adapter
Point us at your existing usage table + a cursor column. We tail it on a schedule. Zero call-site changes; complete coverage of every AI path.
One line
Report-mode SDK
Emit a usage event after your existing metering hook — tk.usage.record({ customerId, model, tokens }). Idempotent on your own row id.
Greenfield
Gateway mode
Route AI through the Tokenality gateway and tag the customer on the request. Zero reporting code — and you gain the governance plane too.
See the full contract on the quickstart, or why the meter stays yours in own your meter.
The tokens are already flowing. The only question is whether you're billing for all of them.
Model what accurate, all-provider, processor-neutral billing would recover for your book.
Frequently asked questions
How is customer billing different from Tokenality's internal cost control?+
Same meter, opposite direction. The internal dimensions — people, projects, budgets — attribute and govern the AI cost you spend. The customer dimension points that same meter outward: the tokens you serve to your customers become revenue you rate with your margin, reconcile, and bill. Cost on one side of the ledger, revenue on the other.
Do I have to route my AI calls through Tokenality?+
No. If you already write a usage row per call, we tail that table on a cursor — zero changes to your AI-call path. Or emit one line after your existing metering hook. Routing through our gateway is a third option for greenfield or if you also want the governance plane, but it's never required.
Which providers can you bill for?+
Every provider you use — OpenAI, Anthropic, Google, Azure, Bedrock, self-hosted and fine-tuned models, embeddings, and caching. A rate card turns provider cost into customer price for all of them, not just the two or three a payment vendor auto-prices.
How do you handle prepaid credits and revenue recognition?+
Prepaid credits are deferred revenue drawn down as customers consume — recognized on burn, per ASC 606. The meter that counts usage is also the control that makes that recognition defensible to an auditor. Overage bills automatically or draws from the credit balance, with alerts before a customer runs dry.
What if we want to switch payment or billing vendors later?+
You own the meter. Where the invoice lands — Stripe, your ERP, a CSV — is a projection you set per customer and can swap without re-instrumenting a single AI call. Export your full event stream any time. That neutrality is the point.