The average business case in a large enterprise is approved by six people, none of whom can later prove they approved it. That sounds like an exaggeration. It is not.

I spent a decade as an enterprise architect across telecommunications, retail, government, and defence — as well as service providers, consultancies, gambling, and technology organisations. In every single one, the investment approval process followed the same pattern: someone writes a business case document, emails it to a chain of stakeholders, collects responses over days or weeks, and eventually declares it "approved." The evidence for that approval is scattered across email threads, some of which live in the inboxes of people who have since left the organisation.

When the board asks six months later why a programme is £2 million over budget and who signed off on the original scope, the answer is always the same uncomfortable silence. The decision was made. The trail was not captured.

This article is a practical guide to building an investment approval process that actually works — one that captures decisions, preserves evidence, and connects approved investments to what happens after the money is released.

Why email-based approval fails

Let me be specific about why email does not work for business case approvals, because I have heard every defence of the practice.

There is no audit trail. An email that says "looks fine, go ahead" is not an approval record. It has no version reference, no indication of which draft was reviewed, no structured rationale, and no timestamp tied to a specific version of the financial model. When an auditor asks to see the approval evidence for a £3 million investment, forwarding an email thread is not a serious answer.

There is no version control. The business case document gets revised four times during the approval cycle. The CFO approved version two. The CTO approved version three. The programme director signed off on version four. Nobody can say with certainty which version each approver actually reviewed, because the document was emailed as an attachment and modified between rounds.

There is no escalation. When an approver does not respond for two weeks, the submitter sends a follow-up email. Then another. Then they walk to the approver's desk, or ask their PA, or simply proceed without the approval and hope nobody notices. There is no automatic escalation path, no delegation mechanism, and no visibility into where the bottleneck sits.

There is no post-decision tracking. The business case gets approved, and then it effectively vanishes. The investment is made, but the assumptions that justified it — the projected return, the risk assessment, the financial model — are never revisited. Nobody connects the approved business case to the initiatives it funded, the suppliers it engaged, or the contracts it generated.

I worked with a government department that approved forty-seven technology investments in a single financial year. When asked to produce a consolidated view of those approvals for a spending review, it took three people two weeks to compile the evidence. Two of the business cases had no retrievable approval at all — the approving director had left, and the email archive was inaccessible.

The five stages of a good approval workflow

A business case approval workflow needs five distinct stages. Not three. Not seven. Five. Each stage has a different purpose, different actors, and different evidence requirements. Collapse them and you lose accountability. Add more and you lose adoption.

Stage 1: Submission

The submitter creates the business case using a structured template. Not a Word document — a form with defined fields: investment category, strategic alignment, financial summary, risk assessment, resource requirements, and expected outcomes. The template forces completeness. You would be amazed how many £1 million investment requests arrive with no risk section and a one-line financial justification.

At submission, the system captures who submitted it, when, and which version. The business case enters the workflow with a status of "Submitted" and a timestamp that cannot be modified.

Stage 2: Financial appraisal

Finance reviews the numbers. Not the strategy — the numbers. Does the financial model hold up? Are the assumptions reasonable? Is the cost estimate based on actual quotes or wishful thinking? This stage should have a dedicated reviewer from finance, and their assessment should be captured as a structured record: approved, approved with conditions, or returned for revision.

The most common mistake I see is combining financial appraisal with strategic review. They are different disciplines. A financially sound investment can still be strategically wrong, and vice versa. Separate them.

Stage 3: Stakeholder review

This is where the business case goes to the people who will be affected by the investment — the department heads, the technical architects, the procurement leads. This stage can run in parallel. You do not need sequential sign-off from five stakeholders when they are each reviewing from a different perspective.

Capture each reviewer's input as a distinct record: their assessment, any conditions they attach, any risks they flag. "No objections" is a valid response, but it should be explicitly recorded, not assumed from silence.

Stage 4: Executive decision

The decision-maker — typically a CIO, CFO, or investment committee — reviews the business case along with all the evidence from the previous stages. They see the financial appraisal, the stakeholder comments, any conditions that were raised. Their decision is recorded with a rationale: why they approved, any conditions they are attaching, any modifications to the requested scope or budget.

This is the stage that most organisations get wrong by reducing it to a binary yes/no. A good approval record captures the reasoning, not just the outcome. When someone asks in eighteen months why this investment was approved, "the CFO said yes" is not useful. "The CFO approved on the basis of a 14-month payback period, contingent on the supplier delivering phase one by Q3" is useful.

Stage 5: Post-decision tracking

The business case does not end at approval. The approved investment should be connected to the initiatives it funds, the suppliers it engages, and the contracts it generates. This creates a traceability chain: from the original business justification, through the approval decision, to the delivery and expenditure.

Without this stage, you are approving investments and then losing track of them. I have seen organisations where an approved business case sits in one system, the resulting contracts sit in another, and the supplier relationship is managed in a third. Nobody can tell you whether the investment delivered what was promised, because nobody connected the dots.

Designing the right approval chain

Not every business case needs the same approval path. A £50,000 software licence renewal does not need the same scrutiny as a £5 million platform re-architecture. Your workflow should adapt based on investment size, category, and risk profile.

Sequential approval works for straightforward investments where each stage depends on the previous one. Finance approves the numbers before stakeholders review the strategy. This is the right choice when stages have genuine dependencies.

Parallel approval saves time when reviewers are assessing different dimensions independently. Three department heads reviewing the same business case from their respective angles can do so simultaneously. Do not make them queue up sequentially when there is no dependency between their reviews.

Quorum voting is useful for investment committees. Rather than requiring unanimous approval from all seven members, you might require four of seven to approve. Define the quorum rules explicitly and enforce them in the workflow. This avoids the common problem where one absent committee member blocks a decision for three weeks.

Delegation must be built in. People go on leave. People change roles. If your approval workflow cannot handle delegation — "While I am away, Sarah has authority to approve investments up to £500,000 in my name" — it will break the first time a key approver is unavailable for a fortnight.

What to capture at each stage

This is where most business case approval systems fall short. They capture the binary outcome — approved or rejected — and nothing else. That is not enough.

At every stage, capture:

  • The decision itself — approved, approved with conditions, returned for revision, or rejected.
  • The rationale — why this decision was made. Not a paragraph of boilerplate. The actual reasoning.
  • Conditions attached — "approved subject to a revised cost estimate from procurement" is a different outcome from an unconditional approval, and the system should track it differently.
  • Financial assumptions reviewed — which version of the financial model was assessed? What was the discount rate? What was the projected payback period? Capture the numbers, not just the conclusion.
  • Risk flags — any risks identified by reviewers should be recorded against the business case, not buried in email threads.
  • The version of the business case that was reviewed — this prevents the problem where the document changes between approval stages.

Every one of these data points should be immutable once recorded. Nobody should be able to go back and change a reviewer's assessment after the fact. That is not bureaucracy — that is basic evidence integrity.

The audit certificate

Here is a feature that pays for itself the first time you need it: an exportable audit certificate for each approved business case.

The certificate is a single document — PDF or similar — that contains the complete approval evidence for an investment: who submitted it, who reviewed it at each stage, what they said, what version they reviewed, when the final decision was made, what conditions were attached, and who the decision-maker was. It draws from the immutable audit trail and packages it into something you can drop into a board pack or hand to an external auditor.

I have sat in audit committee meetings where the governance team spent four days assembling approval evidence for a dozen business cases. With a proper audit certificate, that exercise takes minutes. You generate the certificates, compile them, and present them. The evidence was captured at decision time, not reconstructed months later under pressure.

If your approval system cannot produce this kind of exportable evidence, it is not a governance tool. It is a workflow engine with a governance label on it.

Connecting business cases to what happens next

An approved business case should not be an island. It is the start of a chain of activity: initiatives are launched, suppliers are engaged, contracts are signed, services are deployed. If these downstream activities are not linked back to the originating business case, you lose the ability to answer fundamental questions:

  • Did this investment deliver what was promised?
  • How much have we actually spent against the approved budget?
  • Which suppliers are we using, and were they part of the original scope?
  • Which services depend on this investment, and what happens if we cut funding?

The connection between a business case and its downstream artefacts is where governance becomes genuinely useful rather than merely compliant. It transforms the investment approval process from a gate-keeping exercise into a management tool.

I worked with a large retailer that connected their business case approvals to their supplier and contract records for the first time. Within a month, they discovered that three approved investments were all engaging the same supplier under separate contracts with different commercial terms. Nobody had spotted the overlap because the business cases, supplier records, and contracts lived in different systems with no links between them.

Getting adoption

The best approval workflow in the world is worthless if nobody uses it. I have seen beautifully designed governance processes that people route around because they are too slow, too complex, or too disconnected from how decisions are actually made.

Here is how to get adoption:

Start with one category of investment. Do not roll out the new workflow across all investment types on day one. Pick the category with the most pain — probably the one that caused the most recent audit finding or budget overrun — and prove the value there first. Once people see that the workflow is faster and more reliable than the email chain it replaced, expanding to other categories becomes a conversation about timing, not justification.

Make the workflow faster than the alternative. If submitting a business case through the new system takes longer than emailing a Word document, you have already lost. The structured template should take less time to complete than a blank document, because it guides the submitter through what is needed. The parallel review stages should complete faster than sequential email chains. The audit certificate should save days of manual evidence assembly.

Show the approvers what they gain. Senior stakeholders do not care about governance for its own sake. They care about being able to answer questions quickly, defending their decisions under scrutiny, and not being blindsided by investments they thought they approved but cannot prove. Frame the workflow as a tool that protects them, not one that constrains them.

Do not over-engineer the first version. Launch with the five stages. Add complexity only when the users ask for it. Every unnecessary field on the submission form and every redundant approval stage is a reason for people to go back to email. Start lean. Iterate based on feedback.

The best governance process is the one people actually follow. If yours lives on paper while decisions happen in email, you do not have governance. You have documentation.

Build the workflow. Connect it to what happens after approval. Make it easier than the alternative. And above all, make sure every decision leaves an evidence trail that you would be comfortable presenting to an auditor, a board, or a regulator.

Because one day, someone will ask.