Self-reported SaaS revenue is wrong more often than it's right. Not because founders lie — because MRR definitions diverge across companies, billing systems, and even teams within the same company. Billing-system-verified revenue is the only investor-grade data source, and it takes less effort to set up than most teams spend reconciling spreadsheets each quarter.
8–15%
Median self-reported vs billing-system MRR gap
5
Common MRR definition divergences
2–4 weeks
Due diligence time saved with verified data
Why self-reported SaaS revenue is structurally unreliable
Ask five SaaS companies to calculate their MRR and you'll get five different numbers for economically identical businesses. The problem isn't dishonesty — it's definitional ambiguity. MRR is not a GAAP term. There is no authoritative standard for what goes in and what stays out.
In connected portfolios, self-reported MRR diverges from billing-system MRR by a median of 8–15%. The direction of the error isn't random — self-reported numbers skew high. Companies include revenue they shouldn't, exclude churn they should, and annualize contracts that haven't been invoiced yet.
Monthly Recurring Revenue
Predictable monthly revenue from active subscriptions, normalized from all billing intervals.
The five ways MRR definitions diverge
Annual contracts.A $120K annual contract is $10K/mo MRR — but only if the customer is on a recurring subscription. A one-time annual invoice with no auto-renewal is revenue, not MRR. Most companies count it anyway, inflating their recurring base by 10–25%.
Setup fees.A $5K onboarding fee billed alongside the first subscription payment is non-recurring by definition. Companies that include it in MRR overstate their first month and then show an artificial "churn" in month two when the fee doesn't repeat.
Discounts. A customer paying $800/mo on a plan listed at $1,000/mo generates $800 in MRR, not $1,000. But if the discount is modeled as a separate line item rather than a price override, the billing system may report the gross amount. Companies that pull MRR from plan price rather than collected amount overstate by the discount delta.
Metered billing.Usage-based revenue is inherently variable. A customer who paid $3,200 last month and $1,800 this month doesn't have a stable MRR. Some companies use trailing-3-month averages; others use last month's invoice; others exclude metered revenue entirely. All three approaches produce defensible but different numbers.
Multi-currency.A EUR-denominated subscription converted to USD fluctuates with exchange rates. Companies that snapshot the conversion at contract signing and never update it accumulate drift. A portfolio with 20% international revenue can see 2–4% MRR variance from currency alone.
Revenue verification vs revenue recognition — they're not the same thing
Search "SaaS revenue verification" and most results explain ASC 606 — the revenue recognition standard. That's a different problem. Recognition answers when to book revenue across accounting periods. Verification answers whether the number being booked is real.
A company can have perfect ASC 606 compliance and still report unreliable MRR. Recognition governs GAAP reporting; verification governs operating metrics. The former matters to auditors; the latter matters to operators, investors, and anyone making decisions off of MRR, net retention, or LTV.
ASC 606 is about when to book it; verification is about whether the number is real
ASC 606's five-step model (identify the contract, identify performance obligations, determine the transaction price, allocate it, recognize as obligations are satisfied) is designed for financial statements. It doesn't address whether the subscription data feeding those statements is accurate.
Verification is upstream. It asks: does the MRR number match what the billing system actually invoiced? Are canceled subscriptions excluded? Are discounts reflected? Are annual contracts normalized correctly? If the answer to any of these is "we're not sure," the downstream recognition is precise but potentially wrong — an exact answer to the wrong input.
How to verify SaaS revenue from Stripe billing data
Stripe's subscription object is the canonical source. Every active subscription has a status, a current period, a set of line items, and a price. MRR verification means computing the monthly value from these objects and comparing it to whatever the company reports.
Subscription object → recurring line items → normalized MRR
The algorithm is straightforward. Pull all subscriptions with status active or trialing. For each subscription, iterate its line items. For each line item, take the unit amount multiplied by quantity, then normalize to monthly: divide annual prices by 12, multiply weekly by ~4.33, leave monthly as-is.
Sum the normalized values. That's your billing-verified MRR. Compare it to the company's self-reported number. The delta is your verification gap — and in a typical portfolio, it's 8–15%.
The verification gap concentrates around data points that self-reporting systematically mishandles. Trial-to-paid conversion timing is the most common: companies that count trial starts as MRR overstate by the full value of every trial that never converts, sometimes inflating the number by 5–12% depending on trial volume. Multi-currency normalization is another persistent source of error — a billing system records the exact invoice amount in the settlement currency at the time of charge, while self-reported models typically lock the exchange rate at contract signing and never update it, accumulating drift that grows with each billing cycle.
Prorated charges introduce a subtler distortion. When a customer upgrades mid-cycle, Stripe generates a one-time proration credit and a corresponding charge for the remainder of the period. Companies that pull revenue from invoice totals rather than recurring line items count those prorations as MRR — overstating the upgrade month and then showing a phantom contraction the following month when the one-time adjustment doesn't repeat. Billing-system verification strips these non-recurring line items automatically, producing a clean MRR figure that reflects only actual recurring commitments.
Annual Recurring Revenue
MRR multiplied by 12 — the annualized run rate of subscription revenue.
Handling edge cases — annual contracts, prorations, add-ons, usage billing
Annual contractswith auto-renewal are straightforward: divide by 12. Contracts without auto-renewal require a policy decision — include them as MRR until expiry, or exclude them entirely. The billing system knows the renewal status; the spreadsheet usually doesn't.
Prorations are one-time adjustments when a customer upgrades or downgrades mid-cycle. They appear as invoice line items but are not recurring. Exclude them from MRR — they inflate the upgrade month and deflate the next.
Add-ons billed as separate subscriptions are recurring and belong in MRR. Add-ons billed as one-time invoice items do not. Stripe distinguishes these by object type: subscription items vs invoice items.
Usage billing requires a trailing average or a committed-minimum approach. The most defensible method for diligence is to separate usage revenue from subscription revenue and report both — investors can then apply their own volatility discount to the metered component.
What verified metrics change in due diligence
Due diligence on a SaaS acquisition typically includes a revenue quality-of-earnings analysis. The acquirer's team pulls the company's reported MRR, then attempts to reconcile it against billing data, bank deposits, and accounting records. When the numbers don't match — and they usually don't — the back-and-forth adds 2–4 weeks to the timeline.
Net Revenue Retention
Revenue retained from existing customers including expansion, contraction, and churn.
Verified MRR shortens this cycle by removing the reconciliation debate. When the acquirer can see that MRR is computed directly from Stripe subscription objects — not a spreadsheet formula, not a dashboard estimate — the revenue quality conversation moves from "is this number right?" to "what does this number tell us?"
The impact extends beyond MRR. Every downstream metric depends on accurate revenue inputs. Net revenue retention calculated from verified MRR is defensible. NRR calculated from self-reported MRR inherits every error in the base number — and in a metric defined as a ratio, small input errors produce outsized output errors.
For PE firms running a competitive process, the difference is material. A seller with billing-verified metrics closes faster because the diligence team spends less time on revenue quality and more time on strategic fit. In a market where deal timelines are compressing, 2–4 weeks is the difference between winning and losing an auction.
How North Metric automates revenue verification
Connect a Stripe account via a read-only restricted key. North Metric pulls every subscription object daily, normalizes line items to monthly values, excludes non-recurring charges, and computes MRR using a consistent, documented formula across every connected company.
The result is a single MRR number per company that can be audited back to individual subscription objects. No spreadsheet formulas, no manual reconciliation, no definitional ambiguity. The same pipeline computes ARR, net revenue retention, gross retention, and expansion revenue — all derived from the same verified base.
For portfolio operators running diligence across multiple targets, the workflow scales. Each connected account gets the same treatment: same MRR formula, same normalization rules, same edge-case handling. Comparing revenue quality across targets becomes a table lookup, not a multi-week reconciliation project.