Guides#lemonsqueezy#mrr#metrics

How to Calculate MRR from LemonSqueezy Without Lying to Yourself

A practical guide for indie hackers who use LemonSqueezy subscriptions and one-time sales. Learn how to calculate real MRR, normalize annual plans, and avoid mixing Merchant of Record payouts with recurring revenue.

Makerfolio··12 min read

If you sell software, templates, plugins, or memberships through LemonSqueezy, there is a good chance your dashboard is showing you real money but not necessarily real MRR.

That distinction matters.

Indie hackers love posting revenue screenshots. The problem is that LemonSqueezy is often used for a mix of subscriptions, one-time digital products, upsells, bundles, and merchant-of-record tax handling. If you take the number that feels good and call it MRR, you're not measuring your business. You're flattering it.

This guide shows how to calculate LemonSqueezy MRR the right way.

Makerfolio dashboard preview showing unified revenue sources and recurring revenue metrics
Makerfolio dashboard preview showing unified revenue sources and recurring revenue metrics

The core mistake: treating all LemonSqueezy revenue like recurring revenue

LemonSqueezy is excellent for digital products because it handles a lot of operational pain for small teams. Its pricing page positions the platform at 5% + 50¢ per transaction and emphasizes Merchant of Record handling, tax compliance, fraud protection, and digital-product workflows. That makes it attractive for builders who sell:

But that product mix is exactly why MRR gets messy.

If you sold:

your cash collected this month is not your MRR.

Your MRR is only the normalized recurring portion:

MRR = sum of all active recurring subscriptions normalized to monthly value

The one-time products are real revenue. They just are not recurring revenue.

What counts as LemonSqueezy MRR

For a clean MRR number, include only revenue that is:

  1. tied to an active recurring subscription
  2. expected to recur without a new purchase decision
  3. normalized to a monthly amount

That means these usually count:

These do not count as MRR:

That last point matters more than people realize. LemonSqueezy acts as Merchant of Record for many sellers, which means tax handling is built into the platform experience. Great for operations. Terrible if you start reading gross numbers without separating what is actually yours.

The simple formula

Here's the baseline formula:

MRR contribution = net subscription amount / billing interval in months

| Plan type | Customer price | MRR contribution | |-----------|----------------|------------------| | Monthly | $19/month | $19.00 | | Quarterly | $54/quarter | $18.00 | | Annual | $190/year | $15.83 | | Semi-annual | $120/6 months | $20.00 |

If you stop here, you're already ahead of a lot of founders.

But here's the thing: LemonSqueezy businesses often have more edge cases than plain Stripe SaaS setups, because the same store can sell recurring and non-recurring products side by side.

A realistic LemonSqueezy example

Let's say you run a bootstrapped product stack like this:

Your calculation should look like this:

Recurring revenue only

Subtotal recurring: $1,308.00 MRR

One-time revenue

Subtotal one-time: $4,240.00 one-time revenue

Refund adjustment

If 3 of those annual customers were refunded and are no longer active, remove them from the recurring base:

Real MRR becomes: $1,248.00

The business may have collected far more cash in the month, but the recurring engine is still $1,248 MRR.

That's the number you use for trend tracking, build-in-public updates, growth analysis, and comparisons against prior months.

Why gross sales and payouts are dangerous proxies

A lot of builders fall into one of these traps:

Trap 1: using monthly sales as MRR

If your monthly sales include templates, courses, bundles, or LTDs, the number will spike and collapse based on launches. That tells you about campaign timing, not subscription health.

Trap 2: using payout amounts as MRR

Payouts can include:

Payouts are a cash-flow metric, not an MRR metric.

Trap 3: using gross subscription price instead of net collected value

If you offer discounts, founder deals, annual coupons, or launch pricing, your MRR should reflect what customers are actually paying now.

This is why serious operators prefer net MRR over vanity MRR.

LemonSqueezy-specific edge cases you need to handle

1. One-time and recurring products in the same catalog

This is the biggest source of confusion.

LemonSqueezy is great at letting a solo founder sell everything from a monthly SaaS to a $29 Notion template inside one business. Operationally, that's amazing. Analytically, it's a trap unless you explicitly segment recurring vs non-recurring sales.

If a product does not renew automatically, it is not MRR.

2. Annual plans that look bigger than they are

This one gets people every time.

A $240 annual plan is $20 MRR, not $240 MRR. If you book the whole amount into one month, your growth chart becomes fiction.

3. Discounts and launch offers

If a customer pays $12/month because you gave them a permanent launch discount, that subscription contributes $12 MRR, not the public list price of $19 or $29.

4. Refunds

Refunded recurring charges should not remain in your active recurring base. If you leave them in, your MRR inflates silently.

5. Merchant of Record taxes

LemonSqueezy's Merchant of Record layer is a real advantage because it helps small teams avoid global tax headaches. But from a reporting perspective, you need to separate tax-handled amounts from your own recurring revenue. Otherwise you are mixing compliance plumbing with business performance.

The operational formula indie hackers should actually use

If you want a clean monthly process, use this checklist:

Step 1: export or query active subscriptions only

Ignore completed one-time orders. Ignore expired promotions that are no longer recurring. Start with the current active subscriber base.

Step 2: normalize every recurring plan to monthly value

Use:

monthly amount = net charge / months in billing interval

Step 3: exclude one-time products completely

Track them separately as:

Step 4: remove refunded or inactive subscriptions

This sounds obvious. It is also where sloppy tracking dies.

Step 5: choose your reporting stance and stay consistent

Pick one:

For most indie hackers, net recurring revenue is the more honest operating number.

LemonSqueezy vs Stripe vs Polar for MRR reporting

This is where a lot of multi-product founders get stuck.

| Platform | Useful for | Common MRR problem | |----------|------------|--------------------| | Stripe | SaaS subscriptions, custom billing, usage models | Founders confuse dashboard revenue with true normalized MRR | | Polar | Developer tools, open-source, MoR workflows | Mixed understanding of one-time vs recurring if product mix grows | | LemonSqueezy | Digital products plus subscriptions | One-time sales sit next to subscriptions, so revenue often gets mislabeled as MRR |

If you already read our guides on how to calculate MRR from Stripe or Stripe vs Polar for indie hackers, the LemonSqueezy version has its own twist: the platform is extremely builder-friendly, but that ease of selling digital products makes clean recurring reporting more important, not less.

The best way to report LemonSqueezy revenue publicly

If you're building in public, don't post a giant number with zero context.

Post the split.

For example:

$1,248 MRR
$4,240 one-time revenue this month
Main drivers: annual renewals + template launch

That is infinitely more credible than saying:

We did $5.5k this month 🚀

Why? Because the second version hides whether the business is compounding or just having a good launch week.

Builders, investors, collaborators, and even future customers understand the difference.

If your goal is trust, publish recurring revenue as recurring revenue.

Where Makerfolio fits

Makerfolio is useful here because the product positioning already matches the reporting problem:

That matters a lot if you're running a mixed stack.

Maybe you sell:

Each platform sees only one slice of the business. Your audience sees the whole business. Your reporting layer should do the same.

That's exactly why the LemonSqueezy integration page exists at /integrations/lemon-squeezy, and why a founder using multiple processors eventually needs one trusted place to reconcile recurring revenue.

A simple monthly reporting template you can reuse

If you want a dead-simple system, use this at the end of every month:

Recurring metrics

Non-recurring metrics

Notes

That last section is gold. It stops you from making emotional decisions based on a launch spike.

Final answer: how to calculate LemonSqueezy MRR correctly

Here it is in one line:

LemonSqueezy MRR is the sum of all active recurring subscriptions, normalized to a monthly value, after removing one-time sales, refunds, and non-recurring noise.

If you remember only five rules, make them these:

  1. Do not count one-time product sales as MRR
  2. Normalize annual and quarterly plans to a monthly number
  3. Use the actual paid amount after discounts
  4. Remove refunded or inactive subscribers
  5. Track one-time revenue separately so your recurring trend stays honest

That's it.

And yes, it's less exciting than posting a huge gross-sales screenshot.

But here's the thing: real builders do not win by telling themselves pretty stories. They win by understanding exactly what part of revenue compounds.

If you want to go deeper, pair this guide with:

That's the stack.

Track cash honestly. Track recurring revenue separately. Then build from reality.

#lemonsqueezy#mrr#metrics#indie-hacker#revenue
← All posts

Track what you just learned in Makerfolio.

Connect Stripe or Polar and get verified metrics on your public builder profile.

Start for free →
Published: March 25, 2026