Chargebee produces some of the richest subscription exports available, which is good news, and it carries one status value that reverses the meaning of a churn calculation if you take it at face value: non_renewing.
TL;DR: Chargebee's non_renewing status is the trap: economically churned, still counted as active. Here is which Chargebee objects to export and how to handle addons, item prices and paused subscriptions.
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.
Chargebee separates customers, subscriptions, plans or item prices, addons and invoices. The subscription references one plan and any number of addons, and critically the addon amounts are held separately from the plan amount. An export that captures only the plan price understates MRR for every account with an addon, which in a mature Chargebee account is often most of them. Chargebee also distinguishes the subscription's own currency from the site currency, so multi-currency books need explicit handling.
| Needed | Where it lives in Chargebee | Watch out for |
|---|---|---|
| Account identifier | Customer ID, distinct from subscription ID | Chargebee's model genuinely supports many subscriptions per customer. Aggregate. |
| Subscription status | active, in_trial, non_renewing, paused, cancelled, future | non_renewing means it will not renew. Economically gone, textually active. |
| Amount and currency | Plan unit amount × quantity, plus addon amounts, plus currency code | Missing addons is the most common Chargebee MRR error. |
| Billing interval and term | Billing period and billing period unit | Chargebee supports arbitrary periods, not just month and year. |
| Start date | Subscription started-at, and separately activated-at | Trials mean these differ. Use activated-at for paying tenure. |
| Cancellation or end date | Cancelled-at, plus cancel-scheduled-at for pending cancellations | Both matter; the second is your forward churn. |
| Last successful payment date | Derive from paid invoices for the subscription | Chargebee's invoice history makes this reliable, unlike most platforms. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
non_renewing is churn that has already happenedA non_renewing subscription is still serving and still counted in most active-subscription reports, but the customer has already decided to leave. It should be excluded from forward MRR and counted as churn in the period the decision was made, not the period the subscription finally ends. Treating it as active is the single largest source of overstated MRR in a Chargebee book.
MRR built from plan price alone can be materially below actual billing. Sum plan amount times quantity, then add every recurring addon at its own quantity. Non-recurring addons should be excluded entirely, which means you also need each addon's type.
A pause can be a retention save or a slow cancellation, and the data does not distinguish them. Count paused subscriptions and their revenue separately, look at how many resume historically, and ask whether pausing was offered as an alternative to cancelling — because if it was, the pause count is part of the churn figure.
Chargebee's newer product catalogue model uses items and item prices where older accounts used plans and addons. Exports differ accordingly. Confirm which catalogue version the account uses so you know whether you are missing a component.
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 subscriptions from Chargebee including cancelled, paused and non-renewing ones, for the full history, with customer ID, status, plan amount and quantity, all recurring addon amounts and quantities, currency, billing period and unit, started-at, activated-at, cancelled-at and any scheduled cancellation date. Please confirm whether the account uses plans and addons or the newer items and item prices catalogue.
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 Chargebee 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 Chargebee documentation: https://apidocs.chargebee.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 →
The subscription is still active and serving, but it is set not to renew at the end of the current term. Economically the customer has already churned; the revenue simply has not stopped yet. For any forward-looking MRR figure it should be excluded, and it should be counted as churn in the period the decision was made rather than the period service ends.
Almost always because addons were not included. Chargebee holds addon amounts separately from the plan amount, so an export or query that reads only the plan price understates every account carrying an addon. Sum plan amount times quantity plus each recurring addon, and exclude non-recurring addons.
It depends on whether pausing is offered as a retention alternative to cancelling, and on how many historically resume. Count them separately either way and ask the seller both questions. If pause was the save offer, the pause count belongs in the churn analysis rather than beside it.