AI for treasury cash positioning and forecasting

A treasury cash forecast that works answers one question by a fixed cutoff each morning: how much cash will sit in each account and currency over the next one to fifteen business days, and how sure are we of each day. You build it by categorising every known and scheduled flow from source systems, then modelling only the residual timing scatter.

The model is the easy part. What decides whether the whole thing works is a narrower discipline: making every input reflect what was actually knowable on the forecast date, and nothing that leaked in afterwards.

Most treasury teams already have a spreadsheet that does a version of this. It pulls yesterday’s closing balances, adds expected receipts from the aged receivables report, subtracts the payment run and payroll, and lands on a number. It is not wrong so much as slow and brittle. Someone rebuilds it by hand every morning, the categorisation logic lives in one analyst’s head, and when a large customer pays three days late the whole week drifts with no way to see why. What we build keeps the same skeleton and fixes the parts that fail under load.

Start with categorisation, not with a model

The near-horizon position is mostly deterministic. You know payroll dates and when the quarterly tax payment leaves. Direct debits, loan servicing, and standing intercompany sweeps are all on a calendar somewhere. A large share of receipts maps to specific open invoices with terms and a payment history. Before any forecasting happens, the job is to assign every expected cash movement to a category and a most-likely date, with clean lineage back to the record it came from.

That assignment is where the real engineering sits, and it is a classification problem with a demanding false-positive budget. A bank statement line reading “SEPA CT REF 88213 ACME HLDG” has to resolve to a counterparty, an entity, a currency, and ideally the invoice it settles. Entity resolution across your ERP, your bank feeds, and your TMS decides whether a receipt lands in the right account and on the right day. Get it wrong and the position is off with no obvious cause, which is worse than being off for a reason you can see.

We build this as a labelled pipeline with an audit trail:

• Rule-based extraction for the structured, high-certainty flows: scheduled payments, payroll, tax, debt service.
• A trained classifier for the ambiguous statement narrations and the receipts that do not carry a clean reference.
• An eval set of hand-labelled historical lines that every model change has to clear before it ships, so a “small improvement” cannot quietly regress counterparty matching.
• A confidence score on each categorised item, so low-confidence flows surface for a human instead of silently entering the position.

Straight-through processing is the goal for the confident majority. The residual goes to a queue an analyst clears in minutes, and every override becomes a new training label.

Point-in-time correctness is the whole game

Here is where treasury forecasts get quietly ruined. When you assemble training data or run a backtest, it is easy to let a row see information that did not exist yet on the date you are forecasting. A payment that posted on the 12th appears in the features for the 10th because your extract simply queried the current state of the ledger. The model learns to “predict” things it was actually shown. Backtest accuracy looks excellent. Production accuracy collapses.

The defence is to snapshot every input as-of the forecast date and forbid lookahead. Concretely:

• Store bank statements, open items, and schedules with the timestamp they became knowable, not just their value date.
• When you build the feature vector for forecast date T, query the world as it stood at T, including the fact that some invoices were still open and some payments were still pending.
• Reconstruct backtests the same way, walking a moving cutoff through history, so the reported error is the error you will actually get.

A feature store that serves as-of snapshots makes this tractable instead of a per-analysis archaeology project. It also gives you the reconciliation you need for audit: every forecast can be replayed against exactly the inputs it saw, which matters when a treasurer or an auditor asks why last Tuesday’s number was off.

Model the residual and quantify the uncertainty

Once the known flows are categorised and dated, what remains is scatter. Customers pay early, on time, or late, and the distribution differs by segment and by counterparty. Uncommitted operating spend arrives without a schedule. The tail is items nobody booked. This residual is the actual forecasting problem, and it is small enough that you do not need anything exotic.

We fit per-category timing distributions rather than a single point estimate. A customer on 30-day terms who historically pays at day 34 with a five-day standard deviation should shift the expected receipt and widen that day’s band, not just move a dot. Output is a daily position with an interval, so the treasurer sees not only the central number but where the risk of a shortfall or an idle balance actually sits.

Two operational disciplines keep it honest over time:

• Drift monitoring on the categorisation and the timing distributions. Payment behaviour changes at quarter-end, around promotions, and when a large customer renegotiates terms. If day-of-week or segment error moves, you want an alert, not a surprise.
• A standing backtest that reports error by horizon. Day one and day two should be tight. Day ten should be visibly wider, and the intervals should cover the outcomes at roughly their stated rate. If the bands are too narrow, they are lying, and a treasurer who trusts a narrow band gets caught short.

What comes out is a position a treasurer can act on before lunch, with the reason for each day, lineage back to the source records, and honest bands on the uncertainty. That is the difference between a forecast that informs a funding decision and one that gets quietly ignored because nobody can see where it came from.