Revenue leakage examples from real billing mechanics

What counts as revenue leakage and what does not

A leak is revenue that the business is entitled to under its own terms, that a customer is willing or obliged to pay, and that never arrives because of a gap in process or configuration. A customer who decides to leave is churn, not leakage. A customer who wanted to stay and dropped out because a card failed once and nobody retried it properly is leakage. The distinction matters because leakage can be fixed with billing rules, while voluntary churn needs product and service work.

Every example below follows the same pattern. First the mechanic, then the field or event in billing data that reveals it, then a worked calculation framed as an example with round numbers. None of the figures describe a real company. They exist only to show how the math works.

• The leak is earned revenue, not hoped for revenue.
• It is visible in subscription, invoice, charge or coupon records.
• It has a fix that does not depend on the customer changing their mind.

Example one, a renewal declined once and never retried

The most common leak starts with a renewal charge that fails with a soft decline such as insufficient funds or a generic do not honor response. Many billing setups retry a fixed number of times on a fixed schedule, or stop after a single attempt when the schedule was never configured. The subscription then moves to unpaid or cancelled, and it lands in churn reports next to deliberate cancellations.

To spot it, pull every invoice for a renewal period that ended in an uncollectible or void state, and count the payment attempts on each. Group by decline code. Soft declines with one or two attempts are the recoverable set.

For example, a company with 50,000 USD of MRR sees 6 percent of renewal value fail on the first attempt, which is 3,000 USD. If a full schedule tuned to decline codes would recover half of that and the current setup recovers a fifth, the gap is 0.3 times 3,000, or 900 USD of MRR every month. Over a year that is 10,800 USD of revenue the business had already won. Our page on failed payment recovery explains how retries keyed to the decline code close this gap.

Example two, retries that ignore the decline code

A schedule can exist and still leak. Retrying an insufficient funds decline two hours later rarely works, because the account balance has not changed. Retrying the same charge right after payday, or at the start of the next business day, works far more often. At the same time, hard declines such as a stolen card or a closed account should never be retried at all, because repeated attempts on those codes can raise risk flags with the card networks.

In the data, look at the time between attempts and the code on each attempt. A flat interval for every code is the sign. For example, if 1,000 USD of monthly failures are insufficient funds and the retries all land within the same day, moving them to the next weekday morning can shift a meaningful share into recovered revenue without a single extra email.

Example three, cards that expire before the next renewal

Every card on file has an expiry month. When that month passes before the next renewal and nobody asks the customer for a new card, the renewal fails with an expired card decline. Network updaters refresh many cards automatically, but not all issuers take part and not every card type is covered, so some share of expiring cards will still fail.

The field is the expiry month and year on the default payment method, compared with the next renewal date. Count subscriptions whose card expires within 30, 60 and 90 days and whose renewal falls after the expiry.

For example, 40 subscriptions worth 150 USD each have cards that expire before their next renewal, which is 6,000 USD of MRR at risk. If updaters refresh 60 percent of them, 2,400 USD still depends on the customer entering a new card. A pre-expiry email two weeks before the date, with a direct link to a payment update page, turns that predictable failure into a routine update. The card updater page covers the timing and wording.

Example four, customers still paying a price you retired years ago

Price lists change. Old plans often stay attached to existing subscriptions, either by design as grandfathering or by accident because nobody migrated them. Grandfathering is a legitimate choice. Leakage is when the business believes it migrated everyone and it did not, or when an account that has grown far beyond the old plan's intended size still pays the old rate.

To find it, list every active subscription item by price ID and compare each price with the current list for the same plan. Sort by the difference multiplied by quantity.

For example, 25 accounts pay 79 USD on a plan that now lists at 129 USD. The difference is 50 USD each, or 1,250 USD of MRR. Even if the business decides to move only the accounts with heavy usage, the list tells it exactly how much a price review is worth before anyone writes an email.

Example five, an upgrade that never billed the difference

When a customer moves to a more expensive plan in the middle of a billing cycle, the fair charge is the prorated difference for the rest of the cycle. Depending on configuration, billing systems either invoice that difference at once, add it to the next invoice, or skip it. If the next invoice never comes, because the customer cancels or downgrades before the renewal, the difference is lost for good.

In the data, look for subscription updates that changed the price to a higher one, then check whether a proration invoice or proration line items exist and were paid.

For example, an account upgrades from 100 USD to 300 USD halfway through a month. The prorated difference is 100 USD. If the system queues it for the next invoice and the account turns off renewal before then, the business delivered half a month of the higher plan for nothing. Ten such upgrades a month leak 1,000 USD. Charging the difference immediately at the moment of the upgrade removes the risk.

Example six, seats added without a quantity change

Seat based plans leak when people are added in the product but the subscription quantity never changes. This is less a billing setting than a sync gap between the application and the billing system. The sign is a product seat count that is higher than the quantity on the subscription item. For example, 30 accounts with two unbilled seats each at 20 USD per seat leak 1,200 USD of MRR.

Example seven, a comped account that became a real customer

Teams give accounts away for good reasons, such as partners, pilots or a goodwill gesture after an outage. The leak appears when the comp outlives its reason. The account sits on a 100 percent discount or a zero priced plan, usage keeps growing and nobody reviews it.

To spot it, list subscriptions where the effective charge is zero, then join any usage indicator your billing system holds, such as metered quantities, seat counts or invoice line items with a zero amount. For example, 12 comped accounts that would fit a 249 USD plan represent 2,988 USD of MRR that the business chose to give away once and now gives away every month without deciding to.

Example eight, a forever coupon on a large account

Coupons have a duration. A coupon set to once applies to one invoice, a repeating coupon applies for a set number of months, and a forever coupon never ends. Forever coupons are often created for a single negotiation and then reused, and some end up on accounts far larger than intended.

The fields are the coupon duration and the discount amount on each active subscription. Sort forever coupons by the monthly value of the discount.

For example, a 30 percent forever coupon on an account paying a list price of 2,000 USD costs 600 USD every month. If the original agreement was a first year discount, the account has paid less than intended since month thirteen, and the gap keeps growing. Reviewing the five largest forever coupons often matters more than reviewing the next fifty small ones.

Example nine, repeat refunds and disputes that run out of time

Refunds and disputes leak in two ways. The first is a pattern of refunds that nobody connects, such as the same account asking for a refund every renewal, or refunds clustered around one plan or one billing step. The second is disputes left without a response. Card networks give the merchant a fixed window to submit evidence, and a dispute with no response is typically lost by default.

In the data, group refunds by customer and by plan, and list open disputes with their evidence due date. For example, three disputes of 500 USD each that pass their deadline without evidence cost 1,500 USD plus the dispute fees, even when the service was delivered and the evidence existed.

Example ten, a cancellation that was really a failed payment

Cancellation reasons tell you how much churn is voluntary. The leak hides in accounts that cancelled shortly after a failed payment, often because the customer saw a failure notice, assumed the service had stopped and cancelled instead of updating the card. Others reached the end of a short retry schedule and were cancelled by the system.

Look for cancellations within a few days of a failed charge, and for subscriptions cancelled by the system rather than by the customer. For example, if 2,000 USD of monthly churned MRR includes 700 USD that cancelled within a week of a decline, that 700 USD belongs in the recoverable column, and a clear dunning sequence with a pause option is the fix. The dunning software page shows how such a sequence is built.

Example eleven, no save step at the moment of cancel

Some customers cancel because of price, a seasonal pause or a temporary drop in need. When cancel is a single button, there is no moment to offer a lower plan or a pause. The data shows it as a cancellation reason such as too expensive or not using it right now, with no offer event before it. For example, if 20 cancellations a month at 100 USD each cite a temporary reason and a pause offer keeps a quarter of them, 500 USD of MRR stays. Read more about this in our guide on how to reduce churn.

Example twelve, abandoned checkouts and failed subscription renewals in a store

Stores with subscriptions and repeat orders leak in two places. A shopper starts a checkout, enters an email address and leaves, and no follow-up goes out. Separately, subscription apps on Shopify and WooCommerce Subscriptions attempt renewal orders, some fail, and the retry and email settings are left at defaults.

The fields are checkouts with an email and no completed order, and renewal orders in a failed or pending payment status. For example, 80 abandoned checkouts a month with an average order of 60 USD hold 4,800 USD of intent. Recovering one in ten is 480 USD a month. See abandoned cart recovery for the follow-up timing.

Adding the examples up for your own business

Each leak looks small in isolation. Together they can be a noticeable share of MRR. The useful step is to size every category in USD per month with the same method, then rank them by value and by effort.

Write down the definitions once and run the same queries every month. The trend matters more than the first figure. A periodic billing leakage review keeps the list current, and the net revenue churn formula shows how several of these leaks distort the retention numbers your board reads.

See each leak in your own billing data

RevenueLeak connects read-only to Stripe, Paddle, Chargebee, Recurly, Shopify or WooCommerce, runs these checks across all nine categories and shows the leak in USD per month with a ranked list of accounts to fix. Nothing changes in your billing system until you switch a recovery rule on.