Stripe Prebilling in QuickBooks: One Invoice, Many Months

A customer on a 100 USD per month plan signs up, and Stripe raises an invoice for 1,200 USD dated today. Nothing is wrong. They agreed to pay a year upfront, and Stripe did what it was told.

The problem starts one system later. That invoice reaches QuickBooks as a single invoice dated today, for 1,200 USD, and unless somebody intervenes it books 1,200 USD of income into this month. Eleven twelfths of that has not been earned. Your revenue for the month is overstated by 1,100 USD, your next eleven months are understated by 100 USD each, and every report built on top of them inherits the distortion.

This is Stripe prebilling. It was added to Stripe Billing in the 2026-05-27 Dahlia release, and because it produces ordinary invoices through an ordinary path, nothing in your sync is going to flag it for you.

Automate your Stripe to QuickBooks sync →

This post covers what prebilling actually does, what it puts in front of QuickBooks, and where the responsibility for the accounting sits.

What prebilling actually is

Prebilling lets you collect payment now for multiple future service periods. Stripe's own framing is worth reading literally: it bills customers in advance for periods that have not started, rather than waiting for each billing cycle to arrive.

It is configured through billing_schedules on the subscription, and it has two moving parts.

Which items get prebilled is controlled by applies_to, an array of price IDs. Pass it, and only those items are billed ahead. Omit it, and Stripe prebills every applicable licensed-price item on the subscription. That per-item scoping is more useful than it first sounds: you can prebill an annual platform fee while a monthly seat charge on the same subscription keeps billing monthly.

How far ahead is controlled by bill_until, expressed either as a duration (an interval and a count, so two months from now) or as a timestamp (a specific Unix time).

The result is one advance invoice covering all the specified future service periods, generated when the subscription is created or updated rather than at each cycle.

There is a companion field on the other side. Subscription items carry billed_until, which tells you where the prebilled period ends for that item. If you are ever trying to work out why a subscription that should have invoiced this month did not, that is the field to read.

When the invoice appears is a separate decision

This trips people up, because it is controlled by a parameter that appears to be about something else entirely.

proration_behavior decides the timing of the prebilling invoice:

• always_invoice generates and finalizes the prebilling invoice immediately, at the moment you create or update the subscription.
• create_prorations holds it until the next natural billing cycle date, so the advance charge appears alongside the customer's regular invoice.

Both are legitimate. They produce very different bookkeeping. Under always_invoice an invoice lands on a date no billing cycle explains, which is the classic support ticket that starts "why did this customer get billed today". Under create_prorations the advance amount is folded into a regular invoice, which is quieter but makes that invoice much larger than the plan price, for reasons the invoice date does nothing to explain.

Worth being precise about one thing prebilling does not do. It does not change when a service period starts, and it will not automatically raise an invoice a fixed number of days before a period begins. Stripe is explicit that billing an upcoming renewal early is something you trigger yourself: you update the subscription on the day you want to bill, set bill_until to the end of the period you want covered, and set proration_behavior to always_invoice.

What reaches QuickBooks

Nothing exotic. That is the whole difficulty.

A prebilling invoice is a Stripe invoice. When it is finalized, Acodei creates a matching QuickBooks Invoice that reproduces the line items and the tax lines, subject to your mapping settings. When the customer pays it, the charge belongs to an invoice Acodei has already synced, so it books a Payment Receipt applied to that QuickBooks invoice rather than a Sales Receipt, and the Stripe fee posts as a separate expense.

That is the same path any other invoice takes, which is documented in more depth in our use case on Stripe invoicing with A/R in QuickBooks. If you are not running invoice sync, a charge becomes a Sales Receipt instead, and the record routing rules decide which of the three record types you get.

So the sync does exactly what it should. The invoice arrives, the payment applies, the fee is booked, the clearing account balances. Reconciliation is clean.

And your income statement is still wrong, because reconciliation was never the question. A prebilling invoice is correct as a cash and receivables record and misleading as a revenue record, and no amount of correct syncing changes that.

The dating problem

QuickBooks dates an invoice on one date. A prebilled invoice covers many periods. Those two facts cannot both be satisfied by a single field, which is why the dating settings matter more here than almost anywhere else.

Acodei exposes several settings that decide which Stripe date lands where on the QuickBooks record. One copies the invoice date into the QuickBooks Service Date field, and it is mutually exclusive with the two supply-date settings. Those two work from Stripe's supply date, writing it either into the QuickBooks invoice date or into the service date alone. A fourth dates the invoice on the Stripe due date, and it is mutually exclusive with the supply-date setting, with the interface disabling one while the other is checked. A fifth uses Stripe's effective_at value where it is present, resolved by the same date helper as the supply-date and due-date options.

We covered the full set, and which financial statements each one moves, in the sync settings that change your books.

The honest limit is this. Those settings put a date on the record. A twelve-month prebilled invoice needs twelve periods, and one date field cannot express twelve periods no matter which date you put in it. The dating settings will tell you when service is deemed to start. They will not spread the revenue for you.

Deferral is an accounting decision, not a sync setting

Worth stating plainly, because the alternative is discovering it at year end.

Acodei syncs the invoices and charges that Stripe Billing produces. It does not run dunning, retries or proration on your behalf. What reaches QuickBooks is the invoice Stripe raised, mapped to the accounts you configured, and a deferral entry is not among the records it writes.

Recognising eleven twelfths of a prebilled invoice over the following eleven months is a journal entry, or a schedule, or a deferred revenue workflow inside QuickBooks. It belongs to whoever owns your close. If you are not sure how that should be structured, deferred revenue is the concept to start from, and it is worth reading alongside why Stripe's own revenue recognition reports never tie to QuickBooks. Stripe can tell you what deferral it thinks you have. It cannot post it to your ledger, and the two datasets are built from different events.

The practical version: if you turn on prebilling, tell your bookkeeper before the first invoice, not after the first month closes.

The limits that decide whether you can use it at all

Prebilling carries more constraints than most Stripe Billing features, and several of them will decide the question for you before any accounting discussion starts.

It requires flexible billing mode. Prebilling needs subscriptions with flexible billing mode enabled and API version 2026-05-27.dahlia or later. If you are on classic mode, this is not available, and the classic and flexible distinction is a per-subscription property rather than an account-wide switch.

Usage-based prices are never prebilled. Not by default, and not by configuration. Stripe excludes usage-based prices regardless of applies_to, and you cannot enable prebilling at all if every item on the subscription is usage-based. Setting applies_to[price] to a price with usage_type=metered is rejected. This makes sense once you say it out loud, since nobody can bill in advance for usage that has not been reported, but it means a hybrid subscription will produce a prebilled invoice for its licensed items and continue to invoice usage on the ordinary cycle. That is two invoice streams from one subscription, which is worth knowing before you go looking for the missing usage charge.

It is incompatible with subscription schedules. You cannot use prebilling with subscription schedules, or with subscriptions backed by one. There is a wrinkle worth recording: expired billing_schedules entries stay on the subscription, so if you later want to create a subscription schedule from it, you first have to update the subscription with an empty billing_schedules value to clear them.

There are hard ceilings. The total prebilled cycles across all items cannot exceed 50, so with two items you could prebill each for 25 months. Stripe also advises against setting the end date more than five years out. The end date has to be at least one full billing period from the start, and if it does not line up with the end of a billing period, the partial period before it gets prebilled and the remainder is billed separately.

Coupons are restricted. Only coupons with percent_off and a duration of once or forever work. Amount-off coupons, and coupons with duration=repeating, return an error against a subscription with billing_schedules configured. If discounting is part of how you sell annual prepayment, check this before you promise it. How discounts land on the QuickBooks side is a separate question with its own settings.

Two smaller ones. If a subscription is already scheduled for cancellation and you set a prebilling end date past that cancellation date, Stripe silently clamps the end date to the cancellation date. And payment_behavior cannot be set to pending_if_incomplete when updating a subscription that has an active billing schedule.

The early cancellation fee, which is the cleverest use of this

Buried in Stripe's documentation is a pattern that has nothing to do with prepayment and everything to do with contract enforcement.

A customer signs a one-year commitment at 10 USD per month, billed monthly, and cancels in September. You are owed October, November and December. Prebilling collects it: update the subscription with bill_until set to the end of the committed term and proration_behavior set to always_invoice, which generates and finalizes an invoice for the remaining term immediately, then cancel the subscription with prorate set to false.

The customer's final invoice carries October, November and December. Cancelling afterwards adds no further proration, because prorating was explicitly turned off.

In QuickBooks this arrives as one invoice covering three future months on a subscription that is about to end. Whether that is deferred revenue or a termination fee recognised immediately is a genuine accounting question rather than a sync question, and the answer depends on the contract. It is the sort of thing that should be decided once and written down, because it will recur.

What to check in your own account

If you suspect prebilling is running and nobody told the books:

1. Look for invoices larger than the plan price. A monthly subscription that produced a 1,200 USD invoice did not do that by accident.
2. Read billed_until on the subscription items. It tells you exactly how far ahead each item has been billed, which is the fastest way to confirm what you are looking at.
3. Check for subscriptions in flexible billing mode. Prebilling cannot exist without it, so classic-mode subscriptions can be ruled out immediately.
4. Look at the gap in the invoice sequence. Periods already covered by the prebilled invoice do not get invoiced again, and billed_until tells you where that window closes. A customer who invoiced monthly and then went quiet for eleven months is a prebilling signature, not a churn signal.
5. Reconcile the clearing account anyway. It will balance. That is the point: this is a revenue recognition problem wearing the clothes of a normal month.

Frequently asked questions

What is Stripe prebilling?

Prebilling is a Stripe Billing feature that collects payment now for multiple future service periods. It is configured with billing_schedules on a subscription, where applies_to names which price IDs to bill ahead and bill_until sets how far ahead to go. Stripe generates one advance invoice covering all the specified future periods rather than invoicing at each cycle.

Does a prebilled Stripe invoice sync to QuickBooks differently?

No, and that is the difficulty. A prebilling invoice is an ordinary Stripe invoice, so when it is finalized Acodei creates a matching QuickBooks Invoice reproducing the line items and tax lines according to your mapping, and the payment applies against that invoice. Nothing about the sync marks it as covering future periods.

Will prebilling defer the revenue for me in QuickBooks?

No. Acodei syncs the invoices and charges Stripe Billing produces, and a deferral entry is not among the records it writes. A prebilled invoice books its full amount on its invoice date unless you post a deferral entry or run a deferred revenue schedule in QuickBooks yourself.

Can I prebill a usage-based subscription?

No. Stripe never includes usage-based prices in prebilling, regardless of the applies_to configuration, and you cannot enable prebilling if all of the subscription's items use usage-based prices. On a mixed subscription the licensed items are prebilled and the usage items keep invoicing on their normal cycle.

Why did my prebilling invoice not appear immediately?

Almost certainly proration_behavior. Set to always_invoice, the prebilling invoice is generated and finalized straight away. Set to create_prorations, it waits for the next natural billing cycle date and appears alongside the customer's regular invoice.

How far ahead can I prebill?

The total prebilled cycles across all items cannot exceed 50, so two items could each be prebilled for 25 months. Stripe also advises against an end date more than five years in the future, and the end date must be at least one full billing period from the start of the period.

Does prebilling work with subscription schedules?

No. Prebilling cannot be used with subscription schedules or subscriptions backed by one. Expired billing_schedules entries also remain on the subscription, so you have to update it with an empty billing_schedules value before a subscription schedule can be created from it.

Which QuickBooks date does a prebilled invoice get?

Whichever your dating settings resolve to, and that is a single date. Acodei can copy the invoice date into the Service Date field, or work from Stripe's supply date, due date or effective_at value, and several of those options exclude each other. None of them spreads one invoice across several service periods, because a QuickBooks invoice carries one date.

Where this leaves you

Prebilling is a good feature. Collecting a year upfront improves cash flow, reduces churn and removes eleven payment failures from your year. The reason it deserves attention is not that it is risky, it is that it is invisible: it produces ordinary invoices through the ordinary path, and every system downstream treats them as ordinary.

The decision it forces is the same one every prepayment forces. Cash arrived early. Revenue did not. Somebody has to say which months the revenue belongs to, and that somebody is not going to be your sync tool.

Get the mechanics right and the rest is a normal close. Start a free trial to see how your Stripe invoices land in QuickBooks, or talk to us about your billing setup if prepayment is a large part of how you sell.