Braintree is a payment gateway that happens to offer recurring billing, not a subscription management platform. That has one advantage for a buyer: there is no dashboard MRR figure to reconcile against, so nobody has already made definitional choices for you. Everything has to be assembled, which means you get to make those choices yourself.
TL;DR: Braintree is a gateway, not a subscription analytics platform, so there is no MRR figure to disagree with. Here is how to assemble one from plans, subscriptions, add-ons and discounts.
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.
Braintree models customers, payment methods, plans, subscriptions, add-ons, discounts and transactions. The subscription references a plan and carries its own price, which may differ from the plan price because add-ons and discounts are applied as separate objects with their own amounts and quantities. There is no built-in cohort or churn reporting, so the export is a raw materials list rather than a report.
| Needed | Where it lives in Braintree | Watch out for |
|---|---|---|
| Account identifier | Customer ID, distinct from payment method token | A customer can have multiple payment methods and subscriptions. |
| Subscription status | Active, Canceled, Expired, Past Due, Pending | Past Due is a dunning state and is common in card-heavy books. |
| Amount and currency | Subscription price, plus add-ons, minus discounts | The subscription price alone is not what is billed. |
| Billing interval and term | Plan billing frequency in months | Braintree expresses everything in months; annual is 12. |
| Start date | First billing date, and separately created-at | Free trials shift these apart. |
| Cancellation or end date | Subscription updated-at when status became Canceled | Braintree does not always give a clean dedicated cancellation timestamp; derive from status history if available. |
| Last successful payment date | Most recent settled transaction on the subscription | Essential here, because Braintree's dunning behaviour is configurable per merchant. |
These are the errors we see repeatedly on this platform. Each one is silent: the analysis completes and returns a number that is wrong.
Because Braintree offers no MRR figure, nobody has decided how annual plans, discounts or trials are treated. Write your definition down before you compute anything, apply it consistently, and put it in the memo. This is more work and produces a more defensible number than reconciling against someone else's dashboard.
The billed amount is the subscription price plus add-ons minus discounts, each with its own quantity and its own number of remaining billing cycles. A discount with a finite duration means the amount will change on a known future date, which matters for any forward projection.
Braintree's subscription records are less explicit about when a cancellation was requested versus when it took effect than purpose-built billing platforms. Where the distinction matters, reconcile against transaction history: the last settled transaction bounds the revenue stop date even when the status timestamp is ambiguous.
A Braintree subscription can be configured with a fixed number of billing cycles, after which it simply expires. Those are scheduled endings, not churn, and they should be identified and reported separately or they will look like a retention problem in whichever month they land.
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 Braintree subscriptions in every status including canceled, expired and past due, for the full history, with customer ID, status, plan ID, subscription price, every add-on and discount with amount and quantity, billing frequency, first billing date, created-at, and number of billing cycles if any is set. Please also export settled transactions per subscription so payment history can be reconciled, since there is no MRR report to work from.
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 Braintree 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 Braintree documentation: https://developer.paypal.com/braintree/docs/. 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 →
No. Braintree is a payment gateway with recurring billing, not a subscription analytics platform, so there is no built-in MRR or churn reporting. Both have to be computed from plans, subscriptions, add-ons, discounts and transactions. The upside is that no definitional choices have been made for you.
Start with the subscription price, add every add-on at its own amount and quantity, then subtract every discount at its own amount and quantity. Check each discount's remaining billing cycles too, because a finite discount means the amount changes on a known future date.
It means the subscription is scheduled to end rather than at risk of churning. Those endings should be identified from the configuration and reported separately, otherwise they appear as churn in whichever month they happen to land and make retention look worse than it is.