Maxio is two products that were merged: Chargify on the billing side and SaaSOptics on the reporting side. Which one produced your file changes what it contains and what it has already decided on your behalf, and that is the first thing to establish.
TL;DR: Maxio combines Chargify billing with SaaSOptics reporting, and components hold revenue outside the product price. Here is which side of the platform your export came from and what it omits.
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.
On the Chargify side the objects are customers, subscriptions, products, product families and components, where components carry quantity-based, metered and on-off charges separately from the product price. On the SaaSOptics side you get contract and revenue-schedule level data that has already had revenue recognition applied. The two describe the same business with different assumptions baked in, and a churn analysis built on a recognition-adjusted export is answering a different question from one built on billing records.
| Needed | Where it lives in Maxio (Chargify) | Watch out for |
|---|---|---|
| Account identifier | Customer ID on the Chargify side; contract or account on the SaaSOptics side | The two do not always map one-to-one. Ask which is authoritative. |
| Subscription status | active, trialing, past_due, canceled, on_hold, unpaid, trial_ended | on_hold and unpaid are both revenue at risk, not revenue. |
| Amount and currency | Product price, plus every component (quantity-based, metered, on-off) | Components are the Chargify equivalent of addons and are easy to miss entirely. |
| Billing interval and term | Product interval and interval unit | Chargify supports arbitrary interval lengths. |
| Start date | Subscription created-at and activated-at | Trials separate the two. |
| Cancellation or end date | Canceled-at, plus delayed-cancel-at for end-of-term cancellations | Delayed cancellation is a pending churn signal. |
| Last successful payment date | Derive from the subscription's transactions or statements | Also check past_due and unpaid counts. |
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 a meaningful share of revenue comes from metered usage, there is no single correct MRR. The defensible approach is to report committed recurring revenue from product prices and fixed components separately from usage revenue, and to build the downside case on committed amounts only. Blending them produces a figure that falls when your customers' volumes fall, which is not what a subscription multiple is meant to price.
Revenue recognition smooths annual contracts across the term, which is correct for accounting and wrong for a renewal calendar. If your file came from the reporting side you cannot see when contracts actually renew, which is the artifact a buyer most needs. Ask for billing-side subscription records as well.
on_hold and unpaid are not activeBoth states describe subscriptions that are not currently producing cash. They frequently sit inside an active-subscription count. Separate them and treat their revenue as at risk until proven otherwise.
Chargify organises products into families, and a target with several families may have overlapping or superseded pricing across them. Get the full product and component catalogue, not just the subscription rows, or you will not be able to tell a legacy price from a current one.
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 Chargify subscriptions including canceled, on-hold, unpaid and past-due, for the full history, with customer ID, state, product handle and price, every component with its type, quantity and amount, currency, interval and unit, created-at, activated-at, canceled-at and any delayed-cancellation date. Please also send the full product and component catalogue. If any figures come from the SaaSOptics side, please say so, since revenue recognition changes what they mean.
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 Maxio (Chargify) 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 Maxio (Chargify) documentation: https://developers.maxio.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 →
Maxio is the combined company formed from Chargify and SaaSOptics. Chargify is the billing side and SaaSOptics is the revenue-reporting side. They are different data models with different assumptions, so the first question about any Maxio export is which side produced it.
Separately. Report committed recurring revenue from product prices and fixed components apart from metered usage, and build the downside case on committed amounts only. Usage revenue tracks your customers' volumes rather than your own retention, so blending it into MRR prices someone else's business cycle at a subscription multiple.
Because revenue recognition spreads an annual contract evenly across its term, which removes the lumpiness that a renewal calendar is made of. It is the right treatment for accounting and the wrong input for working out which month a fifth of your revenue comes up for renewal. Ask for billing-side subscription records alongside it.