Most subscription teams can tell you what their recovery tool costs. Very few can tell you what it returns, measured the way they would measure anything else they pay for. The monthly invoice is a precise number. The recovered revenue beside it is usually a vendor dashboard figure, accepted on faith, blended from retry saves, card updates, and subscribers who would probably have paid on the next attempt anyway. That asymmetry is strange, because recovery is one of the few software categories where the output is literally money. An honest audit is not hard. It is just rarely scheduled.
Start with the denominator, because every inflated return begins there. The audit population is every failed renewal in the period, not the subset the tool chose to work, not the accounts still active at month end, and not the failures excluding hard declines. Count recovered accounts against that full population, and count recovered revenue the same way: the amount actually collected from accounts that failed at least once, within a window you name in advance. Thirty days is a defensible window. Ninety flatters everyone. Whatever you choose, write it down before you look at the results, because a window chosen after the fact is a conclusion choosing its evidence.
Next, separate the mechanisms. A card refreshed automatically by the network, a subscriber who clicked an update link, and a retry that succeeded on its third timing guess are three different saves with three different costs and three different lessons. If your tool's report blends them into one heroic percentage, ask for the split. The worked method in a payment recovery ROI calculation you can audit line by line insists on exactly that separation, because a program that looks strong on blended numbers can turn out to be riding on card refreshes that would have happened with no tool at all.
Then price the whole program, not the subscription line. Add the fees on recovered revenue if your pricing works that way, the staff time spent watching queues and handling billing support tickets, and the cost of the subscribers you annoyed into cancelling with one message too many. Percentage-of-recovery pricing makes this step essential: the better the month, the larger the cut, and a program can be genuinely effective while still being badly priced for the value it adds. Run the same audit under a flat-fee assumption and compare. The comparison itself is information, whichever way it lands.
The audit also needs a counterfactual, stated humbly. Some share of failed payments recover with no intervention at all, through ordinary retries and customers fixing cards on their own. You cannot know your exact baseline without a holdout, and most small teams will not run one. But you can bound it: look at your recovery pattern before the tool, or at failure categories the tool does not touch. A vendor figure that credits the program with every save above zero is not lying exactly. It is just answering an easier question than the one you are paying to have answered.
Do this quarterly and the conversation with any vendor changes character. You stop arguing about dashboards and start comparing definitions, which can actually be settled. You also learn which failure categories your money is really working on, and that knowledge steers everything downstream: cadence, messaging, even which plans to sell. Swipe Again publishes its pricing flat and its counting method openly for a simple reason: a recovery program that survives an audit is worth more than one that merely survives a demo, and the audit is the customer's idea to run, not the vendor's favour to grant.
One last discipline: keep the audit sheet. A single quarter's numbers can be weather. Four quarters in a row, measured identically, are climate, and climate is what renewal decisions should be made on. The teams that keep the sheet rarely overpay for long, because the sheet remembers what the dashboard would prefer everyone to forget.
Top comments (0)