The AI

Let AI fill the gaps

This is where it gets interesting.

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.

How AI cash flow forecasting should actually work

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 (fiscal calendars, consumer behaviour, industry cycles).
• Trends — sustained directional movements. Customer receipts growing 10% year over year. Supplier payments gradually increasing as the business scales. Trends capture the underlying trajectory of each cash flow category, separate from seasonal fluctuations. 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. These are highly predictable patterns that do not fit neatly into a seasonal or trend model but are crucial for an accurate forecast.

Understanding business context

Something separates good AI forecasting from great AI forecasting. 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.

This is where the intelligence in the system matters. A well-designed agentic system does not just look at the time series. It considers the nature of each cash flow category, and the forecasting approach should reflect that.

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.

For a category like Rent, it recognises that a step-change in a previously stable amount likely represents a new baseline, not noise. For a category like Capex, it understands that a large payment is likely project-driven and should not be projected forward unless there is a pattern of similar payments. AI reasoning plus a human in the loop is what handles the edge cases that neither would catch on its own.

Which AI models work best

Many forecasting systems, whether built in-house or bought off the shelf, 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.

The field of forecasting models is deep. What actually matters for cash flow forecasting falls into three broad families.

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.

• These are statistical models purpose-built for sequential data with temporal patterns. Some modern, open-source time-series models (such as Meta’s Prophet) also handle trend changepoints (moments where the trajectory shifts) and outliers.
• ARIMA (AutoRegressive Integrated Moving Average) is especially effective for stationary data where the statistical properties do not change over time.
• The interpretability of Exponential Smoothing matters when a treasurer asks “why does the model think this?”

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.

Instead of treating the data purely as a time series, gradient boosting takes a different angle. This makes it powerful when cash flow patterns depend on factors beyond historical timing. These approaches are becoming increasingly relevant as more data becomes available and models become easier to deploy.

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.

This means the forecast always reflects the most current data. There is no waiting for someone to notice. The agent adapts continuously.

In practice the agent selects from multiple model types based on data characteristics:

• Categories with strong seasonal patterns and sufficient transaction volume get time-series models like Prophet.
• Stable, low-volatility categories (like rent or insurance) get recurring pattern detection.
• Categories with sparse or schedule-driven payments (like quarterly taxes or annual dividends) get schedule-based models.
• Categories with very limited data fall back to moving averages.

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.

This is one of the most important design decisions in any AI system, and it is especially critical in treasury, where the numbers drive real financial decisions.

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.

• Assistive. Nothing happens without explicit human consent. It builds trust, lets the team learn how the AI thinks, and ensures no erroneous predictions slip through unnoticed.
• Semi-autonomous. The human focuses their attention where it matters most, rather than reviewing every number.
• High autonomy. The AI injects predictions into the forecast. The human sets the boundaries and monitors the outcomes, but does not approve every individual entry.

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.

This means an organisation can run the agent in a conservative mode for sensitive categories while letting it operate more independently on the routine ones. In a review-first posture, every prediction is presented as a suggestion that the user accepts, modifies, or rejects before it enters the forecast. As confidence grows, teams let the agent automatically inject forecasts for stable categories while still requiring approval for volatile ones. Regardless of the settings, the user can always review and override after the fact.

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.

The right autonomy level is not a permanent choice. Most organisations start at low autonomy, build confidence over a few forecast cycles, and gradually increase it as they see the AI perform. The goal is not to remove the human. It is to focus the human on the decisions that need human judgment.

From reactive assistant to proactive team member

There is another dimension of autonomy that goes beyond how the agent handles individual forecasts. It is about when the agent works.

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 assistant answers questions. The team member takes initiative.

In NineAnts, users can configure scheduled agent tasks using natural language. Tell the agent to “create a forecast for all categories every Monday at 9 AM” and it will. The agent runs autonomously on that schedule, executes the forecast, and can email the results directly to the treasury team or any stakeholder. No one needs to be logged in. No one needs to click a button. The forecast is ready when you need it.

This turns the agent from something you interact with into something that works alongside you. It handles the routine, recurring work autonomously, and frees the team to focus on the exceptions, the judgment calls, and the strategic decisions that actually need a human.

The user experience

Something that does not get enough attention in conversations about AI forecasting: 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.

A manually entered number from a subsidiary has a very different confidence profile than an AI prediction based on 24 months of seasonal data. An ERP figure based on booked invoices is more certain than a forecast for a category where no system data exists. Treating them all the same is misleading. Solving this design problem is one of the most important things you can do when building a forecasting system.

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.

At a minimum, every forecast entry should clearly show its source. Was it imported from the ERP? Pulled from a bank feed? Entered manually by a user? Generated by the AI? Uploaded from a file? The user should never have to guess. In NineAnts, every forecast entry carries a source type that tells you exactly where it came from. AI-generated entries look different from system-imported entries, which look different from manual entries. You can filter by source, so if you want to review only the AI-generated numbers, you can isolate them instantly.

Audit trails matter more than you think

Source labels tell you where a number came from. But in a collaborative forecasting process, you also need to know who changed what and when. Did someone in the French subsidiary override an AI forecast last Tuesday? Did the treasury team adjust the investment assumptions after the board meeting? Was a category re-forecasted because new ERP data came in? Every action should be logged with a timestamp and a user. This is not just good practice. For many regulated industries, it 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 user experience challenge multiplies in a decentralised setup. Each user needs to see their own scope clearly. The finance manager in Brazil should see their entities and their categories, not the entire group forecast. But group treasury needs the consolidated view with the ability to drill down into any entity.

Getting this right is what separates a tool that people actually use from one that gets abandoned after the first quarter. The best forecasting model in the world is worthless if the people who need to interact with it cannot understand what they are looking at.

Control matters just as much as collaboration. Central treasury should lock the cycle once the submission window ends. A partial late update (for example, one entity adding intercompany flows while its counterpart does not) creates mismatches that are worse than having no update at all. Clear ownership of what is expected, by whom, by when, and under which guidelines is what makes a decentralised process work in practice.

The role of the LLM in an agentic system

The word “agent” has been used throughout this guide. It is not marketing language. It is a specific technical architecture that fundamentally changes how forecasting systems work.

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.

With procedural software, if the output does not make sense, you adjust the configuration and try again. The software does exactly what you tell it to do, nothing more. In an agentic system, Prophet (an open-source time-series forecasting library originally developed by Meta) is just one of the tools the LLM can call.

What the LLM actually does

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.

The relevant data it retrieves includes historical transactions, existing forecasts and connected source data. This is fundamentally different from a button that runs Prophet and shows you a chart. The questions the LLM reasons about are judgment calls that require understanding the meaning of the data, not just its mathematical properties.

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.

Not theoretical risk. Career-ending, board-level risk. Traditional treasury software already raised security concerns. AI raises new ones. The data is not just stored and displayed. It is processed, analysed, and used to generate outputs that did not exist before. That changes the threat surface. And it means the questions you need to ask go beyond the standard IT security checklist.

Here are the concerns we hear most often from corporate treasury teams, and what you should be thinking about whether you are building an AI forecasting system in-house or evaluating an external solution.

The concerns that come up

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.

How much can the AI do without my approval? The more autonomy an AI system has, the more important it is that you can control and audit what it does. Regulations like GDPR and CCPA may require specific safeguards for automated decisions with significant effects, but the principle holds regardless: you should be able to configure exactly what the AI can do on its own, what requires approval, and what is off limits.

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. This matters for the basic reason that you need to be able to defend every number in a board meeting.

The key questions to ask

Whether you are evaluating a vendor or building internally, these are the questions your security and compliance teams should be able to answer. If you are buying, ask the vendor. If you are building, ask yourself.

If you are buying and the vendor cannot answer these clearly, that tells you something. If you are building and your own team cannot answer them, you have work to do before going live.

How we handle this in NineAnts

We built NineAnts with the assumption that every customer would ask these questions, and that we should be able to answer all of them before the first meeting ends.

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.

For customers in other regions, we work with you to ensure data stays where it needs to be. Tenant segregation includes input validation and output filtering in the AI pipeline. As described in the section on human in the loop, autonomy in NineAnts is configurable per action type. From a security standpoint, this means customers control exactly what the AI is allowed to do, and every AI-generated output is logged with full traceability.

The ISMS is reviewed and audited regularly. The AI annex of our Data Processing Agreement covers everything from model training restrictions and tenant isolation to AI-specific incident management. We share this documentation with every customer during onboarding, because we believe transparency is not a nice-to-have. It is the baseline.

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.

The LLM figures out the right path for every query. This architecture is what enables the system to handle ambiguity, unexpected questions, and workflows that a traditional software designer could not anticipate.