GoCardless collects by bank debit rather than card, and that changes the retention arithmetic in a way worth understanding rather than normalising away. Mandates do not expire the way cards do, so involuntary churn is structurally lower, but failures take longer to resolve and the mandate can outlive the subscription it was created for.
TL;DR: Bank debit churns differently from cards: mandates outlive subscriptions, failures resolve on a longer cycle, and involuntary churn is lower. Here is how to read a GoCardless export.
Every churn calculation needs the same seven things: a stable customer identifier, subscription status, recurring amount and currency, billing interval and term, start date, cancellation or end date, and ideally the date of the last successful payment. (Why each one, and what breaks without it →) What changes between platforms is where those fields live and which status values mislead you.
The objects are customers, bank accounts, mandates, subscriptions and payments. A mandate is the standing authorisation to debit an account; a subscription is a schedule of payments drawn against it. Because a mandate persists independently, a cancelled subscription can leave an active mandate, and one mandate can support several subscriptions. That indirection is where most analytical mistakes come from.
| Needed | Where it lives in GoCardless | Watch out for |
|---|---|---|
| Account identifier | Customer ID, not the mandate ID | One customer can hold multiple mandates and subscriptions. |
| Subscription status | pending_customer_approval, active, finished, cancelled, paused | finished means a fixed-count schedule completed. Not churn. |
| Amount and currency | Subscription amount and currency | Multi-currency is common given GoCardless's geographic spread. |
| Billing interval and term | Interval unit and interval, plus count if the schedule is finite | A finite count means a scheduled ending. |
| Start date | Subscription start date, and mandate created-at | The mandate can predate the subscription. |
| Cancellation or end date | Subscription cancelled-at, plus mandate status | Check both: a cancelled subscription with a live mandate is a different situation from a cancelled mandate. |
| Last successful payment date | Most recent confirmed or paid-out payment | Bank debit settles more slowly than cards; allow for it. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
finished is not churnA subscription with a fixed number of payments moves to finished when the schedule completes. That is a planned ending, and counting it as churn makes retention look worse than it is. Identify finite schedules from the count field and report them separately.
A cancelled subscription on a live mandate means the relationship is intact and the schedule stopped, which is quite different from a cancelled mandate. Conversely, a failed or revoked mandate ends collection regardless of subscription status. Read both fields together or you will misclassify a meaningful share of endings.
Bank debit failures and their retries take longer than card dunning, so a payment that looks failed today may settle later. Any analysis run close to the present will overstate recent churn. Cut the analysis window back by at least one full settlement cycle before drawing conclusions about recent months.
Bank mandates do not expire the way cards do, which structurally reduces involuntary churn. That is a real advantage of the payment method and it means a GoCardless book's total churn is more voluntary — and therefore more product- and price-driven — than a card-based book with the same headline rate.
Vague requests produce filtered exports. This wording asks for the complete set in the platform's own vocabulary, which is what gets you a usable file first time:
Please export all GoCardless subscriptions in every status including cancelled, finished and paused, for the full history, with customer ID, mandate ID and mandate status, subscription status, amount, currency, interval unit and interval, payment count if the schedule is finite, start date, created-at and cancelled-at. Please also export the payment history including failed payments, so settlement timing and involuntary churn can be separated.
One check first, and it is the same on every platform: count the rows that carry a cancellation or end date. If none do across a multi-year GoCardless export, the file was filtered to active subscriptions and every churn figure you compute from it will come out at zero. That single defect causes more wrong churn numbers than every definitional argument put together, and it is fixed with one email rather than with analysis. The three further checks — row count, MRR reconciliation and history length — take another five minutes.
Once you have a clean export, the analysis is the same regardless of where it came from: recompute churn in both logo and revenue terms, build the renewal calendar, check concentration on parent entities rather than accounts, and test whatever the seller has claimed. The seller-claims pages cover the twelve claims worth testing and the arithmetic for each, and the 23-point checklist is the short version.
Official GoCardless documentation: https://developer.gocardless.com/. Export layouts change; the data model and the traps above do not.
All billing platforms → · Already integrated: Stripe, ChartMogul, ProfitWell, QuickBooks.
Every check on this page can be run by hand in a spreadsheet, and if you have the time you should. If you would rather not: send us the target's subscription export and we run the full human-reviewed analysis — logo churn, revenue churn, customer concentration, annual-plan decay, zombie MRR and an A–F revenue-quality grade. The free Starter tier covers one CSV per month, which is enough to check a single deal.
See a sample report → · Get the free 23-point checklist →
It reduces involuntary churn, because bank mandates do not expire the way payment cards do. That is a genuine structural advantage. It does not change voluntary churn, so a bank-debit book and a card book with the same headline churn rate actually have different underlying retention, with the bank-debit one carrying proportionally more real customer decisions.
That a subscription with a fixed number of payments completed its schedule. It is a planned ending rather than churn, and counting it as churn understates retention. Identify finite schedules from the payment-count field and report their endings separately.
Because bank debit failures and retries resolve over a longer cycle than card dunning, so payments that look failed in the most recent period may still settle. Trimming the analysis window back by at least one full settlement cycle avoids overstating churn in exactly the months people look at most closely.