AI Workflow Teardown: Cash Forecasting

The textbook cash forecasting cycle is a clean loop: entities submit expected receipts and payments, treasury consolidates them into a rolling view, the forecast is compared with what actually landed, and the variances feed back into next week's submission. It appears in every treasury operating model I have seen, and as a description of the work it is nearly useless — because it describes the arithmetic, and the arithmetic was never the problem.

This is the first in a series of teardowns: one real workflow at a time, taken apart with the method rather than described from the outside. Cash forecasting first, because I have rebuilt it enough times to know where it hurts.

The workflow as it runs today

A typical group's short-horizon forecast runs like this. A template goes out — usually a spreadsheet, sometimes a form, occasionally both because two regions never agreed. Entities fill in expected receipts and payments and send them back, in a window that is nominally two days and in practice runs until someone gives up waiting. Treasury pulls the opening position from bank statements, extracts open items from AR and AP, layers in the known items nobody submits — payroll, tax, debt service, intercompany — and assembles a rolling view, commonly thirteen weeks and commonly direct rather than indirect at that horizon.

Then the second half starts. Last period's forecast is compared with what landed, someone works out which entity was wrong and why, a pack is written, a meeting is held. Occasionally a funding or investment decision follows, which was the point of all of it.

Where the time actually goes

Map the cycle honestly — each step, and the reason it takes as long as it does — and the shape is the same everywhere I have seen it.

Most of the elapsed time is waiting for entities to submit, not calculating. After waiting comes chasing: a person reading a mailbox to work out which of forty replies matters and which eleven never arrived. Then normalisation — the file with merged cells, the currency that was not stated, the entity that reported gross where everyone else reports net, the line described only as "project costs". Then the hunt for explanations, the expensive one, because it means opening prior submissions, bank statements and correspondence to reconstruct why a number moved.

The consolidation itself — sum, translate, bucket, compare — takes seconds, and is the only part most people picture when they say "automate the forecast".

"

The forecast was never late because the arithmetic was slow. It was late because eleven entities had not replied.

There is a quieter cost too. A view that lands on Thursday describing the week that began on Monday is a report, not a decision tool. Compressing the cycle is not efficiency; it changes what the number is for.

The deterministic core

Now the split. First pile: everything that must be identical every time it is asked, or that a control depends on.

• Aggregation and currency translation. Sums by entity, category, currency and week, at a stated rate on a stated date.
• Date bucketing. Which week a flow falls into, including value dating, weekends and public holiday calendars per country.
• The opening position. Derived from imported bank statements against known accounts, not typed.
• Variance calculation. Forecast versus actual, by horizon and category, on a definition that does not move between periods.
• Thresholds. Headroom against facility limits, minimum balances, concentration and counterparty limits — policy as code, checked rather than judged.
• Routing and status. Which entity is due, which has submitted, which version is current, who may see which entity's figures.

None of this is a candidate for a model. It is cheap to write, easy to test, and — the part people skip — it is what makes the model-driven parts safe: every drafted explanation lands next to a number calculated the same way it will be next week.

What AI can genuinely do here

The second pile is bigger than sceptics expect, and it maps almost exactly onto what the experienced analyst does all week.

• Reading whatever arrived. The submission sent as an email body, the PDF from a joint venture, the spreadsheet with the extra column, the bank confirmation attached instead of filled in.
• Classifying flows. Mapping a free-text line to a forecast category from a fixed list, with the unmapped ones raised rather than guessed silently.
• Synthesising the cycle. Twelve submissions from six entities into one summary of what changed and what is still missing.
• Drafting. The chaser, the variance commentary, the first version of the review pack.
• Spotting the odd one out. Not computing the variance — that is a rule — but noticing that its explanation does not match the pattern of previous periods, or that a receipt has slipped a week in each of the last four submissions.

What these share is that being wrong is visible and cheap. A misclassified line gets reclassified; a weak draft gets rewritten. Where being wrong is neither visible nor cheap — anything that changes the signed number, anything that moves money — the work belongs in the first pile or the third. That choice, step by step, is the automation, augmentation and autonomy split applied concretely.

What stays with a named human

The third pile is decisions, and the test is not capability. It is who answers for it when it is wrong.

Four things stay with a person, by name: whether a large uncertain flow belongs in this cycle at all; which assumption wins when two sources disagree; what to do about a gap the forecast has exposed — draw, delay, sweep, escalate; and what is said to the CFO about the number.

The redesign does not remove that person; it makes the decision cheap. Once the reading, chasing, mapping and drafting have already happened, the treasurer's work shrinks from assembly to judgement — and the judgement improves, because it is made against the whole picture rather than the three tabs there was time to open.

The state this workflow has to hold

This is where AI redesigns of forecasting quietly fail, and it has nothing to do with models. A forecast is not an answer; it is a record with a history.

• A cycle record with a status per entity: due, submitted, queried, accepted.
• Versions. What the figure was, what it is now, who changed it, why, and which version the review pack was cut from.
• An assumption register. The overrides treasury applies on top of what entities submitted, each with an owner and a reason, so next period's variance is attributable to the assumption rather than the entity.
• A frozen basis for accuracy. The forecast as it stood at cut-off, kept untouched — otherwise every accuracy measure grades a forecast that was edited after the fact.
• An audit trail. Which action, by which identity, at which time, on which entity's data.

That list is why this ends up as an application with a model inside it rather than a chat window with a good prompt. Someone picks the cycle up on Thursday having not seen Monday; an auditor asks in March why an assumption was applied. A conversation holds none of it, which is one reason pilots stall short of running the work.

The exception path

Straight-through entities were never the problem. The cost sits in five recurring exceptions, and the redesign is judged on how it handles them:

1. No submission by cut-off. Detect at the deadline, chase automatically, and — the part usually left undesigned — decide what stands in for the missing data: last period, a trend, or a marked gap. Whichever it is, it must show as a substitution rather than fold into the total.
2. An unmappable line. Raised as a proposal with the suggested category and its reasoning, resolved by a person, and written back so the mapping exists next time.
3. A position that does not tie. The opening balance disagrees with the statement — a break, not a forecast issue, routed to whoever owns the bank data.
4. Late data after cut-off. Never edited into the frozen version. It creates the next version, with the delta visible.
5. A variance nobody can explain. The one that must not be closed automatically. It ages, it is visible, and it belongs to a person.

Design these first. On every forecasting process I have worked on, they are where the week goes — and they are exactly the reading-and-assembling work a model supports.

What it has to integrate with

Mostly reads, which is what makes this a realistic first teardown rather than a two-year programme: bank statements for the opening position and actuals; open items from AR and AP; payroll, tax and debt service calendars; entity submissions in whatever form they arrive; governed FX rates; facility and limit data. Where a group runs a treasury management system, several of those already sit in one place and the integration is narrower than it looks.

The write path is thin: a published forecast version, the accuracy history, the resolved category mappings. Nothing posts to a ledger or moves money, which keeps the control surface small — worth choosing on purpose. Workflows that read widely and write narrowly are where a redesign can be proved without a control review at every step.

The redesigned workflow

Put together: submissions arrive however entities want to send them, and are read, normalised and mapped on arrival, with unmapped lines raised rather than guessed. The moment cut-off passes, the missing entities are known and chased without anyone reading a mailbox. Consolidation, translation, bucketing and variance run as deterministic code against a versioned cycle record. What reaches the treasurer is a complete draft: the position, the movements since last run, the exceptions with their evidence, and a drafted commentary for each material variance.

The treasurer's session is judgement, not assembly: accept or override the assumptions, resolve the aged exceptions, decide the funding action, put the commentary into their own words, publish. The published version is frozen and becomes next period's accuracy baseline, and the resolved mappings make the next cycle shorter than this one.

For the shape of the output underneath all this, the 13-week cash flow model is the same structure without the surrounding machinery.

What the business case is made of

Four measures, named before the build and taken before and after. Not one is a model metric.

• Cycle time, from cut-off to a published forecast someone can act on.
• Hands-on-keys touches per cycle: submissions re-typed, lines mapped by hand, chasers written by hand.
• Coverage at cut-off: how much of the group's cash is represented by entities that submitted on time, without substitution.
• Accuracy by horizon, against the frozen version, so improvement cannot come from editing history.

Coverage at cut-off is the one worth watching: it moves before accuracy does, because a forecast built on substitutions is guessing about the entities it could not reach.

Stated as a shape, illustratively rather than measured: a cycle that runs for days and produces a forecast the treasurer half-trusts becomes one that finishes inside a day and produces a number they can fund against. What justifies the work is not the analyst hours saved. It is the cost of funding decisions made late, or made on a view nobody quite believed.

What this generalises to

Cash forecasting is a good first teardown because it is unusually legible. But the four things that made the redesign work are not treasury-specific.

The elapsed time is almost never in the step everyone wants to automate. Here it is waiting and chasing. In reconciliation it will be matching exceptions; in month-end reporting, the explanations. Map the calendar before choosing the technology, and the map usually points somewhere other than where the enthusiasm is.

The number stays deterministic; the words around it go to the model. Any workflow producing a figure someone signs has this line running through it. Calculation, limit checks and postings stay as code. The reading, classifying, synthesising and drafting around the figure are the model's work — and that is where the hours were all along.

Freeze the basis, or you cannot measure anything. A forecast edited after the fact cannot be graded; nor can a reconciliation whose rules moved, nor a report whose comparatives were quietly restated. Decide what is frozen, when, and what a later correction creates instead of overwrites. That is a state decision, and it settles whether the business case can ever be proved.

Design the exception path first, because it is the workflow. The straight-through cases already flow. The value lands in the items that do not match, do not arrive or do not tie — each needing detection, a route, the context that travels with it, and a write-back so the next one is cheaper. A redesign that handles only the clean cases has automated the part that was never expensive.

The next teardown takes another workflow through the same ten questions. The headings do not change, which is rather the point: a method that only works on the process its author knows best is not a method.

See also the anatomy of an AI-native enterprise workflow, direct vs indirect cash flow forecasting, the next teardown in the series — bank reconciliation — and the general case of section seven: designing the exception path.