Guide · Selling your SaaS
The 5 Stripe Leaks That Kill SaaS Deals in Diligence
When you sell a SaaS, the buyer pulls your Stripe data and checks how real your recurring revenue actually is. Here are the five leaks that surface in diligence, what each one does to your price, and how to find them before the buyer does.
When a buyer evaluates a Stripe-native SaaS, your stated MRR is the starting point, not the number they pay on. They reconcile it against what your Stripe account actually shows, and where the two disagree is where diligence slows down, numbers get questioned, and momentum leaks out of the deal.
Recurring revenue is the asset being bought, so a serious buyer verifies it directly rather than taking the listing at face value. They look at your active subscriptions, your real churn, your effective pricing, and your discounts. Stripe is useful to them precisely because it is hard to dress up: it holds an immutable record of charges, subscription lifecycle, invoices, and payment outcomes. On most SaaS marketplaces, connecting Stripe is part of how a listing gets verified in the first place, so by the time you reach diligence your billing data is already on the table.
Five things commonly sit in that data. None of them are fraud. They are what accumulates when a billing system runs for a few years without anyone auditing it: a failed payment that never retried, a customer still on a plan you stopped selling, a subscription somebody paused and forgot. Each is small on its own, and each one touches a number a buyer looks at. This guide walks through all five from the buyer's side of the table, so you can see what they see and deal with it on your terms instead of theirs.
Two caveats before the list. This assumes Stripe is your primary billing system. If you invoice larger customers through ACH, manual invoices, or a second processor, that revenue lives outside everything here. And this is about billing quality, not accounting. Revenue recognition and sales-tax exposure are separate diligence threads, usually handled in a buyer's quality-of-earnings review, and they are not what these five checks cover. What follows is the recurring-billing slice, the part that lives in Stripe and the part most founders never re-examine before they list.
Why this bites in diligence specifically
A buyer is not only asking how much revenue you have. They are asking how much of it is real, durable, and actually being collected. That is what people in M&A mean by revenue quality, and it is what sets your price inside whatever range the market is paying. Billing leakage commonly runs a few percent of ARR across subscription businesses, small enough to ignore in day-to-day operations and large enough to matter when someone is pricing the whole company.7 Smaller private SaaS tends to sell on a multiple of revenue or profit, but those are not the same multiple and not a fixed rule: a revenue multiple that sounds modest can work out to a much larger profit multiple, and fast-growing or strategic deals sit well outside any rule of thumb.3 Two companies with the same headline MRR do not fetch the same price if one has clean, collectible revenue and the other comes with a list of asterisks.
The leverage point is what founders underestimate. A leak you find yourself is a footnote you handle on your own terms. A material discrepancy the buyer finds first is leverage in their hands. When an analyst spots a number that does not match what you reported, and it is big enough to matter, they adjust that line and start checking the rest more carefully, and the added scrutiny is usually what costs you. Every unexplained billing anomaly becomes another thread to pull, and a diligence full of threads is one where the price and the timeline both drift the wrong way. Materiality is the whole game here: nobody re-trades a deal over a $20 coupon. The risk is the pattern, a handful of anomalies that together make your numbers look unmanaged.
So the goal is not to dress up your account. It is to make sure there is nothing in it that you cannot explain before someone else explains it to you.
The timing trap: why fixing leaks the week before you list backfires
The obvious move is to wait until you decide to sell, clean everything up, then list. It half works, and the half that does not work catches people out.
Buyers weigh trailing performance, not a snapshot you can stage at the last minute. If you recover a chunk of failed-payment revenue two weeks before listing, that recovery has no history behind it yet. A cleanup like this is often genuinely structural, the recovered customers keep paying, so the improvement is real. The problem is that a buyer cannot tell a durable fix from a one-time bump without a track record. An adjustment with a few weeks of data behind it gets treated as unproven, which in practice means it is discounted, underwritten conservatively, or set aside until you can show it holds. You did the work and got little credit for it. A last-minute change also forces the buyer's analyst to reconcile your data-room numbers against your live Stripe account, which adds friction and invites scrutiny at exactly the moment you want the process moving.
The fix has to be old enough to carry a track record. Patch these a quarter or two before you list and the corrected revenue sits inside the trailing period as established fact, with months of real payments behind it. Finding the leaks does not take long. Letting the fix age into your numbers takes months you cannot add back later, which is the whole reason to look early rather than the week before.
The five leaks, from the buyer's side
These are the same five categories any competent revenue audit looks for. The difference here is what each one means to someone deciding what to pay for your company.
1. Recovery gaps: failed payments that never came back
A card declines, Stripe retries a few times, the retries run out, and the charge is never collected. The median SaaS company loses roughly 9% of recurring revenue to failed payments, and a real share of that is recoverable money nobody pursued.1 Stripe's Smart Retries is adaptive, but most teams leave it on defaults and never tune the retry schedule or the dunning emails around it, so collectible revenue slips through.4
This leak is about the dollars. In diligence it reads as the gap between what you billed and what you actually collected, which is one of the first things an analyst reconciles. The customers you lost as a result are the next leak, and the two are worth separating because they damage different numbers: recovery gaps are money left on the table, involuntary churn is a corrupted metric. The deep dive on dunning and recovery gaps covers how to measure your real recovery rate, which usually sits below Stripe's headline average.
2. Involuntary churn: customers who left without meaning to
Involuntary churn is the cancellations that happen because a payment method failed and dunning gave up, not because anyone decided to leave. Research consistently puts it at a large share of total churn for subscription businesses, often somewhere between 20% and 40%.2 Where recovery gaps cost you dollars, involuntary churn corrupts a metric.
Your churn rate is one of the most scrutinized numbers in any SaaS diligence, because it drives the forward model the buyer builds. Unrecovered card failures count against retention exactly like customers who chose to quit, so your curve looks like a product people abandon when a chunk of the departures were billing failures you could have caught. If you separate the involuntary slice before diligence, you can tell the accurate version of your retention story with data behind it. Leave it unquantified and the buyer works from the pessimistic version by default.
3. Legacy pricing: customers stranded on plans you stopped selling
Every SaaS that has raised prices or restructured plans has a tail of customers grandfathered onto old rates. Someone is paying $29 for what now costs $79, and nobody migrated them because nobody wanted the support tickets. It accumulates silently because there is no event that flags it.
The question that comes up in diligence is not really why ARPU is inconsistent, since every mature SaaS has grandfathered plans. It is how much of ARR is trapped on legacy pricing and whether it can be moved. That number speaks to three things a buyer weighs: pricing governance, expansion upside, and the concentration risk if a repricing pushes those accounts to churn. A large legacy book is not automatically a markdown, but it is a question you want to meet with a clear sizing and a migration story rather than a guess. Knowing the exact figure before you list is the difference between those two answers.
4. Zombie subscriptions: active in Stripe, billing nothing
A zombie subscription is one Stripe still reports as active while generating no revenue. The most common cause is billing paused with pause_collection and never resumed, though you can reach the same state through free phases, subscription schedules, manual admin changes, or migration leftovers.5 The customer usually still has access because your app reads the status as active, but no charges are being created. Audits routinely turn up a handful of these per account, often clustered on the high-value customers you most want to look healthy.
How much this distorts depends on how your MRR is calculated. Mature analytics tools recognize a paused subscription and drop its MRR to zero, so if you report through one of those your headline number is probably fine. The distortion shows up in raw Stripe subscription counts, custom dashboards, and any MRR figure derived naively from active status, which is where a lot of small SaaS reporting lives. If your stated MRR counted these as paying, it is overstated, and a buyer who finds a paying-zero subscription in your active count trusts every other figure a little less. If your reporting already excluded them, your active count in Stripe will not reconcile to your revenue, and the buyer has to chase that difference down before moving on. Either way it is a thread, and the guide on zombie subscriptions covers finding and resolving them cleanly.
5. Discount leakage: promos that were supposed to expire and did not
The usual cause is a coupon created with duration: 'forever' for what was meant to be a temporary promotion. A forever coupon keeps discounting a customer's invoices for as long as the subscription lives, so a launch promo from three years ago is still taking 30% off some accounts. One thing founders get wrong is worth stating plainly: a coupon's redeem_by date only controls whether new customers can apply it. It does nothing to stop an already-applied discount from recurring, so a customer who redeemed a forever coupon keeps it indefinitely regardless of any expiry on the coupon. The leak is the duration, not a missing expiry date, and adding a redeem_by would not have prevented it.6 It stays invisible because the customers are happy and the charges go through fine, just smaller than they should be.
In diligence this pushes your realized ARPU below what your published pricing implies, and a buyer notices the gap. When they find a slice of the base permanently discounted, they read it as revenue that is hard to grow, since raising it means risking those accounts. As with everything else, materiality decides whether anyone cares: a single small coupon is noise, a meaningful share of revenue sitting under expired promos is a real conversation. The discount leakage guide covers the safest way to expire these without setting off a wave of support tickets.
How to find all five before a buyer does
You have two honest options. You can write the queries yourself in Stripe Sigma, the SQL editor built into the Dashboard, which has full access to your billing data. A technical founder can absolutely surface these five categories that way, and if you have the time and you know what the edge cases look like, it works. The traps are the ones that are easy to miss precisely because they look normal in the data: a paused subscription still reads as active, an old coupon still reads as a valid discount. The honest comparison of Sigma versus a purpose-built tool lays out where each one makes sense and what each costs in real hours.
The other option is to run a tool that checks all five and prices each finding, which is what Bleedpoint does. It connects to your Stripe with read-only access, runs the five checks, and returns a report with the dollar value attached to each leak. Read-only matters here: it cannot create charges, change subscriptions, or send anything to your customers, so running it is invisible to everyone, including a future buyer. You check your own account privately and decide what to act on. If you want to see the shape of the output first, the sample report is a walk-through of a fictional 14-finding audit.
Whichever route you take, the timing point is the one that moves money. A leak found and fixed six months before you list is revenue you get full credit for, with the track record to prove it. The same leak found by a buyer's analyst is a thread you spend diligence explaining, and often a discount you hand over. Recovered revenue can lift the price when it is material and proven, since smaller SaaS sells on a multiple of that revenue, but the more dependable win is a clean diligence with nothing in it for anyone to pull on.
Frequently asked questions
Will a buyer actually look at my Stripe data when I sell my SaaS?
Almost certainly, if Stripe is your main billing system. Recurring revenue is the asset, so a serious buyer reconciles your stated numbers against what Stripe actually shows rather than taking the listing at face value. On most SaaS marketplaces, connecting Stripe for verification is part of listing. Diligence is the stage where any gap between what you reported and what Stripe shows comes out.
Can I just fix the leaks right before I list?
Fixing them helps, but doing it two weeks before listing helps less than you would hope. A fix that recent has no track record, and a buyer cannot tell a durable improvement from a one-time bump without one, so they tend to discount it, underwrite it conservatively, or set it aside until it is proven. A last-minute change also forces their analyst to reconcile your data room against your live Stripe account, which adds scrutiny. Fix these a quarter or two out so the corrected numbers have months of history inside the period a buyer evaluates.
Does recovering revenue actually raise my acquisition price?
It can, but only when the recovered revenue is material and you fixed it early enough to prove it is durable. Smaller private SaaS tends to sell on a multiple of revenue or profit, so durable recurring revenue added before the trailing period does lift the number, though those multiples vary widely with growth and are not a fixed rule. Recovering a few dollars a month will not move anything. The more reliable benefit is avoiding a surprise: a material leak the buyer finds first becomes a reason to re-trade, and that swing is usually larger than the revenue itself.
What does revenue quality mean in a SaaS acquisition?
Revenue quality is how real, durable, and collectible your stated recurring revenue is. A buyer is not just asking how much MRR you have, but how much of it is genuinely recurring, paid on time, at current pricing, from customers who are actually being billed. Each of the five common Stripe leaks degrades one of those qualities, which is why they get scrutinized in diligence even when the top-line number looks healthy.
Can I check for these leaks myself with Stripe Sigma?
Yes. Stripe Sigma is a SQL editor inside the Stripe Dashboard with full access to your billing data, and a technical founder can write queries to surface each of the five categories. The trade-off is engineering time and knowing exactly what to look for, especially for paused subscriptions and coupon edge cases that are easy to miss. A purpose-built tool runs the same checks in a few minutes and prices each finding. Either way, you want the answer before a buyer does.
Will running a revenue audit affect my customers or the sale?
No. A read-only audit, whether through Sigma or a tool with read-only OAuth scope, cannot create charges, issue refunds, change subscriptions, or send any customer-facing message. It reads your data and produces a report. Nothing about running it is visible to customers or to a buyer, so you can check your account privately and decide what to act on before you list.
Does this cover revenue recognition or sales tax?
No. These five checks are about recurring billing quality, the money flowing through your Stripe subscriptions. Revenue recognition and sales-tax exposure are separate diligence issues, usually handled in a buyer's quality-of-earnings review, and a read-only billing audit does not address them. If Stripe is not your only billing channel, revenue invoiced elsewhere is also outside this scope.
Find the leaks before a buyer does.
Free scan. See exactly what's sitting in your Stripe account, then unlock the full report for $99. Read-only access, no subscription required.
References
- PaymentRescue. How Failed Payments Cost SaaS Companies 9% of Revenue. Citing data from Stripe, Recurly, and ProfitWell. paymentrescue.dev
- Recurly Research, summarized in Monetizely. Understanding Involuntary Churn: The Silent Revenue Killer in SaaS. getmonetizely.com
- Acquire.com. How Acquire.com Works: Sell Your Startup or Buy One. SaaS valuation multiples. blog.acquire.com
- Stripe. Smart Retries and revenue recovery. Stripe Documentation. docs.stripe.com
- Stripe. Pause payment collection on a subscription. Stripe Documentation. docs.stripe.com
- Stripe. Discounts and coupons. Stripe Documentation. docs.stripe.com
- Lago. Revenue Leakage in SaaS: How Billing Gaps Cost 1-5% of ARR. Citing MGI Research. getlago.com