DEV Community: DevSnack

How to Track MRR on Lemon Squeezy (Accurately) in 2026

DevSnack — Sun, 05 Jul 2026 02:29:47 +0000

Originally published on the Throughlines blog.

Lemon Squeezy is a great place to start selling — it's a merchant of record, so tax and compliance are handled for you. But once subscriptions start rolling in, one question gets harder than it should: what's my actual MRR, and can I trust the chart?

Here's how MRR works on Lemon Squeezy, the gotcha most people miss, and how to track it accurately — especially if you also sell on Polar or Paddle.

MRR = monthly recurring revenue, normalized

MRR is the recurring revenue you can expect each month from active subscriptions. The math is simple in principle:

A $20/mo plan contributes $20 to MRR.
A $240/year plan contributes $240 ÷ 12 = $20 to MRR (you normalize annual to monthly).
Sum that across all active subscriptions = your MRR.

The tricky part isn't the arithmetic. It's movement — how MRR changes over time — and what counts as a subscription ending.

The Lemon Squeezy gotcha: a snapshot isn't a history

Lemon Squeezy's built-in MRR/ARR has improved. Historically the charts were calculated in real time from the subscriptions active right now, which meant historical metrics weren't precise — they didn't properly account for subscriptions that were active in the past but have since cancelled. Lemon Squeezy now takes a daily snapshot of MRR/ARR to keep historical data accurate.

That's a real improvement, but it highlights the core issue: MRR is a story over time, not a single live number. To analyze trends, compare months, or explain a dip, you need a ledger of every change — not just today's total.

What accurate MRR tracking actually requires

To track MRR on Lemon Squeezy properly, you need to capture each event that changes recurring revenue and classify it:

Movement	Triggered by	Effect on MRR
New	First active subscription	+
Expansion	Upgrade to a higher-priced plan	+
Contraction	Downgrade to a lower-priced plan	−
Churn	Subscription actually ends / access revoked	−
Reactivation	A churned customer resubscribes	+

Two things people consistently get wrong:

Annual normalization. If you don't divide annual plans by 12, your MRR balloons every time someone buys a yearly plan, then looks like it crashes. Always normalize.
Canceled ≠ churned. This is the big one (next section).

The mistake that wrecks your churn number

On Lemon Squeezy, a subscription can be cancelled but still active until the end of the paid period. That customer is still paying you. If your tracking counts that cancellation as churn immediately, you'll:

Overstate churn.
Record the revenue loss too early.
Panic about a retention problem that hasn't happened yet.

Churn should only be recorded when the subscription actually ends and access is revoked (in Lemon Squeezy terms, when it expires/ends rather than when cancelled is simply flagged true). And if a customer reverses a scheduled cancellation, that pending flag should just clear — no movement at all.

Lemon Squeezy webhooks also don't ship the per-cycle price and interval inline on every event, so accurate tracking means looking up the related product variant to get the real recurring amount. It's the kind of detail that's easy to miss in a hand-rolled spreadsheet.

Three ways to track it

Lemon Squeezy's built-in charts. Good for a quick glance now that snapshots exist. Limited for deep trend analysis, and it only shows Lemon Squeezy.
Spreadsheet from CSV exports. Total control, total maintenance. You'll own the normalization and churn logic forever, and it won't update live.
A purpose-built MoR dashboard. Connect once, get correct movement automatically, and — crucially — combine Lemon Squeezy with your other platforms.

Tracking it accurately with Throughlines

Throughlines is a read-only dashboard built for merchant-of-record platforms, with Lemon Squeezy as a first-class integration.

Connect read-only. Paste your Lemon Squeezy API key; Throughlines backfills history and stays current via webhooks. It never modifies your store.
Correct movement, automatically. Annual normalized to monthly; new/expansion/contraction/churn/reactivation classified for you; variant lookups handled so per-cycle pricing is right.
Canceled ≠ churned, enforced. Pending cancellations keep counting until access is actually revoked.
Accuracy cross-check. Throughlines reconciles its computed MRR against Lemon Squeezy's own figure.
One number across platforms. Selling on Polar or Paddle too? See your consolidated MRR in a single view.

The takeaway

Lemon Squeezy's snapshot-based MRR is a solid glance, but accurate tracking means a proper ledger: normalize annual plans, classify every movement, and never count a scheduled cancellation as churn. Do that by hand and it's a chore that drifts out of sync; do it with a tool built for MoR platforms and you get numbers you can actually quote.

Track your Lemon Squeezy MRR in Throughlines →

Why 'Canceled' Isn't 'Churned' (and How It Wrecks Your Metrics)

DevSnack — Sun, 05 Jul 2026 02:25:21 +0000

Originally published on the Throughlines blog.

It's the single most common mistake in subscription analytics, and it quietly poisons the most important retention number you have. A cancellation is not churn. Treat them as the same thing and your churn rate becomes both inaccurate and early.

Here's the distinction, why it matters more than it sounds, and how to get it right.

The difference in one line

Canceled (scheduled cancellation): the customer has turned off auto-renew, but they're still paying through the end of the current period. They still have access. MRR is unchanged today.
Churned: the subscription has actually ended — the period lapsed, access was revoked, the money stopped. This is when MRR drops.

A customer who cancels on the 3rd but is paid through the 30th has not churned. They might even change their mind before the 30th. Counting them as churned on the 3rd is simply wrong.

Why this wrecks your metrics

If you record churn at the moment of cancellation instead of the moment the subscription ends, three things break:

Your churn rate is overstated. You're counting revenue as lost while it's still being collected.
Your timing is wrong. Losses show up days or weeks early, smearing your monthly cohorts and making trend analysis unreliable.
You react to phantom problems. You see a churn spike, scramble to fix "retention," and the customers in question were never actually gone — some renew or un-cancel.

Worse, the reverse error hides churn: if you only look at "active" subscriptions and never model the transition out of paying, you can miss churn entirely when access lapses silently.

The correct model: track the transition, not the flag

The reliable approach treats a subscription's state, not a single boolean:

A subscription is "paying" when it's active or pending_cancellation (scheduled to cancel but still within the paid period).
Churn fires only on the transition out of paying — when the state moves to ended / access revoked.
A reversal of a scheduled cancellation just clears the pending flag. No MRR movement, no churn, no expansion — nothing moved.

In ledger terms: a scheduled cancellation produces no delta. Only the actual end produces the negative churn delta. This is the rule that keeps churn honest.

How the platforms express it

Each merchant-of-record platform encodes this differently, which is part of why hand-rolled tracking gets it wrong:

Polar distinguishes subscription.canceled (still paying → pending, not churn) from subscription.revoked (access revoked → churn).
Lemon Squeezy can have cancelled = true while the subscription is still active until period-end; churn is when it actually expires/ends.
Paddle signals scheduled cancellations distinctly from the subscription actually ending.

If your spreadsheet just watches for the word "cancel," it will count all three platforms wrong.

A quick gut check

Ask yourself: "Is this customer still paying me right now?"

Yes → not churn, even if they've scheduled a cancellation. Flag it as pending and watch it.
No, access has ended → that's churn. Record the MRR loss now.

How Throughlines handles it

Throughlines enforces canceled ≠ churned as a core rule, identically across every platform:

It tracks each subscription's normalized state and only records churn on the transition out of paying.
A scheduled cancellation is flagged as pending and keeps contributing to MRR until access is actually revoked.
Un-canceling clears the pending flag with zero movement.
The result shows up in a clear MRR-movement waterfall, so you can see real new/expansion/contraction/churn/reactivation — not phantom churn.

Because the same logic runs across Polar, Paddle, and Lemon Squeezy, your churn number means the same thing no matter where the customer pays.

The takeaway

"Canceled" is an intention; "churned" is an outcome. Record churn only when the subscription actually ends — and treat scheduled cancellations as pending revenue that's still yours until proven otherwise. Get this one rule right and your retention metrics finally tell the truth.

See honest churn across all your platforms →

Consolidating MRR Across Merchant-of-Record Platforms (Polar, Paddle, Lemon Squeezy)

DevSnack — Tue, 16 Jun 2026 14:48:27 +0000

Originally published on the Throughlines blog.

A few years ago, "what's our MRR?" had one answer in one place. Now a growing number of founders sell through multiple merchant-of-record (MoR) platforms — Polar, Paddle, Lemon Squeezy — and the question suddenly has two or three partial answers, none of which is the whole truth.

This is the consolidation problem. Here's why it happens, why it's harder than it looks, and how to solve it cleanly.

Why founders end up on multiple MoRs

Each platform has a sweet spot, so spreading out is rational:

Lemon Squeezy is a fast, friendly place to start selling — popular with solo creators and indie hackers.
Polar is developer-first, with strong APIs and room to scale.
Paddle brings deeper subscription and tax tooling that tends to matter once you're past ~$10K MRR.

So you start on one, add another for a specific product or region, and now your revenue is genuinely split. Each platform handles its own sales, tax, and payouts as a merchant of record — which is great operationally, but it means your numbers are siloed by design.

Why incumbents don't solve it

The established analytics tools — Baremetrics, ChartMogul — were built around Stripe. Their integration lists reflect that: Stripe, Braintree, Recurly, Chargebee, the App Stores, and (for some) Paddle. Polar and Lemon Squeezy are barely covered, if at all. So the moment you adopt a newer MoR, the Stripe-era tools can't even see half your revenue, let alone consolidate it.

That leaves most multi-MoR founders doing it by hand: open each dashboard, copy each MRR, add them in a spreadsheet, repeat monthly. It's tedious and — as we'll see — often wrong.

Why naive consolidation is wrong

Adding two or three MRR numbers seems trivial. It isn't, because the inputs aren't consistent:

Different movement definitions. Each platform classifies new/expansion/contraction/churn its own way. Summing totals hides what actually changed.
Annual normalization. If annual plans aren't all divided by 12 the same way, every yearly sale distorts the combined figure.
Currency and rounding. Mixed currencies and per-platform rounding make the sum drift.
Snapshot timing. Platforms snapshot on different schedules; "today's MRR" isn't the same instant everywhere.
Churn timing. If one platform counts a scheduled cancellation as churn and another doesn't, your blended churn is meaningless.

The fix isn't better spreadsheet hygiene. It's a different architecture.

The clean architecture: normalize first, then sum

Consolidation works when you translate every event from every platform into one internal format before doing any math — a ports-and-adapters approach:

Adapters read each platform (Polar, Paddle, Lemon Squeezy) and emit a normalized event: a status plus a monthly-normalized amount in a single currency. No platform-specific quirks leak past this boundary.
One classifier turns state changes into signed movements — new, expansion, contraction, churn, reactivation — using identical rules everywhere.
One append-only MRR ledger holds every signed delta. Your MRR on any date is the sum of deltas up to that date; movement for a period is the deltas grouped by type.

Two invariants tell you it's correct:

Combined MRR = the sum of each platform's MRR.
Each platform's trend line sums to the combined trend line.

When those hold, the consolidated number isn't a guess — it's reconciled.

What good consolidation gives you

One MRR number for the whole business, with month-over-month change.
A per-platform breakdown (stacked area over time) so you can see who's growing and who's leaking.
A combined movement waterfall across all platforms at once.
Blended metrics — churn, ARPU, net revenue retention — computed over your entire customer base, not one silo.
Per-platform accuracy checks so each connection is validated against its own reported figure.

How Throughlines does it

Throughlines is built for this exact problem. It's a read-only revenue dashboard for merchant-of-record platforms, architected for N platforms from day one.

Connect each platform read-only (paste a token/key per platform). Throughlines backfills history and stays live via webhooks, and never writes to your accounts.
Consolidated MRR hero across Polar, Paddle, and Lemon Squeezy, with the delta vs. last month.
Per-platform stacked area + combined movement waterfall, reconciled so the parts always sum to the whole.
Canceled ≠ churned, enforced identically across every platform, so blended churn is honest.
Accuracy gate per connection. Each platform's computed MRR is cross-checked against the platform's own number.
Add a platform, not a migration. A fourth MoR is a new connection, not a re-tool.

The takeaway

If your revenue is spread across Polar, Paddle, and Lemon Squeezy, your true MRR isn't in any one dashboard — and you can't get it by adding numbers in a spreadsheet, because the inputs aren't consistent. Consolidation done right means normalizing every platform into one ledger so the combined number reconciles. That single, trustworthy number is the whole reason merchant-of-record-native analytics exist.

Consolidate your MRR across every platform →