Do refunds reduce MRR? The honest answer

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

A refund reduces your gross revenue directly — it's cash leaving your account, full stop. But it only reduces MRR if the subscription that got refunded also gets canceled. A refunded customer who is still active on a recurring plan still counts toward MRR, because MRR measures the recurring base you're forecasting forward, not the cash that has already moved. Mixing the two up is one of the fastest ways to make your dashboard lie to you.

Two different questions, two different numbers

"How much cash came in this month?" and "How much recurring revenue am I carrying into next month?" are not the same question, and a refund doesn't answer them the same way.

Gross revenue (or net revenue, if you want to be precise) is a ledger of money that actually moved. A refund is a debit against that ledger. If a customer paid $39 in June and you refunded $39 in July, your July gross is $39 lower than it would otherwise have been. That's not up for debate — it's accounting.

MRR is a snapshot of the recurring commitments you currently have, expressed as a monthly rate. It answers "if nothing changes, what do I collect next month?" A refund, by itself, changes nothing about that forward-looking commitment. The subscription is either still active (the customer keeps their access, keeps their billing schedule, and will be charged again next cycle) or it isn't. If it's still active, it's still part of your recurring base — refund or no refund.

This is why "just subtract the refund from MRR" is the wrong reflex. It conflates a past cash event with a forward-looking commitment. The two only move together when the refund is bundled with a cancellation.

Full refund + cancel vs. partial or goodwill refund

The cleanest case is a full refund paired with a cancellation — someone asks for their money back and closes the account in the same motion. Here, both numbers move: gross revenue drops by the refunded amount, and MRR drops by that customer's monthly value, because the recurring relationship is over. If a $79 Portfolio customer refunds and cancels, your MRR should fall by $79 in the same period the cancellation is processed — the refund and the churn are two effects of one underlying event, not one effect counted twice.

The messier, more common case is a partial or goodwill refund on a subscription that stays active. Someone was double-charged, had a billing dispute, or you just decided to smooth things over with a partial credit — and they keep using the product on the same plan. Here, gross revenue takes the hit for the refunded amount, but MRR doesn't move at all, because the subscription itself is unchanged. The customer is still going to be billed the same amount next cycle. If you subtract the refund from MRR here, you're double-penalizing yourself: once in gross (correctly), and again in MRR (incorrectly), for a customer who is still fully on your recurring books.

A useful gut check: ask whether the subscription changed or just the cash. If only cash moved, only gross moves. If the subscription itself was canceled, downgraded, or paused, MRR moves too — and it moves for the plan-change reason, not because a refund happened to be issued alongside it.

Chargebacks are the same story, with a lag

Chargebacks behave almost identically to refunds for this purpose, with one practical wrinkle: they usually arrive weeks after the original charge, initiated by the customer's bank rather than by you, and they often come with a fee on top of the reversed amount. Same rule applies — a chargeback reduces gross revenue by the disputed amount (plus any fee), and it should only reduce MRR if the underlying subscription is also being terminated (which most processors do automatically once a chargeback is filed, since continuing to bill a customer who disputed a charge is asking for another one). The confusion with chargebacks tends to be less about the metric logic and more about timing — a chargeback filed in August against a June charge shows up as a gross-revenue adjustment in August's books, not a retroactive rewrite of June.

How Stripe and RevenueCat surface this

Stripe treats refunds as their own object, separate from the subscription's status. You can fully refund a charge without touching the subscription at all — the charge.refunded event fires, your net volume drops in the dashboard, and the subscription keeps renewing untouched unless you separately call cancel or Stripe's own dunning/cancellation logic kicks in. Stripe's revenue reporting (and its Refunded filter in the Payments view) is built around cash movement, not recurring-base movement — it has no native "recurring revenue" concept at all, which is exactly why founders end up needing a separate MRR calculation on top of it.

RevenueCat is similar but mobile-flavored: refunds usually originate from Apple or Google (a customer requests one through the App Store or Play Store, not through you), and RevenueCat surfaces them as refund events tied to a transaction, distinct from the subscriber's entitlement status. A refunded IAP doesn't automatically revoke the entitlement or cancel the subscription — Apple and Google have their own policies on that, and it varies by region and reason. So the same principle holds: check whether the subscriber is still active before you touch MRR, not just whether a refund event fired.

Neither platform hands you a single number that already nets out "refunds that mattered to MRR" from "refunds that didn't." That reconciliation — matching a refund event to whether the underlying subscription survived it — is manual work if you're stitching Stripe and RevenueCat together yourself, which is the exact gap a tool for tracking revenue as a solo founder is meant to close.

The practical rule

Keep two numbers, and don't let one bleed into the other by reflex:

• Gross (or net) revenue — the cash that actually moved, refunds and chargebacks subtracted, full stop. This is your "did I actually get paid" number.
• MRR — the recurring base you're carrying forward, which only changes when a subscription itself is created, upgraded, downgraded, or canceled. This is your "what should I expect next month" number.

A refund touches the first number always. It touches the second number only when it comes bundled with a plan change. If you're unsure which bucket a given refund falls into, the question to ask isn't "did money go back" — it's "is this customer still going to be billed next cycle." For the mechanics of the second half of that equation — how a cancellation actually moves through your churn math — see how to calculate your churn rate, and for the broader distinction between a point-in-time recurring number and its annualized cousin, see ARR vs. MRR for small SaaS.

Disclosure: SoleOS published this guide. We built SoleOS to pull revenue data from Stripe, RevenueCat, and app-store reporting into one place and keep gross and MRR as separate, correctly-attributed numbers — see the full breakdown on our metrics page. You don't need it if you're running a single Stripe-billed product with no mobile IAP and you're comfortable reading Stripe's own reports directly — at that scale, a spreadsheet and a little discipline about this exact distinction will get you just as far.

Frequently asked questions

If I refund a customer but they stay subscribed, does my MRR go down at all?

No. MRR reflects the recurring commitment on the books, and that commitment is unchanged — the customer is still on the same plan and will be billed again next cycle. Your gross revenue for the period drops by the refunded amount; your MRR does not.

What if I give a partial refund as a discount, then also change their plan?

Treat them as two separate events. The partial refund reduces gross revenue by the refunded amount. The plan change (upgrade or downgrade) moves MRR by the difference between the old and new plan value, independent of the refund. Don't let the refund amount influence the MRR adjustment — the MRR math only cares about the new recurring rate versus the old one.

Do annual-plan refunds work the same way?

The gross-vs-MRR split still holds, but annual plans add a wrinkle: MRR for an annual subscriber is usually the annual price divided by twelve, so a mid-term refund on an annual plan (with cancellation) should reduce MRR by that monthly-equivalent amount, not the full refunded lump sum. If the annual subscriber isn't canceling, MRR doesn't move regardless of how much cash was refunded.

Should refunds show up in my churn rate?

Only when they come with a cancellation. A refund with no cancellation is a revenue-recognition event, not a churn event, so it shouldn't be counted in customer or revenue churn. A refund-plus-cancel is churn, and it should be counted the same way any other cancellation is.

How far back should I expect refund and chargeback timing to lag the original charge?

There's no fixed window — it depends on your refund policy, the processor, and (for chargebacks) the customer's bank, which can take weeks to file a dispute. The practical implication is the same either way: record the adjustment in the period it actually happens, not by rewriting the original charge's period.