Leadership keeps asking for more pipeline while closed-won revenue leaks out through failed payments nobody owns. Here is how to find the leak, set retries on purpose, put payment events in the CRM and give recovery an owner.
Short answer: involuntary churn is revenue you lose when a payment fails, not when a customer decides to leave. In SaaS it is roughly 16 to 33 percent of all churn depending on the data set, and a working recovery path (deliberate retries, CRM visibility, pre-dunning and an owner) gets 70 percent or more of failed payments back.
One traced failed card payment explains most of this page.
Nobody decides to lose these customers. The billing tool, the CRM and three teams each hold one piece, and no one holds the whole thing.
The typical path we trace. The last two boxes are the gap.
The billing system knows the card declined. The account record does not. The CSM, the AE and the exec sponsor are all working the account blind while it quietly goes past due.
→ the root cause in most auditsIt retries a few times on the vendor's schedule, then marks the invoice past due and stops. Whether that ends in cancel, unpaid or pause was set once at onboarding and never revisited.
Finance sees it a month later as a line in the aging report. CS sees it at renewal. Sales never sees it. When everyone can see a slice, nobody owns the save.
The failed-payment email fires after the card is already dead and goes to whoever entered the card two years ago. That person may have left.
New bookings get a weekly call. Failed-payment MRR gets nothing. What leadership never sees, leadership never funds.
If you recover less than half of failed payments, the default retries are doing all the work and nobody else is.
Third-party benchmarks vary because vendors define churn differently, so use ranges, not a single number. Recurly's 2026 benchmarks put the SaaS median at 3.22 percent monthly churn, of which 1.06 points are involuntary, and show involuntary churn falling from 1.30 percent for accounts paying 10 to 25 dollars a month to 0.18 percent above 250 dollars. That is why B2B contracts should sit at the low end.
| Metric | Weak | Acceptable | Strong | Source |
|---|---|---|---|---|
| Failed payment recovery rate | Under 50% | 50 to 70% | Over 70% | Churnkey 2026: retries alone about 51%, retries plus payment wall plus dunning about 70% |
| Monthly involuntary churn rate (SaaS) | Over 1.1% | 0.5 to 1.1% | Under 0.5% | Recurly 2026: SaaS median 1.06%; over 250 dollars a month, 0.18% |
| Involuntary share of total churn | Over 35% | 20 to 35% | Under 20% | Churnkey and Stripe analysis 2026: SaaS 22%, B2B 16%; Recurly 2026 medians imply about 33% |
| Recoveries landing in the first 7 days | Unknown | Tracked | About 61%, and you act inside that window | Churnkey 2026, 5.4M failed payments |
| Retry window | Vendor default, never reviewed | Stripe recommended default: 8 tries in 2 weeks | Chosen per segment, with an owner task | Stripe Smart Retries docs 2026; segmenting from JayOh experience |
| Owner alerted after a failure | At renewal | Within 14 days | Within 72 hours of the 2nd failed retry | JayOh field experience |
Two more numbers shape the playbook. Churnkey reports that soft declines are 80 to 90 percent of all failures, which means most failed payments are retryable, not dead. And Recurly projected that failed payments would cost US subscription businesses more than 129 billion dollars in 2025. That figure is a vendor projection, but the direction is not in dispute.
None of this is new tooling. It connects two systems that already hold the data and gives the problem an owner.
open or uncollectible and subscriptions that moved to past_due, unpaid or canceled. Recovery rate = recovered failed payments divided by all failed payments. Involuntary churn rate = unrecovered failed MRR per month divided by total MRR. Chargebee and Recurly have equivalent dunning reports.Payment Status, Failed Amount, Failed Since, Attempt Count, Next Retry Date.invoice.payment_failed (it carries attempt_count and next_payment_attempt), invoice.paid, customer.subscription.updated and customer.subscription.deleted, per the subscription webhooks docs. In HubSpot, the native Payments object has a Status property you can trigger workflows on (Professional or Enterprise), and HubSpot subscriptions flip to Unpaid when a cycle payment fails; for Stripe billing, use a data sync app or middleware to stamp the five properties. In Salesforce, the Stripe connector stores webhooks as Stripe Event records (stripeGC__Stripe_Event__c) and you filter a record-triggered flow on stripeGC__Event_Name__c. If you bill through Chargebee, our Chargebee to Salesforce and HubSpot integration guide covers the field mapping.Attempt Count is greater than or equal to 2 AND Payment Status is Failed, then create a task for the company owner due in 1 business day and post to the account channel if MRR is above your threshold. Salesforce: record-triggered flow on the Stripe Event object for invoice.payment_failed, look up the account, create a Task for the owner and post to Slack. Unenroll when invoice.paid arrives.Most of the recovery comes from boring decisions made once and enforced by the system.
Put in your numbers to see how much closed-won revenue walks out each month, and what a 70 percent recovery path is worth.
Defaults show a 400K MRR B2B SaaS company. Change any value; results update as you type.
Benchmarks used for the grade: Recurly 2026 SaaS median involuntary churn of 1.06% per month (weak above 1.1%, strong below 0.5%). The calculator ignores win-back and expansion, so it understates the real prize.
Copy the runbook into your wiki, fill in the blanks and assign every line an owner.
Skills are available on Claude Pro, Max, Team and Enterprise plans. New to skills? Read how to use skills in Claude.
Direct answers to what operators ask most.
Involuntary churn is revenue lost when a customer's payment fails and is never recovered, such as an expired card, insufficient funds or a bank decline, rather than because the customer chose to cancel. It shows up as churn even though nobody decided to leave.
It depends on the data set. A 2026 Churnkey and Stripe analysis puts it at 22 percent of SaaS churn and 16 percent for B2B, while Recurly's 2026 SaaS medians (1.06 points of 3.22 percent monthly churn) imply about a third. Plan on roughly one in five to one in three churned customers being payment failures.
Under 50 percent is weak and usually means default retries are doing all the work. 50 to 70 percent is acceptable. Over 70 percent is strong and typically requires deliberate retries, decline-specific dunning, CRM visibility and a human owner, based on Churnkey's 2026 data.
Stripe recommends 8 tries within 2 weeks as a default for Smart Retries, with windows from 1 week to 2 months. Retry soft declines on that kind of schedule, stop retrying hard declines like expired or stolen cards and send an update-card link instead, and never auto-cancel an annual or enterprise contract when retries end.
Yes, but narrowly. Card updater services refresh many expiring cards automatically, and some practitioners see blanket pre-dunning prompt cancellations. Send update-your-card emails 30 and 7 days before expiry only to cards the updater did not refresh, and include the billing contact and the champion.
Listen to Stripe webhooks such as invoice.payment_failed, invoice.paid and customer.subscription.updated, and write payment status, failed amount, failed since, attempt count and next retry date to the company or account record. Use a data sync app or middleware for HubSpot, or the Stripe connector for Salesforce with a record-triggered flow on the Stripe Event object.
Split it by job: RevOps builds and maintains the billing-to-CRM system, the account owner or CSM works the save, and finance reports the number. What fails is when all three can see a slice and nobody is named as the owner.
We see the same pattern in almost every retention audit: leadership asks for more at the top of the funnel while closed-won revenue drips out the bottom through failed payments nobody owns. The fix is rarely a new tool. It is two systems connected, a retry schedule chosen on purpose, five fields on the account record and one named owner. If your CS team is also wrestling with handoffs, our guide to the Closed Won to CS handoff and our RevOps for CS leaders page are the next reads.
Want a second set of eyes on your billing-to-CRM path? We will map where failed payments go today and what it would take to recover them.
Talk to JayOh about your recovery path
We engineer growth systems. JayOh builds the RevOps architecture, GTM execution and data infrastructure that turn messy revenue operations into predictable pipeline for B2B SaaS and PE-backed teams.
