Usage-Based Billing: What It Really Costs to Build, and When You Should Buy Instead

What usage-based billing actually is once real money runs through it

It is not a counter and a cron job. It is four systems that people mistake for one: metering (capturing what happened), rating (turning events into money), invoicing (turning money into a document someone will argue with), and enforcement (stopping usage before it becomes bad debt). Each has a different consistency requirement. Metering wants at-least-once delivery. Rating wants determinism. Invoicing wants exactly-once. Enforcement wants latency under a minute. One Postgres counter satisfies none of them.

The version that ships in a week and breaks in a quarter: a usage_count integer on the customer row, incremented in the request handler, read by a Kubernetes CronJob at midnight on the 1st, pushed to Stripe, then reset to zero. First month with real volume, the job runs out of memory at customer 340 of 900. Kubernetes restarts it. The job has no record of who it already pushed, so it starts from the top and 340 accounts get billed twice. Refunding is the easy part. The expensive part is that your biggest account's finance team now audits every invoice you send for the next year, and you have nothing to show them, because you reset the counter.

Metering: the part that decides whether your invoices are defensible

Never increment. Append. An immutable event log with a client-supplied idempotency key on the event itself, not just on the HTTP call. Stripe's Idempotency-Key header protects one API request and is retained for about 24 hours. It does nothing when your own queue redelivers a message six hours later.

• Retries double count silently. A load balancer returns 504 after the write already committed. Your SDK retries. Without a durable dedupe key stored on your side, that is revenue you invented.
• Late data is not a corner case. A mobile client in airplane mode syncs six days of usage on the 3rd, after last month's invoice is finalized. Stripe's Billing Meters API rejects events timestamped outside a narrow window (currently around 35 days back and 5 minutes forward, worth re-checking before you design around it), so a backfill does not go through the meter at all. It goes through an invoice item on the next cycle or a credit note on the last one. Pick your correction policy now and write it into the contract. Most competent builds roll forward and disclose it on the invoice.
• Do not trust client clocks for period boundaries. Store both occurred_at from the client and received_at from your edge. Rate on received_at unless you have a legal reason not to, and keep both so you can explain the difference later.
• The hot row dies before the CPU does. An UPDATE customers SET usage_count = usage_count + 1 serialises every concurrent request onto one row lock and bloats MVCC. Under roughly 10 million events a month, a partitioned append-only events table with hourly rollups keyed by (customer, meter, hour) is fine. Above that you are into Kafka plus ClickHouse or TimescaleDB, with watermarks for late arrivals, and you rate from the pre-aggregated buckets, never the raw stream.

Rating: the pricing math is not arithmetic

Graduated versus volume tiers is the single most common bug we find in inherited billing code. Graduated: the first 1,000 units at $0.10 and the next 9,000 at $0.05, blended. Volume: all 10,000 at the $0.05 rate of the tier you landed in. Same rate card, different invoice, and the customer only notices in the direction that costs you the relationship. Package pricing and stair-step add two more shapes with two more test matrices.

Rounding is where the money leaks. One million calls at $0.0004 each, rounded to cents per event, is $0.00. Rounded once at the line item, it is $400.00. Compute in integer sub-cent units (Stripe's unit_amount_decimal accepts up to 12 decimal places for exactly this reason), round once at the line item, round half to even.

Proration does not exist for metered lines. A customer upgrades on the 14th. You cannot prorate consumption that already happened. You either split the period into two rated segments or apply the new rate to the whole period. Both are defensible. Only one matches what the customer assumed. Ask before you code it.

Commitments turn a feature into a ledger. Annual prepaid commit, drawn down monthly, overage after exhaustion, rollover or expiry, mid-term true-up. That is a balance with debits and credits, and it needs the same auditability as the events. And once twelve enterprise contracts have bespoke rate cards, pricing has to be data in a versioned table, not an if/else in the rating service, or engineering is in the loop on every deal your sales team closes.

The invoice has to survive an audit, a webhook retry and a tax authority

• Deterministic replay. Same events plus the same rate card version must recompute to the identical invoice. That means rate cards are versioned and immutable, and rated line items store the version they used.
• Drill-down or your support team does it by hand. Every line item must expand to the events behind it, exportable as CSV. Buyers of usage-based products audit. Build this in v1.
• Webhooks arrive twice, late and out of order. Stripe retries with exponential backoff for up to three days in live mode. invoice.payment_failed landing twice is normal traffic. Store the event id, dedupe on it, make handlers idempotent, and fetch the current object from the API rather than trusting the payload you received.
• The finalization window is your last chance. Stripe waits roughly an hour between invoice.created and finalization for pending invoice items. That hour is where late usage gets attached. Miss it and you are in credit note territory.
• Revenue recognition is a build, not a Stripe setting. Under ASC 606 usage revenue recognises as delivered, not when the invoice goes out, and prepaid commits sit in deferred revenue and draw down. Finance wants a monthly schedule and a NetSuite or QuickBooks export.
• Tax bites early. Usage pricing crosses state economic nexus thresholds (commonly $100,000 in sales or 200 transactions) faster than founders expect, and SaaS taxability is state-specific. Texas taxes data processing services on 80 percent of the charge. Wire Anrok, Avalara or Stripe Tax in at the line-item level before you owe back taxes on eighteen months of invoices.

Enforcement and the two-clocks problem

Customers will ask for spend caps within a month of launch. Caps need latency. Billing needs exactness. You end up with two numbers: a fast approximate counter (sharded Redis, incremented in the request path) that powers gates, dashboards and alerts, and the slow exact aggregation that powers invoices. They will disagree, every day, and someone will screenshot it.

Decide the rule up front and publish it: the exact path always wins on the invoice, and the fast path is allowed to overshoot by a documented amount. "Hard cap enforced within 60 seconds, maximum overshoot one minute of peak throughput" is an engineering answer. "Real time" is a sales answer. Then decide what actually happens at the cap: 402, degrade, queue, or alert only. Hard-cutting an API that runs a customer's production creates a Sev1 for them and a churn event for you. Default to alerts at 50, 80 and 100 percent, and cut only on explicit opt-in.

What it costs and what drives the number

These are Digital Heroes delivery bands, drawn from more than 2,000 projects: what we have charged and delivered.

• Focused build inside an existing product: $15,000 to $60,000. One to three meters, graduated or volume tiers, a vendor handles rating and invoicing. You build ingestion, dedupe, reconciliation and the customer-facing usage view.
• As part of a first release: $50,000 to $130,000 in 10 to 16 weeks. Adds plan and rate-card modelling, self-serve upgrade, dunning, and an internal tool that lets a non-engineer fix a mis-metered account without a database console.
• Full platform: $150,000 to $350,000 over 6 to 12 months. Your own rating engine, per-contract rate cards, a commitment and credit ledger, revenue recognition export, tax, real-time enforcement, and migration of live customers.

What specifically pushes this capability up:

• Pricing shapes. Budget about a week per additional shape including the test matrix. Two meters to nine is not free.
• Commitments and prepaid credits. Add 3 to 5 weeks, because you are building a ledger.
• Real-time caps. Add 2 to 4 weeks for the second data path and the reconciliation between the two.
• ASC 606 schedules and an ERP (Enterprise Resource Planning) export. 3 to 6 weeks, and a finance stakeholder who has to be in the room, not on the CC line.
• Migrating customers who already pay you. The sleeper. You shadow-bill the new engine against real events for one to two full cycles and diff every invoice against the old system before you cut over. That is 4 to 8 weeks of calendar time nobody quotes.
• Volume above roughly 10 million events a month. Moves you off Postgres onto a streaming stack: 4 to 6 weeks of build plus permanent ops cost.

When you should not build this

If you have fewer than five meters, no negotiated per-customer rates, and no commitments, do not build a rating engine. Use Stripe Billing meters. Stripe Billing lists at 0.7 percent of billed volume on top of processing, so on $2M of billed revenue that is $14,000 a year, cheaper than three weeks of senior engineering and it never pages you. You still build the ingestion and reconciliation layer yourself, because that lives inside your product and no vendor can reach it.

If you have enterprise contracts, commitments, and a team that invents pricing live on calls, you have outgrown Stripe's model but you are still not a billing company. Buy Orb or Metronome, or self-host Lago if compliance requires the events to stay inside your boundary. The honest build case is narrow: your unit of value is something no vendor models (per-second GPU time net of spot preemptions, a derived score, a formula that changes per contract), or metering is itself the product you sell.

One group should build anyway: companies whose customers audit the meter as a contractual condition. At that point the meter is a compliance artifact with your name on it, and outsourcing it just moves the liability without removing it.

How to brief and vet a developer for this

Brief with artifacts, not a feature request. Bring the rate card. Bring the ugliest real contract you have signed. Bring one real month of raw events or the closest thing you have. State the correction policy you want when late usage lands after finalization. State the maximum overshoot you will accept on a spend cap. A team that gets those four things can scope this in a week. A team that gets "we want usage-based pricing" will quote the demo.

Questions that expose someone who has never shipped it:

• "Our SDK gets a 504 after the write commits, then retries four hours later. Where is the idempotency key and what is the dedupe window?" You want the key on the event, deduped in your store, not a shrug at the vendor's header.
• "An event arrives timestamped 40 days ago. Walk me through it." They should know the meter API refuses it and reach for an invoice item or a credit note. "We'll just insert it" means they have not shipped this.
• "Graduated versus volume tiers, and where does the boundary math live?" Hesitation is the whole answer.
• "Where does rounding happen and in what units?" Correct: integer sub-cent units, rounded once at the line item.
• "A customer upgrades on the 14th. What happens to the metered line?" If they say "prorate it", they are guessing.
• "Recompute last month's invoice from raw events. How do you prove it matches what we sent?" You want versioned rate cards plus deterministic replay plus a diff report.
• "Stripe delivers invoice.payment_failed twice, out of order. What does the handler do?"
• "What is the maximum a customer can overshoot a hard cap, in seconds and in dollars?" A number, or they have not met the two-clocks problem yet.
• "How do we dry-run a price change against last month's real events before we announce it?" If shadow billing is not already in their answer, you will pay for it later at three times the price.

Anyone who calls this "just Stripe metered billing" is describing a demo, not a system that finance will sign off on.