Stripe Usage-Based Billing
How Meters Work, Where It Breaks, and How to Reconcile It
Stripe Billing Meters are a good metering and invoicing engine. They are not a contract engine. This guide covers what Stripe does natively for usage-based billing, the six places B2B contracts break it, and the workflow finance teams use to keep the invoice tied to the deal.
Stripe Usage-Based Billing Definition
Stripe usage-based billing is Stripe Billing's metered pricing model: a meter defines what is counted and how it aggregates, the product sends meter events as customers consume, a usage-based price converts the aggregated total into a charge, and the subscription invoices that charge in arrears at the end of each period. Stripe handles counting, rating, and invoicing. The signed contract's minimums, negotiated rates, true-ups, and revenue schedules are outside its scope and have to be reconciled separately.
The six Stripe objects that make up usage-based billing
Each one does a specific job. Knowing where each stops is how you find the gaps.
Billing Meters
A meter defines what you count (API calls, tokens, seats, GB) and how it aggregates over the billing period: sum, count, or last value. Meters replaced the older per-subscription-item usage records.
Meter events
Your product sends one event per unit of consumption with a customer identifier, a value, and a timestamp. Stripe aggregates events per customer for the period. Events must be sent within Stripe's backdating window or they are rejected.
Usage-based prices
A price attached to a meter converts aggregated usage into money: per unit, package, or tiered (graduated or volume). The price is where a rate card lives, and it is set per product, not per contract.
Subscriptions and invoices
A subscription item on a usage-based price bills in arrears. At the end of the period Stripe rates the aggregated usage, adds any flat recurring fees, and generates the invoice.
Billing credits
Credit grants let a customer prepay and draw down against metered usage. Stripe applies credits to the usage line items on the invoice, and expiry and remaining balance are tracked on the grant.
Revenue Recognition
Stripe's add-on recognizes usage invoices when they are finalized and handles straight-line subscriptions. It works from Stripe objects, not from the signed contract or from usage that never made it into Stripe.
Where B2B contracts break Stripe usage billing
Stripe prices are generic by design. B2B contracts are negotiated one at a time. Every gap between the two is an invoice that does not match the deal.
The contract has terms the Stripe price does not
A negotiated rate, a custom tier boundary, an annual minimum commitment, or a usage cap lives in the signed PDF. The Stripe price is generic by design, so the invoice bills the default rate card and nobody notices until the customer disputes it or the auditor asks.
Minimum commitments and true-ups are calculated outside Stripe
Stripe rates what was consumed in the period. It does not know that the customer committed to $120K for the year, that the shortfall is due in Q4, or that usage above the commit should bill at the overage rate. Those true-ups happen in a spreadsheet.
Usage that never reached the meter
Events dropped by a retry failure, rejected as too old, sent with the wrong customer mapping, or never instrumented for a new feature. Stripe invoices what it received. The gap is invisible unless something independently compares product usage to billed usage.
Prepaid credits, drawdown, and breakage
Billing credits cover the invoice math. They do not produce the deferred revenue schedule, the recognition on consumption, the treatment of expired credits, or the reconciliation between the credit balance Stripe shows and the balance the contract implies.
Mid-period changes and proration
A plan change, added seats, or a renegotiated rate mid-cycle means part of the period should bill on old terms and part on new. If the change is applied in Stripe late, or only in the CRM, the invoice is wrong for the whole period.
Revenue recognition on variable consideration
ASC 606 requires estimating variable consideration and applying the constraint on commit-plus-overage contracts. Recognizing usage invoices as they finalize is often acceptable for pure pay-as-you-go, but commits, prepaid credits, and minimums need a schedule that Stripe does not build.
A worked example: $120K commit, tiered overage
The kind of contract an AE closes every week, and what Stripe does with it on its own.
| Contract term | What Stripe does natively | What still has to happen |
|---|---|---|
| $120K annual commit, billed $10K monthly | Flat recurring price on the subscription | Track consumption against the commit across the year |
| Included usage: 12M events per year | Meter counts events per month | Annual allowance is not a monthly tier; the overage trigger is cumulative |
| Overage: $0.012 per event above the commit, negotiated down from $0.015 | Price bills the list rate unless a customer-specific price was created | Apply the negotiated rate from the contract, and only once cumulative usage crosses 12M |
| Shortfall true-up at term end | Nothing | Calculate unused commit and invoice it, or roll it per the contract |
| Revenue recognition | Recognizes each invoice as finalized | Estimate variable consideration on the overage, constrain it, recognize commit ratably or on usage per the contract |
Three of the five rows are spreadsheet work in most finance teams. All three are where under-billing hides.
The workflow that keeps Stripe invoices tied to the contract
Stripe stays the billing engine. A reconciliation layer reads the contract and checks the invoice before it goes out.
Keep metering in Stripe
Stripe Billing Meters remain the system that counts usage and generates the invoice. No migration, no parallel billing engine.
Read the signed contract
Ari extracts the rate card, tiers, minimum commitment, overage rate, credit grant, and term dates from the contract PDF attached to the closed-won deal in HubSpot or Salesforce.
Re-rate usage against the contract
Before the invoice finalizes, Ari pulls the period's usage (from Stripe, the product database, or both) and independently calculates what the invoice should be under the contract terms.
Reconcile and fix the invoice
Differences between Stripe's draft invoice and the contract calculation are flagged in Slack with the cause: wrong tier, missed minimum, late events, unapplied amendment. Approved corrections are applied in Stripe.
Recognize revenue from the reconciled result
The reconciled usage and contract terms feed an ASC 606 / IFRS 15 schedule, including commit shortfalls, credit drawdown, and breakage, synced to NetSuite or QuickBooks.
How LedgerUp runs this on top of Stripe
Ari reads the contract, re-rates usage against it every period, corrects the Stripe invoice with your approval in Slack, and builds the revenue schedule from the reconciled result. No migration off Stripe.
“Ari took a job we dreaded and turned it into something we don't even think about anymore. Billing just works now. And we found $72K we didn't know we were leaving on the table.”
- Varez, GTM Lead at HappyRobot
Related Guides
How metered billing works in general, the five pricing models, and the revenue recognition rules.
Prepaid credit packs, drawdown, expiry, breakage, and the deferred revenue journal entries.
The four-way match between product usage, contract, billing engine, and ledger.
Everything Ari runs on top of Stripe: contract to invoice, subscriptions, collections, reconciliation.
Stripe Usage-Based Billing FAQ
How does usage-based billing work in Stripe?
Stripe Billing uses meters to define what is counted and how it aggregates (sum, count, or last value). Your product sends meter events for each unit of consumption. A usage-based price attached to the meter converts aggregated usage into a charge (per unit, package, or tiered), and a subscription on that price bills in arrears: at the end of each billing period Stripe rates the usage and generates the invoice. Billing credits can be granted for prepaid drawdown and are applied to the usage lines.
What is the difference between Stripe meters and the old usage records?
Legacy usage records were reported against a specific subscription item, so usage had to be tied to a subscription at the moment it was reported. Billing Meters are defined once, receive events keyed by customer, and can be shared across prices and subscriptions. Meters also support aggregation formulas and event backdating within a limited window. New Stripe accounts should use meters; legacy usage records are on a deprecation path.
Can Stripe handle minimum commitments and overages?
Partly. You can model a flat recurring fee plus a usage-based price, and use tiered pricing to approximate an included allowance with overage rates. Stripe does not natively enforce an annual commitment with a shortfall true-up, apply contract-specific overage rates per customer, or roll unused commit forward. Those rules usually live in the contract and get calculated outside Stripe, which is where reconciliation is needed.
Does Stripe support prepaid credits for usage-based billing?
Yes. Stripe Billing credits let you grant a monetary credit balance to a customer that is applied against metered usage on invoices, with expiry dates and balance tracking. What Stripe does not do is produce the deferred revenue accounting for the prepayment, recognize revenue as credits are consumed, or handle breakage on expired credits. See the credits-based billing guide for the accounting side.
How do you recognize revenue for Stripe usage-based billing under ASC 606?
For pure pay-as-you-go with no commitment, recognizing each usage invoice as it finalizes generally aligns with the usage-based royalty and right-to-invoice practical expedients. Once a contract has a minimum commitment, prepaid credits, or tiered pricing that spans the term, you need to estimate variable consideration, apply the constraint, and allocate to performance obligations. Stripe Revenue Recognition works from Stripe objects, so the contract-level schedule has to come from a system that reads the contract.
What causes revenue leakage in Stripe usage-based billing?
The most common causes are contract terms that were never configured in the Stripe price (negotiated rates, custom tiers, minimums), meter events that were dropped or rejected and never re-sent, mid-period plan changes applied late or only in the CRM, and manual true-up calculations done in spreadsheets. None of these produce an error in Stripe. They produce invoices that are quietly lower than what the contract allows.
How does LedgerUp work with Stripe usage-based billing?
LedgerUp sits on top of Stripe rather than replacing it. Ari reads the signed contract, re-rates the period's usage against the contract terms, compares that to the Stripe invoice before it finalizes, flags and corrects discrepancies in Slack, and builds the ASC 606 / IFRS 15 revenue schedule from the reconciled result. Stripe keeps metering and invoicing; LedgerUp makes sure the invoice matches the deal and the revenue matches the invoice.