Build a Financial Forecast

Build a forecast whose assumptions, calculations, dependencies, and scenarios can be inspected, challenged, and changed.

When a reliable model already exists, preserve its accepted structure and logic rather than replacing it with a generic template.

1. Define the decision and model boundary

Establish:

• company or entity;
• forecast horizon;
• time grain;
• currency;
• intended decision;
• audience;
• required outputs;
• as-of date;
• accepted actuals;
• current source model.

Determine whether the user needs:

• annual or operating budget;
• rolling forecast;
• cash forecast;
• runway model;
• hiring scenario;
• revenue scenario;
• financing scenario;
• decision-specific model.

Separate:

• accepted actuals;
• user-owned assumptions;
• operating-system inputs;
• calculated outputs;
• unresolved questions.

If multiple actual or model versions conflict, resolve the controlling version or expose the conflict before forecasting from it.

2. Build from accepted operating drivers

Use approved evidence that genuinely drives the forecast, such as:

• historical actuals;
• signed contracts;
• qualified pipeline where accepted;
• pricing;
• usage;
• headcount plans;
• compensation assumptions;
• vendor commitments;
• cloud or infrastructure costs;
• payment terms;
• collections assumptions;
• cash balances;
• financing commitments;
• other operating drivers.

For material inputs, preserve:

• source;
• version;
• date;
• owner;
• unit;
• currency;
• applicable period.

Keep distinct model layers for:

1. source actuals;
2. assumptions;
3. calculations;
4. scenarios;
5. outputs.

Make:

• units;
• signs;
• dates;
• currencies;
• formulas;
• dependencies

explicit.

Historical patterns may inform assumptions, but they do not prove those patterns will continue.

3. Preserve existing model logic

When updating a trusted model:

• retain accepted definitions;
• retain approved formulas;
• retain source mappings;
• retain scenario architecture;
• preserve links and schedules where reliable.

Do not restructure the model merely for stylistic preference.

If an accepted model contains an apparent error, flag it and show the impact before changing core logic.

4. Build the base forecast

Construct the accepted base view first.

Connect operating drivers to financial outputs in a way that can be inspected.

Depending on scope, this may include:

• revenue;
• cost of revenue;
• gross margin;
• payroll;
• operating expenses;
• capital expenditure;
• working capital;
• taxes;
• financing;
• cash movement.

Avoid unsupported detail that creates false precision.

5. Model decision-relevant uncertainty

Add scenarios only when they answer a real question.

Possible views include:

• upside;
• downside;
• sensitivity;
• hiring scenario;
• revenue scenario;
• pricing scenario;
• financing scenario;
• cost-reduction scenario.

Change the smallest meaningful set of assumptions defining each scenario.

Explain the operating meaning of each changed assumption.

Do not create arbitrary scenarios simply to make the model appear comprehensive.

6. Model cash and runway carefully

When cash matters, connect:

• operating profit or loss;
• working-capital timing;
• customer collections;
• vendor payments;
• payroll timing;
• one-time costs;
• capital expenditures;
• financing;
• opening cash.

Show how runway changes under important assumptions rather than presenting one runway date as certain.

Where relevant, test sensitivity to:

• slower collections;
• delayed revenue;
• hiring timing;
• one-time expenses;
• cost changes;
• financing timing.

State the runway definition being used.

7. Validate the model

Reconcile opening actuals and period roll-forwards.

Check:

• source actuals;
• totals;
• signs;
• formulas;
• dates;
• units;
• currencies;
• scenario switches;
• linked schedules;
• cash movements;
• balance roll-forwards where applicable.

Investigate implausible jumps.

Identify:

• stale inputs;
• missing drivers;
• manual overrides;
• broken links;
• unsupported assumptions;
• unexplained residuals.

Do not hide balancing adjustments.

8. Deliver a reviewable forecast

Provide the updated model or reviewable draft with:

• scope;
• model version;
• source actuals;
• as-of date;
• forecast horizon;
• concise assumption log;
• assumption owner;
• supporting evidence;
• base view;
• decision-relevant scenarios;
• cash and runway implications where applicable;
• largest changes from the previous view;
• sensitivities;
• gaps;
• unresolved decisions;
• next update points.

Keep important inputs, formulas, and outputs inspectable.

When the next question is why actual results differ from the forecast, route to the financial-performance review workflow.

9. Keep forecast governance explicit

After the user confirms them, preserve:

• source definitions;
• driver logic;
• scenario rules;
• assumptions;
• review preferences;
• materiality.

A recurring forecast workflow may refresh named inputs and prepare a proposed update.

It should stop when:

• a source version changes unexpectedly;
• formula logic falls outside the accepted model;
• entity changes;
• assumption ownership becomes unclear;
• material business conditions change;
• required inputs become unavailable.

Do not silently:

• overwrite an approved budget;
• publish a forecast;
• change an operating plan;
• write back to source systems;
• commit hiring;
• commit spending;
• initiate financing.

Those are separate actions requiring appropriate authority.