How to calculate MRR from Stripe subscriptions and invoices

To calculate monthly recurring revenue from Stripe, convert every active subscription to a monthly value (list price times quantity, with yearly and weekly plans normalised to a month) and add them up. Your dashboard figure may differ, and the gap is usually coupons, usage-based plans or currencies. Here are the rules I use and what to do when numbers do not match.

What is the basic formula?

For each subscription item, multiply the unit amount by the quantity and convert it to a month:

• Monthly plan: price times quantity.
• Yearly plan: price times quantity, divided by 12.
• Weekly plan: price times quantity, multiplied by 365, divided by 12, divided by 7.
• Plans with an interval count, such as every three months: divide by the count too.

Add the items for a subscription, then add the subscriptions. That total is your list-price recurring revenue. It is the value my report uses for every leak, so that the buckets can be compared with each other.

Which subscriptions count?

For the figure called active recurring revenue, I include subscriptions with the status active, past due or unpaid. Trials are separate, since nobody has paid yet. Cancelled subscriptions leave the base on the day they cancel.

If you include past-due subscriptions, you are counting revenue that may not arrive. That is a choice, so state it. Mine puts the failing ones in a separate number, the recurring revenue at risk, which I cover in what MRR at risk is.

Why does my number not match Stripe's dashboard?

Because the two use different rules. These are the usual causes:

• Coupons and discounts. I use list price before coupons, which slightly overstates accounts with heavy discounts. A figure after discounts will be lower.
• Usage-based plans. There is no fixed unit price. I fall back to the last paid invoice for those subscriptions.
• Currencies. If you bill in more than one, a single number needs a conversion rate. Without one, I exclude the other currencies and say how many subscriptions that removes.
• Status rules. Whether past-due and paused subscriptions count differs between tools.
• Timing. A mid-cycle plan change shows up on the next full invoice, so the snapshot can lag by one cycle.

Before I send a report, I compare active recurring revenue with the customer's dashboard figure. I look for agreement within about 10%. More than that, and I stop and ask what differs. Do the same check on your own calculation.

How do I use invoices instead of subscriptions?

Sometimes you need invoices: a subscription object with no clear price, or a history of plan changes. In that case, take the lines on each invoice, skip proration lines, and convert each line to a monthly amount using its period. A line covering about a month is already monthly. A line covering about a year is divided by 12. I use the amount before discounts so that a coupon does not look like a downgrade.

Proration lines are skipped because they describe a mid-cycle adjustment, not the plan's real price. If you count them you will see ghost changes in the data.

What does this have to do with leaks?

Every number in a leak report is a value in monthly terms, and if the base is wrong, everything built on it is wrong. A cancellation is valued at the subscription's monthly value. A downgrade is the fall in monthly value between two paid invoices. An unconverted trial is the monthly price of the plan trialled. A failed payment is the exception, counted as cash for the invoice amount.

That is also why I state a caveat next to each number rather than hiding it in a footnote. A reader should be able to see which rule produced it. For one of those rules in detail, read are downgrades a revenue leak.

Should I count the revenue a lost customer would have paid later?

I do not. A cancelled subscription's value is counted once, in the month of cancellation. The revenue the customer would have paid in later months is not added. That keeps the monthly headline conservative and simple to check. If you want a lifetime-value view, you can build it on top, but you would be adding assumptions about how long that customer would have stayed, and I do not have a source for those.

What is the quickest way to get this wrong?

Mixing a point-in-time snapshot with a period total. Recurring revenue is a snapshot of one day. A leak per month is a total over a window divided by the months in it. If you divide a snapshot by a window, or compare a quarterly total with a monthly one, the ratios will mislead you.

Write the window down. Mine is 365 days, or the real age of the account if it is younger, with a floor of 30 days. Then every monthly figure is the window total divided by the months observed.

How do I document my calculation?

Write down the window, the statuses you included, the currency handling, whether you used list price or collected amounts, and the date you ran it. One paragraph is enough. Next quarter you will not remember, and neither will the person who inherits the sheet.

Do I need help with this?

For a small account, no. A spreadsheet export and half an hour will do. With thousands of subscriptions and several plan intervals, careful counting becomes the slow part. The Revenue Leak Report is $490 and does it from a read-only key. See the sample (synthetic data) for how the base figure appears: a fictional company with $80,330 of recurring revenue.