There is a specific kind of meeting that every technology leader has been in. The proposal is strong. The architecture is sound. The team is credible. And the CFO asks two questions, and the proposal is dead, and nobody in the room is entirely sure what just happened.
What happened is that the proposal answered a technology question and the CFO was asking a capital allocation question. Those are different questions with different evidentiary standards, and a business case exists to bridge them.
Having built these for banks, insurers and asset managers, the same six elements come up every time. Missing any one of them is usually fatal. Getting all six right makes approval close to procedural.
1. A do-nothing baseline that is actually costed
This is the most common omission and the most damaging. Proposals describe what the investment achieves without establishing what happens if the organization does nothing, and "nothing" is never static. Licences escalate. Vendor support lapses. The talent pool for the legacy stack shrinks and its cost rises. Capacity constraints bind harder as volume grows.
A CFO's first instinct is to compare against deferral, because deferral is free this year. If your case has not priced the cost curve of doing nothing over the same horizon, deferral wins by default. Costing the baseline is often the single highest-leverage hour in building a case, and it frequently turns out to be the largest number in the model.
2. Benefits in the currency the organization already reports
Technology benefits are usually expressed in technology units: deployment frequency, incident counts, story points, hours saved. None of those appear in a P&L.
Every benefit has to be walked forward into a line a finance function already tracks. Hours saved become either cost avoided (a role not backfilled) or capacity redeployed (the same people producing more), and those are not the same thing. Faster release cadence becomes earlier revenue recognition from the initiatives it unblocks, or it becomes nothing. Reduced incidents become reduced operational loss provisions, reduced remediation, and in regulated contexts reduced supervisory attention.
If a benefit cannot be walked into a reported line, it belongs in the qualitative section of the case, not in the model. Putting it in the model anyway is the fastest way to lose the room, because it invites the CFO to discount everything you have quantified.
3. A named benefit owner outside of technology
This is the test most proposals fail without knowing it was being administered.
If the benefits are owned by the technology function, the CFO reads the case as a department asking to fund its own improvement. If the benefits are owned by an operating executive who has agreed to carry the number in their plan (fewer FTEs in claims handling, a lower cost-to-serve, a higher straight-through processing rate), the case becomes a business decision that technology happens to enable.
The practical version of this test: is someone willing to have their budget reduced by the benefit amount once it lands? If no one is, the benefit is not real, and the CFO will find that out faster than you can.
4. Sensitivities, stated before you are asked
Every model rests on assumptions. Presenting a single deterministic number invites the committee to find the shakiest assumption and treat the whole case as fragile.
Present the range yourself. Identify the three or four assumptions with the most leverage on the outcome, show what happens at pessimistic and optimistic values, and state which ones you are least confident about. A case that says "if adoption reaches only 60% of plan, payback moves from nine to fourteen months, and we would still proceed" is far stronger than one that claims nine months with certainty.
This is counter-intuitive to people who sell for a living. In front of a finance audience, visible uncertainty handled well reads as rigour, not weakness. Concealed uncertainty, once found, reads as either incompetence or salesmanship, and both are fatal.
5. Cost of the whole life, not the project
Proposals price the build. Finance funds the asset. Those differ by everything that happens after go-live: run cost, licence changes, support model, the maintenance burden of whatever was automated, the training of people who will use it, and decommissioning of what it replaces.
Decommissioning deserves particular attention, because it is where benefits are most often lost. A modernization that stands up a new platform without retiring the old one has added cost, not removed it, and the "savings" never materialize. If the case does not include a funded, dated decommissioning plan with an owner, an experienced CFO will assume the run-cost savings are optimistic. They will usually be right.
6. A decision, not a request
The strongest cases end with a specific, bounded ask and a clear gate: approve this phase, at this amount, to reach this checkpoint, at which point the following evidence will exist and the next decision can be made.
Committees are far more willing to approve a $1.4M first phase with a defined gate than a $9M program with a promise. Not because they are risk-averse in general, but because the first structure gives them an option and the second asks for a commitment. Options are cheap; commitments are expensive. Structure the ask as a series of options and you will be approved more often, faster, and at higher aggregate value than if you had asked for the whole thing at once.
The underlying shift
Everything above reduces to one change in posture. A technology proposal argues that something should be built. A business case argues that capital should be allocated to an outcome, with a named owner, a measurable result, and a path for the organization to stop if the evidence does not hold.
The second is a harder document to write. It is also the only one a CFO is actually equipped to approve.