Stripe cancel_at_period_end set but the customer was still invoiced

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

A cancellation that does not stop billing means one system heard it and another did not: the CRM closed, the subscription stayed active, or a duplicate subscription kept charging. Follow the cancellation timestamp across every billing record for the customer and kill the surviving charge source, then refund what posted after cancellation.

customer cancelled but still billed: dunning flow broken

Use this when

• A cancelled customer received a new invoice or card charge
• The product account may be closed while billing continues
• There may be duplicate subscriptions from a migration

Not for this skill when

• The charge is a final usage true-up permitted by the contract
• The customer cancelled one workspace but kept another active subscription

Steps

1. Pull every subscription, invoice, and payment record for the customer across billing and CRM. Verify: all billing objects and their statuses are listed
2. Compare the cancellation effective timestamp against each subscription's status history. Verify: the record that never cancelled is identified
3. Check for duplicates: same customer, multiple subscriptions, or a legacy plan still attached. Verify: any duplicate charge source is confirmed
4. Cancel the surviving subscription with the original effective date, and void or refund post-cancellation charges. Verify: no further charges can post and the customer is made whole
5. Add a daily cancelled-but-billable report joining cancellations to active subscriptions. Verify: future leaks surface in a day, not in a customer complaint

Variant phrasings

cancelled customer still charged

A related phrasing for the same underlying problem.

cancellation not synced to billing

A related phrasing for the same underlying problem.

duplicate subscription still billing

A related phrasing for the same underlying problem.

Compatibility: Compatibility: subscription billing platforms (Stripe Billing, Chargebee, Zuora) synced with CRM account status, current versions.

Why it happens

Cancellation is an event; billing is a state machine in another system. Events get lost at sync boundaries, and duplicate subscriptions created during migrations are invisible to single-record checks. Only a full object inventory per customer proves billing actually stopped.

Edge cases / pitfalls

• Refund speed matters more than root cause for the affected customer. Refund first, investigate second, and say so in the reply.
• Some charges are card-network retries of a pre-cancellation invoice. Check invoice dates before declaring a leak.
• Proration credits owed to the customer can look like charges in summary views. Read the invoice lines, not the totals.

Provenance

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

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

Thread query: customer cancelled but still billed: dunning flow broken

TL;DR: A cancellation that does not stop billing means one system heard it and another did not: the CRM closed, the subscription stayed active, or a duplicate subscription kept charging. Follow the cancellation timestamp across every billing record for the customer and kill the surviving charge source, then refund what posted after cancellation.

Not specified by the original author.

TL;DR

Post-cancel charges have three causes: the charge predates the cancellation (billing already ran), the customer canceled one subscription but has another, or the cancellation genuinely did not process. Check the cancel timestamp against the charge date first; that resolves most. Refund genuine errors immediately with an apology. Argue only with timestamps, never with policy quotes.

The query

I was charged after canceling: resolution steps

Use this when

• Customers report charges after canceling
• Billing dispute triage
• Writing refund runbooks
• Chargeback prevention

Not for

• Fraud investigations
• Chargeback representment
• Subscription policy design
• Dunning or collections

Steps

1. Compare the cancel timestamp to the charge date

Pull both. If the charge posted before the cancellation processed, that is the answer: the billing run beat the cancel by hours or days. Show the two timestamps. This resolves the majority.

Expected output: the two timestamps side by side.

2. Check for multiple subscriptions or accounts

The customer canceled subscription A; subscription B on another workspace or an old account kept billing. Search by email across accounts. This is the second most common cause.

Expected output: all subscriptions under the customer's email listed.

3. Verify the cancellation actually processed

If there is no cancel record and no timestamp, the cancellation did not go through: the button failed, the flow was abandoned, or it went to the wrong account. Treat it as a genuine error.

Expected output: cancel record found or confirmed missing.

4. Refund or explain with evidence

Genuine error: refund immediately, apologize, confirm in writing. Charge predates cancel: explain with the timestamps and offer goodwill if the gap was hours. Multiple subscriptions: cancel the stragglers and refund per policy.

Expected output: money movement or a timestamped explanation.

5. Prevent the repeat

If the cancel flow failed, file the bug. If the customer has duplicate accounts, merge or note them. Log the pattern: post-cancel charges are a churn-and-review accelerant.

Expected output: the root cause addressed, not just the ticket.

Template: the resolution reply

I looked into the charge, [Name]. Here is what I found:

[Case A - charge predates cancel:]
Your subscription was canceled on [date/time], and this charge posted on [earlier date/time], before the cancellation processed. So the charge is for the period before you canceled. I can see how the timing looks wrong, and I am sorry for the confusion. [Goodwill offer if appropriate.]

[Case B - genuine error:]
You are right: the cancellation did not process correctly on [date]. I have refunded [amount], which will arrive within [N] business days, and confirmed the subscription is now fully canceled. Sorry we put you through this.

[Case C - second subscription:]
You canceled [subscription A] on [date], but [subscription B] on [workspace] was still active and that is what billed. I have canceled it now [and refunded per policy].

Variant phrasings

billed after cancellation

Steps 1 and 2. Timestamps, then the multi-subscription check.

cancel did not stop the charge

Step 3. Verify the cancel record exists.

refund for charge after cancel

Step 4. Refund genuine errors immediately; explain timestamp cases.

Why it works

These tickets are timeline disputes plus money, which makes them emotionally charged. Timestamps settle them factually, and fast refunds on genuine errors convert the angriest tickets into the strongest recoveries. The multi-subscription check matters because "but I canceled" is true and the charge is also true.

Edge cases

• Annual plans canceled mid-term: the charge may be the annual renewal before cancel. Policy governs the refund; explain it plainly.
• The bank shows the charge late: pending vs posted dates confuse the timeline. Ask for the posted date.
• Trial converted then canceled: the conversion charge is legitimate if the trial terms were clear. Show the terms.
• Chargeback already filed: coordinate with finance. Do not refund and fight the chargeback simultaneously without a plan.

Provenance

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

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

Thread query: I was charged after canceling: resolution steps

TL;DR: Post-cancel charges have three causes: the charge predates the cancellation (billing already ran), the customer canceled one subscription but has another, or the cancellation genuinely did not process. Check the cancel timestamp against the charge date first; that resolves most. Refund genuine errors immediately with an apology. Argue only with timestamps, never with policy quotes.