What “verified revenue” actually means
Verified revenue is revenue calculated from records returned by a connected payment or subscription provider rather than copied from a screenshot or typed into a profile. The verification attaches evidence to the source of the data. It does not turn that data into an audit opinion.
On RevenueBug, “verified” means provider-connected. It does not mean RevenueBug has:
- audited the company’s financial statements;
- certified its accounting policies;
- confirmed that the profile owner owns the company or every product in the connected account;
- proved that all displayed revenue belongs to one named product;
- tested profitability, customer retention, liabilities, or tax compliance.
That boundary matters. A provider connection is stronger evidence than an editable claim because the underlying records come from an external system. But the records can still have a broader account scope, a provider-specific revenue definition, delayed adjustments, or transactions unrelated to the product being evaluated. Revenue verification is therefore useful evidence, not a substitute for diligence.
RevenueBug documents its own data boundary in the revenue verification methodology. Anyone comparing profiles should read that methodology before treating similarly named figures from different systems as equivalent.
Verified revenue is not necessarily verified MRR
Monthly recurring revenue (MRR) is a normalized snapshot of active recurring subscriptions:
Subscription MRR = sum of recurring subscription value normalized to one month
For example, a $120 monthly plan contributes $120 of MRR, while a $1,200 annual subscription contributes $100 of MRR. Setup fees, lifetime purchases, and other one-time sales normally contribute $0. Stripe’s own Billing analytics definition illustrates why the details matter: Stripe includes monthly-normalized active and past-due subscriptions, excludes taxes and free plans, and excludes metered products from its standard MRR calculation. Other systems can apply different status, discount, usage, and churn rules.
RevenueBug’s cross-provider headline metric is trailing-30-day provider-reported revenue, not native subscription MRR:
Trailing-30-day revenue = qualifying provider-reported revenue in the latest rolling 30 days
Qualifying refunds or disputes reduce the amount according to the provider adapter, and non-USD events are normalized for display as described in the methodology. The metric is rolling, so its start and end dates move every day. It is also transaction-oriented: depending on the provider data, it may include annual prepayments, usage charges, lifetime deals, services, or other one-time payments.
The two metrics answer different questions:
- Subscription MRR: What is the normalized monthly value of the current recurring base?
- Trailing-30-day revenue: How much qualifying provider-reported revenue occurred during the latest 30-day window?
- Cash deposits: How much money reached the bank after payout timing, processor fees, reserves, and other balance activity?
- Accounting revenue: How much revenue was recognized under the company’s accounting policy for the period?
None is automatically interchangeable with another. In particular, multiplying trailing-30-day revenue by 12 does not create ARR unless the underlying amount consists entirely of normalized recurring revenue.
A worked example: one account, three different numbers
Suppose a provider account reports the following activity in the latest 30 days:
- $7,200 collected from monthly subscriptions;
- $2,400 collected for one new annual subscription;
- $2,000 from lifetime licenses;
- $800 from setup services;
- $500 refunded;
- $300 disputed and deducted under the applicable provider treatment.
An illustrative trailing-30-day calculation is:
$7,200 + $2,400 + $2,000 + $800 − $500 − $300 = $11,600
Now calculate native subscription MRR from the active recurring contracts. Assume the monthly subscriptions still represent $7,200 per month and the annual contract is active for a 12-month term:
Subscription MRR = $7,200 + ($2,400 ÷ 12) = $7,400
The lifetime licenses and setup work do not enter MRR because they do not recur. The resulting figures are both defensible but describe different things: $11,600 of trailing provider-reported revenue versus $7,400 of normalized subscription MRR.
The bank deposit could be lower still because provider fees, payout schedules, reserves, or unrelated balance movements affect cash settlement. Stripe, for example, states that balance transactions represent funds entering or leaving the Stripe balance, and its reporting-category documentation separates charges, refunds, disputes, fees, transfers, and other balance activity. A bank payout is therefore not a clean proxy for either gross sales or MRR.
Use the MRR and ARR calculator when you have subscription-level amounts and terms to normalize. Do not enter an account’s trailing revenue as MRR merely because both are displayed as monthly-looking dollar values.
Provider scope is part of the claim
“Connected to a provider” does not tell you how narrowly the data maps to a product. The available scope depends on the provider, account structure, API, and integration implementation.
A processor account may combine several products, brands, or revenue types. A merchant-of-record platform may organize data around a store or organization. A mobile subscription platform may expose project-wide data covering multiple apps. RevenueCat’s Charts and Metrics API, for example, describes a revenue endpoint that totals revenue across all apps in a project, while chart-specific filters and segments vary by chart. That is a concrete reason not to assume every provider can always isolate one product.
Likewise, authorization methods and permissions vary across revenue platforms. RevenueBug’s current integrations use API credentials with provider-specific permissions; some providers offer narrowly restricted keys while others do not. The verified label alone should never be interpreted as proof that every credential is read-only. Owners should review the credential settings, grant only the access needed, rotate credentials when appropriate, and revoke access when they no longer want the connection active.
Before relying on a figure, identify:
- the provider and connected account, store, organization, project, or app;
- whether that scope contains one product or several;
- which transaction types and statuses are included;
- whether the amount is gross sales, net of refunds, net of fees, proceeds, MRR, or another provider-defined measure;
- the currency conversion policy;
- the last successful import time and covered date range.
The integrations directory is the right starting point for provider-specific context. Where the provider cannot reliably supply product-level attribution, the claim should remain at the broader account or project scope.
How to reconcile a verified revenue figure
A useful reconciliation does more than compare two totals. It explains why each difference exists.
1. Freeze the comparison window
Record the exact start timestamp, end timestamp, time zone, and “as of” time. “This month” and “last 30 days” are different windows except by coincidence. A rolling window can also change between export and review.
2. Record the metric definition
Write down the source objects and inclusion rules: successful charges, paid orders, renewals, refunds, disputes, taxes, fees, test transactions, and non-recurring sales. Name the metric exactly as the provider or RevenueBug names it.
3. Confirm the connected scope
List every product, app, storefront, or business using the credential. If transactions cannot be attributed cleanly, do not allocate them using an unsupported guess.
4. Rebuild the activity bridge
Start with included successful revenue events. Subtract included refunds and disputes. Keep processor fees, taxes, transfers, and payouts in separate lines unless the published definition explicitly incorporates them. This makes a gross-versus-net mismatch visible instead of hiding it in a single adjustment.
5. Normalize currency consistently
Retain the original amount and currency, the conversion date, the rate source, and the rounded display amount. A provider dashboard using current exchange rates can differ from a system using historical transaction-date rates without either system having lost a transaction.
6. Explain timing and revisions
Check event creation time versus settlement time, delayed webhooks or imports, late refunds, won or lost disputes, and backfilled provider corrections. Historical charts can legitimately change when later events alter the earlier economic result.
7. Tie out to independent evidence
For serious diligence, compare the event-level export with subscription records, provider balance reports, payout reports, bank statements, invoices, and management accounts. The goal is not to force every source to the same total; it is to create a documented bridge between totals with different purposes.
Common verification failure modes
Calling every connected figure MRR. A payment feed containing annual invoices and one-time sales proves payment activity, not normalized recurring value.
Assuming account revenue belongs to the listed product. Shared accounts can combine several products. Product attribution must be supported by provider fields or other transaction-level evidence.
Ignoring refunds and disputes. A gross collections chart can overstate retained revenue. Conversely, subtracting processor fees and calling the result “revenue” creates a different metric without saying so.
Comparing calendar months with rolling windows. February revenue, a 28-day provider overview, and the latest 30 days cover different periods.
Treating stale data as current. Imports can fail or lag. Always capture the last-updated timestamp and investigate gaps.
Using bank deposits as the transaction ledger. Deposits are affected by settlement timing, reserves, fees, currency conversion, and payout batching.
Equating verification with profitability or valuation. Revenue says nothing by itself about payroll, hosting, advertising, taxes, debt, owner workload, concentration, or churn.
Using verified revenue in a sale or fundraising process
For discovery, verified provider revenue can help a buyer or investor screen unsupported claims and observe recent direction. Browse startup profiles with the metric label and scope in mind, not as if every chart were audited subscription MRR.
For a transaction, founders should prepare a private evidence pack: provider exports, subscription and customer cohorts, refund and dispute history, bank tie-outs, expenses, tax records, code and domain ownership, major contracts, and an explanation of any shared provider account. A founder planning to submit a startup should make the public claim no narrower than the source data supports.
The practical standard is simple: preserve the provider-derived evidence, label the metric precisely, disclose its scope, and reconcile it to the rest of the business records. That makes verification useful without asking it to prove more than it can.
Frequently asked questions
Is verified revenue the same as audited revenue?
No. Verified means the number was derived from a connected provider. An audit involves independent procedures over financial statements, controls, evidence, and accounting policies. RevenueBug does not describe provider-connected profiles as audited or certified.
Does verified revenue prove the seller owns the startup?
No. Control of a provider connection does not by itself establish ownership of the company, source code, domain, trademarks, customer contracts, or every product in the account. Those require separate legal and operational diligence.
Is RevenueBug’s headline figure MRR?
No. RevenueBug’s cross-provider headline metric is trailing-30-day provider-reported revenue. It can differ materially from native subscription MRR when the business has annual billing, usage charges, one-time products, lifetime deals, refunds, or services.
Can one verified account include multiple products?
Yes. Provider scope may be account-, store-, organization-, project-, app-, or product-level, and some sources do not support reliable product-level attribution. Check the displayed scope and ask for supporting exports when evaluating a specific product.
Can historical verified revenue change?
Yes. Late refunds, disputes and reversals, provider corrections, delayed imports, and currency reconciliation can revise prior days. Record the “as of” time when using a figure in diligence.