A Cash Forecast That Matches the Bank
Professional Services · 2026 · Back-Office Automation
Closed months are bank data, future months are forecast, one chart. Statement lines arrive already matched to the movement they belong to; a person confirms with a tap.
The challenge
This one is ours. Built on the system we run ourselves: our own treasury, in daily use, no client involved. We built it to answer the question every CFO gets asked and almost nobody can answer well — how much will be in the bank in three months?
Every answer we had was built from the cost of the month, not from the payments that actually leave the account. Those are not the same thing. A contractor on a monthly rate is not one payment: it is five. The net amount goes to the person in one month; the tax lines, the contributions and the insurance leave the month after. A forecast that collapses them into a single number is wrong in a predictable way, and you find out when you open the statement.
The other half of the problem is the statement itself. Predicting a payment is worth nothing if nobody checks whether it happened. Doing that by hand means reading the bank export line by line and remembering what each line was supposed to be.
What we built
A treasury system that runs in our own cloud account, in four parts:
- Costs modelled as payments. Every recurring cost expands into the separate outflows it really produces, each one placed in the month it leaves the account. One cost, five payments, five dates.
- One curve, no seam. Closed months are actual bank data. Future months are forecast. The chart is a single line, and the forecast starts exactly where the statement ends.
- Bank reconciliation. You upload the statement; each line is compared against the movements predicted for that period, including partial matches and payments made in instalments. Around 90% of lines come back attached to the right movement. The system suggests, you confirm.
- Invoices sharpen the estimate. When the document arrives, the estimated tax figure is replaced by the exact one and the forecast moves with it.
The AI sits where it earns its place. Learned rules run first, the model is called only on what the rules do not cover, and the person confirms instead of retyping. That order is what keeps the system cheap to run and predictable to read.
The confirmation tap is the control, not a formality: reconciliation is only worth forecasting from if someone owns the moment a bank line is declared closed. One tap per line is a price worth paying for that.
One case is deliberately left to a person, and we would rather say it than round it up: a single statement line that bundles dozens of micro-transactions has no one movement to attach to. Today it gets split by hand. Everything else in the file arrives pre-matched.
The results
The forecast matches the bank because it is built from the same events the bank records — individual payments on individual dates, not a monthly average. Reconciliation is now a page of suggestions to confirm instead of a page of blanks to fill, and the twelve-month cash position is recomputed as statements and invoices arrive rather than rebuilt in a spreadsheet once a quarter.
| Number | What it measures |
|---|---|
| ~90% | of statement lines matched to the predicted movement |
| 1 cost → 5 payments | modelled separately, each in the month it leaves |
| 12 months | of cash position, recomputed as data arrives |
| Closed months | are bank data, not estimates |
What you get
The cost model built on how your money actually leaves, the reconciliation loop against your own bank statements, and the cash chart your finance team opens in the morning. It runs in your own cloud account. Process audit first, scope in writing, and 30 days of support. The receipts-and-reimbursements half of the same treasury system is Receipt-to-Reimbursement Automation.
Want to know whether your forecast survives contact with the statement? Start with the free AI Audit, or book a call.