Stripe Revenue Reports: MRR, Refunds and Failed Payments

A useful Stripe revenue report answers three questions: how much recurring revenue you have (MRR), how much of what you charged you kept (after refunds, disputes and fees), and how much you are losing to failed payments. Stripe records every charge, invoice and subscription, but the raw data is not a report. This guide shows which numbers to pull, how to calculate them, and how to lay them out so a founder or finance lead can read the month in two minutes.

Start with the questions, not the export

Stripe data is event-heavy: charges, payment intents, invoices, subscriptions, refunds, disputes, payouts and balance transactions. If you export everything and start building charts, you end up with a wall of numbers. Decide first what the report must answer each month:

• Is recurring revenue growing? MRR and net new MRR.
• Are customers staying? Customer churn and revenue churn.
• How much did we actually keep? Gross volume, refunds, disputes, fees and net revenue.
• Are we leaking money through failed payments? Failed payment rate and recovery rate.
• Does the cash match? Payouts reconciled to net revenue.

If you sell once-off products rather than subscriptions, skip MRR and focus on gross volume, average order value, refunds and disputes. Everything else in this guide still applies.

How to calculate MRR from Stripe data

Monthly recurring revenue (MRR) is the normalised monthly value of all active subscriptions at a point in time. It is not the same as what you invoiced this month. Normalise every subscription to a monthly amount: a R1,200 annual plan contributes R100 of MRR, not R1,200 in the month it was billed.

1. Take all subscriptions that are active on the last day of the month.
2. Convert each price to a monthly figure (annual ÷ 12, quarterly ÷ 3, weekly × 52 ÷ 12).
3. Apply recurring discounts, and exclude once-off setup fees and usage overages you don't expect to recur.
4. Exclude trials that have not converted yet.
5. Sum the result. That is your ending MRR.

Then break the movement down. Net new MRR = new MRR + expansion MRR − contraction MRR − churned MRR. Say you started September at R180,000 MRR, added R22,000 from new customers and R6,000 from upgrades, lost R4,000 to downgrades and R9,000 to cancellations. Net new MRR is R15,000 and you end at R195,000. That breakdown is far more useful than the headline: it tells you whether growth came from selling more or from losing less.

Refunds, disputes and fees: what you actually kept

Gross volume flatters you. A clean revenue section walks from gross to net in a simple table so nobody has to guess where the money went.

Refund rate = refunded amount ÷ gross volume for the same period. Track the count as well as the value, and group refunds by product or plan if you can: a refund rate that is fine overall can hide one product with a real problem. Treat disputes separately from refunds. A refund is a decision you made; a dispute is a customer going to their bank, and a rising dispute count is an early warning worth its own line.

Failed payments: the leak most reports miss

In subscription businesses, a meaningful share of churn is involuntary: the customer didn't decide to leave, their card simply failed. Report it explicitly:

• Failed payment rate = failed invoice payment attempts ÷ total attempts (or failed invoices ÷ invoices due).
• Recovery rate = failed invoices later paid ÷ all failed invoices in the period.
• MRR at risk = MRR on subscriptions currently past due or unpaid.
• Involuntary churn = MRR lost because subscriptions were cancelled after payment retries ran out.

Say 40 of 800 renewals failed in a month (5%), and 26 were recovered after retries and reminder emails (65% recovery). The 14 that were not recovered, worth R8,400 of MRR, belong in the churn figure, but labelled as involuntary. That distinction changes the fix: better dunning emails and card-update links, not a new retention offer.

Reconcile payouts to revenue

Finance will ask why the bank received a different amount from what the dashboard shows. Payouts are batched, net of fees, refunds and disputes, and timed differently from the charges that created them. Add a short reconciliation section each month: net revenue for the period, plus or minus timing differences, equals payouts received. If you invoice in rand and other currencies, state which currency each figure is in, and read reporting in rand with multiple currencies before you add them together.

A monthly Stripe report structure that works

1. Summary: three sentences on MRR, net revenue and the biggest change.
2. KPIs: ending MRR, net new MRR, customer churn, refund rate, failed payment rate, net revenue.
3. MRR movement chart: new, expansion, contraction and churn as a waterfall or stacked bar.
4. Revenue walk: gross to net table, as above.
5. Failed payments: failed, recovered, lost, MRR at risk.
6. Notes: plan changes, price increases, anything that explains an unusual number.

Summarix can connect Stripe as a data source, compute the figures with its own code rather than letting the AI estimate them, and write the summary and insights around those numbers. You can then schedule the report to arrive by email each month with a PDF attached. Whatever tool you use, the structure above is what makes the report readable.

Common pitfalls

• Counting annual invoices as a month's MRR, which creates fake spikes.
• Mixing test-mode and live-mode data.
• Including trials and zero-value subscriptions in customer counts.
• Adding currencies together without converting them.
• Reporting gross volume as revenue and never showing refunds or fees.

Get the definitions right once, write them at the bottom of the report, and keep them stable. A Stripe report that uses the same formulas every month is worth more than a clever one that changes each time.