Resources

Reading Decline Reports: Your Failures Are Data

Every failed payment leaves a receipt. Your processor records why each charge was declined, and those records — decline reports — are the closest thing subscription businesses have to an X-ray of lost revenue. Most operators glance at a failure count, feel bad, and buy a tool. Read the report properly first. Grouped and counted, your failures will tell you how much of the problem is timing, how much is stale card data, how much is genuinely dead — and how much any recovery effort, bought or built, can realistically fix.

Where decline reports live

The exact location varies by platform, but the data exists on every major billing system. Processors return a decline code and usually a plain-language description with each failed charge, and billing platforms surface them in failed-payment or invoice views, transaction exports, or revenue-recovery reporting. What you want is a row-level export for a defined window — 90 days is a useful default — with at least these fields: date, subscriber or invoice identifier, amount, decline code, decline description, and whether the payment eventually succeeded.

If your platform only shows summaries, export the raw transactions and build the summary yourself. Our guide to measure dunning performance covers the metrics that sit on top of this data once it is clean, and the failed payment log template gives you a ready-made structure for the row-level record if your export is thin.

Step one: group by family, not by code

Raw decline codes number in the dozens, and reading them one by one teaches little. Group them into families that share a correct response. Five families cover nearly everything:

• Insufficient funds. The card is valid but the account behind it cannot cover the charge right now. This is a timing problem. According to Churnkey's published analysis of Stripe data, across 5.4M failed payments, insufficient funds is the largest decline category at 40.6%. In most reports it will be your largest family too.
• Card data problems. Expired cards, incorrect numbers, failed verification values, and cards replaced since the details were stored. This is an information problem: no retry succeeds until the subscriber supplies new details or an updater refreshes them.
• Generic soft declines. Do-not-honor and similar issuer refusals with no durable reason — velocity checks, temporary risk flags, issuer discretion. These often succeed on a later, sensibly spaced attempt.
• Issuer and authentication friction. Transactions that need the customer to approve or authenticate, or issuers that block a category or a cross-border charge. These need customer contact, not retries.
• Hard declines. Closed accounts, lost or stolen cards, confirmed fraud blocks. The payment method is dead. Retrying it will never work and the only correct action is requesting new details or accepting the loss.

The grouping rule is simple: if two codes deserve the same response, they belong to the same family for reporting purposes, whatever their formal names. You are building a work list, not a taxonomy paper.

Step two: count money, not just events

A failure count misleads twice. First, the same subscriber failing three times is one problem, not three. Second, families differ wildly in value — a report heavy with small annual-plan failures may matter more than a larger count of tiny monthly ones. For each family, calculate three numbers: unique subscribers affected, total revenue attempted, and revenue eventually recovered under your current handling. The third number is your baseline. Every improvement claim anyone makes to you later — vendor, colleague, or your own future self — should be measured against it.

Also track your overall failure rate so the report has context. Our explainer on payment failure rate shows how to calculate it consistently — failed charges against total attempted charges — so a rising failure count caused by growth is not mistaken for a worsening problem.

Step three: find the fixable share

Now the report earns its keep. Sort families by what action can change their outcome:

Family	Can action fix it?	The fix it needs
Insufficient funds	Often — with timing	Retries aligned to pay cycles, spaced over days, plus a clear notice
Generic soft declines	Often — with spacing	Later attempts at sensible intervals, not immediate repeats
Card data problems	Yes — with customer help	A fast, branded card-update flow and reminders that name the problem
Authentication friction	Sometimes — with contact	Direct outreach telling the subscriber exactly what to approve
Hard declines	Only with new card details	Stop retrying; request new details once, clearly, then close

Add the first three families together and you have your fixable share: the portion of failed revenue where behaviour — yours or the subscriber's — can change the result. That share, multiplied by your attempted revenue, is the honest ceiling for any recovery investment. If the fixable share is small, your problem is not dunning; it may be pricing, audience quality, or a card-on-file collection problem at signup. Buying recovery software to solve a non-recovery problem is how good money follows bad.

Patterns worth hunting for

Spikes on specific dates

Failures that cluster on certain days point at systemic causes: a price increase landing, a batch of annual renewals with year-old cards, a processor incident, or payday misalignment for your audience. Date clustering is the report's way of saying this was an event, not a trend.

One plan or price point dominating

According to Churnkey's published analysis, low price points under $10/mo show the highest involuntary share at roughly 35%. If your cheapest plan dominates the failure report, suspect card quality at signup and small-charge issuer behaviour before suspecting your customers.

Repeat failures from the same subscribers

Subscribers who fail, recover, and fail again every cycle are telling you their payment method or cash timing is structurally mismatched to your billing date. Offer a billing-date change or an annual option where your product allows it. Retrying harder at the wrong date is not a strategy.

Hard declines you kept retrying

Count attempts made after a hard decline arrived. That number should be zero. Every business that audits this for the first time tends to find waste, because many default sequences retry everything equally. It costs little money per attempt; it costs credibility with issuers and trains your reporting to overstate effort.

What to do before buying anything

1. Pull 90 days of row-level failures and group them into the five families above.
2. Calculate the fixable share in subscribers and in revenue, and your current recovery baseline per family.
3. Fix the free things. Stop retrying hard declines. Make the card-update page work on a phone in under a minute. Write the failure email so it names the specific problem and the single action needed. According to Churnkey's published analysis of Stripe data, each additional dunning email touch adds roughly 1–2 points of recovery — sequencing you already own can move the number before any purchase.
4. Re-measure for one cycle. Compare the same families against your baseline. What remains unfixed after honest free work is the true scope of a tool purchase — and now you can evaluate any vendor against your own families instead of their marketing categories.

The bottom line

A decline report, read by family and valued in revenue, converts a vague anxiety about failed payments into a sized, fixable work list. Most businesses discover the same shape: a large timing problem, a meaningful card-data problem, a soft-decline pool that spacing can win, and a hard core that should never have been retried. Find your fixable share first. It tells you whether you need better emails, better timing, a recovery tool, or a harder look at signup — and it protects you from buying any of them for the wrong reason.

Frequently asked questions

Where do I find decline codes for my failed payments?

Your billing platform or processor stores a decline code and description with each failed charge, visible in failed-payment views, invoice records, or transaction exports. Export row-level data for a defined window such as 90 days, including the date, amount, code, description, and whether the payment eventually succeeded, so you can group and value the failures yourself.

What is the most common reason payments decline?

Insufficient funds is typically the largest family: the card is valid but the account cannot cover the charge at that moment. It is primarily a timing problem, which is why retries aligned to pay cycles and clear subscriber notices recover more of it than immediate repeated attempts do.

What is the fixable share of failed payments?

The fixable share is the portion of failed revenue in families where action can change the outcome: insufficient funds with better timing, generic soft declines with better spacing, and card-data problems where the subscriber can supply new details. Hard declines are fixable only if the subscriber provides a new payment method. Calculating this share shows the realistic ceiling for any recovery effort.

Why should hard declines never be retried?

A hard decline means the payment method itself is dead: the account is closed, the card was reported lost or stolen, or the issuer has blocked it. No later attempt on the same details can succeed. The correct response is to request new card details from the subscriber and stop spending attempts on the old ones.

How often should I review decline reports?

Monthly is a practical cadence for most subscription businesses, using a rolling 90-day window. Review sooner after any pricing change, plan change, or billing-platform migration, because each of those can shift the family mix suddenly, and date-clustered spikes are easiest to explain while they are recent.