Finance teams ask the same question about every software purchase: what do we get back for this? A sound software ROI calculation will not predict the future, but it forces you to be explicit about costs, benefits and assumptions, and that alone prevents many bad buying decisions. It also gives you a baseline to check against after launch.
This guide shows a simple, defensible way to do it, with a worked example using made-up round numbers so you can see the arithmetic.
The basic formula
Return on investment is the net gain divided by the cost:
ROI (%) = (Total benefit − Total cost) ÷ Total cost × 100
Two companions are worth calculating alongside it:
- Payback period: how long until cumulative benefit covers cumulative cost. Often more intuitive for managers.
- Net present value (NPV): future benefits discounted to today’s value. Useful for large, multi-year systems; ask your finance team which discount rate they use.
Choose a time frame, typically three years for business software, and use the same one for every option you compare.
Step 1: Count the real cost
Total cost of ownership is wider than the subscription. Include:
- Licences or subscriptions over the period, with expected price rises and growth in users.
- Implementation: configuration, data migration, consultants.
- Integration: connectors, development, middleware subscriptions.
- Training: both course fees and the working time people spend in sessions.
- Internal project time: staff hours at a loaded hourly rate.
- Administration and support: the ongoing time of whoever manages it.
- Hardware or infrastructure, if on-premise.
- Exit or switching costs if you expect to leave within the period.
If you are replacing something, subtract costs that will go away, such as the old subscription. Be careful to count only what actually disappears.
Step 2: Identify the benefits and make them measurable
Benefits fall into a few groups. The trick is to translate each into money, or to keep it separate as a non-financial benefit.
Time savings
The most common claim and the most often exaggerated. Estimate:
hours saved per person per week × number of people × weeks per year × hourly cost
Then apply a realisation factor. Saved minutes rarely become productive hours. A cautious approach is to count only half, or less, of the theoretical time, unless the saved time directly removes overtime or temporary labour.
Error and rework reduction
Count how often errors happen now (wrong invoices, duplicate orders, missed renewals), how long each takes to fix, and any direct cost such as credits or refunds. Estimate the fraction the new tool will prevent.
Revenue effects
Faster quotes, better follow-up or fewer abandoned carts might increase revenue. These are the hardest to prove. Use conservative assumptions, count only the margin (not the revenue), and consider listing them as upside rather than baking them into the core figure.
Cost avoidance
Retiring old tools, avoiding hiring for growth, reducing hardware or reducing third-party fees. Include only items you will genuinely stop paying.
Risk and compliance
Better audit trails or access control reduce risk, but the monetary value is uncertain. Describe it qualitatively unless you have solid internal data.
Step 3: Gather baseline data
ROI claims are only as good as the “before” numbers. Before you buy, measure:
- Time to complete key tasks (sample a few people and take an average).
- Volume of each task per month.
- Error and rework rates.
- Cycle times, such as days from quote to invoice.
Ask the people doing the work, not only their managers, and document your sources. If you have no data, say so and use ranges. A needs assessment exercise often produces exactly this baseline, so it pairs well with the ROI work.
How to Run a Software Needs Assessment for Your Company
Worked example
The numbers below are invented for illustration. Replace them with your own.
A 12-person operations team is considering a workflow tool to replace manual spreadsheets and email approvals. Time frame: three years.
Costs
| Item | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Subscription | 6,000 | 6,000 | 6,000 |
| Implementation and integration | 5,000 | 0 | 0 |
| Training (fees plus time) | 2,000 | 500 | 500 |
| Administration time | 1,500 | 1,500 | 1,500 |
| Total | 14,500 | 8,000 | 8,000 |
Three-year cost: 30,500.
Benefits
- Time saved: 12 people × 2 hours a week × 46 working weeks × 25 per hour = 27,600 a year in theory. Applying a 50% realisation factor gives 13,800 a year.
- Fewer approval errors: 3 incidents a month × 1.5 hours to fix × 25 per hour = 112.50 a month, about 1,350 a year, assuming the tool prevents most of them. Count 1,000 to be cautious.
- Retired tool: 1,200 a year.
Annual benefit: 13,800 + 1,000 + 1,200 = 16,000. Over three years: 48,000. (In practice benefits ramp up gradually, so year 1 might be lower. For simplicity we use a flat figure here.)
Result
- Net gain: 48,000 − 30,500 = 17,500
- ROI: 17,500 ÷ 30,500 × 100 ≈ 57%
- Payback: cumulative cost after year 1 is 14,500 against 16,000 of benefit, so it pays back within the first year on these assumptions, subject to the ramp-up caveat.
Now stress-test it. If the realisation factor is 25% instead of 50%, time savings fall to 6,900 a year, annual benefit to about 9,100, and three-year benefit to 27,300. That is below cost, with a negative ROI. This tells you the decision depends heavily on that one assumption, so you should validate it in a pilot.
Step 4: Run sensitivity checks
Build three scenarios: conservative, expected and optimistic. Change the biggest assumptions (usually time saved and adoption rate) and see what happens to ROI and payback. If the project only works under the optimistic case, treat that as a warning. If it works in the conservative case, you have a more robust argument.
Step 5: Present it honestly
Show your assumptions in a table, label estimates as estimates, and separate hard savings (money that leaves the budget) from soft savings (time freed up). Add a short list of non-financial benefits: staff satisfaction, faster customer response, better visibility. Include the key risks, such as low adoption or integration problems. Executives tend to trust a model that shows its weak points.
If your decision involves a specific category, for instance weighing ERP against CRM, you can reuse the same structure for each option to compare like with like.
ERP vs CRM: Which Does Your Business Need First?
Step 6: Measure after launch
An ROI case that is never revisited is just a sales document. Pick two or three metrics (task time, error count, adoption rate), record them at 30, 90 and 180 days, and compare them to the baseline. Share results with stakeholders. If benefits fall short, find out why: usually it is training, configuration or process design rather than the product itself. Our guide on integrating applications can help if the gap is manual re-entry between systems.
How to Integrate Business Apps Using APIs and Automation
Common mistakes
- Counting only the subscription as cost.
- Assuming every saved minute becomes productive work.
- Double-counting the same benefit under different names.
- Ignoring the learning curve in the first months.
- Using vendor-supplied benchmarks without checking they match your situation.
Frequently asked questions
What is a good software ROI?
There is no universal threshold. Many organisations set an internal hurdle, such as a payback period within a certain number of months or a minimum return compared with other investments. Ask your finance team what they use.
How do I value time savings fairly?
Use a loaded hourly cost (salary plus employer costs) and apply a realisation factor. Treat time savings as soft savings unless they remove actual spend such as overtime or contractors.
Should I include intangible benefits?
List them, but keep them separate from the numerical ROI. Better morale, faster decisions or reduced risk matter, but turning them into precise figures usually invites challenge.
How long should the evaluation period be?
Three years is common for business software. Shorter periods penalise tools with upfront setup effort; longer ones rely on increasingly uncertain forecasts.
Conclusion
A useful software ROI calculation is not about finding a magic percentage. It is about listing every cost, converting benefits into cautious numbers, testing the assumptions and then checking reality after launch. Do that, and you will make better buying decisions and have clear evidence when a tool is working, or when it is time to change course.
