Talabat's treasury team: an n8n model for minimum cash per bank account, then a Claude Code agent for the daily pack

In two sentences

A corporate treasury team at talabat, the Middle East delivery company, first built a small n8n workflow that learns from daily bank balances how much cash each account really needs, and then its senior treasury manager used Claude Code to build an agent that assembles the daily treasury data, KPIs, dashboard and regulatory report from the ERP. It is a short first-hand account without figures, but it shows a sensible order of work: a statistical model you can explain first, and an agent that does the repetitive assembly second.

Who does it and why it is interesting

Bahaa Dawoud is Senior Treasury Manager at talabat in Dubai. In a September 2023 post he announced that he had joined the Delivery Hero talabat group in that role to build “the MENA Treasury hub”, after a long career in treasury at the retailer Majid Al Futtaim. talabat listed on the Dubai Financial Market in December 2024 and operates across several Gulf and Middle East countries, so its treasury deals with many bank accounts, currencies and local rules.

On 29 May 2026 he described, in a LinkedIn post, two pieces of automation built inside his team:

1. An n8n tool built by his colleague Noha Bashtar “a couple of months” earlier, to understand cash-flow behaviour across the group’s bank accounts.
2. His “first AI Agent”, built with Claude Code once the company enabled it, for “a specific Treasury project”.

Why it matters for this directory:

• It is treasury, not accounting. Most agent cases we see are about the close or accounts payable. Minimum cash balances and a daily regulatory report are everyday treasury work that rarely gets written up.
• The people who do the work built the tools. The post insists on that: “Rather than waiting for a one-size-fits-all external solution”, the team built “an internal layer”. Other talabat posts show this is a company-wide push, not a one-off.
• Two different tools for two different jobs. The forecast lives in a workflow tool; the messy multi-source assembly is handed to a coding agent. That split is worth copying.

The company context

The project did not happen in a vacuum. On 15 May 2026 talabat’s own LinkedIn page described an all-hands called “AI: but make it real”, with live demos, team use cases and governance, aimed at “making AI accessible for everyone across the business”. On 19 June 2026 Maha Gad, writing about talabat’s internal #FluentwithAIChallenge, reported 121 builds submitted in 45 days and said 96% of them came from employees with no coding or engineering background. And on 16 September 2026 Abdallah Mohsen, who presents himself as Assistant Finance Manager at talabat Oman, said he had spoken at the company’s AI Festival Oman about how the finance team built its own automation tools, “saving our team significant time every month, eliminating vendor costs”. None of these posts mentions the treasury agent; they show the environment that made it possible: access to Claude, training and permission to experiment.

What the two tools do

Piece 1: the n8n minimum-cash model

According to the post, the tool:

• analyses daily movements in bank balances;
• measures how balances vary within each month;
• highlights seasonality and cyclical trends “that the human eye may miss”;
• helps forecast “the minimum cash needed for each account to operate on a statistical basis”.

He does not say which statistics are used, how much history the tool reads, whether it calls an AI model or is pure calculation, or how the result is used (for example, to set sweep or cash-pooling targets). We therefore treat it as a statistical workflow orchestrated in n8n, not as an “AI” tool in the strict sense.

Piece 2: the Claude Code agent

The agent, in his words, “is connected to our ERP environment” and:

• pulls daily data “from multiple sources”;
• saves it in a structured project folder “with the right naming convention”;
• extracts it into spreadsheets, creates daily tabs and adds KPI layers for comparison;
• pushes outputs to a web-based dashboard;
• generates “the required daily regulatory report in a fraction of the time”.

He calls it “a lean enabling layer” on top of existing data and infrastructure. He does not name the ERP, the banks, the dashboard, the regulator or the report, and does not explain whether the agent runs unattended or whether he launches it and reviews each step.

Architecture as we understand it

The cover diagram summarises our reading. What is stated and what is our assumption:

Element	Stated in the post	Our assumption for replicating it
Data	Daily bank balance movements; ERP; “multiple sources”	Bank statements (MT940/CAMT or CSV exports) and ERP cash and payment reports
Forecast	n8n tool, statistical, minimum cash per account	Scheduled n8n workflow with a Code node computing percentiles
Assembly	Claude Code agent connected to the ERP	Claude Code in a dedicated folder, running small scripts with read-only credentials
Outputs	Spreadsheets with daily tabs, KPIs, web dashboard, daily regulatory report	Same, with a human checking the report before it is sent

How to replicate it, step by step

The following is our own proposal, built around what the post describes. Adapt it to your controls policy and your regulator.

Part A: a minimum-cash model in n8n

1. Collect history. Export at least 12 months of daily closing balances for each bank account, plus the account’s currency and its role (collections, payroll, suppliers, tax). Daily balances are enough; you do not need transaction detail for this step.
2. Compute net daily movement. For each account, today’s balance minus yesterday’s, with transfers between your own accounts tagged so they do not look like real outflows.
3. Choose the refill horizon. How many business days does it take to top up the account if it runs low (for instance, two days for an intra-group transfer)? The buffer has to cover the outflows during that window.
4. Bucket the month. Split days into buckets that match your business: start of month, mid-month, payroll days, tax days, month-end. This is where the “variation within each month” in the post comes in.
5. Compute a high percentile. For each account and bucket, take the cumulative net outflow over the refill horizon and compute, say, the 95th percentile. That is the proposed minimum balance. Flag buckets with few observations rather than trusting them.
6. Automate it in n8n. A Schedule Trigger node runs the workflow weekly or monthly, a node reads the balances (database, spreadsheet or file), a Code node does the calculation in JavaScript or Python, and a final node writes a table and emails or posts it to the treasurer.
7. Keep a person in charge. The workflow proposes minimum levels; the treasurer approves them and records any override (a known large payment, a bank holiday, a new country).

Part B: a daily treasury pack with Claude Code

1. Get permission and access right. Use the company-approved Claude plan, read-only ERP and bank credentials stored outside the folder, and data your policy allows the tool to process.
2. Create a project folder with fixed subfolders, for example inputs/YYYY-MM-DD/, work/, outputs/YYYY-MM-DD/ and scripts/. The post stresses the naming convention: decide it before the agent does.
3. Write a CLAUDE.md at the root that tells the agent the folder rules, the file naming pattern, the list of sources, the KPI definitions, the report template and what it must never do (post entries, send emails, change source files).
4. Turn each source into a small script. Ask Claude Code to write one script per extraction (ERP cash report, each bank’s statement, FX rates) and to test it on yesterday’s data. Scripts make the daily run repeatable; the agent writes and runs them rather than “reading” numbers freehand.
5. Lock permissions. In Claude Code’s permission settings, allow only the commands and folders the pack needs and deny everything else, especially writes outside the project and any network call you have not approved.
6. Build the workbook and the KPIs. One tab per day, the same columns every day, and a comparison layer (day on day, versus the minimum-cash level from Part A, versus forecast).
7. Publish to the dashboard from the outputs folder, not from the agent’s working files.
8. Generate the regulatory report as a draft. A treasurer checks totals against the bank and ERP balances, then submits it. Keep a log of each run and of every correction.

A worked example (illustrative numbers)

Imagine a supplier-payments account in one country, with a two-day refill horizon. Over the last 12 months, the 95th percentile of two-day net outflows is 1.8 million in the first week of the month and 0.6 million mid-month. The workflow proposes keeping 1.8 million from day 1 to day 7 and 0.6 million afterwards, instead of a flat 2 million all month, which frees cash mid-month for sweeping or paying down a facility.

The next morning the Claude Code run drops the ERP payment run, three bank statements and the FX file into inputs/2026-10-21/, runs the extraction scripts, adds tab 2026-10-21 to the workbook and flags that this account closed below its proposed minimum. The treasurer sees the flag on the dashboard, checks the regulatory draft against the bank portal and submits it. These numbers are invented for the example; the post gives none.

Results stated by the author

• On the n8n tool: “it already helped us reduce manual work, enable scalability, and accelerate forecast preparation”.
• On the agent: it generates “the required daily regulatory report in a fraction of the time”.

That is all. There are no hours, no accuracy measures for the minimum-cash forecast and no comparison with the previous process. Evidence level: experience — an identified professional explains what his team built, without verifiable figures.

Limitations and risks

• One post, one voice. The company posts confirm the AI programme, not this project. We have not seen the tools.
• Regulatory reports need controls. If an agent prepares a report for a regulator, someone must check it against source balances before submission, and you must be able to show how each figure was produced. The post does not describe the review.
• ERP access is the sensitive part. “Connected to our ERP environment” can mean many things. Read-only service accounts, logged runs and no credentials in the project folder are the minimum.
• Statistics are not a policy. A percentile-based minimum works on history; it misses one-off payments, new entities and stress events. The treasurer should own the final levels.
• Fragility. Bank formats and ERP report layouts change. Scripts need tests and an owner who is not on holiday the day they break.
• Shadow IT. Tools built by finance teams need a home: version control, documentation and someone in IT who knows they exist.

Common mistakes

• Letting the agent read numbers out of PDFs or screens instead of writing scripts that extract them the same way every day.
• Forgetting to remove transfers between your own accounts, which inflates “outflows” and the minimum cash.
• Computing one buffer for the whole month when payroll and tax days drive the real peaks.
• Submitting the regulatory report straight from the agent’s output.
• Giving the agent write access to the ERP “for convenience”.

Conclusions

The talabat treasury story is short on numbers, but its design choices are sound: a transparent statistical workflow for a question treasurers already ask (how much cash does this account really need?) and a coding agent for the daily assembly work that eats mornings. If you replicate it, keep the same order, keep every step reviewable and treat the minimum-cash output as a proposal that a person signs off.