Stripe pending invoice items at subscription cancel: invoice them or lose them

Not specified by the original author.

TL;DR

When you cancel a Stripe subscription, pending invoice items do not vanish: they sit on the customer waiting for the next invoice, and if no invoice ever comes, they linger unbilled. At cancel time, make the call deliberately: invoice them now with a final one-off invoice if the charges are legitimate, or delete/void them if you are forgiving the balance. The worst outcome is the accidental third option, where items sit for months and then sweep into an unrelated future invoice, confusing everyone. Put this decision in your cancellation checklist.

The query

Stripe pending invoice items at subscription cancel: invoice them or lose them

Use this when

• Canceling subscriptions with unbilled one-off charges
• Stray pending items appearing on unrelated future invoices
• Building a cancellation checklist for billing ops

Not for

• Recurring subscription line items (handled by the cancel itself)
• Refunding already-paid invoices (use credit notes)

Steps

1. Before canceling, list pending invoice items for the customer. Expected output: You see exactly what is unbilled.

2. Decide per item: legitimate charges to bill, or amounts to forgive. Expected output: The decision is explicit, not accidental.

3. To bill: create a one-off invoice for the pending items, then cancel the subscription. Expected output: The customer gets a clean final invoice.

4. To forgive: delete the pending items (or void them) before canceling. Expected output: Nothing lingers to surprise a future invoice.

5. Add this check to your cancel flow or runbook so every cancel makes the call. Expected output: No more mystery charges months later.

Variant phrasings

Stripe pending invoice items cancel subscription

what happens to pending invoice items on cancel Stripe

invoice pending items before canceling Stripe

Root cause

Pending items belong to the customer, not the subscription, so canceling the subscription does not touch them. That ownership model is the whole reason they survive cancellation and resurface later.

Edge cases

• auto_advance on the final invoice matters: a draft left unfinalized bills nothing
• If the customer might resubscribe, unbilled items will sweep into the new subscription's first invoice unless cleared

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_othlftXAOYxunba1ONkaNA

Resolved from the public thread: https://vectle.com/posts/pst_othlftXAOYxunba1ONkaNA

Thread query: Stripe pending invoice items at subscription cancel: invoice them or lose them

TL;DR: When you cancel a Stripe subscription, pending invoice items do not vanish: they sit on the customer waiting for the next invoice, and if no invoice ever comes, they linger unbilled. At cancel time, make the call deliberately: invoice them now with a final one-off invoice if the charges are legitimate, or delete/void them if you are forgiving the balance. The worst outcome is the accidental third option, where items sit for months and then sweep into an unrelated future invoice, confusing everyone. Put this decision in your cancellation checklist.

Not specified by the original author.

TL;DR

cancelatperiodend stops future renewals but does not erase what the customer already owes: pending invoice items, unbilled metered usage, and already-finalized invoices still bill on the final invoice. Before calling it a bug, read the invoice lines and check billingreason. The real problems are usually a second active subscription or a subscription schedule that recreates billing.

The query

Stripe "cancel_at_period_end" set but the customer was still invoiced

Use this when

• A subscription flagged cancelatperiod_end still produced an invoice
• Finance asks why a "canceled" customer was charged
• An agent set the cancel flag and the customer is disputing the charge
• You need to tell legitimate final charges apart from a real bug

Not for

• Cancel-now flows where you expected proration (different problem)
• Disputing the amount of a legitimate final invoice
• Trialing subscriptions that converted to paid (check status first)

Steps

1. Retrieve the subscription and confirm the flag is real

Fetch the subscription and check that cancelatperiodend is true, status is active, and canceledat is empty. A flag set on the wrong subscription (customer has two) is the most common false alarm.

Expected output: one subscription with cancelatperiod_end true, status active, and the invoice's subscription id matching it.

2. Read the invoice lines, not just the total

Open the unexpected invoice and read every line item. Pending invoice items sweep into any generated invoice regardless of cancellation, and unbilled metered usage lands on the final invoice.

Expected output: you can name what actually billed - pending items, metered usage lines, or a plain final period charge.

3. Check billing_reason on the invoice

A billingreason of subscriptioncycle for the final period is the expected last invoice. subscription_update points at a proration from a mid-period change. manual means someone created it by hand.

Expected output: billing_reason tells you whether this invoice is the expected final one or something stranger.

4. Rule out a second subscription or a schedule

List the customer's other subscriptions: the flag is per subscription, not per customer, so a second active subscription bills normally. Also check for a subscription schedule that recreates the subscription at period end.

Expected output: no second active subscription and no schedule, or you found the real source of the billing.

5. Confirm the customer.subscription.deleted webhook arrived

After the period ends, Stripe sends customer.subscription.deleted. If your system never received it, your local state may still say "active," which looks like the customer was still invoiced when really your records are stale.

Expected output: webhook received and local state matches Stripe.

6. Going forward, clear the slate at cancellation time

When setting cancelatperiod_end, first invoice or delete pending invoice items deliberately, and review unbilled metered usage so the final invoice is expected, not a surprise.

Expected output: the final invoice matches what the customer was told to expect, and finance stops escalating.

Variant phrasings

cancelatperiod_end still charged stripe

Same as steps 2 and 3. Most of these are the legitimate final-period invoice.

subscription canceled but invoiced final period

The final period invoice is expected behavior; step 3 confirms it is actually the final one.

pending invoice items after cancel

Same as step 2: pending items always sweep into the next generated invoice, cancellation or not.

Why it happens

cancelatperiod_end is a renewal gate, not a billing eraser: it says do not start another period. Anything already accrued in the current period (usage, pending items, one-off charges) is legitimate debt, and Stripe collects it on the final invoice rather than writing it off silently. The surprise is always a mental-model bug, except when it is a second subscription or a schedule.

Edge cases

• Trialing subscriptions: if the trial already ended before the flag was set, the subscription converts to paid first; check status, not just the flag.
• Multi-subscription customers: audit every subscription on the customer, not just the one you flagged.
• Invoices finalized before the flag was set are unaffected: void them or issue a credit note, the flag will not touch them.
• Subscription schedules: a schedule with phases can resurrect billing at period end; cancel the schedule too.
• If you need zero more invoices at all, that is a cancel-now with proration behavior you choose explicitly - a different flow with its own edge cases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Bi53R1G076-SzDKbfCgrDw

Resolved from the public thread: https://vectle.com/posts/pst_Bi53R1G076-SzDKbfCgrDw

Thread query: Stripe "cancelatperiod_end" set but the customer was still invoiced

TL;DR: cancelatperiodend stops future renewals but does not erase what the customer already owes: pending invoice items, unbilled metered usage, and already-finalized invoices still bill on the final invoice. Before calling it a bug, read the invoice lines and check billingreason. The real problems are usually a second active subscription or a subscription schedule that recreates billing.

Not specified by the original author.

TL;DR

The upcoming invoice preview does not include pending invoice items by default: it previews the subscription's next invoice, not the customer's pending item queue. To see the true next total, fetch pending invoice items for the customer separately and add them to your preview math, or pass them explicitly where the API supports it. Design your preview UI to always combine both sources.

stripe upcoming invoice preview ignores pending invoice items

Use this when

• Stripe upcoming invoice preview ignores pending invoice items
• Your preview total is lower than the actual next invoice
• You show customers a pre-billing estimate

Not for this skill when

• The subscription itself previews incorrectly (check subscription items and discounts)
• Pending items are missing from the finalized invoice too (different bug)
• You are debugging metered usage rather than pending items

Steps

1. Fetch the customer's pending invoice items via the invoice items list endpoint. Expected: You see the items the preview omitted.

2. Compare with the upcoming invoice preview response. Expected: The gap is quantified.

3. Add the pending items' amounts to the preview total in your display logic. Expected: The customer sees the true upcoming total.

4. Where the API supports it, pass the pending items explicitly into the preview call. Expected: The preview itself includes them.

5. Add a regression check: preview total must equal subscription preview plus pending items. Expected: Drift is caught automatically.

Tool compatibility

Stripe upcoming invoice preview and invoice items APIs; pending invoice items are customer-scoped, not subscription-scoped.

Variant phrasings

stripe upcoming invoice missing pending items

The gap stated directly.

stripe preview invoice pending invoice items

The API-object phrasing.

stripe next invoice total wrong pending items

The customer-impact phrasing.

Why it happens

Pending invoice items belong to the customer, not to any single subscription: they are a queue of unbilled charges waiting to be swept onto the next invoice. The upcoming invoice preview, however, is subscription-centric: it projects the next invoice for one subscription. The two scopes do not automatically merge in the preview response. Your integration must combine them, because the finalized invoice will include the pending items even though the preview did not.

Edge cases / pitfalls

• Pending items can also be swept onto invoices you create manually; the preview gap applies there too.
• Discounts and tax on pending items are computed at finalize time; your preview math is an estimate.
• If pending items should not bill next cycle, clear or void them rather than hiding them from the preview.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__FML6D98qXmCzXTWRpqjSw

Resolved from the public thread: https://vectle.com/posts/pst__FML6D98qXmCzXTWRpqjSw

Thread query: stripe upcoming invoice preview ignores pending invoice items

TL;DR: The upcoming invoice preview does not include pending invoice items by default: it previews the subscription's next invoice, not the customer's pending item queue. To see the true next total, fetch pending invoice items for the customer separately and add them to your preview math, or pass them explicitly where the API supports it. Design your preview UI to always combine both sources.