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.

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