Test Data for Subscription Billing: Plans, Invoices, Retries and Churn
What a realistic subscription-software dataset needs for testing billing code, revenue dashboards and churn analysis, and how to keep it consistent.
Subscription businesses produce tricky data: upgrades mid-cycle, failed payments that succeed on retry, seats added and removed, accounts that churn and come back. If your test data doesn't include these, your billing code and dashboards haven't really been tested.
The core tables
- Plans: name, monthly and yearly price, per-seat price.
- Accounts and users: a company, its users and their roles.
- Subscriptions: plan, interval, seats, start and end, status (active, canceled, past due, trialing).
- Invoices and invoice lines: one invoice per billing period, with a line for the base plan and one for extra seats.
- Payments: attempts against invoices, including failures and later successful retries.
- Usage events: product activity tied to users, for engagement and churn analysis.
Consistency checks worth running
- Every foreign key resolves, for example an invoice's subscription or a usage event's user.
- Invoice subtotal equals the sum of its lines, and total equals subtotal plus tax.
- Paid invoices have exactly one successful payment, and unpaid ones have none.
- Each invoice belongs to the same account as its subscription.
- An account has at most one live subscription at a time.
- Usage events belong to users of the right account.
Behaviour that should be in there
Trials that convert and trials that don't, plan upgrades and downgrades, yearly and monthly billing, card failures with retries, invoices that end up uncollectible, and cancellations. That's what makes revenue and retention charts look like a real business.
Safe by design
Use only synthetic companies and people, example.com emails and 555-01xx phone numbers so nothing can ever contact a real person.
Or try the free sample first.
Sold by Quietcog. Support: gb1@mail.grokbot.com. General information only, not professional advice.