Can you trust TrustMRR revenue numbers?

Why is “verified revenue” on TrustMRR easy to misunderstand?

TrustMRR’s “verified revenue” is much stronger than self-reported revenue, but the word “verified” currently covers less than many readers probably assume.

TrustMRR was built around a good idea: instead of asking founders to type their revenue into a profile or upload a screenshot, it connects directly to a payment provider through a read-only API key. TrustMRR’s current FAQ says Stripe, LemonSqueezy, Polar, Paddle, DodoPayment, RevenueCat, Superwall and Creem are supported, and a payment connection is required to create a verified listing.

That removes a huge source of uncertainty. When a founder tweets that a SaaS makes $20,000 MRR, we are largely trusting the founder. When TrustMRR shows roughly $20,000 MRR from a connected Stripe account, we have independent evidence that the payment account contains data supporting roughly that figure.

The confusion starts when “payment-provider verified” quietly becomes “financially verified.” Those are different standards. TrustMRR can establish where the underlying data came from without proving everything we might want to know about the business behind it.

A TrustMRR number can therefore be genuine and still answer a narrower question than the reader thinks it answers.

What does TrustMRR actually verify?

TrustMRR currently verifies revenue metrics pulled from a connected payment provider, which gives us good evidence about the payment account but much less evidence about the company’s full financial picture.

According to TrustMRR’s FAQ, the platform stores aggregate figures such as total revenue, MRR, last-30-day revenue, customer count and active subscriptions. The connection uses a read-only or scoped API key, so TrustMRR cannot create charges or alter the payment account.

That is a meaningful verification layer. We know the financial metrics were generated from provider data rather than typed manually into the profile.

TrustMRR also deliberately keeps the data relatively high-level. Its FAQ says it does not collect customer PII, while the terms describe the collected information as revenue-related metrics rather than a complete accounting ledger.

So when we see $40,000 of verified revenue, we have strong evidence that the connected provider recorded roughly that level of activity under TrustMRR’s calculation. We still do not know from the public number alone who paid, why they paid, whether one customer generated most of it, how much was refunded later, how profitable it was, or whether every payment belongs exclusively to the product named on the page.

That is a useful amount of verification. It just stops earlier than an audit.

Can a founder just type a fake revenue number into TrustMRR?

No. A founder cannot simply open a TrustMRR profile and replace $2,000 of verified revenue with $20,000.

TrustMRR says there is no manual alternative to connecting a supported payment provider when adding a verified startup. Founders can edit descriptive information such as the startup name, website, category, pricing, audience and product description, but the verified revenue metrics come from the provider connection.

That blocks the easiest form of fake MRR.

A normal revenue screenshot gives the founder control over almost everything the reader sees. The founder chooses the dashboard, time period, crop and surrounding context, and a fabricated screenshot can look convincing enough on social media. TrustMRR takes the key number out of that process.

Could someone create artificial transactions inside a real payment account? In principle, payment verification cannot make that logically impossible. But now the person has to manufacture actual payment activity rather than alter pixels or type a number into a database. Fees, refunds, chargebacks and payment-provider fraud systems make that a much more cumbersome game.

The practical point is simpler: TrustMRR makes basic revenue fabrication substantially harder.

Does TrustMRR prove the revenue belongs to that exact startup?

Only partly. TrustMRR proves the connection to a payment-provider account more strongly than it proves the exact boundary between that account and the startup shown on the page.

A payment account and a product are not always the same thing. One company can sell several products through the same processor. A founder can combine software, consulting, implementation work, digital products or another revenue stream inside one business.

TrustMRR’s public verification documentation does not say it inspects every transaction and attributes each payment to the specific product represented by the profile. In fact, the FAQ says TrustMRR stores aggregate revenue metrics rather than customer or transaction-level data.

That leaves a gap between “this connected account has generated this money” and “this exact product generated every dollar shown here.”

TrustMRR’s current marketplace terms reinforce the distinction. Although payment-provider revenue is pulled through the API, TrustMRR says it does not independently validate the financial statements, revenue figures, margins, business metrics, ownership claims or other representations exchanged by buyers and sellers during an acquisition. Buyers are expected to check those claims themselves.

For browsing startups, that gap is manageable. For buying one, we would want processor exports, accounting records and product-level reconciliation before assuming the public TrustMRR figure maps perfectly to the asset being acquired.

Can real TrustMRR revenue still be misleading?

Yes. A perfectly real TrustMRR payment can still create the wrong impression about how strong the underlying business is.

Take two startups showing $50,000 of last-30-day revenue. One might have 1,000 customers paying $50 each every month. Another might have landed one $40,000 consulting project alongside $10,000 of SaaS subscriptions. Both can legitimately generate $50,000 of payment-provider revenue.

The same problem appears around launches. A product selling annual plans can have an unusually strong month when many customers prepay for twelve months. A lifetime-deal campaign can produce a burst of real revenue that will not recur next month. An ecommerce or marketplace product can process a large amount of customer spending while keeping only a fraction of that amount economically.

TrustMRR does give us extra clues such as MRR, active subscriptions and customer counts. Those help enormously. Yet the public aggregate figures still cannot tell us whether 70% of revenue comes from one customer, whether the customer base has deteriorated, or whether a short promotion caused the recent spike.

So a sentence like “this startup makes $50,000 per month” can overstate what the number actually proves. The connected payment account processed around $50,000 over the recent 30-day period; whether the startup has a durable $50,000-a-month business requires another layer of evidence.

Is TrustMRR MRR the same as monthly revenue?

No. TrustMRR MRR and TrustMRR last-30-day revenue measure different things, and the gap between them can be surprisingly large.

Stripe defines MRR as the monthly-normalized value of active and past_due subscriptions. A customer paying $1,200 annually therefore contributes $100 to MRR each month even though the business collects the $1,200 at one particular point in the year. Stripe also counts past_due subscriptions until their status changes to something that removes them from MRR.

TrustMRR’s own business currently gives us a neat example. Its public profile recently showed roughly $40,100 of revenue over the previous 30 days but only about $20,500 MRR, with 15 active subscriptions. The $40,100 figure therefore cannot sensibly be read as “TrustMRR has $40,100 MRR.”

The opposite gap can appear too. A SaaS selling lots of annual plans may have strong MRR during a month when relatively few annual subscriptions happen to renew, leaving cash revenue below normalized recurring revenue.

So if TrustMRR says a startup has $30,000 MRR, we read that as roughly $30,000 of normalized monthly subscription value under TrustMRR’s calculation. If the question is “how much cash did customers actually pay recently?”, the last-30-day revenue metric is the more relevant starting point.

Can TrustMRR really be 30% different from Stripe or another provider?

Yes. TrustMRR currently warns that its reconstructed revenue, MRR or churn numbers can differ from the payment provider’s own dashboard by as much as 30%.

TrustMRR explains in its FAQ that payment providers use different internal formulas and do not necessarily expose those formulas publicly. TrustMRR therefore rebuilds some metrics from API data, with refunds, prorations, trials and currency conversions among the reasons its answer can differ from the provider’s.

Thirty percent is a meaningful difference.

At $1,000 MRR, we are talking about hundreds of dollars. Around $10,000 MRR, the gap can move into the thousands. Once a startup is doing $100,000 MRR, a 30% discrepancy is large enough to change a valuation discussion.

This also means the apparent precision of some TrustMRR pages deserves skepticism. A figure such as $18,743 MRR looks exact to the dollar, while TrustMRR itself tells us the reconstructed metric may not match the provider dashboard one-for-one.

For research, benchmarking and figuring out the rough scale of a company, that limitation does not kill the usefulness of the data. If we are pricing an acquisition, the underlying provider dashboard and transaction records need to win any disagreement.

Are Stripe and RevenueCat numbers on TrustMRR really comparable?

Only roughly. TrustMRR can put Stripe and RevenueCat startups on the same page, but their MRR figures do not always describe identical economics.

Stripe counts the monthly-normalized value of active and past-due subscriptions under its Billing methodology. RevenueCat also normalizes active paid subscriptions to a monthly value, but its standard MRR measure uses the gross subscription price before app-store commissions and taxes. RevenueCat offers separate views for revenue net of taxes and for estimated proceeds after taxes and store commissions.

That difference can become material for mobile apps. A RevenueCat app showing $100,000 gross MRR may receive considerably less than $100,000 after store commissions and taxes. A Stripe SaaS showing $100,000 MRR has a different fee structure again.

We can still compare the two companies at a high level. Both numbers tell us the approximate recurring scale of the businesses. Comparing them down to the last dollar, or treating $1 of MRR as having the same economic value across every provider, goes too far.

Source	What its MRR roughly tells us	Main thing to watch
Stripe	Monthly-normalized value of active and past-due subscriptions	MRR can differ from cash collected and can include past-due subscriptions
RevenueCat	Monthly-normalized gross value of active paid subscriptions	Standard MRR is before estimated store commissions and taxes
TrustMRR	A reconstructed metric using connected provider data	TrustMRR says provider-specific calculations can create sizable differences

Are TrustMRR revenue numbers always fresh?

No. TrustMRR normally syncs connected revenue frequently, but several of the biggest profiles visible today are running on expired API connections.

The current FAQ says functioning revenue connections typically sync hourly. TrustMRR also leaves an explicit warning on profiles when an API key expires, along with the last successful update.

That warning is important because some prominent profiles are now quite stale. Gumroad’s profile displays an expired Stripe connection whose data stopped updating in late 2025. Easytools has the same issue, also dating from late 2025. Stan currently shows roughly $76.6 million of all-time revenue and $3.57 million MRR, but its Stripe connection stopped syncing in spring 2026.

These are three of the largest profiles on the platform, rather than obscure listings deep in the database.

Stale data does not tell us the old number was wrong. It tells us the number has stopped answering a current question. If Stan has grown substantially since its connection expired, $3.57 million MRR would understate the business today. If it has shrunk, the old figure would overstate it.

The timestamp deserves almost as much attention as the number.

TrustMRR profile	Displayed scale	Current verification status
Gumroad	About $879M GMV	Stripe connection expired; last successful sync in late 2025
easytools	About $82M GMV	Stripe connection expired; last successful sync in late 2025
Stan	$76.6M total revenue, $3.57M MRR	Stripe connection expired; last successful sync in spring 2026

Can TrustMRR miss some of a startup’s real revenue?

Yes. TrustMRR can show less revenue than a startup actually makes when all of the company’s payment sources are not connected.

The platform itself recognizes this situation. TrustMRR’s FAQ allows founders to attach a secondary payment provider and combine revenue from multiple sources.

That feature exists for a reason. A company might collect web subscriptions in Stripe and mobile subscriptions through an app-store stack. Another could migrate between processors. A founder might have separate merchant accounts for different products or geographies.

If TrustMRR sees only one of those sources, the verified figure can be perfectly genuine while still being incomplete.

Expired connections create another version of the problem. TrustMRR continues to display the last available figures when a provider key stops working, while clearly marking the profile as stale. A company that keeps growing after that point will look smaller and smaller relative to its real current revenue.

So there are at least two directions in which readers can get the wrong intuition. Inflated interpretations receive most of the attention, yet missing or stale data can also make a healthy business look weaker than it currently is.

Is TrustMRR’s $1.6 billion of “verified revenue” really startup revenue?

No, not under one clean accounting definition. TrustMRR’s current $1.596 billion headline combines businesses whose displayed dollars can represent quite different things.

TrustMRR’s statistics page currently describes a daily snapshot containing $1,596,605,077 of verified revenue across 55 million transactions. On its own, that sounds like roughly $1.6 billion earned as company revenue by the startups in the database.

Then we look at the companies driving the number.

Gumroad alone has roughly $878.6 million displayed prominently as GMV on its TrustMRR profile. Easytools has another $82.1 million displayed as GMV. Combined, those two profiles contribute about $960.7 million, equivalent to 60.2% of the entire $1.596 billion headline.

GMV is fundamentally different from the revenue a platform keeps. If a marketplace processes $100 million of sales for creators and earns a percentage fee, the $100 million describes commerce passing through the platform rather than $100 million belonging economically to the company.

Stan adds another $76.6 million of displayed all-time revenue. The three profiles together represent roughly $1.04 billion, or about 65% of TrustMRR’s total headline. That means a tiny number of very large businesses dominate the aggregate.

This is one of the clearest examples of why the word “revenue” needs context on TrustMRR. The underlying dollars may be genuinely processor-backed while the platform-wide sum mixes metrics that we would not normally add together in financial analysis.

TrustMRR profile	Displayed lifetime metric	Approx. amount	Share of $1.596B headline
Gumroad	GMV	$878.6M	55.0%
easytools	GMV	$82.1M	5.1%
Gumroad + easytools	GMV	$960.7M	60.2%
Stan	All-time revenue	$76.6M	4.8%
All three	Mixed metrics	About $1.04B	About 65.0%

Is a 2x TrustMRR acquisition multiple really 2x ARR?

No. A TrustMRR marketplace multiple currently uses the last 30 days of revenue multiplied by 12, so a displayed 2x multiple does not automatically mean the startup is priced at two times recurring ARR.

TrustMRR spells out the calculation in its FAQ: asking price divided by annualized revenue, where annualized revenue equals the previous 30 days multiplied by 12.

Consider a startup that just collected $100,000 during a launch month. Annualizing that period gives $1.2 million. At a $2.4 million asking price, TrustMRR would show roughly a 2x multiple.

If the startup usually makes $20,000 per month and the $100,000 came from a one-off lifetime deal campaign, calling the company a 2x ARR acquisition would seriously overstate the recurring base.

A business with annual subscriptions can produce the opposite distortion. Its normalized recurring revenue may be healthy even during a 30-day period when relatively few annual customers happened to renew.

The TrustMRR multiple is useful for quickly comparing asking prices against recent sales activity. Calling it an ARR multiple is a bigger claim; first we would want to see how much of those sales actually recur.

Does verified TrustMRR revenue mean the startup is a good business?

No. TrustMRR can tell us that customers paid real money while leaving most of the questions that determine whether the startup is attractive unanswered.

Imagine two startups each generating $30,000 a month. The first has 90% gross margins, hundreds of customers, low churn and almost no paid acquisition. The second spends $25,000 every month to generate its $30,000, depends heavily on one customer and loses subscribers quickly.

Their TrustMRR revenue could look similar.

Profit margin does appear on marketplace listings when supplied, but TrustMRR requires the seller to enter that figure when listing a startup for sale. Its terms go further and explicitly say TrustMRR does not independently validate profit margins, financial statements, customer counts, business metrics, valuations, ownership claims or other seller representations during acquisitions.

Those omissions become especially important now that TrustMRR is an acquisition marketplace rather than simply a public revenue database. The platform’s own deal process includes a due-diligence stage before the asset purchase agreement is finalized.

For us, verified revenue is a very good first filter. It tells us that a startup has crossed one hurdle many small businesses never cross: real people appear to be paying it.

Whether we would actually want to own that revenue depends on churn, margins, customer concentration, refunds, acquisition costs, founder dependence, IP ownership and the stability of the payment history.

TrustMRR was never going to fit all of that into one green verification badge.

Is TrustMRR really better than an MRR screenshot?

Yes, by a lot. A fresh TrustMRR profile deserves substantially more trust than an MRR screenshot posted by the founder.

With the screenshot, almost every relevant step is controlled by the person making the claim. We may have no way to know whether the dashboard is genuine, whether the time window was cherry-picked or whether the image was edited.

TrustMRR removes most of that freedom from the core financial metrics. The startup has to connect a payment provider, the provider data drives the verified numbers, and TrustMRR currently refreshes working connections on a regular schedule. When a key expires, the profile says so publicly.

The platform also exposes multiple numbers at once. Last-30-day revenue, MRR, total revenue, customers and active subscriptions can contradict an overly simple founder narrative in useful ways. A startup claiming to be a pure subscription SaaS looks very different if TrustMRR shows $50,000 of recent revenue but almost no MRR.

None of this reaches the standard of audited accounts. It does move the evidence several steps beyond “trust my screenshot.”

If we are researching an indie startup and only have time for one external check, a current TrustMRR connection is one of the more useful pieces of evidence available.

Can you trust TrustMRR revenue numbers?

Mostly yes. We trust fresh TrustMRR numbers as strong evidence of the rough level of real payment activity behind a startup, but we would not treat them as audited revenue or assume every displayed metric means exactly what its label seems to mean.

Several findings push us toward that answer.

Founders cannot simply type whatever verified revenue figure they want. TrustMRR retrieves financial data from connected payment providers using read-only access. Working connections typically refresh frequently, and stale ones are visibly flagged. Those features solve much of the problem TrustMRR was created to solve.

At the same time, we found meaningful limits. TrustMRR says its reconstructed metrics can differ from provider dashboards by up to 30%. MRR and cash revenue are different measures. RevenueCat and Stripe do not always describe recurring economics on exactly the same basis. A startup can have missing payment sources. Some major profiles are currently stale. TrustMRR’s acquisition multiple annualizes a single 30-day period. And its $1.596 billion platform-wide revenue headline currently gets about 60% of its value from Gumroad and easytools figures labeled GMV.

The practical rule is pretty simple.

If a founder says “we make $30,000 MRR” and gives us a screenshot, there is still a basic authenticity question.

If a live TrustMRR profile shows roughly $30,000 MRR through Stripe, we can be reasonably confident that a genuine Stripe account contains subscription activity in roughly that range.

We still would not say, based on TrustMRR alone, that the named product has exactly $30,000 of collectible, durable, profitable monthly recurring revenue.

TrustMRR is currently very good at answering “is there real money here, and roughly how much?” Once the question becomes “how good is this revenue, exactly where did it come from, and what is the business worth?”, we need more evidence.