LR-11

Most Stripe Accounts Are Leaking Revenue. Yours Probably Is Too.

Your Stripe dashboard shows Monthly Recurring Revenue. Your bank account shows a different number. Some of the gap comes from timing, fees, or refunds — that's normal. But persistent, unexplained gaps often indicate revenue leakage, and most SaaS founders don't know it exists.

In audits of hundreds of Stripe accounts, the majority showed some form of revenue leakage. The sources were consistent: subscriptions stuck in past_due limbo, expired discount coupons still being applied, failed payments that were never recovered, and subscription states that had drifted from the application's records.

This is not a billing bug in the traditional sense. Stripe processes payments correctly. The leakage happens in the space between Stripe and your application — in lifecycle events that weren't handled, recovery flows that don't exist, and billing states that nobody is monitoring.

For a SaaS at $10K MRR, even a small percentage of silent leakage compounds to thousands of dollars per year. It doesn't show up as an error. It shows up as revenue that plateaus, cash flow that tightens, and churn that quietly increases.

Who This Is For

Founders who notice a gap between Stripe MRR and actual bank deposits
Teams that haven't audited their Stripe account for past_due, incomplete, or unpaid subscriptions
Developers who handle subscription creation but don't have automated recovery for failed payments
Anyone whose app doesn't periodically reconcile its database with Stripe's subscription records

If you've never compared your application's active-user count with Stripe's active-subscription count, the two numbers probably don't match.

What Founders Experience

MRR looks healthy. The Stripe dashboard shows growth. New subscriptions are created. The headline number goes up.
But cash doesn't match. Actual deposits are lower than expected. The founder attributes it to payment timing, currency conversion, or fees — not to leakage.
Ghost subscriptions accumulate. Subscriptions in past_due state — where the payment failed but the subscription wasn't cancelled — sit in limbo. They're counted as "active" in some dashboard views but generate no revenue.
Expired coupons keep applying. A launch promotion that was supposed to end months ago is still discounting new renewals because nobody removed the coupon from the subscription.
Discovery requires manual audit. There's no alert, no error, no automatic flag. The only way to find leakage is to export Stripe data and compare it against your records, subscription by subscription.

What's Actually Happening

Revenue leakage has multiple sources, and they accumulate independently:

1. Past-Due Subscriptions in Limbo

When a payment fails, Stripe retries according to your Smart Retry settings. During retries, the subscription status is past_due. If all retries fail, the subscription may remain in this state indefinitely — depending on your configuration.

These subscriptions appear active or counted in some dashboard views, but are not reliably generating revenue. The customer isn't paying, the app may or may not still grant access, and nobody is actively resolving the situation.

2. No Dunning or Recovery Flow

Stripe handles retries automatically, and can send some customer-facing emails depending on your configuration. But customer communication and recovery flows beyond that are your responsibility. For customers whose payments permanently fail, you need a dunning flow: email notifications, in-app warnings, and eventually access revocation. Most AI-generated apps have none of this.

Research suggests that payments not recovered within 30 days have less than a 15% chance of ever recovering. Without active dunning, that recovery window passes silently.

3. Expired Discounts Still Applied

Promotional coupons and trial discounts that were applied to subscriptions at creation time may continue applying to renewals long after the promotion ended. Stripe doesn't automatically expire a coupon from existing subscriptions — it only stops new subscriptions from using the coupon code. Subscriptions already carrying the coupon continue to renew at the discounted rate.

4. App-State Drift from Stripe Reality

This is covered in detail on the Cancelled But Still Active page. The summary: when your app's subscription records don't match Stripe's records — whether from missed webhook events, processing errors, or lifecycle gaps — revenue leaks in both directions. Users with access who aren't paying (lost revenue) and users without access who are paying (churn risk).

What This Puts at Risk

Cumulative revenue loss. Each individual source of leakage may be small. Combined and compounded over months, the total can be significant. The audit that found 94% of accounts affected reported meaningful average monthly leakage per account.

Unreliable metrics. MRR, churn rate, LTV, and CAC payback all depend on accurate subscription data. If your active subscriber count includes ghost subscriptions, every metric derived from it is wrong. Investor reporting, growth projections, and pricing decisions are based on inflated data.

Invisible churn. Some leakage manifests as customers who are technically "active" but have stopped paying. They inflate your user count while contributing nothing to revenue. The real churn rate is higher than your dashboard shows.

Compounding over time. Revenue leakage doesn't self-correct. Without active monitoring and reconciliation, the gap between reported and actual revenue grows every month. The longer it runs, the harder it is to unwind.

How Trust Score Relates

Ghost subscriptions sit at the boundary of what automated code scanning can detect. Trust Score's relevant checks are:

BIL-16 (webhook-only fulfillment) ensures that subscription state changes flow through verified events — the foundation for keeping your app in sync with Stripe. Without this, state drift is inevitable.

BIL-04 (idempotent processing) prevents duplicate fulfillment that can corrupt subscription records.

However, ghost subscriptions are primarily a Stripe account configuration and operational monitoring problem, not a code-level vulnerability. This is where automated scans stop. Real revenue leaks require direct Stripe audit — examining past_due subscriptions, coupon usage, and payment recovery rates. This is part of the Launch Readiness Assessment's billing review.

Detection: How to Check Your Own Stripe Account

Check 1: Count ghost subscriptions

In the Stripe Dashboard, filter subscriptions by status:

Go to Billing → Subscriptions
Filter by past_due — these are failed payments in retry limbo
Filter by incomplete — these are subscriptions that were never fully activated
Filter by unpaid — these are subscriptions past the retry window

Interpretation: Any subscriptions in these states are not generating revenue but may be counted in your active metrics. Each one represents a customer who needs intervention — dunning emails, payment method update requests, or access revocation.

Check 2: Compare Stripe active subscriptions vs app active users

Count the number of active subscriptions in Stripe. Compare it against the number of users with premium access in your application database.

Interpretation:

App count higher than Stripe = cancelled or failed subscribers still have access (see Cancelled But Still Active)
Stripe count higher than app = paying subscribers may not have access (fulfillment failure)
Counts match = good sign, but verify a random sample to confirm individual records align

Check 3: Check for stale coupons

In the Stripe Dashboard, go to Products → Coupons. Check each active coupon:

When was it created?
Is it still supposed to be active?
How many subscriptions are currently using it?

Interpretation: Coupons from old promotions that are still applied to renewing subscriptions are silently discounting revenue every billing cycle.

Related Launch Risks

They Cancelled. They Still Have Access. You're Losing Money. — The code-level root cause of app-state drift from Stripe.
Stripe Will Retry Until It Breaks You. — Non-idempotent processing can corrupt subscription records, contributing to ghost states.
Your Stripe Webhook Trusts Strangers. — Without verified webhooks, subscription lifecycle events are missed entirely.
Anyone Can Upgrade to Pro for Free. — Revenue leakage from the other direction: users with access who never paid.

FAQ

What exactly is a ghost subscription?

A subscription that appears active or counted but is not reliably generating revenue. Common forms: past_due subscriptions where payment failed and may or may not recover through retries, incomplete subscriptions that were never fully activated, and subscriptions with stale coupons that discount the full amount. They inflate your subscriber metrics without contributing reliably to revenue.

Isn't Stripe Smart Retry supposed to handle failed payments?

Smart Retry handles automatic payment retries over a configured period. But if all retries fail, Stripe doesn't automatically cancel the subscription or notify the customer — that's your responsibility. Without a dunning flow (emails, in-app prompts, eventual access revocation), failed subscriptions sit in past_due indefinitely.

How much revenue leakage is typical?

In audits of hundreds of Stripe accounts, the majority showed some form of leakage. The amount varies by business model, pricing, and how long the account has been running. The longer you operate without reconciliation, the more leakage accumulates. Even a small percentage of silent failures compounds over months.

Can Trust Score detect ghost subscriptions automatically?

Not directly. Ghost subscriptions are a Stripe account configuration and operational issue, not a code-level pattern. Trust Score checks the code-level foundations that prevent drift (webhook fulfillment, idempotency), but auditing your Stripe account for past_due subscriptions, stale coupons, and recovery gaps requires direct Stripe data review — included in the Launch Readiness Assessment.