How do you measure the return on a software investment?
Return on a software investment is only trustworthy if you measured the starting point. KodDelta asks for three baseline numbers before any build: hours spent on the task, the rate of rework, and the elapsed time from start to finish. Measure them for two weeks, then measure the same three after go-live.
Every software proposal contains a return argument, and most cannot be checked. This page is about the checkable version: which numbers to write down before you start, how to collect them, and which of the resulting gains are genuinely cash.
The two formulas, and why they are the easy part
| Figure | How it is calculated | What it tells you |
|---|---|---|
| Net annual gain | Labour saved + rework avoided + margin gained − annual maintenance | The recurring benefit, after the cost of keeping the system running |
| Payback period | Build cost ÷ (net annual gain ÷ 12) | How many months until the build has paid for itself |
| Annual ROI | (Net annual gain ÷ build cost) × 100 | The recurring return as a percentage of what you spent once |
None of this is difficult arithmetic. The difficulty is the inputs. A payback figure is exactly as trustworthy as the measurement of the process before it changed, and most companies have never made that measurement.
The three numbers to baseline
- Hours. How long the task takes, per person, per week — not the estimate people give in a meeting, but the number they write down while doing it.
- Rework. How many transactions a month are corrected, returned or re-entered, and what one of them costs to resolve, counting everyone who touches it plus any freight, scrap or credit note.
- Elapsed time. How long a case takes from arrival to completion. An order needing eleven minutes of work but four days of waiting has a waiting problem, and waiting is what customers experience.
These three cover almost every genuine benefit a workflow system produces. If a claimed gain does not show up in one of them, be suspicious of it.
How to collect the baseline in two weeks
-
Pick one process, not the company
Choose the single workflow the project will replace first. Measuring everything produces nothing.
-
Give each person one sheet and one question
"How many minutes today on this task?" recorded at the end of each day for ten working days. Anything more elaborate will not be filled in.
-
Count rework from records you already have
Credit notes, return authorisations, corrected invoices and re-sent shipments are already in your accounting package. Pull three months and take a monthly average.
-
Timestamp twenty real cases, and fix your hourly rate
Note when each of twenty recent transactions arrived and completed; the median is your elapsed time. Then set the loaded hourly wage once — gross salary plus employer contributions divided by actual working hours — and use it in every calculation afterwards.
Two weeks of this makes every later claim arguable in a way a supplier's slide never will be. The full method for costing manual work is in the hidden cost of manual work.
Which gains are cash, and which are only capacity
This distinction decides whether your finance team believes the case.
| Gain | Cash or capacity? | Condition for it to be cash |
|---|---|---|
| Fewer hours on data entry | Capacity by default | Becomes cash if overtime stops, a temp contract ends or a vacancy is not refilled |
| Fewer corrections and returns | Cash | Freight, scrap and credit notes are already real spend |
| Cancelled software subscriptions | Cash | Only once the contract is actually terminated, not at renewal intent |
| Faster quote turnaround | Capacity, sometimes revenue | Cash only if you can show win rate or order volume moved |
| Lower stock buffers | Working capital | Measurable directly from average inventory value |
| Better visibility for management | Neither | Real, but do not put a number on it |
A case that puts every saved hour straight into the cash column will be challenged in the first review meeting, and rightly. Separating the columns is what makes the rest of the numbers credible.
A worked example, with its assumptions on the table
A distributor re-enters dealer orders by hand. Three staff spend five hours a week each on it, and about forty orders a month need correcting afterwards.
| Line | Assumption | Annual effect |
|---|---|---|
| Build cost | Dealer ordering module, one-off | $12,000 |
| Baseline hours | 15 hrs/week at $15 loaded | $11,700 of paid time |
| Hours after go-live | Falls to 4 hrs/week for exceptions | $8,580 released |
| Corrections | 40/month falls to 8, at $25 each to resolve | $9,600 avoided |
| Maintenance | 18% tier on a $12,000 build | − $2,160 |
| Net annual gain | Sum of the above | $16,020 |
| Payback | $12,000 ÷ $1,335 per month | About 9 months |
The correction saving is cash immediately. The $8,580 of released hours is capacity until those three people are doing something the business can point to, or until the overtime stops. Presented that way the case survives scrutiny; presented as "$16,020 saved", it does not.
When and how to measure after go-live
- Month one is provisional. People are still learning the screens and old habits run in parallel. Record it, but do not report it as the result.
- Month three is the real reading. Repeat the same two-week measurement, with the same people and the same sheet.
- Compare like periods. Same season, same working days, comparable volume. If volume changed, express the result per transaction.
- Keep the baseline document. A year later nobody remembers what the process cost before, and without it the improvement becomes an anecdote.
Three ways software business cases go wrong
- No baseline at all. Without a before there is no after, and the project ends up judged on how people feel about it.
- Everything at once, measured at the end. A twelve-month build with a single go-live delays any evidence for a year. One working module in weeks 4 to 6 lets the first measurement happen while the rest is still a decision — which is why the vendor questions ask when software first runs.
- Counting a gain the system cannot cause. A workflow system does not raise your prices or find new customers. Claim the hours, the rework and the cycle time; leave the rest out and the numbers you do claim will be believed.
If you want help defining the baseline before committing to anything, describe the process on the quote form. The build bands the arithmetic runs against are on the pricing page, and the five-year view of the same decision is in custom versus off-the-shelf.
Frequently asked questions
What is the formula for software ROI and payback period?
Annual ROI equals net annual gain divided by build cost, times one hundred, where net annual gain is labour saved plus rework avoided plus margin gained minus annual maintenance. Payback in months equals build cost divided by net monthly gain. Both are useless without a measured baseline.
Which three numbers should be baselined before the build?
Hours: how long the task takes, per person, per week. Rework: how many transactions are corrected or re-entered per month and what one correction costs. Elapsed time: how long a case takes from arrival to completion. Collect all three for two full weeks before anyone writes code.
Do saved hours count as cash savings?
Only if you stop paying for them. Saved hours become cash when overtime falls, a temporary contract ends or a vacancy goes unfilled. Otherwise they are capacity, which belongs in a different line of the business case. Presenting capacity as cash is how software business cases lose credibility.
How long should you wait before measuring results?
Take the first reading a month after go-live and treat it as provisional, because the early weeks include learning. Take the real reading at three months, over a period comparable to the baseline: same season, same working days, same product mix.
What is a realistic payback period for an operational module?
For a focused module replacing daily repetitive work, payback commonly falls between a few months and a year, but the honest answer comes out of your own baseline. KodDelta does not publish a single headline figure, because the result depends on how much manual work the current process contains.
What should make you distrust a supplier's ROI claim?
A percentage offered before anyone has measured your process. If a supplier can quote an efficiency gain without knowing your hours, error rate or cycle time, the figure came from a slide rather than your business. Ask instead which three numbers they intend to measure, and when.
Let's talk about what you need.
The 30-minute discovery call is free and carries no commitment.