FastSpring has been selling software for long enough that a mature account often contains three generations of commercial model at once: perpetual licences with maintenance, annual subscriptions, and modern monthly plans. Separating those is the main analytical task, because only one of the three is recurring revenue in the sense a multiple assumes.
TL;DR: FastSpring is a merchant of record with a long tail of legacy software pricing, so exports frequently mix perpetual licences, maintenance plans and true subscriptions. Here is how to separate them.
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.
The objects are accounts, products, subscriptions and orders, with FastSpring acting as merchant of record and therefore handling tax and appearing as the seller. Subscriptions carry a state and a next-charge date; orders record what was actually transacted. As with any merchant of record, gross customer payment, recognised revenue and net payout are three different figures.
| Needed | Where it lives in FastSpring | Watch out for |
|---|---|---|
| Account identifier | Account ID, with email as a secondary key | Long-lived accounts may have multiple products across generations. |
| Subscription status | Active, overdue, cancelled, deactivated, trial | Cancelled subscriptions may remain in service to the period end. |
| Amount and currency | Subscription price and currency; payout is net of fees and tax | Multi-currency and local pricing are common. |
| Billing interval and term | Interval and interval length | Annual dominates in legacy software accounts. |
| Start date | Subscription begin date, plus original order date | These differ when a perpetual licence later gained a maintenance plan. |
| Cancellation or end date | Cancellation date and deactivation date | Two states, two dates, as with several other platforms. |
| Last successful payment date | Most recent completed order for the subscription | Needed to distinguish overdue from cancelled. |
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 perpetual licence is one-time revenue. A maintenance or support plan attached to it is recurring but usually renews at a low rate and can be declined without losing the product, so its retention behaves nothing like SaaS. Separate all three models before computing anything, and apply different multiples to each.
The customer's gross payment, the recognised revenue and the net payout all differ, because FastSpring remits tax and deducts its fee. State which basis you are using and be consistent, since reconciling MRR against bank deposits without accounting for both will always show a gap.
Long-running accounts accumulate grandfathered prices, and revenue per customer varies widely for the same product. Get the full product and pricing history so a legacy price can be distinguished from a current one, otherwise the pricing analysis will look chaotic rather than historical.
An overdue subscription has failed to charge and has not yet been cancelled. It is revenue at risk. Count it separately and check the historical recovery rate rather than treating it as either active or churned.
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 FastSpring subscriptions in every state including cancelled, deactivated and overdue, for the full history, with account ID, product, state, price, currency, interval and interval length, begin date, next charge date, cancellation and deactivation dates. Please also send the full product catalogue and pricing history, and flag which products are perpetual licences, which are maintenance plans and which are true subscriptions.
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 FastSpring 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 FastSpring documentation: https://developer.fastspring.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 →
As two separate things. The licence is one-time revenue and belongs outside MRR entirely. The maintenance or support plan is recurring, but it typically renews at a lower rate than SaaS because the customer keeps the product either way, so it warrants its own retention analysis and its own multiple.
Because FastSpring is a merchant of record. It collects a gross amount, remits tax, deducts its fee and pays out the remainder, so gross subscription value, recognised revenue and net payout are three different numbers. Reconcile them once deliberately and then work consistently in one basis.
That a charge failed and the subscription has not been cancelled. It is revenue at risk rather than revenue lost or revenue earned. Count it separately, and ask for the historical recovery rate so it can be weighted rather than guessed at.