Zuora is built for complex enterprise contracts, and its data model reflects that: a subscription is a versioned object modified by amendments, with revenue held in rate plan charges rather than in a single price. The current subscription row tells you very little about how it got there, which is exactly what a churn analysis needs.
TL;DR: Zuora models amendments rather than simple subscription states, so the current row does not tell you what changed or when. Here is how to reconstruct history from rate plan charges and amendments.
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.
Accounts hold subscriptions; subscriptions hold rate plans; rate plans hold rate plan charges, which is where amounts, quantities and effective dates actually live. Changes are recorded as amendments that create new subscription versions, so a single commercial relationship spans multiple rows. Any analysis that reads only the latest version of each subscription will miss every upgrade, downgrade and partial cancellation in the history — which for an enterprise book is most of what matters.
| Needed | Where it lives in Zuora | Watch out for |
|---|---|---|
| Account identifier | Account ID, distinct from subscription number and subscription ID | Enterprise accounts routinely hold many subscriptions. |
| Subscription status | Draft, active, pending activation, pending acceptance, cancelled, expired, suspended | Status is per version. Read the latest version per subscription number. |
| Amount and currency | Sum of rate plan charge amounts × quantities, plus currency | There is no single subscription price. This is the biggest structural difference from other platforms. |
| Billing interval and term | Charge billing period, plus initial and renewal term on the subscription | Multi-year terms with annual billing are common. |
| Start date | Subscription start date and contract effective date | These differ and both are used in practice. Confirm which the seller means. |
| Cancellation or end date | Cancelled date, term end date, and any cancellation amendment | The amendment carries the intent; the term end carries the revenue stop. |
| Last successful payment date | Most recent paid invoice for the subscription | Enterprise collections are slower; do not read a lag as churn. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
A Zuora subscription has no single price field. Recurring revenue is the sum of its rate plan charges, each with its own amount, quantity, billing period and effective dates. Any export that omits charge-level rows cannot produce an MRR figure at all, and this is the most common reason a Zuora analysis has to be restarted.
Upgrades, downgrades, quantity changes and partial cancellations are all amendments creating new subscription versions. Reading only the current version gives you the end state with no path, so contraction becomes invisible and expansion looks like it was always there. Request amendment history explicitly.
Enterprise customers frequently cancel some rate plans while keeping others. That is contraction and it will not appear in any status-based churn measure, since the subscription remains active. On an enterprise book, contraction is often larger than outright churn.
Where subscriptions carry multi-year initial terms, several years can pass with almost no renewal events. Reported churn over that window describes a period in which leaving was largely unavailable. Build the renewal calendar over the full term structure rather than a twelve-month window.
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 Zuora subscriptions with full amendment history and all rate plan charges, for the full history, including account ID, subscription number and version, status, every rate plan charge with amount, quantity, billing period and effective start and end dates, currency, contract effective date, initial and renewal term, term end date and cancellation date. Charge-level rows and amendment history are both essential; a subscription-level export alone cannot produce MRR.
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 Zuora 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 Zuora documentation: https://developer.zuora.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 →
Because a Zuora subscription has no price field. Recurring revenue lives in rate plan charges, each with its own amount, quantity, billing period and effective dates. Without charge-level rows there is nothing to sum, which is why a subscription-level export is not enough to start.
Amendments are how Zuora records changes: upgrades, downgrades, quantity changes and partial cancellations each create a new subscription version. Reading only the current version gives the end state with no history, so contraction disappears entirely and expansion appears to have always been there. Amendment history has to be requested explicitly.
It does not appear in one at all, which is the problem. When a customer cancels some rate plans and keeps others, the subscription stays active and no status-based measure records anything. That is contraction, and on enterprise books it is frequently larger than outright logo churn.