Every larger software project demands one answer before you sign: in how many months does it pay for itself? If neither you nor the vendor can answer with a number, you are not building an investment — you are hoping. The good news is that calculating payback is not rocket science. Two numbers and one formula are enough.
The formula you can memorise
Annual ROI = (annual benefit − annual running cost) ÷ project price. Even more practical is the payback period: project price ÷ monthly net benefit = the number of months until the investment is repaid. And benefit is not only saved time — it includes fewer errors, lower penalties, higher conversion, and revenue you simply could not have served without the system.
Example 1: order automation
Three people spend a combined 120 hours a month re-typing orders between systems, and an 11% error rate drives complaints. At a labour cost of €18/h, the time alone is €2,160 a month. Automation for €38,000 cuts manual work by 74% (saving ~€1,600/mo) and the error rate below 1% (another ~€900/mo in avoided complaints). A monthly benefit of ~€2,500 means a payback of roughly 15 months — and from year two it is pure saving.
Example 2: site speed and conversion
An e-shop with €1.8M annual revenue has a slow checkout and a 1.3% conversion rate. Cutting load time from 4.1 to 1.2 seconds and rebuilding the checkout lifts conversion by 23%. At the same traffic, that is roughly +€210,000 in annual revenue. For a €31,000 project, the payback is under two months — here, site speed translates straight into sales.
Example 3: AI document processing
A financial firm processes 1,400 contracts a month, each re-typed by hand into three systems. An AI workflow with extraction and checks shortens approval from 5 days to 8 hours and cuts admin by 62%. With an AI Sprint at €14,900 and savings on the order of €4,500 a month, payback is under four months — without hiring a single new person.
Three mistakes that ruin an ROI calculation
First, counting only development and forgetting running cost — hosting, support and further development. Second, having no baseline: if you do not know what the process costs today, you have nothing to measure the improvement against. Third, promising benefit without measuring it. That is why we define KPIs before the start, measure the baseline, and after launch compare with the same method — otherwise every number is just marketing.
When software is a cost, not an investment
Not every project pays back — and an honest vendor tells you before you sign. If the benefit depends on volume you do not have (automating a process that runs three times a month) or on behaviour you cannot influence, the payback stretches into years. Rule of thumb: if payback exceeds the lifetime of the solution or 36 months, find a cheaper way to solve the problem. Sometimes the best ROI is not starting the project at all.
The benefit you will not see in a spreadsheet
Hard numbers — saved hours, fewer errors, higher conversion — are only half the story. The other half is the soft benefit that shows up later: faster decisions from real-time data, lower turnover once people stop doing mind-numbing routine, and reputation when you answer a client in an hour instead of three days. We do not put soft benefit into the formula as a guess — we write it into the contract as a secondary KPI, so nobody forgets it a year on.
A euro today is not a euro next year
For projects with a payback beyond two years, it pays to look at the money through a finance lens, not just an accounting one. A hundred thousand saved three years out is worth less today than a hundred thousand this year — because of inflation and the alternative return on capital. So for longer projects we apply a simple discount and favour solutions that deliver savings sooner. A short payback is not just convenience; it is lower risk that the world shifts under your feet in the meantime.
If you have the payback period and the measurement method shown to you before signing, you separate an investment from a cost in a single meeting. And that is exactly the difference between a vendor who delivers and one who presents.