How do I verify a seller's revenue?

What is the one thing that actually proves revenue?

A live screen-share of the payment processor dashboard, driven by the seller while you name the date ranges, is the only routine check that proves revenue at this size. Everything else is corroboration. A screenshot is an image, an exported PDF is a file, and a spreadsheet is a document the seller typed. All three can be produced in a few minutes by anyone with a browser and a text editor, and at six figures that is a risk you do not need to carry.

Nobody needs to take the request personally. It is a fifteen-minute call that removes the single largest category of loss in small software acquisitions, and an honest seller will find it unremarkable.

How do you run the screen-share?

Run it as a call where you do the directing and the seller does the clicking, on the live dashboard rather than on anything prepared in advance. Ask them to start by logging in while sharing, so you see the authentication rather than an already-open tab. Then work through a fixed list, naming the date ranges yourself so nothing has been set up ahead of the call.

1. Log in live, with the account email visible in the profile menu.
2. Set the reporting period to the trailing twelve months and read the gross volume.
3. Change it to three specific months you name at random, one of them recent.
4. Open the payouts or transfers list and show the destination bank account's last four digits.
5. Show active subscriptions, with the count and the total MRR, and sort by amount.
6. Open the refunds and disputes view for the same twelve months.
7. Open failed payments and involuntary churn for the last three months.
8. Filter customers by creation date to show how many of the current subscribers are older than a year.
9. Export a customer-level CSV during the call and email it to you before you hang up.

The CSV matters because it lets you do arithmetic afterwards that the dashboard does not present. Sum it, compare the total against the gross volume you watched, and check that the MRR implied by the subscription list matches the MRR in the listing.

What should you cross-check afterwards?

Cross-check the processor against two independent sources: the bank and the product itself. Processor payouts should land in bank statements at the expected cadence, with amounts that match after fees. Active subscriptions in the processor should correspond to active accounts in the application database, and a large gap in either direction needs an explanation.

Where the seller trades through a company, ask for the filed accounts or the tax return covering the trailing period. It will not match the processor exactly and it is not supposed to. It should be in the same neighbourhood, and it establishes that the business exists to somebody other than the seller.

What does gross volume hide?

Gross volume hides fees, refunds, failed payments and annual prepayments, and all four move the number you should be pricing on. A business showing $40,000 of gross volume over twelve months has paid roughly $1,400 in processing fees before anything else happens. Refunds and disputes come out next, then any revenue that arrived as a twelve-month prepayment and will not recur for another year.

Ask specifically for net volume after refunds and fees, and for the split between monthly and annual plans. A seller quoting MRR that includes annual subscriptions divided by twelve is quoting accurately. A seller quoting MRR that counts the whole annual payment in the month it landed is quoting something else, and you will find it in the CSV.

What counts as weak evidence?

Screenshots, PDF exports, spreadsheet summaries and third-party dashboard images are all weak evidence on their own. So is a screen-share of a spreadsheet, which is the same document with a webcam pointed at it. Analytics traffic figures prove nothing about revenue and should never substitute for processor data.

A seller who offers a screenshot instead of a call is not automatically dishonest. Ask once, plainly: "Can we do fifteen minutes on a call with the dashboard open, at whatever time suits you?" If the answer is no, or the calls keep being rearranged, or the account is suddenly locked for a security review, treat the revenue as unproven and price accordingly. In practice that means walking.

When should you do this?

Do it before diligence, not during it. Confirming revenue is cheap and fast, and technical diligence is neither, so there is no reason to read a codebase for a week before finding out whether the business earns what the listing says. On a pre-screened listing the seller has already been through an identity check, which narrows the question from "is this person real" to "is this number accurate", and the screen-share answers the second.

Then do it once more, briefly, immediately before funds are released. Revenue at signing should look like revenue at close, and a month can change a business. Ten minutes on the dashboard at the end of the process protects the whole of it.

Related: how-to-tell-if-revenue-screenshots-are-real, do-i-need-to-show-stripe-data, due-diligence-for-a-100k-deal