## 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.

```text
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