Failed recurring payments: what they really cost a growing business

A failed recurring payment looks like a small problem. A card has expired, a bank has declined the transaction, or a customer's account has insufficient funds on the day. On its own, each failure is a minor administrative task. Multiplied across hundreds or thousands of customers, it becomes one of the most persistent and least visible drains on a growing business.

The cost is rarely where people look for it

Most finance and operations teams measure the cost of failed payments in terms of the revenue not collected on time. That figure matters, but it understates the real impact.

The larger cost sits in the staff time spent chasing failed payments manually: identifying which payments failed, contacting the customer, taking a new card number, and re-attempting the transaction. For a business with a subscription or membership model, this can consume a disproportionate amount of finance team capacity, particularly around monthly billing cycles when failure volumes spike together.

There is also a customer experience cost. A customer whose payment fails and who then receives a manually chased, sometimes delayed, request for updated card details, has a noticeably worse experience than one whose payment simply retries and updates in the background. Repeated failures without resolution are also one of the more common, and most avoidable, causes of customer churn.

The scale of the problem

This is not a marginal issue. The Recurly 2026 State of Subscriptions report put the global cost of failed subscription payments at 129 billion US dollars (£94.5 billion) in lost revenue in 2025, and separate industry research puts involuntary churn, customers lost to failed payments rather than any decision to leave, at 20-40% of total subscription churn across most sectors. On average, around 10% of recurring payments fail on their first attempt.

The detail matters as much as the headline figure. A card that has been cancelled needs a new card. A payment declined for insufficient funds on a specific day often clears on a well-timed retry a few days later, with no customer involvement needed at all.

Why payments fail in the first place

Card expiry is the most common cause, and it is entirely predictable. Every card issued has an expiry date recorded at the point of setup, yet many recurring payment systems make no use of that information until the payment itself fails.

Other common causes include temporary insufficient funds, bank-side fraud flags on unusual transaction patterns, and changes to a customer's card following a lost or stolen card replacement. Getting the retry schedule right, how soon, how often, and for how long, makes a meaningful difference to recovery rates, even without treating each cause differently.

What effective recurring payment management actually does

Automated recurring payment management addresses this through configurable, consistent handling, rather than relying on staff to catch and re-attempt each failure manually.

Card expiry is tracked proactively, with customers prompted to update details before a payment is due, not after it has failed
Retry timing, frequency, and number of attempts are configured at account level, along with what happens if a payment still cannot be collected, whether that means suspending immediately or deferring to the next attempt
Customer notifications are handled automatically and consistently, removing the need for finance staff to draft and send individual chase communications
Plan changes, pauses, and cancellations are managed within the same system, reducing the administrative overlap between billing and customer service

The effect of these changes together is a measurable reduction in failed payment volume, alongside a significant reduction in the manual staff time spent managing the payments that do fail.

Why this matters more as a business scales

The administrative burden of manual payment chasing does not scale in a straight line. A business managing fifty recurring payments manually can absorb the occasional failure without much disruption. A business managing five hundred cannot, because the failure rate stays broadly proportional while the available staff time to manage it does not increase at the same pace.

This is typically the point at which businesses recognise that recurring payment management needs to move from a manual, ad hoc process to a managed system, ideally before failure rates and staff workload have already become a visible problem internally.

Next step

Adelante's recurring card payments handle plan creation, retries, card expiry updates, and customer notifications within a single automated system, with typical deployment taking one to two weeks.

Speak with our team to understand what a reduction in failed payments could mean for your business, both in recovered revenue and in staff time returned to more valuable work.

< Older Post

Call centre agent wearing headset working at a desktop computer in an office

The PCI compliance gap hiding in your council's payment channels

By Ned Lowe • August 21, 2026

Councils often assume their payment security is covered, but PCI DSS compliance gaps tend to build up quietly across departments, suppliers, and channels. Here is where they usually hide, and what closes them.

Woman working at a desk on a computer with a large monitor showing spreadsheets in an office

Why manual reconciliation is costing council finance teams more than they realise

By Ned Lowe • July 27, 2026

Manual council income reconciliation costs far more than most finance teams recognise, particularly around month end, when transaction volumes are highest and reporting deadlines are closest together. Ask a council finance team how long reconciliation actually takes each month, and the answer is rarely a precise figure. It is usually something closer to “however long it needs to,” because the process tends to expand to fill whatever time is available. Where the time actually goes Reconciliation is often assumed to be a single task, but it is really several tasks stacked together. Bank statements are exported and reviewed line by line against income records. Payments are matched manually, one at a time, even though the majority of them are routine and unremarkable. Genuine exceptions, the handful of transactions that actually need investigation, are buried within a much larger volume of transactions that simply need confirming. This matters because the effort involved in reconciling a straightforward, correctly allocated payment is, in a manual process, almost identical to the effort involved in reconciling one that needs closer attention. Every transaction gets the same level of manual handling, regardless of whether it needs it. The risk sitting behind the time cost The time cost is the most visible problem, but it is not the only one. When reconciliation is manual and high-volume, errors, missed payments, and unusual transactions become harder to identify, simply because they are one line among many being reviewed at speed. A duplicate payment, a missed allocation, or an irregular transaction pattern can sit unnoticed for longer than it should, particularly during the periods when reconciliation is most rushed. For councils managing income across multiple bank accounts and multiple services, this risk compounds. Each additional account is another full manual review, and each additional service is another set of transaction patterns that finance staff need to hold in mind while working through the detail. What automated matching actually changes The shift from manual to automated reconciliation is not about removing finance team oversight. It is about applying that oversight only where it is genuinely needed. Automated matching clears allocated payments in a single step, whether that is a straightforward one-to-one match or the more complex one-to-many, many-to-one, and many-to-many matching that real-world reconciliation regularly requires. What remains for the finance team to review is the smaller set of genuine exceptions, the transactions that actually warrant a closer look, rather than the full transaction volume. This changes reconciliation from a task defined by volume to one defined by exception. A month with ten thousand transactions and a month with one thousand transactions require a similar amount of finance team attention, because the review effort scales with the number of exceptions, not the number of transactions. What this looks like for a council finance team in practice ● A rolling balance is maintained per bank account, so finance teams can track position without a full manual reconciliation each time ● Reconciliation extends across every bank account a council holds, filtered by payment date or posted date as needed ● Notes can be added and items archived without affecting overall totals, keeping a clear working record without disrupting the wider reconciliation ● Standard reports are available and can be copied and tailored to a council’s own reporting process, rather than requiring a reporting structure to be built from scratch Why this does not require a new system One of the more common assumptions about reconciliation improvements is that they require replacing existing systems or migrating data, which is often reason enough for the improvement to be deprioritised. Bank Reconciliation , as a SmartPay module, works directly within the SmartPay income records already in place, using the same secure access finance teams already have. There is no new system to learn and no migration project to plan around, which means the time saved on reconciliation is not offset by a lengthy implementation process to get there. Next step If reconciliation is currently taking longer than it should, particularly at month end, or if visibility across multiple bank accounts has become harder to maintain as transaction volumes have grown, it is worth seeing how automated matching changes that balance in practice. Contact the SmartPay team to Arrange a short demonstration of the Bank Reconciliation module, using examples relevant to your own reconciliation process.