UNHCR uses AI to prepare its treasury cash forecast: what it did, what it gained and how to replicate it

Context: why a humanitarian agency needed a different way to forecast its cash

Treasury forecasting is one of the processes where the gap between what AI promises and what actually works shows most. That is why a case told in detail by the person who runs it deserves attention: the treasury unit of UNHCR, the UN Refugee Agency. Hikaru Kozuki, senior treasury specialist and head of that unit, explained it at the EuroFinance International Treasury Management 2026 conference, and EuroFinance published the summary on 16 September 2026.

The starting point is familiar to any treasurer. The team collected information by hand from different source systems, consolidated it in spreadsheets and then validated and adjusted it. Kozuki sums it up with a question: why were they spending so much time collecting data instead of analysing the result of the forecast? By the time the number was ready, the reality it was meant to reflect could have changed. In a humanitarian organisation, he recalls, the situation does not wait.

Two pressures were added to that. Since mid-2025, changes in donor support and budget cuts made history a less reliable guide for anticipating cash needs. And UNHCR’s headcount had shrunk without the workload falling in the same proportion. The forecast had to take into account future-dated transactions, historical trends, seasonality, currencies and changes in the operating environment: too many variables to keep going with a manual process.

This is not a project that starts from zero. According to an earlier EuroFinance article, in September 2023 UNHCR modernised its treasury management systems and bank connectivity and integrated them with its cloud ERP and the Digital Hub of Treasury Solutions (DHoTS), a treasury platform shared by several UN agencies with technical support from UNICC. That base of integrated data is what makes the next step possible.

Who does it and with what

• Protagonist: UNHCR’s treasury unit, with Kozuki as head and spokesperson for the case.
• Technology partner: the United Nations International Computing Centre (UNICC), which already managed bank, payroll, supplier payment and donor receipt information for UNHCR. That prior relationship settled much of the concern about data security.
• Data: accounts payable, future-dated purchase orders and almost ten years of history, plus scenario assumptions.
• Output: a cash forecast and an automatic dashboard with the charts and tables for management.
• What the source does not say: which type of AI model is used (statistical, machine learning or a language model), which tools it is built with, how much it cost or what forecast error it has. It is best not to fill those gaps with assumptions.

How they built it, step by step

The order matters as much as the pieces. Kozuki describes a deliberately iterative process in several phases.

1. Map the cash drivers and their sources

The work started with the data, not the model. The team identified the main cash flow drivers (among them accounts payable and future-dated purchase orders) and which system each one came from. Treasurers took part from the beginning: they helped define which questions the forecast had to answer, which cash flow categories were relevant and what level of accuracy was needed.

2. Normalise: decide which date is the cash event

This is where the most interesting problem in the case appeared. The different systems did not describe the same fact in the same way. A single transaction could have an approval date, an accounting date, a payment date, a date of receipt by the payee and a bank reconciliation date, and any of them could be used to place the cash movement in time.

To compare, in Kozuki’s words, apples with apples, the project became partly an exercise in data governance: deciding which fields mattered, setting common definitions and establishing which date represented the real cash event in each category.

3. Build the forecasting layer and automate the presentation

The resulting model combines current information with historical patterns. For the short term it leans more on ERP data, which is reliable because it reflects commitments already made; for the long term it uses historical trends adjusted to the budget conditions of the moment, plus scenario assumptions. The team also wanted the presentation to produce itself: instead of finishing the analysis and then building charts and dashboards by hand, the aim was to join collection, forecasting and visualisation in a single flow.

4. Run in parallel and earn trust

The biggest difficulty, according to Kozuki, was not convincing anyone that AI could process data, but getting treasurers to trust the result. “It can’t be a black box,” he says: the team has to understand how the model arrives at its figures because it is the one explaining them to management. That is why, for a while, the AI forecast coexisted with the manual one. The team compared both with actual data and saw where the model was more or less accurate. Responsibility remained human: AI produces the forecast, but treasurers review it and decide.

A concrete example for your team

The most replicable part of the case is not the model but the data dictionary that comes first. This table is an illustrative example of how a mid-sized treasury team might start; it is not UNHCR data.

Cash flow category	Source system	Date that rules	Horizon where it is used	Data owner
Supplier payments	ERP, accounts payable	Scheduled payment date	0–13 weeks	Accounts payable manager
Approved purchase orders	ERP, purchasing	Scheduled payment date according to terms	4–26 weeks	Purchasing
Payroll	Payroll system	Bank debit date	Whole horizon	Human resources
Customer or donor receipts	ERP, accounts receivable	Bank value date	0–13 weeks with data, then history	Collections manager
Taxes	Tax calendar	Bank debit date	Whole horizon	Tax

With that table agreed, the first pilot can be limited to two or three categories with clean data and a single currency, as Kozuki himself recommends when he says that today he would start with something smaller.

How to replicate it in your company

These steps are our adaptation of the lessons the source gives; they do not describe UNHCR’s internal system.

1. Choose the decision before the tool. Kozuki insists that AI is only a tool: first you need to know which decision you want to improve (short-term liquidity, timing of FX transactions, level of investments). That determines which data, which model and which controls you need.
2. Take an inventory of cash drivers. For each category, note which system it comes from, how often it is updated and how good its quality is.
3. Write the data dictionary before modelling. What counts as a forecastable flow, which date rules, how you treat currencies, how you record restricted funds and who answers for each field. It is what Kozuki says he would do even earlier if he started today.
4. Separate horizons. Use ERP commitments (registered invoices, approved orders) for the short term and adjusted history for the long term. Do not ask the model to guess what you already know.
5. Start with methods you can explain. A case from the same source illustrates it: at ASML, according to EuroFinance, the team tested twenty open-source Python algorithms against five years of actuals and retrains the model every month with a person reviewing its performance. What matters is not the algorithm but being able to explain why the result is what it is.
6. Run in parallel for several cycles. Keep the manual forecast while you compare both with actuals. Measure error by category and horizon, not just in total.
7. Automate the presentation. A dashboard that updates itself frees up time even if the model is not perfect.
8. Leave the decision and execution in human hands. UNHCR is exploring agents that suggest when to buy or sell currencies or place investments, but the transactions would be executed by people.

Stated results and their source

Item	What is stated	Type of data	Source
Work of collecting and consolidating data	Could fall by 40% to 60% once the model is stable	Estimate by the head of the unit	EuroFinance, September 2026
Preparation of charts and tables	Less effort thanks to the automatic dashboard	Qualitative statement	EuroFinance, September 2026
Use of the team’s time	Less time collecting and normalising, more analysing	Qualitative statement	EuroFinance, September 2026
Forecast accuracy	Not published	—	—

Kozuki stresses that the goal is not a perfect forecast but to make good decisions easier under uncertainty. According to him, seeing possible liquidity gaps and surpluses earlier helps decide precautionary balances and investment levels, and the conversation with management now centres on assumptions: which donor receipts are firm, which payments could be delayed and where risks appear.

Limitations and risks

• Evidence: it is a real case, but told by its protagonist at a conference and summarised by the organiser. There are no audited figures or error metrics.
• Incomplete process: the source acknowledges that it is not fully automated and that some data still needs human intervention.
• Dependence on context: UNHCR already had integrated treasury systems, almost ten years of history and a trusted technology partner. Without that base, the data effort will be larger.
• Less reliable history: the case itself arises because the 2025 funding changes made the past a worse predictor of the future. A model based on history needs scenario assumptions and human review.
• Connection cost: Kozuki points out that the main brake on integrating further with the ERP, including Workday, is the budget for connection costs, not technical capacity.
• Data security: treasury data is sensitive. UNHCR solved it by relying on a partner that already held it; other companies will have to go through IT security, as Cloud Software Group describes in the EuroFinance article on ASML.

Common mistakes this case helps avoid

• Starting with the model. Without common definitions, AI amplifies inconsistency instead of resolving it, Kozuki warns.
• Mixing dates. Using the accounting date in one category and the payment date in another produces timing gaps that look like model errors.
• Covering the whole organisation at once. A narrow pilot shows value sooner and builds trust.
• Dropping the manual forecast too soon. Without a comparison period against actuals you will not know where the model fails.
• Expecting AI to decide. In this case AI gathers, processes and presents; interpreting uncertainty and deciding remains the treasurers’ job.

Conclusions

The UNHCR case is valuable precisely because it is unspectacular. It does not promise an autonomous treasury: it shows that the biggest job is putting the data in order, agreeing which date rules and earning the team’s trust with a parallel period. AI comes afterwards, to remove hours of collection and build the dashboard, and leaves treasurers the part that really adds value: discussing assumptions and deciding. If you want to replicate it, the first deliverable is not a model but a table of definitions and a small pilot.