How buyers verify MRR, and why screenshots are not enough

Monthly recurring revenue is the number most small SaaS deals are priced from, directly or indirectly. It is also the number most likely to be presented generously. Usually not dishonestly: founders tend to read MRR off whatever their dashboard shows, and dashboards make different choices about what counts.

A buyer's job is to rebuild MRR from the underlying data and confirm the money actually arrived. This guide covers how that is done. Sellers should read it too, because the cleanest way to hold your price is to present the number the buyer would have calculated anyway.

Why a screenshot proves very little

A screenshot of a billing dashboard shows a number on a screen at one moment. It does not show how the number was calculated, what was excluded, or whether the image was edited. Editing a screenshot takes seconds, and buyers who have been around small deals for a while have seen it happen.

Even an honest screenshot has limits. Different tools calculate MRR differently. Stripe's own billing analytics, third-party analytics tools and a founder's spreadsheet can all show different figures for the same account on the same day, and each can be defensible. A buyer cannot tell from a picture which choices were made.

What buyers want instead is data from the system of record: an export they can recalculate, a screen share where they watch the seller navigate the live dashboard, or read-only access to the billing account.

What MRR should and should not include

MRR is the normalized monthly value of active recurring subscriptions. The adjustments below are where most of the differences come from.

Annual and multi-month plans

An annual plan paid at $1,200 contributes $100 to MRR each month, not $1,200 in the month it was paid. Counting the full payment in one month inflates that month and makes growth look lumpier than it is. Quarterly plans are divided by three, and so on.

Trials

A customer on a free trial is not paying. They belong in MRR only once they convert and their first payment succeeds. Some tools count trialing subscriptions as MRR, which can overstate the number, especially right after a trial campaign.

Discounts and coupons

If a customer's list price is $50 a month and they have a 50% coupon, they contribute $25. A 100% discount contributes nothing. Buyers also ask when discounts end, because a coupon expiring in two months could either lift MRR or trigger churn.

Failed payments and past-due subscriptions

A subscription whose last payment failed may still show as active while the billing system retries the card. Some of those customers will recover, and some will not. Buyers usually want to see past-due MRR separately, and the historical recovery rate, rather than having it counted as healthy revenue.

One-time charges, setup fees and usage

Setup fees, one-off services and add-on purchases are revenue, but they are not recurring. Usage-based charges are a judgment call: many buyers exclude them from MRR and value them separately, or use an average of recent months.

Taxes, refunds and currency

Sales tax and VAT collected are not revenue. Refunded payments should come out. If you bill in several currencies, the conversion rate and date need to be consistent across months.

None of those adjustments involves bad faith. They are the kind of gap that appears when a number is read off a dashboard without asking how it was built. But a buyer who finds a quarter of the headline MRR disappearing on recalculation will reprice the deal and trust the rest of the data less.

Revenue is not MRR

MRR is a run rate. Revenue is money earned in a period, and cash collected is what actually hit the bank. A business can have growing MRR and falling cash collected in a month if many annual customers renewed the previous month. Buyers look at all three and expect them to tell a consistent story over twelve months or more:

• MRR by month, rebuilt from subscription data
• Gross charges, refunds and disputes by month, from the billing system
• Net payouts from the billing system to the bank
• Deposits received in the bank

If the P&L shows revenue that is materially higher than what the billing system collected, there needs to be an explanation, such as invoices paid by bank transfer outside the billing system.

Cross-checking payouts against bank deposits

This is the step that turns billing data from "a number in a dashboard" into money that demonstrably arrived. Billing platforms like Stripe pay out net of fees, refunds and disputes. Each payout should appear in the business bank account as a deposit of exactly the same amount, usually within a few days of the payout date.

A buyer takes the payout list for the last 12 months, takes the bank statements for the same period, and matches them. Unmatched payouts, or payouts that match a different account than the one in the data room, are questions the seller will need to answer. Our guide to reconciling Stripe payouts with bank deposits covers the matching rules and the usual reasons items do not match.

How buyers get the data

In order of how much buyers trust it:

1. Read-only access to the billing account, through a restricted API key or a connected tool. The data comes straight from the source and can be recalculated. See how to create a read-only Stripe key.
2. A live screen share where the seller navigates the billing dashboard while the buyer watches and asks questions.
3. CSV exports of subscriptions, invoices, charges and payouts, which the buyer rebuilds in a spreadsheet.
4. Screenshots and spreadsheets prepared by the seller, which buyers treat as claims to be checked.

For sellers: calculate it the buyer's way first

Before you list, rebuild your own MRR with the adjustments above, write down how you calculated it, and put that method in your data room. If your number goes down, better that you find out now than in the middle of a negotiation. Our SaaS due diligence checklist covers the rest of what buyers will check.

How Arrhis shows MRR

Arrhis pulls subscriptions, invoices and payouts from Stripe with a read-only key, so buyers work from the system of record instead of a screenshot. Payouts are matched against deposits in your connected bank account by exact amount within three days. Every figure is labelled "From Stripe", "From Mercury", or "Uploaded by seller", so a buyer can see what came from a system of record. Create a deal room, open the demo room, or compare it with sharing files from Google Drive.