Verified revenue vs screenshots: avoiding fake numbers

A screenshot of revenue proves almost nothing, because anyone can edit it in a few minutes. Verified revenue means you or a trusted platform saw the numbers inside the payment provider itself, then matched them with bank deposits and the seller's accounts. If a seller will not allow that, treat the revenue as unproven.

This is general education, not legal or financial advice. If you suspect fraud, speak to a lawyer.

Why screenshots fail

A dashboard screenshot is an image. It does not show whether the number is real, whether it covers the right dates, or whether refunds, disputes and test payments are included. A seller can crop, edit, photograph a different account or simply show an old peak.

Even honest sellers share misleading screenshots by accident. Common examples include:

• A gross revenue figure that ignores refunds and chargebacks.
• A single great month presented as typical.
• A figure that includes one-time payments in a business marketed as recurring.
• Revenue from a related business mixed into the totals.

Treat screenshots like a sales brochure. They show what the seller wants you to see.

What "verified" should mean

Proper verification has three layers, and each catches different problems.

Layer 1. Source data from the payment provider

You or the platform sees the data directly in the payment system. Stripe, for example, lets an account owner create restricted API keys with read-only permissions, so they can share data without giving up control. Stripe's documentation on restricted API keys describes how a key can be limited to reading only specific resources. That is the technical reason a read-only connection is a reasonable thing to ask for.

Marketplaces use similar connections. Acquire.com says its listings show live metrics, and Empire Flippers says it checks that real revenue and profit are there. Neither page spells out the method in full, so ask the platform which systems it connects to and what it checks manually.

Layer 2. Bank deposits

Payment providers send money to a bank account in payouts. Match each month's payouts to the provider's reported totals, allowing for fees, refunds and timing. If revenue on the dashboard is high and bank deposits are low, something is wrong.

Layer 3. Accounting records

A profit and loss statement, tax filings or accountant-prepared books should agree with the first two layers. FE International's sell-side checklist says buyers typically try to tie revenue to bank statements, rebuild ARR from contracts and check every add-back against source documents. Do the same.

A step-by-step verification method

1. Ask for read-only access. Request a live view, not an export. If the seller is nervous, offer a screen-share where they log in and you choose the reports.
2. Pull 12 to 24 months of monthly data. One month is easy to stage. Two years is much harder.
3. Separate recurring from one-time revenue. List subscriptions, one-off purchases and anything else. Only recurring revenue earns a recurring multiple.
4. Reconcile with the bank. Match payouts to reported revenue, month by month.
5. Check refunds and disputes. A rising refund rate can signal an unhappy customer base or an aggressive sales tactic.
6. List customers. Count unique paying customers and look at the revenue per customer. Revenue concentrated in a handful of accounts is more fragile.
7. Rebuild the profit. Add real costs such as hosting, AI usage and support, and compare with the seller's claim.
8. Ask who verified it. If a platform says metrics are verified, ask exactly what was checked and what was not.

Red flags in revenue claims

• Only images, no live access.
• Account recently created, with large revenue in the first month or two.
• Revenue figures that do not match bank payouts.
• Payments from the same few cards or customers repeated each month.
• Unusually high revenue with very little traffic or social presence.
• Willingness to move to private payment or skip escrow.
• Pressure to decide quickly "because other buyers are circling."

For more patterns, read our guide to red flags in startup listings.

Use outside data as a cross-check

Outside data cannot prove revenue, but it can catch claims that do not fit. The StartupsIntel traffic checker models monthly visits for any domain using five public popularity lists, and then estimates revenue using a simple formula: visits times a 3 percent paying rate times the lowest paid plan, with 80 percent of customers on monthly plans and 20 percent on yearly. That is an estimate, not a measurement, and it is always labelled so.

How to use it:

• If a listing claims revenue far above the modelled range, ask why. There may be a good explanation, such as strong paid acquisition, enterprise contracts or a big existing email list.
• If a listing claims very little revenue but the modelled traffic is large, the product may be underpriced or badly monetized, which could be an opportunity.
• Compare against peers in the revenue rankings to see whether the claim is in a sensible range for the category.

The methodology page explains the model and its limits in full.

What verified revenue still does not prove

Even a clean, verified revenue history leaves open questions.

• Sustainability. Past revenue does not guarantee future revenue. Check retention and the reasons customers leave.
• Profit. Revenue can be real while costs make the business unprofitable.
• Ownership. The seller may not own all the code, brand or customer data.
• Quality of customers. A large share of free trials, discounted customers or customers on the verge of canceling lowers value.

Pair revenue verification with the full due diligence checklist.

A short example of reconciliation

Imagine a listing claims $6,000 in monthly revenue. The payment dashboard shows $6,000 in gross charges, but refunds took $600 and fees took $200, leaving $5,200. Bank payouts for the month show $5,100 because one payout landed a day late. Those gaps are normal and easy to explain.

Now imagine the bank shows only $2,500. That is not timing. Either charges were refunded later, the dashboard includes test or related-party payments, or the bank account is not the one the seller showed you. Ask for payout reports for that month and do not move forward until the difference is explained in documents.

What to do if numbers do not add up

1. Ask politely and specifically. "The Stripe total for March is lower than the screenshot. Can you explain the difference?"
2. Give the seller a chance to correct honest errors. Many mismatches are timing or refunds.
3. Stop if answers are vague or change. Inconsistent explanations are a strong warning.
4. Do not pay outside escrow. If you have already sent money, contact the payment provider and platform quickly.
5. Report suspected fraud to the marketplace and to relevant authorities.

For sellers: make your numbers easy to trust

If you are on the other side of the table, verification helps you. Connect your payment provider read-only, keep clean books, reconcile every month and explain unusual spikes. Buyers pay more when they trust the numbers, and deals close faster. See our guide on how to sell your startup.

If you prefer to skip the guesswork, the Buy a startup marketplace lists startups with revenue verified from the payment provider.

FAQ

Are screenshots ever acceptable as proof of revenue?

They can be a first look, but never final proof. Treat them as a starting point and always follow up with live read-only access and bank reconciliation.

How can a seller share Stripe data safely?

By creating a restricted API key or read-only user that can see only the data you need. This lets you see numbers without moving money or changing settings.

What if the seller refuses to give access?

That is a major warning sign. Some sellers need an NDA first, which is reasonable, but a flat refusal to verify revenue means you should not pay a revenue-based price.

Does verified revenue mean the business is a good buy?

No. It only means the revenue is real. You still need to check churn, costs, code, contracts and dependency risks.