Stripe Prebilling: Charge Multiple Periods Upfront Without Switching to Annual
Stripe now lets you bill any subscription upfront for future periods, at the item level, without converting it to an annual plan. Here's how it works.
For years, if you wanted to collect more than one period of payment upfront from a subscriber, you had exactly one clean option: move them onto an annual Price and eat the commitment tradeoff that comes with it. Anything short of a full year meant hand-rolled invoicing, custom proration logic, or just not doing it. Stripe closed that gap with prebilling — a native way to bill any subscription ahead of time, for any window you choose, without touching the subscription's actual billing interval.
Prebilling itself entered public preview on Stripe in September 2025, then got materially more flexible in May 2026 when Stripe added billing_schedules support, letting you prebill specific items rather than an entire subscription. Combined with the Metronome acquisition, it's clear which direction Stripe is pushing: billing infrastructure that separates how long you commit from how far ahead you pay. That distinction matters more for churn than it sounds like it should.
What prebilling actually does
A normal Stripe subscription bills one period at a time — charge, wait, charge again. Prebilling changes that by letting you generate an invoice today that covers several future periods in one shot. You configure it through a billing_schedules object on the subscription:
bill_untilsets how far ahead to prebill — a specific date, or a number of periodsapplies_tospecifies which prices on the subscription get prebilled — you don't have to prebill everything- each affected subscription item exposes a
billed_untilproperty so you can see exactly when its prepaid window runs out
The subscription's underlying interval doesn't change. A monthly subscription prebilled for six months is still, structurally, a monthly subscription — it just won't generate another invoice until the prepaid window is up. That's the core difference from an annual plan, and it's why prebilling is worth understanding even if you already offer annual billing.
| Approach | What actually changes | Commitment implied |
|---|---|---|
| Standard monthly billing | Nothing — one invoice per period | None, cancel anytime |
| Switch to annual Price | Subscription interval changes to yearly | Full year, until you build a downgrade path |
| Prebilling | Payment collected ahead of schedule; interval stays the same | Whatever window you set — a quarter, a half year, anything |
Why fewer billing events means fewer chances to churn
We've written before about why annual subscribers churn at roughly a third the rate of monthly ones — every renewal charge is a decision point, and a monthly subscriber faces twelve of them a year against an annual subscriber's one. Prebilling gives you a version of that same mechanism without asking anyone to sign a yearly contract. A subscriber prebilled for a quarter still only has four decision points a year instead of twelve, even though they could cancel with 30 days' notice like any other monthly customer.
Source: derived from Stripe's billing_schedules / bill_until configuration options — each bar is a count of invoices generated per year, not a survey figure.
Every one of those billing events is also a dunning event. A quarterly prebill doesn't just cut cancellation opportunities to a third — it cuts the number of times a card can fail to a third too, which is the same math we cover in our Stripe dunning guide from the opposite direction. Fewer charges means fewer soft declines, which means less involuntary churn riding along on top of whatever voluntary churn you're already fighting in your cancellation flow.
The part annual billing can't do: item-level prebilling
Annual Prices are all-or-nothing — every line item on the subscription moves to the yearly interval together. Prebilling's applies_to parameter breaks that constraint. You can prebill the flat platform fee on a subscription six months out while leaving a metered usage line billed as it's actually consumed. That combination is exactly the shape of pricing that AI and infrastructure products have been converging on: a prepaid base plus consumption on top, rather than a single flat number.
This is also the same mechanism behind Stripe's credits-based billing model, where a customer prepays a balance that gets drawn down per API call, GPU-second, or generation, with every transaction logged to an auditable balance-transaction ledger. Metronome, the usage-metering platform Stripe acquired for roughly $1 billion, was built specifically to handle this pattern at the volume OpenAI, Anthropic, and similar companies need — millions of usage events a second against prepaid balances. Prebilling is the primitive that makes the "prepay the base, meter the rest" version of that pattern available on a standard Stripe subscription, not just a custom metering platform.
For a straightforward SaaS product without usage-based pricing, the practical takeaway is smaller but still real: you can offer a "prepay a quarter, save a bit" option to subscribers who won't commit to a full year, without building a second product tier or a separate annual Price just to capture that one behavior.
Where prebilling runs into limits
A few constraints worth knowing before you build against it. Prebilling requires the subscription to use Stripe's flexible billing mode, and it requires proration to be enabled — you can't set proration_behavior to none on a prebilled subscription. It isn't available on subscription schedules, or on subscriptions backed by one, so if your upgrade/downgrade logic runs through schedules today, you'll need a separate path for prebilled accounts. Coupons are restricted too — only percent_off discounts with a duration of once or forever are supported, so a "20% off your first 3 months" style coupon with a fixed duration count won't apply cleanly to a prebilled invoice.
The messier edge case is refunds. If a customer cancels partway through a prebilled window, you choose how to handle the unused portion — a prorated refund, a full refund of the last payment, or none at all, the same three options you'd have on any mid-cycle cancellation. But if you do refund a prebilled invoice, there's currently no clean way to remove that prebilling period from the subscription afterward, even after releasing the underlying billing schedule. If your cancellation flow issues automatic refunds, test this specific path in Stripe's sandbox before it touches a live prebilled account.
Implementing it
The basic shape, once a subscription is already on flexible billing mode:
- Create or update the subscription with a
billing_schedulesentry specifyingbill_until(a date or period count) andapplies_to(which prices to include) - Stripe generates a single invoice covering the prebilled window at the next billing cycle
- Check
billed_untilon each subscription item to know exactly when that item's prepaid coverage ends - When the prebilled window lapses, the subscription reverts to billing one period at a time unless you configure another prebilling window
Surface billed_until somewhere the customer can see it — a billing page, an account settings panel, an email receipt. A subscriber who prepaid six months and has no visibility into how much runway is left is a subscriber who's more likely to be surprised by the next charge, and a surprised subscriber is exactly the profile that files a dispute instead of just cancelling. We cover that failure mode in more depth in our piece on Stripe chargebacks and disputes — prebilling reduces charge frequency, but a charge nobody was expecting is still a charge somebody might dispute.
What this means for your cancellation flow
A prebilled subscriber cancelling with four months of prepaid runway left is a fundamentally different situation than a monthly subscriber cancelling with nothing banked. They've already paid you; the only question is whether they stay engaged enough to renew what they've prepaid, or ask for the unused balance back. That's a save-rate opportunity most generic cancel flows miss entirely, because they're built around a single "you'll lose access on your renewal date" message that doesn't account for prepaid time already sitting on the account.
If you're tracking how prebilled or annual accounts affect your blended churn number versus straight monthly, our churn calculator is a fast way to separate the two rather than lumping them into one rate. CancelFlow can already read a subscriber's remaining prepaid balance and billing cadence at the moment they hit cancel, which means the offer a prebilled customer sees — pause the remaining balance instead of refunding it, say — can reflect what's actually at stake instead of treating every cancellation the same regardless of how much has already been paid.
Frequently asked questions
What is prebilling in Stripe?+
Prebilling is a Stripe Billing feature that lets you charge a subscriber upfront for multiple future billing periods on a single invoice, instead of billing one period at a time. You configure it with billing_schedules on a subscription, set bill_until to define how far ahead to bill, and optionally use applies_to to prebill only specific items rather than the whole subscription. It requires the subscription to use flexible billing mode.
How is prebilling different from just switching a subscriber to an annual plan?+
Switching to annual means creating a new Price with interval: "year" and moving the subscription onto it permanently — the subscriber is now on a yearly contract. Prebilling keeps the subscription's underlying interval untouched (it can stay monthly) and simply collects payment for several upcoming cycles at once, tracked via the billed_until property on each subscription item. You can prebill three months, six months, or any window you choose, and the subscriber reverts to normal per-period billing once the prebilled window runs out.
Can you use Stripe prebilling with usage-based or metered billing?+
Yes, and this is one of its more useful applications. Because prebilling applies at the item level, you can prebill the flat or platform-fee line of a subscription while leaving metered or usage-based items billed as they're incurred. This is the same mechanism behind Stripe's credits-based billing for usage-heavy products — customers prepay a balance, usage draws down against it, and every transaction is recorded in an auditable ledger.
What happens to an unused prebilled balance if a customer cancels?+
Stripe doesn't auto-refund it — that decision is yours. When you cancel a subscription with an active prebilled period, you can issue a prorated refund for the unused portion, refund the most recent payment in full, or provide no refund at all, the same three options available on any mid-cycle cancellation. One thing worth knowing before you rely on this: if a prebilled invoice gets refunded, there's currently no clean way to remove that prebilling period from the subscription afterward, even after releasing the underlying billing schedule — worth testing in a sandbox before you put refund logic into production.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →