Investment appraisal memo for capital approval

Nothing here is financial advice, and none of it replaces your own checks.

Use this process to turn a capital proposal into an approval memo that a decision-maker can read, challenge and approve. It is for FP&A analysts and finance business partners who need to connect a model to a clear capital expenditure decision.

Nothing here is financial advice, and none of it replaces your own checks. The memo is a draft work product. The accountable finance lead and approval committee decide whether the assumptions, analysis and conditions are sufficient.

1. Set the decision before drafting

Write the decision required in one sentence before you give any material to the model. Do not begin with the project history or a long description of the asset.

Use this format:

Approve capital expenditure of [amount] for [asset or project], subject to [conditions], to achieve [commercial outcome].

Then record the approval boundary:

• Decision owner: the person or committee with authority to approve.
• Spend requested: total requested amount, currency, whether it includes contingency and whether it is gross or net of recoverable taxes.
• Decision date: when approval is needed and what slips if it is delayed.
• Scope: the sites, assets, workstreams or contracts included.
• Exclusions: costs, later phases or operating changes not covered by this request.

2. Build a controlled source pack

Create one folder or workspace for the current appraisal. Name each file so its purpose and date are visible. For example: Capex_model_base_case, Engineering_scope_v3, Operations_notes, and Risk_register.

Prepare a short source register before you prompt the model. Include:

Source	Use in the memo	Check before use
Appraisal model	investment, cash flow, return measures and sensitivities	calculation status and scenario selected
Assumptions log	volume, price, cost, timing and useful-life assumptions	owner and last review date
Project proposal	scope, delivery plan and commercial rationale	alignment with the model scope
Stakeholder notes	operational need, dependencies and concerns	whether comments are evidence or opinion
Risk register	risks, mitigations and residual exposure	risk owner and current status

Extract model outputs into a separate table rather than asking the model to interpret a spreadsheet without context. Include the case name, units, currency, timing convention and the cells or report pages used. For example, distinguish annual cash flow from cumulative cash flow, and nominal values from real values.

Do not upload confidential material until you have checked your organisation's policy and the relevant xAI documentation. Product behaviour and data controls can be version-dependent.

3. Reconcile the facts before asking for prose

Create a one-page fact sheet from the source pack. This is the control document for the memo. Resolve differences here, not after polished wording has hidden them.

Include these fields:

• Project name and sponsoring business unit.
• Spend profile by period, including contingency.
• Expected operating impact by period.
• Key return measures used by your organisation.
• Payback or other required decision metrics, if applicable.
• Three to five critical assumptions, with units and owners.
• Main downside case and its changed assumptions.
• Alternatives considered, including doing nothing.
• Delivery dependencies, such as permits, suppliers, shutdown windows or recruitment.
• Proposed conditions for approval.

Mark any unresolved item as TBC, not as a plausible estimate. Give each TBC an owner and a date for resolution. If the project team says a benefit is "significant", replace that word with the relevant output, or state that the benefit is not yet quantified.

4. Draft the memo in a fixed order

Give the model the fact sheet, then provide the source extracts needed to explain it. Ask it to draft only from those materials. State that it must preserve uncertainty, flag contradictions and leave missing facts as TBC.

Use this instruction structure:

Draft an approval memo for the decision owner named below.

Use only the supplied sources. Do not invent figures, benefits, risks,
benchmark comparisons or stakeholder views. Mark unsupported statements as TBC.

Use these headings in this order:
1. Decision required
2. Commercial rationale
3. Investment and expected outcomes
4. Key assumptions and sensitivities
5. Alternatives considered
6. Delivery risks and mitigations
7. Conditions for approval
8. Recommendation

For every financial figure, state the case, period and unit where relevant.
Separate facts from management judgement. Keep the recommendation conditional
where an approval condition is unresolved.

Then add the fact sheet and extracts below the instruction. Keep stakeholder notes separate from model outputs. That makes it easier to spot when the draft presents an opinion as a confirmed fact.

The intended memo structure is simple:

1. Decision required: state the spend, scope, decision-maker and requested timing.
2. Commercial rationale: explain the operational or strategic problem and the expected value mechanism.
3. Investment and outcomes: show spend, benefits, timing and the measures used in the appraisal.
4. Key assumptions and sensitivities: identify the few assumptions that move the result most.
5. Alternatives considered: compare the preferred option with do nothing, defer, repair, lease, outsource or phased delivery where relevant.
6. Risks and conditions: make approval conditional on specific evidence, limits or gates.
7. Recommendation: repeat the exact decision sought and the conditions attached.

5. Test the draft for decision usefulness

Read the draft beside the fact sheet, not on its own. A well-written paragraph can still contain a wrong period, wrong scenario or unsupported conclusion.

Check the following in order:

1. Recalculate or trace every headline figure to the approved model output.
2. Check that all totals use the same currency, unit, period and scope.
3. Confirm the downside case changes the assumptions actually described in the memo.
4. Check that alternatives are genuine choices, not weak descriptions designed to make the preferred option look inevitable.
5. Turn vague conditions such as "subject to further review" into measurable gates, owners and evidence required.
6. Ask the project sponsor to confirm scope and delivery statements, and the model owner to confirm financial statements.

Output is going wrong when it smooths over disagreement, converts estimates into certainty, or gives a return measure without the assumptions that drive it. It is also wrong if it describes a sensitivity as a risk without saying what action would reduce the exposure. Remove any sentence that cannot be traced to a source, a named judgement owner or an explicit recommendation.

6. Keep a repeatable review habit

Save three items with the final memo: the fact sheet, the final model output pack and a change log. The change log should state what changed after the first draft, why it changed and who confirmed it.

Use the same headings and fact-sheet fields for each capital proposal. This makes comparison across projects easier and prevents different teams from hiding different assumptions in different formats. It also gives you a clean starting point when the committee asks for a revised case.

When the draft does not work

If the draft is generic, provide the decision sentence, the fact sheet and the expected headings again. If figures conflict, stop drafting and reconcile the source register before editing prose. If the recommendation feels too certain, identify the unresolved assumption and convert it into a condition for approval, a decision gate or a TBC item. If the memo is too long, cut project history first, not assumptions, alternatives or conditions.