PayPal is the hardest common source to analyse, for a structural reason: many businesses using it for recurring payments never had a subscription object in the first place, only a series of transactions. Reconstructing subscriptions from transaction history is possible and lossy, and it is worth knowing in advance which parts are unrecoverable.
TL;DR: PayPal subscription records are the thinnest of any common billing source, and buyers are usually handed transaction lists instead. Here is how to reconstruct a subscription view and what you cannot recover.
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.
Modern PayPal Subscriptions has products, plans and subscriptions with proper statuses. But a large share of long-running PayPal recurring revenue predates that model or was implemented with older recurring-payment profiles or plain repeated billing agreements. In those cases there is no subscription object to export, and what you receive is an activity or transaction report. The two situations require completely different approaches, so establish which one you are in before requesting anything.
| Needed | Where it lives in PayPal | Watch out for |
|---|---|---|
| Account identifier | Payer ID or payer email from the subscription or transaction | Email is often the only stable link available. It changes, which is a real limitation. |
| Subscription status | APPROVAL_PENDING, ACTIVE, SUSPENDED, CANCELLED, EXPIRED | Only available if real subscription objects exist. Otherwise infer from payment gaps. |
| Amount and currency | Plan billing cycle amount, or the transaction amount | Transaction amounts are net of PayPal fees; plan amounts are gross. |
| Billing interval and term | Plan billing cycle frequency | If reconstructing, infer from the median gap between payments. |
| Start date | Subscription start time, or the first transaction date | The first-transaction proxy is usually reliable. |
| Cancellation or end date | Status update time, or inferred from payment cessation | This is the field most often unrecoverable. See below. |
| Last successful payment date | Most recent completed transaction | Always available, and it is what you build everything else on. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
Where there are no subscription objects, a cancellation is invisible: all you see is that payments stopped. The workable convention is to treat a payer as churned when their gap since the last payment exceeds roughly 1.5 billing intervals, and to state that convention explicitly in the analysis. It is defensible and it is an estimate, and the difference matters when the number is being used to set a price.
Building revenue from transaction records gives a figure net of PayPal's fees, while a plan-based figure is gross. Decide which basis you are using, apply it throughout, and note it. Mixing the two within one analysis is the most common error on PayPal data.
PayPal recurring payments fail for expired funding sources and revoked billing agreements, and those failures often look identical to voluntary cancellation. A book with high involuntary churn is more recoverable than one with high voluntary churn, and on PayPal data alone you frequently cannot distinguish them. Say so rather than assuming.
PayPal handles refunds and disputes in their own records rather than as adjustments on the original transaction. A revenue figure built from completed payments alone is gross of both. Request them explicitly.
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 confirm first whether recurring revenue runs through PayPal Subscriptions with actual subscription objects, or through older recurring-payment profiles or repeated billing agreements. If subscriptions exist, please export all of them in every status with payer ID, plan, amount, currency, billing cycle, start time and status update time. If they do not, please export the full completed-transaction history with payer ID or email, amount, currency and date, plus refunds and disputes separately.
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 PayPal 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 PayPal documentation: https://developer.paypal.com/docs/subscriptions/. 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 →
Yes, with a stated convention and a wider error bar than any other source. If real subscription objects exist you can read statuses directly. If not, churn has to be inferred from payments stopping, typically treating a gap of more than about 1.5 billing intervals as churn. Either way, write the convention into the analysis, because it is an estimate.
Because much long-running PayPal recurring revenue was implemented without subscription objects at all, so there is nothing to export except transactions. Cancellation dates, plan changes and the distinction between voluntary and involuntary churn are all absent from a transaction list, and no amount of care recovers information that was never recorded.
Net of PayPal's fees. Plan amounts, where they exist, are gross. Pick one basis for the whole analysis and state which, because mixing gross plan amounts with net transaction amounts is the most common error made on PayPal data.