Stripe Mixed Interval Subscriptions in QuickBooks

A customer signs up for your annual platform fee and your monthly usage plan. One customer, one relationship, one card on file. For years Stripe made you model that as two subscriptions, because every item on a subscription had to share a billing interval. Flexible billing mode dropped the restriction, and now both prices can sit on one subscription.

The billing side of that is tidy. The accounting side has a trap in it, and the trap is that a single invoice can now carry a line covering one month and a line covering one year, while the invoice itself is dated a single day and reports a period of no length at all.

If your deferral schedule reads the invoice, it will recognise a year of revenue in a month. Nothing errors, nothing reconciles wrong, and the cash agrees. Only the timing is broken, and it is broken by exactly the amount you were trying to defer.

Start a free trial if you want Stripe invoices reaching QuickBooks without hand-keying them. The rest of this post is about which numbers to read once they arrive.

The subscription no longer has a billing period

The first thing to unlearn is that a subscription has a cycle.

On a mixed interval subscription, Stripe moved the billing period down onto the items. Its documentation states that "each subscription item has its own current_period_start and current_period_end", and that subscription items "track their respective billing periods directly instead of as a top-level shared billing period on the subscription resource."

The subscription still reports a period, but it is computed from the items rather than owned by them. Stripe's own example is a subscription created on 1 January with a monthly, a bimonthly and a quarterly item:

	Period start	Period end
Monthly item	1 January	1 February
Bimonthly item	1 January	1 March
Quarterly item	1 January	1 April
Subscription	1 January	1 February

After the 1 February renewal, Stripe says "the subscription's current period adjusts to match the latest current_period_start and earliest current_period_end of all the items." The monthly item moves to 1 February through 1 March. The other two do not move. The subscription now reads 1 February to 1 March, tracking the item that renews soonest.

Cycle once more and the subscription reads 1 March to 1 April while the quarterly item is still sitting in the period that started on 1 January, two subscription cycles ago.

So when a report or a script reaches for the subscription's period, it gets a window over the shortest item. That is a useful number for answering "when does something next happen". It is the wrong number for answering "what period did this revenue cover", and on a mixed interval subscription those two questions have stopped having the same answer.

The invoice period is not the service period, and Stripe says so

Here is the part that decides whether your accrual is right.

Take Stripe's two-item example: a 15 USD monthly price and a 100 USD quarterly price, both starting 1 January. The invoice Stripe generates that day carries both lines, and in Stripe's published response the numbers look like this:

Line 1, "1 × Monthly Price (at $15.00 / month)", period 1 January to 1 February.
Line 2, "1 × Quarterly Price (at $100.00 every 3 months)", period 1 January to 1 April.
Invoice period_start: 1 January. Invoice period_end: 1 January.

The invoice header describes a period of zero length. That is not a defect and it is not an edge case. Stripe defines those fields as bookkeeping about the document rather than about the service. In the invoice object reference, period_end is "the latest timestamp at which invoice items can be associated with this invoice", and period_start is the earliest such timestamp. Both descriptions then end with the same instruction: "Use the line item period to get the service period for each price."

The line-level field is the one that means what you want it to mean. Stripe documents the invoice line item period as "the period this line_item covers. For subscription line items, this is the subscription period." It adds one sentence that should settle any argument about which field is authoritative: if you have Stripe Revenue Recognition enabled, "the period will be used to recognize and defer revenue."

Stripe's own revenue engine reads the line period. Your schedule should read the same field.

What it costs to read the wrong one

Run the 115 USD invoice through both methods on a monthly accrual.

Defer by line period, which is correct:

Month	Monthly item	Quarterly item	Recognised
January	15.00	33.33	48.33
February	15.00	33.33	48.33
March	15.00	33.34	48.34

Defer by the invoice, which is what an invoice-date schedule does with a header period of zero length:

Month	Recognised
January	115.00
February	15.00
March	15.00

January is overstated by 66.67 USD and the two months after it are understated by 33.33 and 33.34. The full-year totals agree, which is precisely why nobody catches it: the annual number is right, the quarterly numbers are not, and the difference only surfaces if somebody compares a monthly revenue report to a contract.

One customer at 66.67 USD a quarter is a rounding error. Two hundred customers on the same plan is 13,334 USD of revenue sitting in the wrong month, every quarter, in a set of books that balances.

One subscription, a changing number of documents

The second surprise is structural rather than numerical, and it changes what reconciliation looks like.

Stripe states the rule in its mixed interval subscriptions guide: it "generates a single, combined invoice when item-level billing periods align and separate invoices when billing periods diverge."

Alignment is not a setting you choose. It is whether two clocks happen to strike on the same date. Follow the 15 USD monthly and 100 USD quarterly subscription through a quarter:

1 January. Both items start. One invoice, two lines, 115 USD.
1 February. Only the monthly item renews. One invoice, one line, 15 USD.
1 March. Same again. 15 USD.
1 April. The clocks meet. Stripe's documentation says this renewal "creates an invoice for both the monthly and quarterly item." One invoice, two lines, 115 USD.

Over a year that subscription emits twelve invoices, four carrying two lines and eight carrying one. The customer signed one contract and never changed it.

For anyone reconciling, two habits break at once. "One invoice per customer per month" stops being true of the amount, since the customer owes 115 USD in four months and 15 USD in eight. And a customer statement that used to show a steady monthly figure now shows a sawtooth, with no change in the underlying agreement to point at when the customer asks.

Neither is a problem to solve. Both are things to know before somebody flags the April invoice as a duplicate charge.

What actually lands in QuickBooks

Acodei's product documentation has no page on subscriptions, subscription items or billing intervals, and nothing in it describes reading an interval. That sounds like a gap and mostly is not, because on a mixed interval subscription the invoices carry everything anyway.

What is documented is the invoice lifecycle. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice that reproduces every line item, and tax lines, as your mapping settings allow. When it is paid, by a successful charge, by a manual payment per your settings, or by a credit balance offset, a QuickBooks Payment Receipt or Credit Memo follows and is applied to the invoice created earlier. Each line takes the product returned by Multiple Product Mapping when that is enabled, and the default product otherwise, so the monthly line and the quarterly line can map to different QuickBooks products.

Put that against Stripe's invoicing behaviour and the shape falls out without guessing. Stripe decides how many invoices exist and which lines sit on each one. The documented Acodei trigger is the finalized invoice, one QuickBooks Invoice each, with the documented exception of an invoice whose line items are all zero, which is not synced. So the eight-and-four pattern above arrives in QuickBooks as eight one-line invoices and four two-line invoices.

The honest boundary is the service period. Nothing in Acodei's documentation describes a destination for a per-line service period. The nearest documented settings are three mutually exclusive Service and Supply Date toggles, which are Admin-level, off by default, and described in terms of the invoice date and the Stripe supply date rather than the line period.

That matters here more than it does on an ordinary subscription, because an ordinary subscription's lines all cover the same window and the distinction never bites. On a mixed interval subscription it does. So before you build a deferral process on top of the synced records, open one synced invoice in your own QuickBooks file and look at what the date fields actually contain. That is a two-minute check and it is worth more than any assumption, including the ones in this post.

If you want the line quantities to survive the trip as well, Quantity Tracking is the setting that decides it. Acodei documents it as pushing Stripe quantities instead of a hard-coded 1 per line, off by default, unavailable with inclusive tax, and requiring backend enablement.

Building the schedule when the field is not there

Say the dates in QuickBooks do not carry the line period, which is the conservative assumption until you have checked. You can still build a correct deferral, because the data exists on the Stripe side and the invoice number joins the two.

The recipe is unglamorous and takes about an hour once:

Pull the invoice's lines.data from Stripe and read period.start and period.end on each line. Not the invoice's period_start.
Group the lines by period length. On a mixed interval subscription these will genuinely differ, which is your signal that the invoice needs splitting rather than a single schedule.
Post the short-period lines to revenue in the month they cover, and the long-period lines to deferred revenue, releasing on the line's own schedule.
Reconcile the sum back to the QuickBooks invoice total, which should match to the cent.

The last step is the one that catches mistakes, because the total is the number both systems agree on. If your monthly release amounts do not sum back to the document, the split is wrong, not the invoice.

For the general accrual mechanics under this, our post on Stripe revenue recognition in QuickBooks covers which dataset to build the books on, and the deferred revenue entry covers the liability side.

The failure on the small item takes the large one with it

One more consequence, and it is the one with the largest number attached.

Dunning is not per item. Stripe states that "if all retries for a payment fail, even if the failing payment is for an invoice related to only one of the items on the subscription", it "cancels the entire subscription and marks it as unpaid or past due, depending on your configured dunning settings."

So an expired card on the 15 USD monthly line can cancel the subscription carrying the 100 USD quarterly commitment. Cancellation behaves the same way: "canceling a mixed interval subscription or schedule cancels all the subscription items, regardless of their interval."

In the books this shows up as an absence rather than an event. The invoices already synced stay where they are. What stops is the next one. A quarterly item that should have invoiced in April simply does not, and unless somebody is watching subscription counts rather than invoice counts, the first sign is a revenue line that came in light with no bad debt to point at.

The related trap sits on cancellation dates. Stripe notes that the deprecated cancel_at_period_end "can't detect which subscription item's current_period_end to use as the cancellation date" and "defaults to the earliest item period end". Cancel a mixed interval subscription with the old parameter and you may end it at the monthly item's boundary while the customer has paid through the quarter. Stripe's replacement is cancel_at with min_period_end, max_period_end, max_billed_until, or an explicit timestamp, and those three names are worth reading as three different refund conversations.

Before you sell the pricing model

Two constraints to check before anyone promises a customer a combination.

The intervals have to be multiples. Stripe requires that "every item's price interval (the combination of price.recurring.interval and price.recurring.interval_count) must be a multiple of the shortest price interval in the subscription", and says plainly that "some price interval combinations aren't supported."

It treats 1 week and 7 days as equivalent, and 12 months and 1 year as equivalent. Supported combinations it lists include 1 month with 3 months, 1 month with 1 year, and 2 months with 4 months and 6 months. The rejections are the ones that catch people out: there are no equivalences between week and month, week and year, day and month, or day and year, and it lists 2 months with 3 months, 4 months with 6 months, and 5 months with 1 year as unsupported. A weekly add-on cannot sit on a monthly subscription, however natural it sounds in a pricing meeting.

And the move is one way. Mixed interval subscriptions require flexible billing mode, and Stripe's comparison of the two billing modes states that "you can't migrate a subscription from flexible billing mode to classic billing mode." Classic does not support mixed intervals at all: "all items in a subscription must have prices with the same interval and interval count." Flexible also raises the item ceiling from 20 to 100.

Two surfaces still do not support it. You "currently can't create mixed interval subscriptions on Checkout Sessions", and you "can't apply a retention coupon on mixed interval subscriptions through the customer portal." If your signup flow is Checkout, the pricing model needs an API path before it needs an accounting policy.

Frequently asked questions

What is a mixed interval subscription in Stripe?

It is one Stripe subscription carrying items whose prices have different recurring intervals, such as a monthly price and an annual price together. Stripe supports it only in flexible billing mode. Each item keeps its own billing period, and Stripe generates invoices against the item periods rather than one shared cycle.

Why does my Stripe invoice period start and end on the same day?

Because the invoice-level period is not a service period. Stripe defines period_start and period_end as the earliest and latest timestamps at which invoice items can be associated with the invoice, and on a mixed interval subscription's first invoice both can be the creation date. Stripe's documentation directs you to use the line item period to get the service period for each price.

Which date should I use to defer revenue from a Stripe invoice?

The line item period. Stripe documents that field as the period the line covers, and states that Stripe Revenue Recognition uses it to recognise and defer revenue when enabled. Deferring by invoice date on a mixed interval subscription recognises a long line's full amount in the month the invoice was issued.

Does a mixed interval subscription send one invoice or several to QuickBooks?

Both, depending on the month. Stripe issues a single combined invoice when the item periods align and separate invoices when they diverge. Acodei's documented behaviour is one QuickBooks Invoice per finalized Stripe invoice, reproducing every line item as your mapping settings allow, so QuickBooks receives whatever shape Stripe chose to issue.

Does Acodei write the per-line service period into QuickBooks?

Nothing in Acodei's product documentation describes a destination for a per-line service period. The documented settings nearest to it are three mutually exclusive Service and Supply Date toggles, which are off by default and described in terms of the invoice date and the Stripe supply date. Open one synced invoice in your own file and check the date fields before building a process on the answer.

Can I put a weekly item and a monthly item on the same subscription?

No. Stripe requires every item interval to be a multiple of the shortest interval on the subscription and states there are no equivalences between week and month, week and year, day and month, or day and year. It also lists 2 months with 3 months and 4 months with 6 months as unsupported combinations, since neither is a multiple of the other.

What happens if the card fails on only one item?

The whole subscription is affected. Stripe cancels the entire subscription and marks it unpaid or past due when all retries fail, even where the failing payment relates to an invoice for a single item. A failure on a small monthly add-on can therefore end the subscription carrying a much larger annual commitment.

Can I move a mixed interval subscription back to classic billing mode?

No. Stripe states that you cannot migrate a subscription from flexible billing mode to classic billing mode. Since mixed intervals require flexible mode, putting two intervals on one subscription is a one-way decision for that subscription.

The point

Mixed interval subscriptions are a billing feature with an accounting consequence, and the consequence is small enough to miss and large enough to matter. One invoice can describe two different lengths of time. The field that says how long is one level below the field most schedules read. And the number of documents a single subscription produces now depends on arithmetic rather than on anything the customer did.

None of that needs a new process. It needs your deferral schedule pointed at lines.data[].period instead of the invoice, and somebody who knows why April's invoice is bigger.

Acodei syncs the invoices Stripe produces into QuickBooks Online, reproducing the line items and the tax lines your mapping allows, and recording the payment against the invoice when it settles. Which month the revenue belongs to is still your call, and now you know which field to make it from. Start a free trial.