The SaaS Subscription Record Generator creates batches of believable subscription records for building and demoing SaaS revenue dashboards, MRR charts, and churn analytics. The figures are internally consistent — MRR matches the plan and billing interval, and renewal dates follow correctly from start dates — so charts built on the data look realistic.
How it works
Each record draws a plan tier from a standard pricing ladder (Free, Starter, Pro, Business, Enterprise) and a billing interval that is annual about 40% of the time. MRR is then normalised to a monthly figure: monthly plans use the listed price, while annual plans apply a roughly 17% discount, modelling paying for ten months across a twelve-month term.
Dates and risk are derived consistently:
startDateis a random day within the last year.renewalDateis start plus one month for monthly plans or plus one year for annual plans.churnRiskishighfor past-due and canceled records,mediumfor paused, and otherwise scored inversely to revenue so larger accounts skew low-risk.
A running active MRR total sums only active subscriptions, just as a real dashboard would.
Why MRR normalisation matters for demos
A SaaS company with a mix of monthly and annual subscribers cannot simply add up all payments to get MRR — that would inflate monthly figures in the months when annual renewals happen. The correct approach is to divide an annual subscription’s payment by 12 and count that monthly fraction as the subscriber’s contribution to MRR.
This generator does that normalisation automatically, and also models the standard annual discount — roughly 17%, equivalent to getting two months free — so the blended ARPU across a generated batch reflects the real dynamic: annual subscribers pay less per month but are worth more in aggregate over 12 months because they churn far less frequently.
The active MRR total displayed below the generated list mirrors exactly how a real Stripe or ChartMogul dashboard computes MRR: only active subscriptions contribute, not trialing, canceled, or past_due ones.
Illustrative example
For example, a batch of five records might look like:
| Customer | Plan | Interval | MRR | Status | Churn Risk |
|---|---|---|---|---|---|
| cus_7f2k1p | Enterprise | annual | $833 | active | low |
| cus_3a9m2z | Pro | monthly | $99 | active | low |
| cus_8b4n0x | Starter | monthly | $29 | past_due | high |
| cus_1c6j3y | Business | annual | $249 | active | low |
| cus_5d8l7w | Free | monthly | $0 | active | low |
Active MRR from this batch: $833 + $99 + $249 + $0 = $1,181 (the past-due record is excluded).
Practical tips
- IDs follow a Stripe-like shape (
sub_…,cus_…) so they slot naturally into payment-flow demos and Stripe-integration test suites. - Generate 50 or more records to get a realistic spread across all plan tiers and status values; smaller batches may miss rare statuses like
paused. - Rerun and merge JSON arrays to model a larger book of business for pagination and chart-rendering tests.
- All generation runs locally with no API key or network request.