How to Calculate Net MRR Across Stripe, Polar, and Lemon Squeezy

If your business runs on a single payment processor, calculating MRR is already easy to mess up.

If your business runs across Stripe, Polar, and Lemon Squeezy, the risk gets even bigger. Now you are not only normalizing billing intervals. You are also reconciling different dashboard defaults, different product mixes, and different assumptions about what counts as recurring revenue.

That is why so many founders end up with three different numbers:

the number they say publicly,
the number they use internally,
and the number that actually reflects recurring revenue.

Those should not be different numbers.

This guide gives you a practical framework for calculating net MRR across multiple processors without mixing subscriptions, one-time sales, discounts, and processor-specific noise.

Start with the actual MRR definition

ChartMogul defines Monthly Recurring Revenue as the sum of recurring subscription revenue for active or past-due subscriptions, while excluding one-time line items and normalizing non-monthly plans by billing interval. That is the right starting point because it forces discipline before you touch a spreadsheet or build a dashboard.

The key idea is simple:

MRR is recurring subscription revenue normalized to a monthly amount.

So if you sell:

a $30 monthly subscription in Stripe,
a $240 annual subscription in Polar,
and a $99 one-time template in Lemon Squeezy,

your MRR is $50, not $369.

Stripe monthly plan = $30 MRR
Polar annual plan = $240 / 12 = $20 MRR
Lemon Squeezy template sale = $0 MRR

That one-time sale still matters for total revenue. It just does not belong inside MRR.

If that distinction is fuzzy, refresh the definition in the MRR glossary before you go further.

Why multi-processor businesses get this wrong

The first problem is that each billing system is designed around its own worldview.

Stripe's subscription documentation focuses heavily on subscription lifecycle states, invoices, payment behavior, and API-level billing logic. That is powerful, but it also means a founder can easily confuse an invoice event with recurring revenue.

Polar positions itself as a modern billing platform with subscriptions, usage billing, invoicing, and merchant-of-record capabilities. That makes it attractive for developer products, but it still leaves you with the same core question: which transactions represent recurring monthly value and which do not?

Lemon Squeezy adds another wrinkle because it is often used for a mix of subscriptions and digital product sales. Its own docs and platform messaging emphasize subscriptions, digital products, tax handling, and merchant-of-record workflows. That is great for running the business. It also means your reporting has to work harder to separate recurring subscriptions from one-off launches, bundle spikes, and digital download revenue.

In other words: the processors help you get paid, but they do not automatically give you a clean cross-platform definition of net MRR.

Step 1: Build one inclusion rule for every processor

Before you calculate anything, define a single rule that applies across all platforms.

Include in MRR:

active paid subscriptions,
recurring subscription items,
discounted subscription amounts after the discount,
annual, quarterly, and custom-interval plans normalized to a monthly value.

Exclude from MRR:

one-time orders,
setup fees,
template sales,
course purchases,
LTD sales,
shipping,
taxes,
refunded non-recurring orders,
canceled subscriptions,
free trials that have not converted.

This is the part people skip. They jump to formulas before deciding what belongs in the metric. That is backwards.

Step 2: Normalize every billing interval to monthly

The math is not complicated. The discipline is.

Use this formula:

monthly value = recurring amount / billing interval in months

Examples:

| Plan | Billed amount | Interval | MRR contribution | |------|---------------|----------|------------------| | SaaS starter | $19 | monthly | $19 | | Pro annual | $240 | yearly | $20 | | Team plan | $90 | quarterly | $30 | | Biannual plan | $300 | every 6 months | $50 |

This is the same logic behind the existing guides on how to calculate MRR from Stripe and how to calculate MRR from Lemon Squeezy.

If a business has mixed processors, you do not get to normalize one platform correctly and leave the others raw. The rule has to apply everywhere.

Step 3: Keep one-time revenue visible, but separate

This is where a lot of indie businesses break their own analytics.

Founders who sell software often have hybrid revenue models:

SaaS subscriptions in Stripe,
sponsorships or developer-focused subscriptions in Polar,
templates, plugins, courses, or add-ons in Lemon Squeezy.

That is normal. The mistake is trying to squeeze all of it into one vanity MRR number.

The better model is:

Net MRR = recurring revenue only,
One-time revenue = non-recurring sales,
Total revenue = net MRR plus non-recurring revenue over the selected period.

That is also the logic behind a stronger revenue dashboard for indie hackers. A useful dashboard does not hide one-time revenue. It simply does not confuse it with recurring revenue.

Step 4: Decide what “net” means and stay consistent

Here is the part that gets philosophical fast.

Some teams define net MRR as:

subscription revenue after discounts

Others define it as:

subscription revenue after discounts and transaction fees

ChartMogul explicitly notes that transaction fee handling can change how MRR is calculated, and that refunds may be handled differently depending on the integration. That should tell you something important: there is no universal truth unless you define the policy clearly.

For an indie business, the cleanest operational choice is usually:

subtract discounts,
exclude tax,
exclude one-time revenue,
optionally subtract processor fees if you want finance-grade conservatism,
document the policy and never switch definitions casually.

The worst possible move is changing the definition month to month depending on whether you want the graph to look bigger.

Step 5: Respect subscription status

Stripe's official subscription lifecycle matters here. A subscription can be trialing, active, past_due, unpaid, paused, or canceled, and those are not cosmetic differences.

If you are calculating net MRR across processors, you need a status policy such as:

active = include,
trialing = exclude until paid,
canceled = exclude,
paused = exclude,
unpaid = exclude,
past_due = include or exclude based on your accounting policy, but choose once and stay consistent.

That one decision alone can swing your reported MRR hard if you have weak collections or lots of trial volume.

Step 6: Use secure, read-only connections when possible

There is a technical reason this topic overlaps with product architecture.

Stripe's own API key guidance recommends server-side handling and the use of restricted API keys where possible. That matters because once you connect live revenue systems to a third-party analytics layer, security becomes part of the reporting story.

If you are doing this manually, make sure you understand:

what key type you are using,
whether access is read-only,
what data gets stored,
and whether the system is keeping only aggregates or sensitive operational detail.

If you want a cleaner workflow, that is exactly where a product like Makerfolio fits. The platform is designed around integration pages like Stripe, Polar, and Lemon Squeezy, plus a public builder profile for verified proof.

A simple cross-platform calculation framework

Here is the practical sequence:

Pull recurring subscription items from each processor.
Exclude one-time orders and non-recurring items.
Normalize all recurring plans to monthly values.
Apply discounts to subscription amounts.
Convert all subscription values into one reporting currency.
Filter by your chosen status policy.
Sum the result.

That gives you a usable cross-platform net MRR number.

Pseudo-formula:

Net MRR = Σ(recurring subscription amount normalized monthly)
          - subscription discounts
          - optional processor fees

Then keep one-time revenue on a separate line.

Example: one founder, three processors

Let's say a founder has this stack:

Stripe

20 customers on a $29 monthly SaaS plan = $580
5 customers on a $290 annual plan = $120.83 monthly equivalent

Polar

8 customers on a $15 monthly developer tool plan = $120
2 customers on a $120 yearly plan = $20 monthly equivalent

Lemon Squeezy

10 customers on a $12 monthly subscription = $120
$1,400 in one-time template sales this month = $0 MRR

Raw recurring subtotal:

580 + 120.83 + 120 + 20 + 120 = 960.83

If discounts reduce subscription revenue by $40 across the three processors:

Net recurring subtotal = 920.83

If you also subtract $32 in processor fees from the subscription portion:

Net MRR after fees = 888.83

The $1,400 in template sales still matters for total cash generated this month, but it does not belong in MRR.

Why this matters for public proof too

Many founders do not calculate MRR just for internal reporting. They want to share progress publicly.

That changes the stakes.

Once you publish numbers on social media, launch pages, or investor updates, the metric is no longer private. It becomes part of your reputation. That is why content like how to share Stripe revenue publicly without exposing customer data matters. A weak MRR definition makes public proof look sharper than it really is.

The better move is to publish numbers you can defend:

recurring revenue is really recurring,
one-time spikes are clearly separated,
processor-specific quirks are normalized,
and the public view is backed by a system instead of screenshots.

Sources

Final takeaway

Calculating net MRR across Stripe, Polar, and Lemon Squeezy is not hard because the formula is exotic. It is hard because mixed businesses have mixed revenue, mixed defaults, and mixed habits.

The solution is boring in the best possible way:

define what belongs in MRR,
normalize every recurring plan to monthly,
separate one-time revenue,
apply one status policy,
document your net definition,
keep the reporting consistent.

If you want to stop doing that manually, create a Makerfolio account, connect your billing stack, and turn the whole thing into one dashboard with a shareable proof layer.