capex_business_case v1.0.0

name: capex_business_case description: Build a capital expenditure request pack that can survive finance review: options appraisal, life cycle costing, NPV, IRR, payback and profitability index from a runnable model, sensitivity and scenario tables, a risk register, benefits tracking, and staged approval gates. Use when someone asks for a capex request, a capital business case, an investment appraisal, ROI justification for equipment, property, vehicles, or a major system purchase, or help getting a big spend approved.

Capex Business Case

Purpose

Turn a request to buy something expensive into an approval pack a finance reviewer can check line by line. The pack states the problem, compares real options, shows the full life cycle cost, proves the return with a model the reviewer can rerun, names the risks, and sets the gates where money is released and where results get checked later. A persuasive paragraph with a single ROI number is not a business case.

Workflow

1. Intake and threshold check

• Record: what is being bought, who owns it, who uses it, what breaks or stalls without it, the date it is needed by, and the total ask.
• Ask for the organisation's capex threshold, approval limits, hurdle rate or discount rate, and required template. These vary by organisation. Never invent them. If they are unknown, build the pack with clearly labelled assumptions and list what finance must confirm.
• Confirm the spend is capital, not operating: an asset the organisation will use over more than one period. Licence renewals, repairs that only restore existing function, and consumables usually sit in operating budgets. Flag borderline items for finance to classify rather than classifying them yourself.

1. Frame the options

• Always appraise at least four options: do nothing (the baseline, with its own costs and risks stated honestly), do the minimum that fixes the core problem, the preferred option, and one genuine alternative (a cheaper asset, a lease, a service contract, a phased buy, or a different supplier model).
• Kill options only for stated reasons: fails a legal or safety duty, cannot meet a hard deadline, or costs more for the same outcome. Record the reason in the pack.
• Use the five case structure from HM Treasury's Green Book as the pack spine, adapted for private firms: strategic (why now, fit with plans), economic (which option gives best value), commercial (can the market supply it, on what terms), financial (is it affordable, where does the cash come from), management (who delivers it, on what plan). See references/appraisal-and-gates.md.

1. Build the cash model

• Model incremental cash only: the difference between this option and the do nothing baseline, year by year, over the asset's stated life.
• Include the whole life cycle cost: purchase, delivery, installation, training, implementation labour, licences, maintenance, energy, added staffing, upgrades, added working capital, downtime during changeover, and decommissioning or disposal, less any residual or trade in value.
• Count each benefit once. A cost saving is either lower operating cost in the cash flows or a benefit line, never both. Separate cash benefits (cost avoided, revenue gained, cost of failure avoided with evidence) from non cash benefits (safety, quality, compliance, staff time that will not reduce headcount or overtime). List non cash benefits in words, do not convert them into invented money.
• Exclude sunk costs: money already spent stays out of the appraisal, however large it was.
• State every assumption on the face of the model: asset life, volumes, prices, inflation treatment, tax treatment. If tax or inflation is not modelled, say so in one line rather than hiding it.
• Run the model in bin/capex_model.py instead of doing the arithmetic in prose. Save the input JSON with the pack so a reviewer can rerun it.

1. Appraise and stress the numbers

• Report all of: NPV at the stated discount rate, IRR against the hurdle rate, profitability index, simple payback, discounted payback, and simple ROI. One metric alone hides the weakness of the others.
• Read the metrics honestly: NPV is the primary test for mutually exclusive options. IRR can mislead when cash flows change sign more than once or when options differ in scale. Payback says nothing about cash after payback. State these limits in the pack where they bite.
• Run sensitivity from the tool: flows up and down 10 and 20 percent, cost up 10 and 20 percent, discount rate up and down 2 points, plus the switching value (how far flows can fall before NPV hits zero).
• Build three coherent scenarios: downside, base, upside. Change several inputs together in each scenario and write what story each scenario tells (late delivery plus lower volumes, for example). Do not present the upside as the base case.
• Apply an optimism check: if the sponsor's estimates have no track record, say so, widen the downside, and name what evidence would narrow it. Do not apply a made up percentage haircut.

1. Risk register and benefits plan

• One row per risk: risk, cause, impact on cost, timing, or benefits, likelihood, severity, owner, mitigation, and the contingency it justifies. Risks with no owner get an owner before the pack ships.
• Tie contingency to the register. A flat percentage with no risks behind it will be challenged, and should be.
• Benefits plan: each claimed benefit gets a named owner, a measure, a baseline value, and a review date. Benefits nobody measures do not get counted in the headline NPV without a warning note.

1. Approval gates and delivery

• Stage the ask through gates from references/appraisal-and-gates.md: Gate 0 idea and problem check, Gate 1 outline case with options and rough costs, Gate 2 full case with firm quotes and the final model, Gate 3 funds released against milestones, Gate 4 post implementation review.
• Ask for approval of the preferred option and a stated tolerance (cost ceiling and the NPV floor below which the sponsor must return for reapproval), not for a blank cheque.
• Set the post implementation review date at approval time. The review compares actual cost, timing, and benefits against this pack and records the variance and the cause.

1. Write the one page summary last

• Page one carries: the problem in two sentences, the options in a table with NPV and life cycle cost, the recommendation, the ask and its funding source, the top three risks, and the gate requested. A reader who stops at page one should still know what they are approving.

Output Contract

Deliver a pack containing:

• One page summary as described in step 7.
• Options table: option, life cycle cost, NPV, IRR, payback, and the reason any option was dropped.
• The model input JSON and the model output (JSON or markdown table) from bin/capex_model.py, with every assumption listed.
• Sensitivity table and the three scenarios, each with its story in one line.
• Risk register and benefits plan with owners and dates.
• Approval request: amount, funding source, tolerances, gate, and the post implementation review date.
• An open items list: every fact finance or procurement still has to confirm.

Worked example (verified with the tool): initial cost 500,000, discount rate 8 percent, net cash flows 120,000, 150,000, 180,000, 180,000, 160,000, plus 20,000 residual in year 5. Output: NPV 137,412.09, IRR 17.22 percent, profitability index 1.2748, payback 3.28 years, discounted payback 3.89 years, simple ROI 62.0 percent. Flows can fall 21.56 percent before NPV reaches zero. Rerun it: put those figures in a JSON file matching the format in bin/capex_model.py and run python3 bin/capex_model.py <file>.

Operating Rules

1. Every number in the pack traces to a quote, a contract, a measured baseline, or a labelled assumption. Unverifiable numbers get cut or labelled, never presented as fact.
2. Never invent a discount rate, hurdle rate, tax rate, asset life, approval threshold, or vendor price. Ask, or state the assumption and who must confirm it.
3. Cash is not profit. Keep depreciation and accounting treatment as a separate note for finance, out of the cash model, unless the organisation's template says otherwise.
4. Do not split a purchase into smaller requests to fit under an approval limit. State the full programme cost, including later phases the decision commits the organisation to.
5. The do nothing option gets costed honestly. A baseline rigged to look terrible makes the whole pack untrustworthy.
6. If NPV is negative at the stated rate, say so on page one and make the case on stated non financial grounds (legal duty, safety, service continuity) or recommend against. Never tune assumptions quietly until NPV turns positive.
7. Style: plain, direct sentences. No em dashes. No sales language about the asset. The numbers carry the argument.