Sizing a funding requirement

Every figure needed to size Marchmont's facility is already computed by the time the run finishes. None of them is hard to produce and none of them needs a formula that is not already in the engine. What goes wrong is the reading: which row of the output you point at, and whether the window you ran was long enough for that row to exist.

So the method below is mostly a sequence of refusals. Do not read the first crossing. Do not read the last month in view. Do not read a trough that sits on the edge of the window. Do not read a total where a level is wanted. Each of those produces a number that is correct as arithmetic and wrong as an answer.

Three lines of reading over one run. The tie check goes first, because a run that does not tie is not a source of a number, and it costs one line to refuse it.

cashOutMonth answers when the problem starts. The loop answers how big it gets. The second loop answers when it ends. Reading only the first of the three is the single most common way a funding requirement comes out too small, and it is not a mistake of arithmetic: £7,432 is the correct depth in month 10.

A trough is only a trough if the line turns inside the window. If the deepest month in view is the last month in view, the run has reported where it stopped looking rather than where the bottom is. The test is one field.

Twelve months returns a number that looks like an answer and is a description of the window. Twenty four months and forty eight months agree, which is the only evidence available that the horizon is long enough. Agreement between two windows is not proof, but disagreement is proof of the opposite, and that is worth one extra run.

Free cash flow over the first twelve months totals -£297,261. That figure is real and it is the sum of every pound that left. The balance at month 12 is -£47,261. Neither is wrong. They are a flow and a level.

The difference is the £250,000 of opening cash, which absorbed most of the outflow before the balance ever went under. A facility funds the level, not the flow, because the question is how far below zero the bank account goes rather than how much money moved. Sizing on the cumulative outflow overstates the requirement by whatever the business already had, and sizing on the last month in view understates it by whatever happens next.

A facility that ends in month 18 is a facility that ends one month before Marchmont's worst month. A facility that ends in month 24 ends while the balance is still under. The month the line crosses back is month 28, and it is the first month at which the business no longer needs the money, so it is the first defensible end date.

This is the reason the horizon question from part 1 is not academic. A 24 month run contains the trough and does not contain the recovery, so it can size the facility and cannot term it. The recovery reader returns zero on that run, and zero means "not inside this window" rather than "never", which is a distinction worth putting in the variable name rather than in a comment.

Asking for exactly £115,501 is asking for a plan in which nothing is allowed to be wrong. One customer paying late in month 18 breaks it, and the model has no variable for that customer. So the request is the trough plus an amount, and the amount is a judgement about how wrong the assumptions could turn out to be.

What makes a judgement defensible is not the size of it but what it is measured against. The growth ladder is already computed across five settings, and it says what being wrong costs: at 2% a month there is no gap to fund at all, at 4% the trough is -£115,501 and closes in month 28, at 6% the trough is -£897,962 and has not closed by month 48. A buffer chosen with that table on the page is arguable. A round number chosen because it felt prudent is not arguable, and the other side will replace it with their own round number.

No figure for the buffer appears anywhere in the measured set, and inventing one here would be the same error the page is warning against. What the ladder supports is the shape of the argument: how far up the rung you are covering, and the point at which covering further stops being a buffer and becomes a different request.

Two experienced people looking at -£115,501 and the ladder behind it will propose different amounts, and the gap between them is not a gap in understanding.

One position: size it tight and keep the recovery date credible. The strength of the request is that it is checkable. A trough, a term and two named assumptions can all be re-derived by the person being asked, and a modest, stated margin on top can be argued line by line. Ask for a great deal more than the model supports and the checkable part is gone, because now the figure rests on an unstated view of how wrong the model is. Money that is available also tends to get used, and a facility sized for a worse company is an invitation to become one.

The other position: the asymmetry is not close, so take the headroom. Being over-funded costs a fee that can be written down in advance. Being under-funded costs the company, and the second conversation happens from a much weaker position than the first, at exactly the moment the numbers look worst. On this view the tight number optimises the wrong thing: it minimises a cost you can measure by accepting a risk you cannot, and the ladder itself shows how quickly the requirement moves when one assumption slips.

Both are held by people who have watched the other one fail. The model contributes nothing to settling it, because it has no variable for the cost of unused headroom and none for the cost of going back. What it can do is make the disagreement specific: say which rung of the ladder your buffer covers, and the argument becomes about that rung rather than about temperament.

Described rather than recommended, and generic rather than specific to any business. The usual list is an amount, a period, the use it is put to, the assumptions the amount rests on, what happens if those assumptions move, and how the money gets repaid. Four of the six come straight out of the run: the amount is the trough, the period runs from the crossing to the recovery, the use is the working capital build, and the sensitivity is the ladder.

The two that do not come out of the run are the buffer and the response if the assumption moves, and those are the two that get asked about. Session 6 is the presentation side of the same problem and is worth reading alongside this, because a figure produced well and presented badly gets refused in the same way as a figure produced badly.

The instinct when growth comes in above plan is to scale the request in proportion. It does not work, because the relationship between growth and the trough is not a proportion and the ladder says so plainly. Going from 4% to 6% moves the trough from -£115,501 to -£897,962, moves the crossing forward from month 10 to month 6, and removes the recovery from the window altogether. A scaled version of the old request would have a term on it that the model no longer supports.

Rerunning costs one line. The output of that line is a different request with a different shape, and saying so out loud is a much better position than presenting a scaled figure and being asked where the recovery date went.

A trigger is a condition agreed in advance that obliges you to go back and talk before the position changes rather than after. Two properties make one useful. It is written on the thing that moves first, which for Marchmont is the growth rate or the collection days rather than the bank balance. And it is observable by both sides, so that nobody has to take your word for whether it has fired.

The level is a judgement in exactly the way the buffer is, and no measured threshold exists anywhere in the model output. What the ladder supports is the reasoning: the request was built on 4%, the rung above it is a different kind of request, so the condition worth writing is one that fires somewhere between those two rather than at the point where the difference has already been paid for. Where between them is an argument, and it is an argument to have before the money is drawn.

The second half of the trigger is the part people leave out. A condition with no stated response is an alarm with nobody assigned to it. Session 7 measured what the responses actually do: collecting in 45 days instead of 75 leaves the cash line above zero all year, and so does growing at 2% instead of 4%. Naming which of those you would reach for, in advance, is what turns the trigger into a plan.

The chain at the top of the diagram is the whole argument for an early conversation. Growth above plan is visible in the order book in the month it happens. It reaches the cash balance months later, because the receivables build lags the revenue that caused it by the collection period. And it reaches the facility limit later still. Each step loses options.

A conversation held at step one is about a forecast that has moved and what to do about it, with the business profitable and the balance still positive. The same conversation at step three is about a breach, held by people who now have a reason to doubt the first set of numbers. The arithmetic is identical in both. What has changed is who is believed.

None of that is a claim about what any lender will do, and the response of a real counterparty to a real request is outside anything a model can say. It is a claim about what the model makes visible and when, which is the part you control.