How to verify a startup's revenue before you buy it

To verify a startup's revenue, get the data from the source instead of from the seller. Ask for read-only access to the payment provider (Stripe, Paddle, RevenueCat, App Store Connect), work out MRR yourself from active subscriptions, and match the provider's payouts to deposits in the seller's bank account. Screenshots, spreadsheets and pitch decks are claims, not evidence.

This guide covers what to ask for, how revenue figures get inflated (on purpose or by accident), and a checklist to work through before you send an offer. It is written for buyers of small SaaS and app businesses, roughly under $1M in annual revenue, where there is usually no audited accounts and no broker doing the work for you.

Why aren't screenshots enough?

A screenshot shows what the seller chose to show. It can be edited, cropped to the best months, taken from a test-mode account, or show a different product's revenue in the same account. Even an honest screenshot of a Stripe dashboard mixes things that aren't recurring revenue, like one-off payments and annual plans counted in the month they were paid.

You don't need to assume bad faith to insist on source data. Many sellers simply calculate MRR differently from how a buyer would, and the gap only shows up when someone looks at the raw subscriptions.

What access should you ask the seller for?

Ask for read-only access to the account that takes the payments. It lets you see everything and change nothing, so a reasonable seller has little reason to refuse once you've shown you are a serious buyer.

Provider	What to ask for
Stripe	A View only team member invite on the live account, or a restricted API key (starts with rk_live_) with read permissions only. Never a full secret key.
Paddle, Lemon Squeezy and similar	A read-only team seat, or exports of subscriptions and transactions sent live on a call.
RevenueCat (App Store and Google Play apps)	A read-only collaborator invite on the project, plus the store's own financial reports.
App Store Connect / Google Play Console	Payments and financial reports for the last 12 months, shown live on a screen share if they won't add you.
Bank account	Statements covering the same 12 months, so you can match payouts.

If the seller won't give access before an offer, a common middle ground is a screen share where you say what to click. What you are avoiding is a pre-recorded tour.

How do you calculate MRR yourself?

MRR is the monthly value of active, paying subscriptions, after discounts. Work it out from the subscription list, not from the payments list:

1. Take active subscriptions only. Include past-due ones if you want, but note them. Exclude trials, cancelled subscriptions and ones that are paused or unpaid.
2. Normalise to a month. An annual plan at $1,200 is $100 MRR, not $1,200 in the month it was paid. A weekly plan at $5 is about $21.67 ($5 × 52 ÷ 12).
3. Apply discounts. A $50 plan with a permanent 20% coupon is $40 MRR. A 100%-off coupon is $0, however many of those customers there are.
4. Leave out one-time payments. Setup fees, lifetime deals, consulting invoices and top-ups are revenue, but not recurring revenue.
5. Convert currencies at one rate. If the account bills in several currencies, convert everything at the same date's rate so months stay comparable.

Then compare your number with the seller's. A difference of a few percent is normal rounding and timing. A difference of 20% or more needs an explanation before you go further.

How do you check the revenue actually reached the bank?

Match the payment provider's payouts to deposits on the seller's bank statements for at least three months. Stripe lists every payout under Balance → Payouts, with the date and amount. Each one should appear in the bank account within a few days.

This catches the rare but serious case of a fabricated or test account, and it also tells you about refunds, disputes and fees, which reduce what the business really keeps. If payouts go to an account that isn't the business's, ask why; it may be fine (a personal account for a small side project) but it affects how the handover works.

What are the common ways revenue gets inflated?

Most inflated numbers come from a handful of patterns. Check for each one in the raw data.

One-off and annual payments counted as monthly

The most common mistake. A month with three annual renewals looks like a growth spike. Look at the billing interval of each subscription and recalculate.

Cherry-picked months

A seller shows the last 30 days after a launch or a promotion. Ask for 12 months of MRR history and look at the trend, not the latest figure. If the account is less than three months old, you are buying a guess.

Free or near-free customers

Customers on 100%-off coupons, or on a price far below the list price, inflate customer counts and sometimes "MRR" if gross amounts are used. Count how much subscription value sits on heavy discounts and when those discounts end.

One customer, or a friendly one

If one customer pays a large share of MRR, the business is really a contract with that customer. Check who the top five customers are, how long they have paid, and whether any of them share a name, email domain or card with the seller. Payments from the founder's own companies or friends are hard to spot, which is why concentration alone is worth flagging.

Revenue from another product

One Stripe account often bills several products. Filter subscriptions by product or price ID and count only what is being sold. Ask how the other products will be separated at handover.

Refunds, disputes and churn hidden by new sales

Gross sales can rise while the business shrinks. Look at refunds and disputes per month, and at how many subscriptions were cancelled versus started. Monthly churn above about 10% means the customer base largely turns over within a year, whatever the headline MRR says.

Due diligence checklist for revenue

Work through this before you make an offer, or make your offer conditional on it.

• Read-only access to the live payment account (not test mode)
• MRR rebuilt from active subscriptions, normalised, net of discounts
• 12 months of MRR history, with any spike or drop explained
• Payouts matched to bank deposits for at least three months
• Top five customers identified, with their share of MRR
• Share of subscriptions on 100%-off or heavy coupons, and when they expire
• Monthly churn and refunds for the last six months
• Only the product being sold included in the figures
• Age of the payment account, and why it's new if it is
• A plan for transferring subscriptions or the account itself at handover

Revenue is one part of due diligence. You will also want to check code ownership, the domain, hosting and third-party accounts, app store accounts, and the legal side of the sale with a lawyer. Those are outside the scope of this article.

How does provider-verified revenue help?

Some marketplaces connect to the payment provider directly, so the figures on a listing come from the provider instead of from the seller. That does a large part of the checklist above before you even contact the seller, and it means every listing is measured the same way.

On VerifyArr, every startup connects Stripe or RevenueCat with a read-only key, and the metrics are resynced every hour. For Stripe, MRR is computed from the subscriptions themselves using the rules above: active and past-due only, normalised to monthly, discounts applied, one-time payments excluded. Each startup page shows 12 months of history, growth, churn and customer count, and Stripe-connected startups are flagged when:

• one customer makes up more than 30% of MRR,
• more than 20% of subscription value is on 100%-off coupons, or
• the Stripe account is less than 90 days old.

The verified badge comes off if syncing stops for 48 hours, so a revoked key doesn't leave old numbers on display. VerifyArr doesn't check bank deposits, code or company ownership, so the payout match and the rest of your diligence are still yours to do. What it removes is the argument about whether the headline number is real.

Frequently asked questions

Can a Stripe dashboard be faked?

A screenshot can be edited, and a test-mode account can be filled with fake payments that look real. Live access to the account, plus payouts that match bank deposits, is very hard to fake.

Is it safe for a seller to give a buyer a Stripe API key?

A restricted key with read-only permissions can't move money, issue refunds or change customers. A full secret key can, and a seller should never share one. A View only team invite is the simplest option for a single buyer; the seller can remove it at any time.

How many months of revenue history should a buyer ask for?

At least 12. That covers seasonality and annual renewals, and shows whether growth is steady or came from one launch. For a business younger than 12 months, ask for everything since the first payment and price the uncertainty in.

What is the difference between MRR and revenue?

Revenue is everything the business was paid in a period, including one-off sales. MRR is only the recurring part, expressed per month. A business with $10k revenue last month can have $4k MRR if most of it came from annual plans and lifetime deals.

Should the seller's MRR match what Stripe shows?

Roughly. Stripe's own MRR figure and a buyer's calculation can differ because of how each treats past-due subscriptions, trials, discounts and currency conversion. Ask which rules the seller used, then use your own.

---

If you're looking for a business to buy, browse startups with verified revenue or see median asking multiples by category on the stats page. Selling instead? Read where to sell a small SaaS.