Failed Payment Log Template: Track Every Failure

Before there is a recovery tool, there should be a log. Most subscription teams learn about failed payments the way they learn about leaks — late, anecdotally, and after the damage is done. A failed payment log template fixes that with deliberately low technology: one row per failure, the fields that matter and no more, a filled example week so your team can copy the format exactly, and a twenty-minute weekly review ritual that turns rows into decisions. Run this log for a month and you will see your failure patterns — issuer clusters, expiry waves, payday timing — while they are still cheap to fix.

This log is the manual foundation of measurement. Once the habit exists, the recovery KPI template turns the same data into headline numbers, and our guide on how to measure dunning performance covers the reporting layer above both.

The log: columns and what goes in each

Set this up as a spreadsheet or a simple table in your team wiki. Resist adding columns in week one — every extra field lowers the chance the log gets filled in at all.

Column	What to record	Format rule
Date failed	Date and time of the declined charge	Your local date, one row per attempt is wrong — one row per failed invoice, attempts noted inside it
Subscriber	Name or account ID, plan, and tenure	Use the account ID your billing platform uses, so rows join up with support tickets
Amount	The invoice total that failed	Exact amount, including tax — amounts expose whether failures cluster on a plan
Decline code	The raw code or message returned by the processor	Copy it exactly. Never paraphrase the processor's words
Decline family	Your grouping: insufficient funds, expired card, card replaced / do-not-honour, authentication required, suspected fraud hold, other	Pick from the fixed list only. The family column is what you sort by in the review
Retry count so far	How many attempts have been made on this invoice, including the first failure	A number, updated as retries happen — not a new row per attempt
Outreach sent	What the subscriber has been sent: email 1, email 2, SMS, in-app notice, with dates	Short codes like E1, E2, SMS1 keep this fast to fill
Card updated?	Whether the subscriber has supplied a new payment method, and when	Yes + date, or No. This separates "fixed themselves" from "retry succeeded"
Outcome	Recovered on retry / recovered after card update / still open / cancelled — involuntary / cancelled — subscriber chose / written off	Closed outcomes only from the fixed list; open rows stay visibly open
Days to resolve	Days from first failure to the closing outcome	Filled at closure. This is the number your retry window is built from
Notes	Anything human: subscriber replied, disputed the charge, asked to pause, mentioned a bank change	One line. Long stories belong in the support ticket, linked here

A filled example week (for illustration only)

The rows below are invented to show the format and the level of detail expected. They are labelled for illustration only and are not real subscriber records or results.

Date	Subscriber / plan	Amount	Family	Retries	Outreach	Outcome	Days
Mon	Acct 1042 — Pro monthly, 14 months	$49.00	Insufficient funds	2	E1	Recovered on retry	3
Mon	Acct 0877 — Basic monthly, 3 months	$19.00	Expired card	1	E1, E2	Recovered after card update	4
Tue	Acct 2210 — Pro annual, 11 months	$470.00	Authentication required	1	E1, SMS1	Recovered after card update	2
Wed	Acct 1560 — Basic monthly, 6 months	$19.00	Insufficient funds	3	E1, E2	Still open	—
Thu	Acct 0931 — Team monthly, 22 months	$129.00	Card replaced	2	E1	Recovered after card update	5
Fri	Acct 3108 — Basic monthly, 1 month	$19.00	Do-not-honour	1	E1	Cancelled — subscriber chose	1
Fri	Acct 2744 — Pro monthly, 8 months	$49.00	Insufficient funds	4	E1, E2, SMS1	Cancelled — involuntary	12

Notice what the format forces into view even in an invented week: insufficient funds appears three times, the only involuntary cancellation took twelve days and four attempts, and the annual-plan failure was an authentication step the subscriber cleared in two days once actually contacted. Real logs surface the same shapes with your own subscribers' behaviour.

The 20-minute weekly review ritual

Same time every week, one owner, the log open. Twenty minutes, four passes, no more.

1. Close the dead rows (5 minutes). Every row older than your full retry window must have a closed outcome or an explicit reason it is still open. A log with stale "still open" rows is a log nobody trusts.
2. Sort by family (5 minutes). Count the week's failures by decline family and compare with the running picture. Churnkey analysis of Stripe data across 5.4M failed payments found insufficient funds is the largest category at 40.6% — if your mix looks nothing like your own history, ask why before you act.
3. Hunt the three patterns (5 minutes). Work the pattern checklist in the next section, in order.
4. Write three decisions (5 minutes). Not observations — decisions, each with an owner and a date: a retry timing change, an email fix, a card-expiry send, a descriptor correction. If a week produces no decisions, the review is theatre; say so and fix the review.

Then size the month. Put the logged failure volume and amounts into the recovery calculator to see what the open rows are worth, and compare your family mix and recovery pace against the failed payment recovery benchmarks so you know whether a bad week is weather or climate.

The three patterns to hunt

1. Issuer clusters. Several failures in a week sharing a bank, a card network quirk, or an identical unusual decline code often means something changed on the issuer side — a portfolio conversion, a stricter authentication policy — not that your subscribers suddenly changed. Clusters call for checking your processor's guidance and your authentication flow, not for more aggressive retries. Never retry hard declines, and treat a sudden cluster of fraud-related declines as a signal to investigate, not a volume to push through.

2. Expiry waves. Cards expire in cohorts — the cards issued together after a big signup month expire together three years later. If expired-card rows start climbing, that is a wave arriving, and the correct response is upstream: a proactive card-update campaign to the cohort whose cards expire next month, before they fail. The log's job is to give you the two or three weeks of warning that makes the campaign possible.

3. Insufficient-funds timing. Plot insufficient-funds failures and their successful retries against the calendar. If recoveries land disproportionately just after common paydays — the start of the month, mid-month, Fridays on a bi-weekly cycle — your retry schedule is fighting the calendar and losing. Shift retry attempts toward the days your own log shows money arriving, and note the change as a dated decision so next month's review can judge it.

Keeping the log alive

Logs die from friction, not from disagreement. Three rules keep this one running: the person who works failures updates the row in the same sitting, never in a Friday batch; the fixed lists for family and outcome are edited only by the log owner, so the categories stay comparable across months; and the weekly review happens even in a quiet week — especially in a quiet week, because a sudden drop in logged failures usually means logging stopped, not that payments healed. Review the column set quarterly. Retire a column nobody reads, and add one only when a real review question went unanswered without it.

The bottom line

A failed payment log template is the cheapest recovery system there is: eleven columns, one row per failure, a weekly twenty minutes of honest sorting. It will not recover a single payment by itself — but it tells you which declines dominate, when retries actually land, which expiry wave is coming, and what every open failure is worth, which is everything you need to fix recovery in the right order. When the log shows more volume than a spreadsheet ritual can carry — and it will, if it works — that is the moment to automate the retries, outreach, and card updates behind it, and you can see exactly what that setup includes on our pricing page.

Frequently asked questions

Should we log every retry attempt as its own row?

No. Keep one row per failed invoice and update the retry count, outreach, and outcome on that row as work happens. One row per attempt multiplies the bookkeeping and makes it impossible to see at a glance how many subscribers are actually affected, which is the number the weekly review runs on.

What is the difference between a decline code and a decline family?

The decline code is the exact raw response returned by the processor, and you should record it word for word. The decline family is your own fixed grouping of those codes — insufficient funds, expired card, authentication required, and so on — which is what makes the log sortable and comparable week over week.

How long should we keep a failed payment row open?

Until the invoice reaches a closed outcome: recovered, cancelled, or written off at the end of your full retry and outreach window. Rows left open past that window without a noted reason are the first thing the weekly review should clear, because stale open rows quietly inflate how bad the problem looks.

Can a spreadsheet really handle this, or do we need software?

A spreadsheet handles the log well at low and moderate failure volumes, and starting there builds the discipline that makes any later tool more effective. When updating rows and running retries by hand starts consuming real staff hours each week, the log itself will show you — in open rows and days to resolve — exactly where automation pays.

Who should own the failed payment log?

One named owner: the person who runs the weekly review, controls the fixed category lists, and writes the three decisions each week. Others can add and update rows, but a log with several owners editing categories in different ways stops being comparable within a month.