Recurly has the most consequential vocabulary trap of any major billing platform. A canceled subscription is still active and still serving until its term ends. The state that means actually gone is expired. Analyse Recurly with the intuitive reading of those words and your churn rate is wrong in both directions at once.
TL;DR: In Recurly, canceled does not mean gone — expired does. Getting that backwards inverts a churn rate. Here is the state model, the export you need, and how to handle add-ons and trials.
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.
Recurly models accounts, subscriptions, plans, add-ons and invoices. A subscription belongs to an account, references a plan, and can carry add-ons whose amounts are separate from the plan's unit amount. The state machine is the important part: future, active, canceled, expired, paused and failed, where canceled is a subscription that will not renew but has not yet reached the end of its paid term.
| Needed | Where it lives in Recurly | Watch out for |
|---|---|---|
| Account identifier | Account code or account ID, not the subscription UUID | Recurly accounts can hold multiple concurrent subscriptions. |
| Subscription status | future, active, canceled, expired, paused, failed | canceled is still serving. expired is gone. This is the whole game. |
| Amount and currency | Plan unit amount × quantity, plus add-on amounts, plus currency | Add-ons are separate objects with their own quantities. |
| Billing interval and term | Plan interval unit and interval length | Recurly supports multi-month terms that are neither monthly nor annual. |
| Start date | Activated-at, and separately trial-started-at / trial-ends-at | Use activated-at for paying tenure, not created-at. |
| Cancellation or end date | Canceled-at (decision date) and expires-at (service end date) | Two different dates with two different meanings. You need both. |
| Last successful payment date | Derive from the subscription's paid invoices | Also check for subscriptions in a failed or dunning state. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
canceled versus expired inverts the answerCounting canceled as churn overstates churn in the current period, because those subscriptions are still paying until they expire. Counting only expired as churn understates forward churn, because it ignores every customer who has already decided to leave. The correct treatment uses both: canceled_at as the churn decision date for cohort analysis, and expires_at as the revenue stop date for MRR. Report the decision date, because it is the one that tells you what is happening now.
As in Chargebee, an MRR figure built from plan amounts alone understates any account with add-ons. Recurly add-ons carry their own quantities, so you need amount and quantity for each rather than a single add-on total.
Subscriptions in trial are active and paying nothing. Filter them out of the churn denominator or the rate is diluted directly. Recurly gives you trial start and end dates, so this is straightforward once you remember to do it.
Recurly's pause holds the subscription without advancing the billing cycle. For a buyer, paused revenue is neither present nor definitively lost. Count it separately and ask for the historical resume 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 Recurly subscriptions in every state including canceled, expired, paused and failed, for the full history, with account code, state, plan code, plan unit amount and quantity, all add-on codes with amounts and quantities, currency, interval unit and length, activated-at, trial start and end, canceled-at and expires-at. The distinction between canceled-at and expires-at matters, so please include both columns.
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 Recurly 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 Recurly documentation: https://recurly.com/developers/. 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 →
A canceled Recurly subscription will not renew but is still active and still serving until the end of its paid term. An expired subscription has actually ended. The intuitive reading of those two words is backwards, and getting it wrong inverts a churn rate — so use canceled-at as the churn decision date and expires-at as the revenue stop date.
The cancellation date, because that is when the customer decided to leave and it is what tells you about the current period. The expiry date is what you use for MRR, since revenue continues until then. Reporting only expiry dates lags reality by up to a full billing term.
Yes. Add-ons are separate objects with their own amounts and quantities, so a figure built from plan unit amounts alone understates any account carrying one. Sum plan amount times quantity plus each add-on amount times its own quantity.