On the third of the month, a billing clerk at a growing software and support business opens the failed-invoice list. Eleven items. One customer's debit order bounced, one invoice was rejected because it did not carry the purchase order number, one went to an accounts mailbox that no longer exists, and one was charged to a card that expired in the previous quarter. She fixes each one by hand, emails the customer, and moves on. The following month there are fourteen failures. Some are the same customers. Nobody has ever looked at the list as a whole.
Handling each failed recurring invoice as an isolated exception works at 40 customers. At 400 it becomes a permanent part-time job, and the same few causes keep producing new work.
Why isolated handling feels reasonable
Each failure arrives looking unique. The customer is different, the amount is different, and the person who notices it is whoever happens to open the exception list. Fixing it quickly feels like the responsible thing to do, and in the narrow sense it is. The invoice gets paid, the customer is satisfied, and the clerk has cleared her queue.
The trouble is what is not captured. The fix is recorded in an email thread or in the clerk's memory, not in a place where it can be counted. Without a count, nobody can see that nine of the eleven failures this month came from two causes, or that those two causes were there last month as well.
What recurring failure usually has in common
Recurring invoice failures fall into a small number of families. Most businesses find that three or four of them explain the bulk of the volume:
- Payment failures: expired cards, insufficient funds, returned debit orders, changed bank details.
- Delivery failures: invoices sent to a departed employee, a full mailbox or an address the customer no longer monitors.
- Content rejections: a missing purchase order number, wrong legal entity name, wrong VAT number, or an amount that no longer matches the agreed price.
- Timing failures: invoices raised after the customer's payment run cut-off, so they miss a whole cycle.
Each family has a different owner and a different fix. Payment failures sit largely with finance and the payment platform. Delivery and content rejections trace back to customer data captured at the start, which usually belongs to sales operations or onboarding. Timing failures belong to whoever controls the billing calendar. If failures are only ever treated as exceptions, none of those owners ever sees their share.
What the payment platforms already assume
Subscription and invoicing platforms are built on the assumption that failure is routine and should be handled by rule. Stripe's documentation on automating payment retries says payments can fail for many reasons and that many are recoverable. It describes retrying failed subscription and invoice payments according to a configured policy, with a recommended default of eight tries within two weeks. It also lists situations in which no retry happens at all, including when no payment method is available or when the issuer returns a hard decline. That list is a useful reminder: some failures can be retried automatically, and the rest need a person, and the two groups should be separated by rule rather than by whoever spots them first.
The same vendor's description of automatic collection for invoices notes that by default failed payments on certain non-card methods are not retried automatically. A business using debit orders or bank transfers therefore cannot assume that the platform is quietly recovering failures. Someone has to know which payment methods are covered by which recovery rule.
Customer messages can also be automated. The documentation on automated customer emails covers failed payment notifications that let customers update their payment method, expiring card notices, and reminders for unpaid recurring invoices sent on a configured schedule. These do not remove the need for human follow-up, but they take the simplest cases off the clerk's list so that the exceptions she sees are the ones that genuinely need judgment.
You do not have to use any particular platform to apply the idea. A spreadsheet-based billing run can carry the same discipline: a failure reason code on every failed invoice, a rule for what happens next, and a monthly count.
Turning exceptions into a pattern
The change is modest but it needs a decision. Every failed recurring invoice gets a reason code from a short fixed list when it is cleared. Once a month, someone totals the codes, ranks them, and asks the question the clerk has never had time for: what would have prevented the top two causes from happening at all?
Typical answers are small and upstream. Capture a billing contact and a generic accounts address at onboarding, not just a named person. Record the purchase order requirement as a field on the customer, so the invoice cannot be generated without it. Send a card-expiry warning before the next billing date. Move the invoice run three days earlier for customers whose payment runs close on the twentieth. None of these needs new software. All of them need someone to own the list.
The effect compounds with growth. A business that doubles its customer count with the same failure rate doubles its exceptions. A business that has removed the two main causes grows without adding clerk time. This is the broader point made in the existing article on why small tasks become expensive at scale, and it is why growth is such a common trigger for noticing the problem.
Watch for duplicated fixes
One caution. When recovery is partly automatic and partly manual, a payment can be retried by the platform while the clerk also reissues the invoice. The customer pays twice, or receives two reminders for the same debt. The risks of repeated actions in automated processes are covered in retry logic creating duplicate transactions. Before adding any automated retry, agree which failures are left to the platform and which are left to people, and make the status visible so the two do not collide.
If your team already spends time reviewing exception lists, see human exception queues growing faster than automated throughput, and for the follow-up habit that sits behind many of these failures, cash collection that depends on someone remembering.
Practical next actions
- Export the last three months of failed or rejected recurring invoices and sort them into the four families: payment, delivery, content and timing.
- Add a reason code to every failed invoice from now on, selected from a short fixed list when the clerk clears it.
- Identify the two most common causes and name one person who owns each, including the upstream team responsible for the customer data involved.
- Decide which failures are retried automatically and which go to a person, and write the rule down, including which payment methods the retry rule covers.
- Fix the cause at the point of capture: add the required fields, such as purchase order number and a shared accounts mailbox, to your customer onboarding form.
- Review the count of failures by reason in a ten-minute monthly meeting and record whether each cause is growing or shrinking.
Sources and further reading
- Automate payment retries
- Automatic collection (last verified 10 October 2026)
- Automate customer emails
Related Mellorca reading
- Failed direct debits do not automatically create follow-up work
- Collections activity is not visible to account managers
- Cash forecasts ignore real collections workflow states