Running a cash flow scenario for a big decision means building an alternative version of your forecast with that decision in it, then reading the result against your cash floor. The scenarios worth a finance team's time are attached to a dated choice: a hire, a large purchase, a customer paying late, or a downside you need to be ready for.

Decision scenarios are different from standing scenarios

Most guides to scenario planning, including our own, describe the standing structure: a base case maintained weekly, a downside and an upside, reviewed as a set. That structure answers the question "how exposed are we?" It does not, on its own, answer the question sitting in this week's finance meeting: can we afford this hire, should we buy or lease the new kit, and what happens if our largest customer pays six weeks late?

Those are decision scenarios. Each one takes the live base case, changes only what the decision would change, and shows you the cash consequence week by week before you commit. They are temporary by design. A decision scenario exists to be merged into the forecast when the decision is confirmed, or retired when it is not, which is what keeps the model tidy while the standing cases carry on underneath.

Not every decision needs one. If a cost is small, reversible and comfortably inside your headroom in every week of the forecast, put it straight in the base case and move on. The scenario treatment is worth the effort when the amount is large relative to your buffer, the timing interacts with other outflows such as VAT or payroll, or the decision is genuinely reversible only before a certain date. This guide covers the four that come up most for finance teams in 11–50-person businesses: a hire, a large purchase, delayed receipts, and the downside case.

How to run a decision scenario

Step 1: Copy the live base case. Build the scenario as an alternative version of the current forecast, never as an edit to it. The base case stays intact as the source of truth, so the only differences between the two versions are the assumptions you are testing.

Step 2: Change only what the decision changes. Give the scenario dated, specific inputs. A hire is a start date, a full employment cost and a ramp period, not a round monthly number. A purchase is an amount, a payment shape and a VAT consequence. Resist tidying other assumptions while you are in there.

Step 3: Find the week the scenario crosses your cash floor. Compare weekly closing cash in the scenario against the base case, and note the first week the scenario breaches your minimum balance, if it does. That week number is the output of the exercise: it turns "can we afford it?" into "we can afford it from this date, with this much headroom".

Step 4: Attach a trigger and an owner before you commit. If the scenario shows the position tightening, write down what you will watch, the level that triggers action, the action itself and who owns it. Deciding that in advance is the difference between a plan and a hope.

Step 5: Merge or retire the scenario once the decision is made. If the decision is confirmed, fold the scenario into the base case so the forecast reflects reality. If it is not, retire the scenario rather than leaving it to drift out of date alongside the live model.

The hiring scenario: can we afford this person, and from when?

Hiring is the decision small finance teams model most often, and the one most often modelled too thinly. The scenario input is the full employment cost, dated: salary, employer National Insurance and pension contributions, equipment, any recruitment fee, and a realistic view of when the person starts drawing salary against when they contribute. For a revenue-generating hire, the honest version books their cost from the start date and their revenue only after a ramp period; a salesperson who starts in September does not change September's receipts.

As a worked example, a £48,000 salary in the UK costs about £55,700 a year, or roughly £4,640 a month, once 2026/27 employer National Insurance and the statutory minimum pension are added: National Insurance at 15% on earnings above the £5,000 secondary threshold, and 3% of qualifying earnings between £6,240 and £50,270. Treat that as the floor rather than the fully loaded figure, because equipment, recruitment fees, a better-than-minimum pension and any benefits all sit on top of it. The point is that the scenario should carry your numbers for this role, not the salary alone.

Two things are worth building in rather than finding out later. The £10,500 Employment Allowance is set against your total employer National Insurance bill for the year, not against each hire, so a business already running a payroll has usually absorbed it well before the new person starts; model the marginal hire at the full National Insurance cost unless you know you have allowance left. And since 6 April 2026, statutory sick pay has run from the first day of absence, with the three waiting days and the lower earnings limit both removed, and it cannot be recovered from HMRC. It is a small line, but it is a real one in a first-year scenario.

Employment on-costs work differently in the US, Australia and New Zealand, so the arithmetic above is the UK version. The method holds in every market; the percentages do not.

The most useful trick is to run the same hire at two start dates. The answer to "can we afford this person?" is often not yes or no but "yes from November, and only with three weeks of headroom if they start in September". Read the result on the weekly view, because payroll timing against your receipts cycle is exactly the kind of pressure a monthly total smooths over.

The large purchase scenario: buy outright, phase it, or spread it

A large purchase is a shape question as much as an affordability question. The same £60,000 of equipment can hit the forecast as one outflow next month, as staged payments across delivery milestones, or as a financed monthly cost over three years, and the three shapes produce very different lowest weeks. The scenario's job is to show you each shape against your cash floor so you are choosing between real consequences rather than instincts.

Two timing details do most of the damage in practice. The first is VAT: on a significant purchase the VAT is itself a large outflow, and whether its recovery lands before or after your next quarterly payment changes the shape of the tightest weeks. The second is coincidence with other dated liabilities. A purchase that clears your floor comfortably in isolation can breach it if the payment lands in the same fortnight as a corporation tax instalment or a heavy payroll month. The scenario catches this because the whole forecast is in the picture, not just the purchase.

It is also worth running the same purchase one quarter later. Delay is a real option with a measurable value, and showing the board "buying in Q1 takes our lowest week £38,000 below the floor; buying in Q2 keeps us £11,000 above it" is a stronger conversation than debating whether the business can afford the kit in principle.

The delayed receipts scenario: your largest customer pays late

Payment timing is the input a finance team controls least, which makes it the scenario most worth rehearsing. Build it from observed behaviour rather than invoice terms: take your largest expected receipts over the next quarter and slide each one by the gap that customer has actually shown, then add a couple of weeks for the version of the quarter where their own cash tightens. Model by name any customer whose receipts are large enough that a delay on their own would move your closing cash, rather than working to a general concentration threshold. No independent research establishes a share of revenue at which a customer becomes a concentration risk for a business of this size, and the thresholds in circulation come from company sale and lending contexts rather than day-to-day cash management. Concentration is what turns a late payment from an annoyance into a floor breach, and your own forecast is what shows you where that line falls.

This is not a rare scenario at this size. In the Department for Business and Trade's 2025 late payments research, carried out by London Economics, 42% of businesses with 10 to 49 employees had overdue invoices, payment terms longer than 60 days, or both at the time of the survey. Among small businesses affected by late payment, an average of £52,081 was tied up in it at any one time, equal to 1.47% of annual turnover. The survey covered 1,455 UK businesses, with fieldwork in January and February 2025.

It is also worth knowing what that research does not tell you. It measures how much is late, not how late. The published report carries no distribution of days overdue, even though the survey collected one, so the most authoritative UK study of late payment gives no answer to the question a forecast actually needs. That is the practical case for building the delay in your scenario from your own ledger rather than from a market average.

Keep this scenario about late, not never. A receipt that will not arrive at all is a bad-debt question for the base case and a conversation with your commercial team. The delayed receipts scenario answers a narrower question with a cash answer: how many weeks late can our biggest payers run before we cross the floor, and what do we do in the week the forecast first shows it happening? Because collections behaviour drifts gradually, this is the scenario to refresh monthly even when no decision is on the table.

The downside scenario: several things go wrong at once

The downside case is a standing scenario rather than a decision scenario, and the method guide covers how to build one that is a coherent story rather than a blanket percentage haircut. It earns a place in this guide because of what it does to the other three: every decision above should be read against the downside as well as the base case.

A hire that clears the floor in the base case but breaches it in the downside is affordable with a condition attached, and the scenario tells you exactly what the condition is. That might be a start date two months later, a facility agreed before the offer letter goes out, or a pre-agreed cut that frees the cash if the downside starts coming true. Running decisions through the downside is how a finance team says yes with its eyes open rather than defaulting to no.

The upside scenario: growth takes cash before it gives it back

The counterintuitive scenario is the good news. A large new contract usually means cash out before cash in: people or materials from the start date, invoices raised in arrears, receipts landing on the customer's payment terms rather than yours. Winning work can pull the forecast down for a quarter before it lifts it, and a business can trade profitably into a cash gap while congratulating itself. Accountants call the extreme version overtrading, and it is a taught concept rather than an exotic one: growth increases stock and receivables, and both absorb cash before the new work has paid for itself.

The upside scenario prices the cash cost of saying yes. Model the new work with honest phasing on both sides and read the lowest week it creates. If delivery costs cross your floor before the first receipts arrive, the scenario has told you the size of the bridge you need, and the time you have to arrange it, while the contract is still being negotiated rather than after it is signed.

Keep every scenario on one model

The fastest way to lose the value of all of this is a folder of forecast copies: one file for the base case, one for the hire, one for the downside, each drifting as the live numbers move. Within a month nobody is certain which file reflects reality, and reconciling them absorbs the time the scenarios were meant to save. Every case should run through one model, refreshed from one set of actuals, so the only differences between versions are the assumptions. The method guide covers where spreadsheets stop being able to hold that discipline, and what to look at when they do.

How Float fits

Float is built around the base-case-plus-scenarios pattern this guide describes. It connects to Xero and QuickBooks Online (a Sage Intacct integration is in development, with a waitlist open), pulls reconciled bank balances, invoices and bills, and keeps a rolling 13-week and monthly forecast current automatically, so every scenario starts from a live base case rather than last month's export.

The quick checks run on include/exclude toggles: switch a budget line off, watch the forecast recalculate in real time, and you have answered "what if we delay this cost?" without building anything. The four decisions in this guide run as what-if scenarios: full alternative versions of the cash flow built alongside the base forecast, which stays intact as the source of truth. When a decision is confirmed, you merge the scenario into the base rather than rebuilding, and a dedicated hiring tool models the full cash impact of a new hire from country-specific cost templates before you commit.

Two features sharpen the specific scenarios above. Smart expected payment dates set each invoice's expected date from the customer's actual payment history, so the delayed receipts scenario starts from observed behaviour rather than contractual terms. And the cash threshold limit holds your floor on the forecast and tracks the date you reach it, so comparing a decision's consequence across versions is a matter of comparing dates. Current plans, including scenario allowances, are on the pricing page.

Frequently asked questions

What cash flow scenarios should a finance team run?

A finance team should maintain three standing cases, a base, a downside and an upside, and add temporary decision scenarios when a specific choice is on the table. The decision scenarios that come up most at 11–50-person businesses are a hire, a large purchase, a delayed receipts case built on the largest customers' observed payment behaviour, and a growth case that prices the working capital cost of new work. Each one is read against the cash floor, then merged into the forecast or retired once the decision is made.

How do I model the cash flow impact of a new hire?

Model the full employment cost from the start date, not the salary: employer National Insurance, pension contributions, equipment and any recruitment fee, with revenue from the hire booked only after a realistic ramp period. Note that the Employment Allowance is set against your annual employer National Insurance bill as a whole rather than against the new hire, so an existing payroll has usually used it up already. Run the same hire at two different start dates and read the result on the weekly view, because payroll timing against your receipts cycle is where the pressure shows. The output is a date and a headroom figure rather than a yes or no.

Should a large purchase go into the forecast or into a scenario?

If the purchase is committed, it belongs in the base forecast with its real payment dates. If it is still being weighed, run it as a scenario, and model the payment shapes you are actually choosing between: outright, staged or financed. The scenario should include the VAT consequence and check for collisions with other dated outflows such as tax instalments, because a purchase that is affordable in isolation can breach your floor when it lands in the wrong fortnight.

How do I model late customer payments in a cash flow forecast?

Slide your largest expected receipts by each customer's observed payment gap rather than applying a blanket delay, and model by name any customer large enough that a delay on their own would move your closing cash. What it answers is how many weeks late your biggest payers can run before you cross your cash floor, and which week the forecast first shows it. Tools that set expected payment dates from actual payment history, as Float does, give this scenario a factual starting point.

What is the difference between a decision scenario and a downside scenario?

A decision scenario changes one thing you control, such as a hire or a purchase, and shows its cash consequence against the base case. A downside scenario changes a coherent set of things you do not control, such as slower collections and a slipped sale landing together. They work as a pair: a sound decision clears the floor in the base case and carries a pre-agreed condition for the downside, so you know in advance what you would do if the environment turns.

Can we test a decision on both the 13-week view and the monthly view?

Yes, and the two views answer different questions about the same decision. The weekly 13-week view shows whether the decision creates a pinch in a specific payroll or VAT week, which monthly totals smooth over. The monthly view, extending up to three years in Float, shows the shape of the decision over its life, which matters for financed purchases and hires whose contribution builds over quarters. A decision that looks fine on one view is worth checking on the other before you commit.

When should a scenario be merged into the base forecast?

Merge a scenario at the point the decision is confirmed, so the base case reflects committed reality: the offer accepted, the order placed, the contract signed. Until then the scenario stays alongside the base as an alternative version, and if the decision is dropped the scenario is retired rather than left to age. What should never happen is the scenario quietly becoming the forecast while the decision is still open, because then the base case is carrying assumptions nobody has agreed to.

Can scenario access be restricted to the finance team?

Access control is worth confirming before scenarios carry sensitive assumptions such as planned hires. Float uses three roles: Admins have full control, Editors can build and change forecasts and scenarios, and Viewers have read-only access, so a hiring scenario can be visible to leadership without being editable outside the finance team. The integration is one-way and read-only: Float reads from Xero or QuickBooks Online and never writes back to your accounting records.

The value of a decision scenario is the week it buys you: the gap between seeing a consequence in the forecast and meeting it in the bank account. Start a free 14-day trial of Float and run the decision you are weighing right now as a what-if scenario on a live forecast of your own numbers.