AI Cash Flow Forecasting: A Practical Guide

AI cash-flow forecasting works when the cash identity stays deterministic and the model only predicts what is actually uncertain. The formula is not a suggestion:

Ending cash = opening bank cash + receipts − disbursements

Every production system that survives a treasury review separates four jobs: classify transactions, estimate timing on open items, calculate the roll-forward with ordinary arithmetic, and explain the miss. Mixing those jobs is why most “AI forecast” projects look accurate in a demo and drift by week six.

Two forecasts, not one

Direct and indirect methods answer different questions. Running only one creates a blind spot.

Direct is the liquidity tool. Indirect is the planning tool. A credible stack keeps both and reconciles them at the month boundary: the first four to six weeks of the indirect view should not contradict the direct view without a named driver.

Published accuracy figures are vendor samples, not a benchmark you can import. One anonymized SaaS book showed hybrid models at about 93–96% on week 1–4 ending cash and 76–84% by week 8–13, versus a maintained spreadsheet at 84% and 62–71%. Other write-ups put a well-built direct forecast at 90–95% by week 4, and note that roughly 30% of deployments stall at 70–80% because the bank, open AR, or committed AP never made it into the model. Treat those ranges as order-of-magnitude, and score your own book.

What the model is allowed to touch

Split every cash line into three classes before you train anything.

Known. Amount and date are contractual or already approved: payroll calendar, rent, debt service, tax instalments, insurance, approved capex draws, intercompany settlements on a fixed calendar. Encode these as schedules. A Prophet or XGBoost fit on payroll is a liability, not a feature. One treasury backtest cut weekly net-flow error by about three quarters simply by telling the model when payroll and tax hit, rather than asking it to discover them.

Patterned. Amount or date varies, but history is informative: customer collections, vendor payment runs, card settlements, freight, utilities, bonus accruals. This is the machine-learning surface.

Event. No stable history: a large customer loss, a plant shutdown, an acquisition, a one-off legal settlement, a covenant waiver. These belong in a scenario layer with an owner and an expiry date, not in the training set.

The hybrid pattern — rules for known items, statistical or tree models for patterned items, human scenarios for events — is the one that holds up in mid-market books. Full end-to-end machine learning only earns its keep with 18–24 months of clean history and enough transaction volume that a tree can see non-linear effects. Below that, it overfits noise and loses to a seasonal naive plus a collections lag.

Data, in the order it actually moves accuracy

Tier 1 is the usual reason forecasts plateau:

• Reconciled bank balances, daily, by account and currency. Opening cash that is not the bank is not a forecast.
• Open AR with invoice date, due date, amount, customer, dispute flag, and credit status.
• Open AP and approved-but-not-invoiced POs, with terms and a payment-run calendar.
• Payroll, tax, and debt calendars.

Tier 2 separates a good week-4 forecast from a lucky one:

• Customer payment history: days past due, partial pays, short-pays, deductions.
• Vendor payment behavior versus terms. Many companies pay on a run, not on the due date.
• Shipment or delivery confirmation. A delivered invoice collects. An invoiced-but-not-shipped one often does not.
• Intercompany calendar and in-transit cash. In a multi-entity manufacturing group this is frequently the largest surprise.
• FX rates on unhedged exposures, applied after the local-currency forecast, not inside it.

Tier 3 is useful later: order book, inventory builds, commodity indexes, macro series. Add them only after Tier 1 reconciles. Extra features on a dirty open-item file make the narrative sound smarter and the cash number worse.

Hygiene failures that quietly dominate model choice: duplicate vendor or customer masters, wrong terms on the master, stale POs that will never invoice, unapplied credits, and approval queues the forecast never sees. If invoices can sit in an inbox for five days, the model is forecasting a process lag, not a customer.

Model choice by bucket

Do not fit one model to net cash. Net cash is a residual. Forecast receipts and disbursements separately, then roll.

A practical model menu, in the order a finance team can defend:

1. Seasonal naive and moving average as the baseline you must beat.
2. Prophet or SARIMAX when the series is weekly, seasonal, and you can pass known events as regressors.
3. Gradient-boosted trees (XGBoost, LightGBM) when you have invoice-level features: amount, age, customer, terms, dispute, delivery status. This is the right tool for time-to-pay, not for the cash balance itself.
4. A language model only for classification proposals, exception notes, and scenario prose. It does not own the number.

Use a walk-forward backtest, not a random 80/20 split. Train through week t, forecast t+1 to t+13, then roll forward. A random split leaks the future into the training set and flatters every model.

Metrics that survive a CFO review

A single “95% accurate” line is not a control. Track four numbers, by bucket and by horizon.

• WAPE (weighted absolute percentage error) on receipts and on disbursements. Prefer this to MAPE. Cash series cross zero, and MAPE explodes.
• MAE on ending cash, in currency. A €40k miss means something different in a €2m week than a percentage does.
• Signed bias. A model that is always €27k light is usable if you know it. An unbiased model with the same MAE is not automatically better for a revolver decision.
• Date error on collections and payment runs. Amount-right, week-wrong is the failure mode that breaks a 13-week forecast.

Also keep a forecast-value-added log: model versus seasonal naive versus last week’s human override. If the override does not beat the model over eight weeks, stop overriding that bucket. If the model does not beat naive, retire it.

Operating cadence

Weekly, same day, same owner:

1. Lock opening cash to the bank, by entity and account.
2. Refresh open AR, AP, POs, payroll, tax, and debt. Stamp an as-of time.
3. Apply known schedules. Run patterned models. Drop events in from the scenario register.
4. Produce the 13-week roll, plus a base, downside, and upside that move only named drivers: DSO plus five days, a payment run pulled forward, a lost order, an FX shock.
5. Reconcile last week’s forecast to this week’s actual. Attribute the miss to amount, date, new item, or omitted item. Change an assumption only when the miss repeats.
6. Write the exception note: three drivers, one action, one owner. The model can draft it. Treasury signs it.

Monthly, the indirect bridge takes the direct weeks 1–4 as given and extends months 2–12 from the rolling P&L: revenue to collections via DSO by segment, COGS and opex to payments via DPO, inventory to cash via DIO, plus capex, interest, tax, and dividends. Manufacturing books should bridge inventory explicitly. A revenue beat that builds stock is not a cash beat.

Alert thresholds worth setting on day one: minimum cash versus the policy buffer, revolver availability, covenant headroom, and any entity whose week-2 balance goes negative before intercompany settlement.

A ninety-day build, in the order that pays

Days 1–30 — the cash identity. One entity, one currency. Bank plus open AR/AP plus three calendars: payroll, tax, debt. A weekly roll in a sheet or a small app. No model. The win is a number that ties to the bank and a miss log. If this does not reconcile, stop.

Days 31–60 — timing models on two buckets. Collections lag by customer segment, and vendor slip versus the payment run. Keep the seasonal naive beside them. Publish WAPE and bias. Add classification only for the uncoded bank lines that block the tie-out.

Days 61–90 — the operating layer. A second entity, an intercompany calendar, FX after local currency, a scenario register, and an exception narrative a human approves. Only then talk about a 12-month driver bridge or more entities.

The architecture that stays governable is simple. ERP and bank remain the systems of record. A feature store holds open items and calendars. Models write predictions with a method name and a timestamp. A deterministic roll-forward sits underneath, and no model can overwrite it. Overrides are rows, not edits. Prior runs are immutable. Rebuilding the file in place destroys the only data you need in order to learn from misses.

For a privacy-sensitive FP&A stack, the split is clean. Classification, lag models, and the roll-forward run on-prem against real AR, AP, and bank data. External models, if used at all, see synthetic or aggregated series for method development — not customer names and invoice amounts.

Failure modes that look like model problems

• Forecasting bookings or revenue instead of collections.
• Training on the old forecast instead of bank actuals. The model then learns your optimism.
• One net-cash series hiding a payroll spike inside a collections miss.
• Stale open POs inflating committed cash out.
• Intercompany and in-transit cash left out of both sides.
• No owner for events, so the downside case is a vibe.
• Accuracy quoted on a single horizon, usually the one that looks best.
• A model from two years ago still running after a term change, a new plant, or a shift in customer concentration.

What to refuse

Do not let an agent close the cash number. Do not auto-apply an override. Do not train on one-off items you already know are one-off. Do not add a feature whose source has no service level. Do not present a scenario whose driver cannot be named in one sentence.

The practical test is simple. At the Monday review you should be able to point at ending cash, name the three lines that moved it, say which of those lines came from a schedule, a model, or a person, and show last week’s miss in the same structure. If the system cannot do that, it is a chart, not a forecast.