Finance sent it back again and did not say why

Ask the reviewer this, in writing: which number would have to change for this to be approved? It is a short question with nowhere to hide, and the reply names the defect. Reviewers rarely volunteer the reason because the objection is usually about a number's provenance rather than its size, and "I do not believe that benefit" is an awkward sentence to put in an email.

Four defects account for almost every repeat rejection. They look identical from your side of the desk and they have entirely different fixes.

Reading the reply

Whatever comes back, it will probably be phrased gently. Translate it.

The last row deserves a separate response. If the case is sound and simply out-competed, rewriting it will not help; the useful move is to find out what beat it and on which criterion, so that next quarter's version is aimed at the actual contest.

The four defects

1. The benefit was asserted, not measured

Signature: the case contains a percentage with no method behind it. "Reduces handling time by 30%" invites exactly one question, and the case has no answer to it. Finance is not doubting that the tool helps; it is refusing to underwrite a number whose origin is an assumption in a slide.

Fix: baseline first, then write the case. Measure the current process for 2 weeks — volume, cycle time, rework rate, who touches each item — and state the benefit as a delta against a number the business already recognises. A modest benefit measured beats a large one estimated, every time, because only one of them can be tested after launch.

2. The benefit belongs to someone who never agreed to it

Signature: the saving is expressed in hours or FTE, in a department other than yours, and no budget holder from that department is named anywhere in the document. This is the defect finance spots fastest, because they see the same hours claimed by two projects in the same cycle.

Fix: get the owning manager to state, in writing, what they will do with the released capacity — reduce contractor spend, absorb growth without hiring, redeploy to a named backlog. Any of those is bankable. "The team will have more time" is not, and finance is right to say so. If nobody will sign, the honest move is to remove the benefit from the case rather than defend it.

3. A build number with no run number

Signature: a single implementation figure and a benefit line, with nothing recurring on the cost side. Anyone who has approved software before knows this is incomplete, and an incomplete cost side makes every other number in the document suspect.

Fix: fill in the full structure — build, run, change and exit — using the line items inside total cost of ownership, and be specific about the fact that maintenance is not flat. It grows with the number of surfaces you are running, on a curve described in how maintenance load grows over a system's life. A case that shows a rising run line and still works is far more persuasive than one that assumes it stays constant.

4. You asked the wrong person

Signature: the case is competent, nobody has criticised its content, and it has now been deferred twice without a substantive comment. Approval authority is usually banded by amount, by payback horizon, or by whether spend is capitalised — and a request whose payback runs past the band gets pushed upward rather than refused. From your seat that looks identical to rejection.

Fix: ask what the delegated authority actually is, then either route the case to the person who holds it or reshape the request to sit inside the band. The second option is usually faster and is covered in the next section.

Finance is not rejecting the project. It is refusing to sign a number it cannot trace, which is the job.

The rewrite that gets approved

1. Open with the baseline, not the solution. One paragraph: what the process costs today, measured, with the source of the measurement named. Everything after this is a delta.
2. Name the benefit owner beside every benefit. A person, not a department, who has agreed in writing what happens to the released capacity.
3. Put run cost on the same page as build cost, split into one-off and recurring, over a 3-year horizon. Blending them is the fastest way to get a case returned.
4. State the payback period explicitly and check it against the approver's authority before submitting. If it is 26 months and the band is 18, you already know the outcome.
5. Include the do-nothing column. What the current process costs over the same 3 years, growing at the same rate as volume. A case with no comparison is an argument; a case with one is a choice.
6. Add a stop condition. The point at which you would recommend abandoning it, and what evidence would trigger that. Reviewers approve cases with stop conditions more readily, because the downside is bounded rather than open.

When the answer is to ask for less

A smaller first commitment is not a weaker case, it is a different one. It replaces a projected benefit with a measured one, and the second request is then argued from evidence produced inside your own organisation rather than from a model. Structuring that first step so it sits inside existing delegated authority is a specific craft — the constraints and the traps are in structuring a first purchase under the approval line.

The practical shape is a bounded piece of work with a defined output and a decision point at the end, which is how we scope first engagements as MVP and product builds. What makes it work financially is that the deliverable is the measurement as well as the software: after it, the benefit line has a source.

When the benefit is not money

Sometimes the honest benefit is quality — better answers, fewer errors, more consistent decisions — and finance has nothing to bank. Do not convert it into a fabricated saving. Convert it into a measurement instead: a scored sample with a threshold and a method, so that quality becomes a number with provenance even if it is not a monetary one. Model-graded scoring is one such method, and its limits matter as much as its results, which is exactly the sort of honesty that survives a finance review.

There is also the possibility that the rejection is correct. A capability that sits off the path customers choose you for is often better rented than built, however good the case looks — the test is in which capabilities are worth owning outright. Finance sometimes sees this before the sponsor does, and a third rejection on the same case is worth reading as data rather than as an obstacle. The surrounding decisions are collected in deciding what to build and who builds it, inside the library.

• business case
• budgeting
• approval
• stakeholders