ARR vs MRR: which should a small SaaS report

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Report MRR to yourself — it's the honest, monthly-normalized measure of the recurring revenue your subscribers currently represent, and it's the number that actually moves when you ship a feature, fix churn, or raise prices. ARR is just MRR × 12, a convention borrowed from annual-contract B2B software, and multiplying a small monthly number by 12 mostly makes it look bigger without telling you anything new. Use MRR to run the business day to day; reach for ARR only when you're talking to someone — an investor, an acquirer, a bank — who thinks in annual terms.

Disclosure: SoleOS publishes this guide, and SoleOS's own dashboard normalizes MRR across Stripe, RevenueCat, and app-store billing for founders running multiple products — so we have an obvious interest in this topic. That said, if you run one product on one monthly Stripe price with no annual plan, your MRR is just your monthly Stripe revenue, and you don't need a tool to tell you that; a glance at your Stripe dashboard is enough.

What each one actually measures

MRR (monthly recurring revenue) is the sum, normalized to a monthly basis, of every active subscription's recurring value. A $19/mo plan contributes $19. A $190/year plan contributes roughly $15.83 — you divide the annual price by 12 so it sits on the same monthly footing as everything else. Add up every active subscriber's normalized contribution and you have MRR: what your recurring revenue would be if this month repeated forever, assuming nothing changes.

ARR (annual recurring revenue) is simply MRR × 12. It's not a separate measurement — it's a unit conversion. That distinction matters more than it sounds like it should, because ARR is meaningful mainly in businesses where revenue actually arrives in annual chunks: enterprise contracts, annual-only pricing, multi-year deals. In those businesses, ARR approximates real committed cash and real contract terms. In a monthly-billed indie SaaS, ARR is a hypothetical projection — "if every current subscriber stayed exactly as they are for twelve months" — which is rarely how solo-founder subscriber bases behave. People churn, downgrade, and upgrade constantly at this scale.

Why ARR gets misused by small, monthly-billed products

The mechanical reason ARR shows up so often in indie SaaS marketing and self-talk is simple: it's a bigger number. $500 MRR becomes "$6K ARR." $2,000 MRR becomes "$24K ARR." Nothing about the underlying business changed — you just multiplied by 12 — but the bigger figure feels more like validation, and it's tempting to lead with it in a tweet or a founder update.

The problem is that ARR implies durability monthly billing doesn't have. An annual-contract company reporting $24K ARR usually has customers locked in for a year; canceling mid-contract is rare and penalized. A solo founder with $2,000 MRR on monthly Stripe subscriptions has no such lock-in — a bad month of churn can knock a real chunk off that number long before an "ARR" figure would catch up. Reporting ARR without that context isn't lying, but it lets a volatile number borrow the credibility of a stable one — and it makes cross-founder comparisons misleading, since a monthly $10K MRR business and an annual-contract $120K ARR business can have wildly different churn and cash-flow dynamics despite similar-looking ARR math.

MRR is the more honest operating number for indies

If you bill monthly, your reality moves monthly. A cancellation shows up in this month's MRR, not twelve months from now. A price increase shows up this month. MRR tracks the actual current state of your recurring revenue — the granularity a founder running several products needs, since you're making weekly or monthly calls about which app deserves your next sprint, not annual capital-allocation calls.

MRR also composes better across a portfolio. If you run products on Stripe web subscriptions and RevenueCat mobile subscriptions side by side, summing normalized MRR gives you one coherent "how is the business doing right now" number. Summing ARR across products just triples the distortion — you're compounding a projection of a projection. For a walkthrough of pulling consistent revenue numbers out of Stripe and RevenueCat in the first place, see how to track revenue as a solo founder.

Annual plans complicate MRR — normalize, don't spike

The one place MRR gets genuinely tricky for indie SaaS is when you offer both monthly and annual pricing, which most do to reduce churn and pull cash forward. The mistake is counting the full annual charge in the month it's billed — a $120/year subscriber shouldn't show up as a $120 MRR spike in January and $0 for the next eleven months. That makes your MRR chart look like a seismograph and tells you nothing about trend.

The fix is normalization: divide the annual price by 12 and count that monthly-equivalent amount every month for the life of the subscription. A $120/year plan contributes $10 to MRR each month, the same way a $10/month plan would. Do this consistently and your MRR line reflects steady-state recurring value instead of billing-cycle noise — which is also what lets you meaningfully compare a monthly-plan month to an annual-plan month.

This is exactly the kind of reconciliation work that's easy to get wrong by hand once you have Stripe, RevenueCat, or app-store billing all feeding different cadences into the same number — it's worth automating rather than eyeballing in a spreadsheet each month.

MRR/ARR vs. gross revenue and bookings

MRR and ARR only count recurring subscription value — the amount you'd expect to keep collecting if nothing changed. They deliberately exclude:

• One-time purchases (a lifetime deal, a one-off consulting invoice, an in-app one-time unlock)
• Usage overages or metered charges that vary month to month
• Setup fees or onboarding charges
• Refunds and chargebacks in the period (these reduce cash but are usually handled as churn adjustments to MRR, not subtracted from gross)

Gross revenue ("bookings," in a stricter sense) is everything that hit your payment processor in a period — recurring and non-recurring together. It's the right number for cash-flow planning and total collections, but the wrong number for judging the health of your subscription business: a bulk lifetime-deal push can make gross revenue look great while the recurring base is flat or shrinking. Keep the two separate, even informally.

MRR vs. ARR at a glance

Which to report to whom

Report MRR to yourself, weekly or monthly, as your primary operating metric — the number that should actually change your decisions about pricing, churn fixes, or which product deserves your next sprint. If you run several products, look at MRR per product as well as combined, since an aggregate can hide one app quietly dying while another grows.

Report ARR only when the audience specifically thinks in those terms: a prospective acquirer running SaaS comps, an investor comparing you to annual-contract portfolio companies, or a lender asking for an annualized figure. State both numbers and be explicit that ARR is MRR × 12 on a monthly-billed base with normal indie churn — don't let the bigger number stand in for contracted revenue it doesn't represent. A metrics dictionary and the broader Founder Playbook are built around that same instinct: MRR as the operating truth, ARR as a translation you produce on demand rather than a number you live by.

If you sell through app stores, remember that neither MRR nor ARR nets out platform fees automatically — how that revenue is recognized and reconciled is its own topic, covered in merchant of record for indie SaaS.

Frequently asked questions

Should I ever report ARR if all my subscribers are monthly?

You can, as long as you label it clearly as MRR × 12 rather than as contracted annual revenue. Some investors and acquirers ask for ARR by default because it's the convention in SaaS, even for monthly-billed businesses. Give them the number, but don't let it substitute for MRR in your own tracking — the annualized figure will lag behind reality by definition.

How do I handle annual plans mixed with monthly plans in one MRR number?

Normalize every annual subscription to its monthly-equivalent value (annual price ÷ 12) and add that to your monthly subscribers' full price. The result is one MRR figure that reflects steady-state recurring value regardless of billing cadence. Avoid counting the full annual charge as a one-month spike — it overstates growth in the billing month and understates it for the following eleven.

Does a cancellation get removed from MRR immediately, or at the end of the paid period?

Most founders remove it once the subscription is confirmed not to renew, though some keep a canceled-but-still-active subscriber in MRR until the paid period ends. Either convention works as long as you apply it consistently — the point is not double-counting a subscriber as both "active" and "churned" in the same month.

What about lifetime deals or one-time app-store purchases — do they belong in MRR?

No. MRR and ARR represent recurring value only. A lifetime deal or one-time unlock is real revenue and belongs in your gross revenue and cash-flow numbers, but including it in MRR overstates your recurring base and will make a future month look like a cliff when, in reality, nothing recurring changed — you just had no equivalent one-time sale that month.

Is MRR still useful if I only have a handful of subscribers?

Yes — arguably more so, because at low volume a single cancellation or upgrade is a large percentage swing, and you want to see that clearly rather than smoothed into an annualized figure. At small scale, MRR's month-to-month sensitivity is the point: it's the fastest signal you have that something changed in the business.