Costing the Return of an Internal Project That Generates No Revenue

Two kinds of value, and only one of them is cash

Sort every claimed benefit into one of four boxes before anything else. The first is hard avoided cost: a licence cancelled, a contractor invoice that stops, cloud spend that falls, a rented machine returned. Something leaves the bank account that used to leave it and does not any more, and you can name the invoice. The second is avoided future cost: the hire not made, the extra warehouse not rented, the capacity upgrade postponed. Real money, but conditional on a decision nobody has taken yet. The third is recovered time, which is the subject of the next section and is not money at all until something is done with it. The fourth is risk reduction — a smaller chance of an outage, a fine, a data loss — which is expected-value arithmetic and belongs in a business case only with the probability written down.

The case in this article is deliberately ordinary. A migration off a legacy system: $130,000 to build, being twelve person-months at a loaded $7,500 a month plus $40,000 of outside help. Replace that loaded monthly figure with your own before you use any of this — what an employee actually costs an employer is a country-by-country question with a large gap between gross pay and total cost, and this site covers it separately. What matters here is the shape, not the constants: a build cost in person-months plus a purchased component, both of which are real cash whether or not the person-months are new hires.

The benefits are just as ordinary. The legacy licence costs $9,000 a year and stops. Hosting falls from $1,800 to $900 a month, saving $10,800 a year. Total avoided cost: $19,800 a year, and every euro of it is nameable on a bank statement. That is the entire hard case, and it is the part of the business case that almost never gets contested — which is exactly why it is worth separating from the part that does.

The build cost is not the project cost

The most common omission in an internal business case is the run cost of the thing being built. The old platform is being replaced by a new one, and the new one costs money too: in this case $900 a month of subscription and one day a month of somebody's upkeep, which at a loaded daily cost of $375 is $4,500 a year. Together that is $15,300 a year of new running cost against $19,800 a year of avoided cost. Net hard cash is $4,500 a year, not $19,800 — a factor of 4.4 between the number people quote and the number that is true.

Put that against the outlay and the arithmetic is brutal. Five years of $4,500 discounted at 8 % is worth about $17,967 of present value against a $130,000 build: a net present value of minus $112,033, an internal rate of return well below zero, and no payback date at all inside the horizon. On the hard cash alone this project should not be done, and it is worth saying that sentence out loud before reaching for the softer benefits, because the softer benefits now have to carry $112,033 of gap on their own.

Three cost lines are missed almost as often as the run cost. The migration itself — dual running, data cleaning, the parallel period where both systems are paid for. The training and the productivity dip in the first months, which is a negative benefit and belongs in year one. And the cost of the decision to stop: what does it cost to reverse this if it goes badly, and is there a reversal at all? A project with no exit is not more expensive on paper, but it should carry a higher hurdle, and the only honest way to express that is to widen the sensitivity range rather than to invent a risk premium in the discount rate.

A recovered hour is a claim, not a cash flow

Nine people, twenty-five minutes a day, two hundred and twenty working days: 825 hours a year. At a loaded hourly cost of $56.25 — twelve months of $7,500 spread over 1,600 genuinely productive hours, an assumption you should replace with your own timesheets — that is $46,406 a year. It is the largest line in the case and it is the one line that no bank statement will ever show. Those 825 hours amount to 0.516 of a full-time person, spread across nine desks. Nobody leaves, no invoice stops, and payroll is identical in December. A second version of the same case makes it starker: twelve people saving twenty minutes a day is 880 hours, 0.55 of a person, nominally $49,500 — and still nothing happens to the bank account.

So make the assumption explicit and price it. Suppose a fraction of the recovered hours genuinely goes to something with a value — a backlog that was being postponed, work that was being bought outside, capacity that lets the team absorb next year's growth. Redeploy none of the 825 hours and the five-year net present value at 8 % stays at minus $112,033. A quarter: minus $65,711. Half: minus $19,389. Three-quarters: plus $26,932. All: plus $73,254. Solve for zero and the answer is 60.5 % — roughly 499 of the 825 hours. That single number is the honest way to present this project: it does not pay unless three-fifths of the time it saves actually goes somewhere that a manager can name.

Two consequences follow, and the second one is the finding of this article. First, the horizon matters more than anyone expects: over three years instead of five, the break-even redeployment rises from 60.5 % to 99 %. An internal project judged over three years effectively has to pay for itself in hard cash, because recovered time cannot carry it. Second, and more useful: if the recovered capacity is what lets the team skip one hire from year three onwards, at a loaded $90,000 a year, the five-year net present value is plus $86,817. That beats redeploying every single one of the 825 hours for five straight years, which is worth $73,254. One nameable headcount decision, arriving two years late, is worth more than the entire theoretical total of recovered minutes. Write the business case that way round.

The do-nothing case is not everything staying the same

Every business case is a comparison against a counterfactual, and the counterfactual is almost always written as a flat line. That is usually wrong, and it is wrong in a direction that penalises the project. A legacy stack rarely holds its cost: support contracts get repriced upward as a product ages, the specialists who know it get rarer and more expensive, and the compliance work it needs grows rather than shrinks. Take the legacy licence and hosting in this case, $30,600 a year together, and assume they simply drift upward by 6 % a year. The present value of that drift over five years, discounted at 8 %, is $22,530 — a benefit of the project that a flat baseline throws away entirely.

Risk and rework belong in the same section, and they belong there with numbers attached. Suppose the current process produces fourteen incidents a year, each costing six hours of somebody's time to unpick: 84 hours a year, and a project that cuts them by 60 % recovers 50.4 hours, worth $2,835 a year at the same loaded rate. That is a small number, and printing it small is the point — quantified rework benefits are usually modest, and a business case that leans on them without arithmetic is leaning on nothing. The same discipline applies to outage or penalty risk: write the probability, write the cost, multiply, and if you cannot write the probability then the benefit is a reason and not a number.

One more discipline is worth importing from public appraisal, where the counterfactual has to survive a reviewer. Both of the frameworks used to appraise investment across Europe fix a discount rate rather than letting each analyst choose: the European Union's rules for co-financed operations use 4 % in real terms as the benchmark financial discount rate, and the United Kingdom's Green Book uses a social time preference rate of 3.5 % in real terms for the first thirty years. Neither number is right for your company — an internal project should be discounted at your own cost of capital or hurdle rate — but the practice is worth copying: fix the rate as policy, apply it to every case, and stop letting the discount rate become the place where the answer is negotiated.

Where the money lands in the accounts, and how to check yourself a year later

Whether the $130,000 hits this year's profit or is spread over several changes the shape of the case even though it changes nothing about the cash. Under IAS 38, as endorsed in the Union by Commission Regulation (EU) 2023/1803, expenditure in the research phase must be recognised as an expense when incurred, while development expenditure may be capitalised as an intangible asset only where all six conditions in its paragraph 57 are satisfied: technical feasibility of completing it, the intention to complete and to use or sell it, the ability to use or sell it, a demonstration of how it will generate probable future economic benefits, the availability of adequate technical and financial resources to finish it, and the ability to measure the attributable expenditure reliably. Miss one and the cost is an expense, full stop.

That accounting choice does not change the net present value, and anyone arguing a project on the basis of how it looks in the profit and loss account is arguing about presentation. It does change two real things. It changes the profit of the year in which the project is done, which matters if a covenant, a bonus or a tax position depends on it. And it changes what happens if the project is abandoned, because a capitalised asset that turns out not to work has to be impaired, which puts the whole cost into a single later year rather than the year the work happened. How the resulting asset is then written down is a separate subject with its own arithmetic, covered elsewhere on this site.

The last thing an internal business case owes anyone is a way to be proved wrong. Almost none of them are ever checked, which is why the same optimistic multipliers survive from project to project. Write down, before the work starts, three testable statements: the licence line that must disappear from the December invoice, the hosting bill that must fall to a stated figure, and the specific hire or contractor spend that will not happen. Then look at those three lines a year later. If the recovered time was real, one of the three will show it; if none of them does, the 825 hours went into the day and the project was worth doing for some other reason, which is a fine answer as long as nobody wrote it up as a return.

Frequently asked questions

Can I just multiply the hours saved by the hourly salary?

Two things are wrong with it, and they pull in opposite directions. The rate is too low, because gross salary is not what the employee costs the employer — the gap between the two is substantial and differs by country, and this site covers it in its own articles rather than re-deriving it here. And the result is too high, because the multiplication assumes every recovered hour turns into money, which it does not unless somebody is not hired, something is not bought, or work that was being postponed gets done. In the case in this article the naive multiplication gives 46,406 a year and the project needs 60.5 % of it to be real over five years, or 99 % over three. Compute the full number if you like, then state the redeployment fraction beside it, and let the reader see both.

What discount rate should an internal project use?

Your own cost of capital, or the hurdle rate the business has already fixed for capital spending — and above all, the same one for every case. The reason to fix it as policy rather than choose it per project is that a discount rate chosen after the cash flows are known becomes a lever for getting the answer somebody wanted. The public appraisal frameworks do exactly this: the European Union's rules for co-financed investment set 4 % in real terms as the benchmark financial discount rate, allowing a different one only with a justification applied consistently across similar operations in the same sector, and the United Kingdom's Green Book sets a social time preference rate of 3.5 % in real terms for the first thirty years. Neither figure is right for a company, but the practice of fixing the rate before the case is written is right everywhere.

What if the only benefit is that a risk goes down?

Then the benefit is a probability times a cost, and it belongs in the case only in that form. Write down the frequency you have observed, not the one you fear: fourteen incidents a year at six hours each is 84 hours, and a sixty per cent reduction recovers 50.4 hours, worth 2,835 a year at a loaded hourly cost of 56.25. Quantified this way, most rework and reliability benefits turn out to be small, and that is useful information rather than a reason to stop quantifying. Where the risk is catastrophic and rare — a fine, a data breach, an outage that loses a customer — the expected value is dominated by a probability nobody can estimate, and the honest move is to take that benefit out of the arithmetic entirely and present it as a separate, non-financial reason to proceed. A business case with one honest number and one clearly labelled judgement is more persuasive than one with two numbers, one of which is invented.

Should the build cost be capitalised or expensed?

It depends on which phase the spending falls into and whether six specific tests are met. Under IAS 38, as endorsed in the Union by Commission Regulation (EU) 2023/1803, expenditure in the research phase is recognised as an expense when incurred; development expenditure may be capitalised only where the entity can demonstrate all six of the conditions in paragraph 57 — technical feasibility of completion, the intention to complete and to use or sell, the ability to use or sell, how probable future economic benefits will be generated, the availability of adequate technical and financial resources, and reliable measurement of the attributable expenditure. Two practical consequences follow. The choice does not change the net present value, so it should never decide whether a project goes ahead. And it does change what an abandonment costs in reported terms, because a capitalised asset that stops being useful has to be written down in a single later year.

How do I know a year later whether the business case was true?

By having written, before the work started, statements that a later invoice can contradict. Three are usually enough: the licence line that must disappear from a named month's invoice, the hosting or supplier bill that must fall to a stated amount, and the hire or contractor spend that will not happen and by when. Recovered time cannot be audited, so do not try — audit the three cash lines instead and treat them as the test of whether the time saving was real. If all three hold, the case was sound. If none of them does, the hours went back into the working day, and the project may still have been worth doing for reasons of quality, safety or morale — it just was not a return, and someone should say so before the next business case reuses the same multiplier.