How much revenue leakage justifies software?
Work out the level of revenue leakage at which software pays for itself, and why the flow of new leaks matters more than the backlog of old ones.
Software for monitoring revenue is justified when the leakage it finds, and that you actually recover, is comfortably higher than the total annual cost of the software plus the time to follow up findings. A useful rule of thumb: annual leakage should be at least two to three times that total cost, because you never find everything and never recover everything. Even more important than the total is how many new leaks arise each month: you clear the backlog of old leaks once, while the flow of new leaks is what ongoing software pays for.
The calculation behind the threshold
You want to know the level of leakage at which software pays off. That is the break-even point. It is not simply the price of the software, because there are two filters between leakage and return.
Detection rate. No system finds all leakage. Some of it sits in agreements that were never recorded, in systems that are not connected or in patterns that only become visible after months.
Realisation rate. Not everything you find becomes revenue. Old discrepancies cannot always be recovered, and some corrections are not commercially wise.
The threshold is then:
Minimum leakage = total annual cost / (detection rate x realisation rate)
Worked example: the threshold for your company
Suppose the total annual cost of software plus internal follow-up is EUR 40,000. You assume the software finds 60 percent of the leakage, and that you realise 70 percent of that. These are example assumptions.
- Detection rate x realisation rate = 0.6 x 0.7 = 0.42.
- Minimum leakage = EUR 40,000 / 0.42 = about EUR 95,000 a year.
Below EUR 95,000 of leakage a year, the software costs more than it delivers. At EUR 200,000 it delivers about EUR 84,000, more than twice the cost.
Set that amount against your revenue. At EUR 5M revenue, EUR 95,000 is almost 2 percent. At EUR 15M revenue, it is just over 0.6 percent. The larger the company, the lower the percentage of leakage needed to justify software.
How does the threshold compare with revenue?
The commonly cited estimate for revenue leakage is 1 to 5 percent of revenue. Where that estimate comes from and how reliable it is is covered in how much revenue leaks on average. Setting that range against the threshold from the example:
| Annual revenue | Leakage at 1% | Leakage at 3% | Threshold (example: EUR 95,000) |
|---|---|---|---|
| EUR 2M | EUR 20,000 | EUR 60,000 | Not reached |
| EUR 5M | EUR 50,000 | EUR 150,000 | Only with higher leakage |
| EUR 10M | EUR 100,000 | EUR 300,000 | Reached, even at 1% |
| EUR 25M | EUR 250,000 | EUR 750,000 | Comfortably reached |
The threshold depends on what the software costs. A solution costing EUR 15,000 a year including follow-up has a threshold of about EUR 36,000, and can be justified even at a EUR 3M company if enough is leaking. Which pricing models exist and which costs come on top of the licence is covered in what a Revenue Intelligence platform costs.
Backlog and flow: the distinction that decides the choice
The total amount of leakage is not the only measure. What matters more is where it comes from.
The backlog is the leakage that has built up over the years: contracts that were never indexed, discounts that run too long, subscriptions set up wrongly. You find it once, you correct it, and then it is gone.
The flow is the leakage that arises anew every month: new deals handed over incorrectly, new additional work not invoiced, new price changes not implemented.
For the backlog you do not need ongoing software. A thorough one-off check is enough. For the flow you do, because a one-off check only finds the leaks that exist at that moment.
So the question is not only how much is leaking, but how much is added each month. A company with a large backlog but a small flow, because it signs few new contracts and changes little, is better served by a one-off clean-up. A company with a small backlog but a large flow, because it grows fast and sells a lot of custom work, is better served by continuous monitoring.
How to estimate the flow
- Run a one-off check over a recent period, for example the last quarter.
- For each discrepancy found, establish when it arose.
- Count how many discrepancies arose per month, and what they are worth.
- That is your flow. Multiply by twelve for an annual figure.
If that flow is comfortably above the threshold, ongoing software pays off. If it is below, a periodic check is probably enough.
What else to weigh besides the amount
The amount is the hard measure. A few softer factors can shift the balance.
Complexity and growth. A company that grows fast, adds new product lines or introduces a new pricing model gets a larger flow. What is below the threshold today may be above it in a year.
Dependence on individuals. If the current check depends on one person who does it well, there is a real risk that the check disappears when that person leaves.
Other returns. Time saved, better forecasts, earlier sight of customers who are slipping away. You do not count these in the threshold, but they can tip a borderline case.
Valuation. If you expect a sale or a funding round within a few years, demonstrable control over your revenue is valuable in its own right.
The alternatives below the threshold
If your leakage is below the threshold, that does not mean you should do nothing. It means you should do something cheaper.
- A fixed monthly process in spreadsheets. Export, match, flag differences, one owner per discrepancy. Works well with a limited number of customers and contracts.
- Better processes at the handover. A second check on every new contract, a checklist for additional work, an annual indexation round. Prevents a large part of the flow.
- A periodic external audit. A one-off review that finds the backlog and points out the biggest sources of the flow. The Revenue Audit is such a review, separate from any software.
Where the line lies between what you can do by hand and where automation starts to pay off is covered in how to detect revenue leakage automatically.
A decision framework
- Estimate your total leakage. Take a sample, or use the bottom of the range if you have no data yet.
- Separate backlog and flow. How much is old, how much arises each month?
- Calculate your threshold. Total annual cost divided by detection rate x realisation rate.
- Compare the flow with the threshold. Flow comfortably above the threshold: ongoing software pays off. Flow below the threshold: a one-off clean-up and better processes.
- Clear the backlog either way. That always pays, with or without software.
- Repeat in a year. Growth and change shift the outcome.
How to build the full business case including the payback period is covered in how to calculate the ROI of Revenue Intelligence. For the broader picture of all returns: what Revenue Intelligence delivers.
Frequently asked questions
Is there a fixed percentage of leakage above which software pays off?
No. It depends on what the software costs and how large your revenue is. A EUR 20M company may already have enough at 0.5 percent leakage to justify software, while a EUR 3M company may not have enough at 2 percent. Work it out with your own costs.
What detection rate and realisation rate should I assume?
There are no reliable standard values. Use cautious assumptions and ask the vendor how they arrive at their estimate. After six months you can measure the actual values and adjust the calculation.
What if I do not know how much is leaking?
Then that is the first question to answer. A sample of one quarter or a one-off review gives you a figure to work with. Buying software without knowing what is leaking is a gamble.
Should the software pay for itself within a year?
That is a strict but healthy requirement. The implementation costs fall in year one, so if the case is already positive then, it is robust. A case that only turns positive in year three rests on many assumptions about the future.
More in this cluster
- What does Revenue Intelligence deliver?Start here
- When does a business need Revenue Intelligence?
- Do I need Revenue Intelligence if I already have a CRM?
- Do I need Revenue Intelligence if I already have Power BI?
- Can an SME use Revenue Intelligence?
- Who is responsible for revenue leakage?
- When does a revenue audit make sense?
- What does revenue leakage cost?