How to do AI Cash Flow Forecasting · Part II
The AI
Which AI models fit which cash flow categories, the agentic approach, human-in-the-loop autonomy, the role of the LLM as orchestrator, and AI security and data governance.
Let AI fill the gaps
You now have two layers of data: categorised historical cash flows (what happened in the past) and known cash flows from connected systems (what you already know about the future). The gap between those known cash flows and reality is where AI earns its keep.
A well-designed AI agent analyses your historical data category by category to identify three types of patterns:
- Seasonality — repeating calendar-driven patterns. Customer receipts higher in November and December. Tax payments clustering in specific months. Supplier payments dipping every August when Europe is on holiday. Seasonality is one of the strongest signals because it is driven by structural factors that persist year after year.
- Trends — sustained directional movements. Customer receipts growing 10% year over year. Supplier payments gradually increasing as the business scales. A model that captures seasonality but misses the trend systematically underforecasts a growing business.
- Recurring patterns — regularities beyond seasonality and trends. Your largest customer paying on the 15th of every month like clockwork. Capex spiking every 18 months when equipment needs replacing. Dividends paid twice a year on fixed dates.
Understanding business context
Patterns alone are not enough. The system needs to understand business context. Take Rent. The company has been paying €50,000 per month for two years. Then suddenly, in March, the amount doubles to €100,000. A pure pattern-matching model treats this as an anomaly and tries to smooth it over. But the company signed a new lease for additional office space — €100,000 is the new normal. The model should not revert to €50,000 next month. It should project €100,000 going forward.
Now flip it: the same rent category jumps to €150,000 for one month because of a deposit on the new lease. That is genuinely a one-off and should not be baked into the recurring forecast. The difference between a structural change and a one-time event cannot be determined from numbers alone — it requires understanding what kind of cash flow you are looking at and what is driving the change. Rent behaves differently from Customer Receipts. Tax payments follow a regulatory calendar. Capex is lumpy and project-driven. Salaries are stable but step up when headcount changes. Each category has its own logic.
In NineAnts, the Treasury Agent classifies each category as stable, seasonal, trending, or volatile, and adapts its approach accordingly. When a pattern changes, it reasons about whether the change is structural or temporary. When the signal is genuinely ambiguous, it surfaces the change to the treasurer rather than guessing. That separates a forecasting tool from a forecasting agent: the tool applies a model, the agent thinks about the data.
Which AI models work best
Many forecasting systems apply the same model to every category. But Customer Receipts, with hundreds of transactions per month and clear seasonal patterns, needs a fundamentally different approach than Capex, which might have five transactions per year at irregular intervals.
Time-series models. Meta’s Prophet is particularly well-suited for cash flow forecasting because it was designed to handle multiple seasonalities (weekly, monthly, yearly), trend changepoints, and holiday effects — exactly the patterns that show up in business cash flows. ARIMA is a classic approach, effective for stationary data. Exponential Smoothing methods like Holt-Winters are simple but surprisingly effective for stable seasonal patterns, with the added bonus that they are interpretable.
Machine learning models. Gradient boosting (XGBoost, LightGBM) can incorporate external features like payment terms, customer segments, and macroeconomic indicators. Neural networks capture complex non-linear relationships but need substantially more data to train and are harder to interpret. For most treasury use cases today, time-series and statistical models still deliver the best balance of accuracy and interpretability — but that may shift as more data becomes available.
Simple statistical models. Don’t underestimate them. A well-tuned moving average or linear regression can outperform sophisticated models for categories with few transactions or very stable patterns. If your rent is €50,000 every month, you do not need Prophet. Matching model complexity to data complexity is engineering maturity, not compromise.
The agentic approach
Traditional forecasting trains a model offline on historical data, deploys it, and uses it until someone decides to retrain. The fundamental weakness: the model is always looking at stale assumptions. The world changes; the model stays frozen.
The agentic approach is different. The Treasury Agent does not train a model once and reuse it. Every time a forecast is requested, the agent analyses the data fresh — fetching the latest transactions, evaluating the characteristics of each category in real time, and selecting the most appropriate model on the fly, like a mechanic reaching for the right tool depending on the task. If a category that was stable for two years suddenly becomes volatile, the agent detects this on its next run and switches models. No waiting, no manual retraining, no deployment cycle.
In practice the agent picks: time-series models like Prophet for categories with strong seasonality and sufficient volume; recurring-pattern detection for stable, low-volatility categories like rent or insurance; schedule-based models for sparse, schedule-driven payments like quarterly taxes or annual dividends; and moving averages as the fall-back for categories with very limited data. The user can see which model was selected for each category and why. The model fits the data, not the other way around.
Human in the loop
Once the agent produces a forecast, a fundamental question emerges: how much control do you want to keep? “Human in the loop” is not just a safety feature — it is a philosophy about how humans and AI collaborate.
At one end of the spectrum, the AI is purely assistive. It generates predictions, but a human reviews and approves every entry. This is the right starting point for any organisation new to AI forecasting. In the middle, the AI operates semi-autonomously — filling in forecasts automatically for high-confidence categories, flagging uncertain predictions for human review. At the other end, the AI operates with high autonomy: handling routine categories end-to-end, escalating only when something unusual appears.
In NineAnts, autonomy is not a single low/high toggle. It is configured per action type: generating a forecast, writing a prediction directly into a category, adjusting existing entries, running scheduled jobs, sending notifications. For each, you decide whether the agent may act on its own, must ask for confirmation first, or is not allowed to perform the action at all. Most teams start in a review-first posture and unlock specific actions as confidence grows.
Regardless of autonomy level, every AI-generated entry is clearly marked. The user always knows which numbers came from the AI, which from connected systems, and which were entered manually. If you cannot distinguish AI-generated data from human-entered data, you cannot meaningfully review or trust the forecast.
From reactive assistant to proactive team member
Most AI tools are reactive. You open the application, type a question, get an answer. The AI waits. A truly agentic system can also be proactive: it can run on a schedule, generate the weekly forecast every Monday at 7am before treasury arrives, compare last week’s actuals to forecast every Friday afternoon and flag deviations, or monitor bank balances daily and alert the team when excess cash crosses a threshold. It does not wait to be asked. It does the work and reports back. This is the difference between an assistant and a team member.
The user experience
A cash flow forecast is only useful if the people working with it trust it. Trust comes from clarity. When a treasurer opens the forecast on Monday morning, they are looking at numbers that come from fundamentally different sources: ERP imports, bank statement data, manual entries from a colleague in Singapore, AI-generated predictions, and AI predictions that were manually adjusted by a local team. If all of these look the same on screen, the treasurer does not know what to question, what to verify, and what to trust.
Every number needs a label. Source type — AI, ERP, bank, manual, file upload — should be visible at a glance, and filterable. A full audit trail (every create, update, delete, import, AI injection, with timestamp and user) turns the forecast from a static spreadsheet into a living, traceable document. For many regulated industries, this is a compliance requirement.
Designing for collaboration across subsidiaries. When twenty subsidiaries contribute to a single consolidated forecast, the interface needs to serve both audiences without overwhelming either. Local users need simplicity: their categories, their numbers, what the AI suggests, approve or adjust. Group treasury needs depth: consolidated totals, drill-down by entity, filter by source type, and the ability to spot which subsidiaries have submitted and which have not. Central treasury should also be able to close a forecast cycle and lock it against further edits — coherence across entities is more important than squeezing in last-minute changes.
The role of the LLM in an agentic system
Traditional forecasting software is procedural: you configure it, press a button, it runs a model, gives you output. An agentic system is different. At its core sits a Large Language Model that acts as the brain. The LLM does not do the statistical forecasting itself — Prophet handles time-series modelling, moving averages handle sparse categories. The forecasting models are specialised tools. The LLM is the orchestrator. It decides which tool to use, when, and why.
When you ask the system to forecast Customer Receipts, the LLM first classifies your intent (forecast, analysis, comparison?), retrieves relevant data, examines the data characteristics, selects the appropriate forecasting model, interprets the model’s output in context, and communicates the result back in plain language — explaining not just the number but the reasoning behind it. The LLM can also reason about things statistical models cannot: whether a category is seasonal or volatile, whether recent data suggests a trend change, whether a discrepancy between forecast and actuals deserves attention. An LLM can read a transaction description, understand that “Office Lease Q2” is rent-related, and categorise it accordingly. A pure rule engine would need a specific rule for that.
AI security and data governance
Every treasury team considering AI should be asking hard questions about security — and should be sceptical of any vendor that brushes those questions aside. Financial data is among the most sensitive information a company holds: transaction histories, cash positions, bank account details, counterparty relationships, forecast assumptions. Mishandling creates real, board-level risk.
Where does my data go? You need to know exactly where your data is processed, not just stored. With AI, application data might sit in Frankfurt or Virginia, but if the AI model runs on servers in a different jurisdiction, your prompts and outputs may be crossing borders every time a forecast is generated. Ask for a clear statement that all processing — including AI inference — happens within infrastructure you can verify.
Is my data used to train AI models? Many providers use customer interactions to improve their models. Any serious vendor should give you an unambiguous contractual guarantee: your data is not used for model training, fine-tuning, or service improvement in ways that could expose it to others. There is a meaningful distinction between training a foundation model on your data (which should never happen) and using interaction signals like acceptance or rejection of a forecast to improve workflow logic for your own tenant. The second is how a system learns your preferences. The first is a red line.
Can other customers see my data? In a multi-tenant SaaS platform, the isolation question gets more complex when AI is involved. AI outputs are generated dynamically — if the model has been exposed to data from multiple tenants during processing, there is a risk of cross-contamination. Look for logical tenant separation at every layer including the AI layer, input validation and output filtering against prompt injection, and incident management procedures that specifically address AI-related risks.
Can I trace what the AI did and why? From a security and compliance angle, AI adds a specific audit requirement: you need to know not just that a number changed, but which AI model generated it and what data it was based on. Logging of AI-generated outputs should include the model or workflow used, the data sources referenced, and any subsequent human modifications.
How NineAnts handles this: all data is hosted on Microsoft Azure infrastructure, with data residency configured to match customer requirements (EEA-based data centres for European customers). AI processing, including all LLM interactions, runs within infrastructure that Automation Boutique controls. Customer data is never sent to third-party AI providers as independent recipients or controllers. It is not used to train, fine-tune, or improve AI models. Tenants are logically segregated at every layer. Automation Boutique maintains an ISO 27001 certified Information Security Management System, and our Data Processing Agreement includes a dedicated annex on AI security and processing controls.
The agent architecture
Think of it as a team. The LLM is the team lead. The forecasting models are the specialists. The data connectors are the researchers. The action engine is the analyst who translates findings into recommendations. The team lead coordinates them all, routes the right questions to the right specialist, synthesises the answers, and communicates with the user.
In practice, the system has dozens of specialised nodes, each handling a specific part of the workflow, with the LLM routing between them based on what the situation requires. Ask for a forecast, and you get one path. Ask why last month’s actuals deviated from the forecast, and you get a completely different path through the system. A treasurer might ask: “Why were our supplier payments so high in March?” That is not a forecast request. It is an analytical query that requires pulling actuals, comparing to historical norms, identifying outlier transactions, and forming an explanation. A procedural system cannot handle this. An agentic system can. That is the revolution in treasury technology — not just better models, better reasoning.