Five questions to answer before you design usage-based billing

Most billing projects start with a price: a cents-per-thousand-tokens number, a few plans, a free tier. Teams that don't end up rebuilding billing a year later settle five questions first. None of them are about the price.

1. What does a customer actually pay for?

Start with the unit of value, not the unit of cost. Is it tokens, requests, seats, completed tasks, or credits that stand in for all of them? For AI products the answer is often per model, and your own costs move every time a provider changes its rates, so the pricing model has to change easily too.

In Meterbox: plans price each model separately and set its limits, and outcome-based pricing charges for completed results rather than raw usage. Each model records what its provider charges you, so every usage event carries a margin, and provider invoices reconcile against what your ledger expected. Price a model at that cost plus a markup and its price follows when the provider changes rates; a model you price by hand raises an alert when a provider change pushes its margin below your floor. Meterbox Advisor turns a plain-English deal brief into a proposed subscription built from your catalog, and nothing changes until you apply it.

2. Where does usage come from, and can you trust it?

Billing is only as reliable as the events feeding it. Decide where events originate (your API gateway, your application, a data pipeline), how many arrive, which dimensions matter for price (model, region, tier), and what happens to an event that arrives late or twice.

In Meterbox: record usage through the metering API, in batches, from files in your storage bucket, or through Segment, Airbyte and Kafka connectors. Prices can vary by any dimension you attach to a customer. Late events backfill into the right period, and a past period gets a reconciling line instead of a silently wrong invoice. Send an Idempotency-Key with a write and a retry returns the first result instead of counting twice.

3. How do customers actually buy?

Self-serve customers pay by card as they go or buy credits up front. Enterprise customers sign commits with overages and true-ups. Most products end up with both, plus seats layered on usage. Decide now what happens when a customer hits a limit: block them, slow them down, or bill the overage.

In Meterbox: pay-as-you-go, prepaid credits, seats, annual prepay, trials, and contract commits with true-ups all run on the same catalog. Each plan chooses whether overage is blocked, throttled or billed, soft limits can upgrade a customer automatically, and a per-customer spend cap stops runaway usage. For sales-led deals, quotes turn into subscriptions when accepted, and contract extraction reads the terms straight from a signed PDF.

4. Who else needs this data?

An invoice is the least of it. Customers want to see usage inside your product before the bill arrives. Sales wants it in the CRM. Finance needs revenue recognized correctly and journals in the ledger. Your data team wants it in the warehouse. Decide how fresh each view has to be.

In Meterbox: embeddable React components and a drop-in customer portal show usage, credits and plan changes in your product. CRM sync covers Salesforce and HubSpot, revenue recognition follows ASC 606, and journals export for NetSuite and Xero. Webhooks report lifecycle changes as they happen, reverse ETL pushes customers, usage and credit grants to S3, Segment, Hightouch or any HTTP endpoint, and AI agents can query billing through a hosted MCP server.

5. What happens when something goes wrong?

Something will: a customer's usage spikes overnight, a price change needs to roll out without surprising existing customers, a plan ships with the wrong number, an auditor asks who changed what. Plan for it before the first invoice.

In Meterbox: spend caps and spend-spike alerts catch runaway usage. Plans are versioned, so existing customers keep their price until you move them. Before you publish a price change, replay real usage against it to see who pays more and who pays less. Sandbox and production are separate environments, and configuration moves from one to the other deliberately. Every change lands in a tamper-evident audit log, and credit notes correct a finalized invoice.

Start with the questions

The answers will change as your product does. The point is to choose billing infrastructure that lets them change without a rebuild. If you're working through these now, see how the platform fits together or compare plans.