Daily Cash Position: One View Across Banks and Entities

A reliable daily cash position should be the first thing a treasurer sees each morning, yet in most multi-entity groups it is still assembled by hand from bank portals, emailed statements and spreadsheets. By the time the figure is ready, the morning's funding and payment decisions have often been made on yesterday's guess. This article explains where the data comes from, how AI agents collect, normalise and classify balances and flows across banks and entities, and which controls make the result trustworthy. It also covers how to roll it out without a large treasury system project, and where the extra effort is not worth it.

1. What is a daily cash position, and why is it hard to produce?

A daily cash position is the consolidated view of how much cash the group holds this morning, where it sits, in which currency and entity, and what is due to move in and out today. It differs from a forecast. The forecast looks weeks ahead; the position answers a narrower question: can we fund today's payments, and where is idle cash we could sweep, invest or use to repay a facility? Treasury needs that answer before the payment cut-off, not after lunch.

The difficulty is rarely the arithmetic. It is collection. A group operating across several countries usually banks with a mix of global and local institutions, each with its own portal, file format and timing. Someone logs into each portal, downloads balances, pastes them into a workbook, converts currencies at whatever rate is to hand and emails the result. Every step is a chance for a missed account, a stale balance or a formula that broke when a new account was opened. The figure looks precise and often is not.

2. Bank statement aggregation: where the data comes from

Bank data reaches treasury through several channels, and most groups use all of them at once. Larger banks send end-of-day statements as SWIFT MT940 or ISO 20022 camt.053 files, with MT942 or camt.052 messages supporting intraday cash reporting. Some offer APIs that return balances on request. Smaller local banks may provide only a portal download in a spreadsheet format, or a PDF statement sent to a shared mailbox. Each channel carries different detail and arrives at a different time of day.

The ERP supplies the other half. Approved payment runs, payroll files, expected customer receipts, intercompany settlements and FX deals booked in the treasury module all describe cash that will move today, even if the bank has not yet seen it. A daily cash position built only from bank balances tells you what was there last night. One that adds these known items tells you what you will hold at the end of the day, which is the figure funding decisions actually depend on.

Take a distribution group with entities in Dubai and Riyadh and a holding company in the UK. The UAE and Saudi banks publish statements on their own schedules, working weeks and public holidays differ across the region, and the UK bank's files arrive overnight from another time zone. A manual process copes by waiting until everything is in. An agent-based process records which statements have arrived, flags which are missing, and shows the position with that gap made explicit rather than hidden.

3. How agents consolidate cash visibility across banks and entities

Multi-entity cash consolidation works best when the job is split into narrow agent roles. A collection agent retrieves statements from every channel on a schedule, including PDF statements and portal exports with no structured format. A normalisation agent maps each file to one data model: account, entity, currency, value date, amount and description. A classification agent assigns each flow to a category such as customer receipts, supplier payments, payroll, tax, intercompany or financing. Underneath sits the bank account master. An account missing from the master is missing from the position, so agents raise an exception for any unknown account number instead of dropping it or guessing its entity.

This is where domain-trained finance AI agents earn their place over scripts. A rules-based parser breaks when a bank changes its narrative format or a new local bank is added, and someone has to fix it before the morning report can go out. An agent can read the new layout, propose a mapping and send it to a treasury analyst for approval, so the change is controlled and recorded instead of patched in a spreadsheet at seven in the morning by whoever happens to be in first.

4. From balances to a position: adding today's known flows

Treasury cash positioning starts with the right opening figure. Ledger balance, available balance and value-dated balance can differ, especially where card settlements, cheques or incoming transfers are in float. Agents should carry all three where the bank provides them and use the available or value-dated balance for funding decisions. That choice needs to be documented and applied consistently, so nobody compares a ledger balance at one bank with an available balance at another and draws the wrong conclusion.

Then come the day's known items. The agent pulls approved payment runs from the ERP, payroll scheduled for today, tax payments, loan repayments, FX settlements and intercompany sweeps, which only tie out cleanly when intercompany reconciliation is already under control. Each item is tagged with its source and confidence. A confirmed outgoing payment is not the same as a customer promise to pay, and the position should show that difference rather than netting everything into one optimistic number.

The result is a projected end-of-day balance per account, entity and currency, converted to the group reporting currency at a stated rate. The same classified data is the natural starting point for a rolling 13-week cash forecast, because yesterday's actual flows by category are what any forecast has to be built and tested against. In practice, building the daily position first and the forecast on top of it works better than trying to do the reverse.

5. Controls that make the number trustworthy

A daily cash position that treasury doubts is worse than none, because people quietly go back to their own spreadsheets. Trust comes from a small set of checks that run every morning before anyone sees the figure. Completeness: every account in the master has reported. Continuity: today's opening balance equals yesterday's closing balance for each account. Reasonableness: no balance has moved far outside its normal range without a matching known flow to explain it.

Each failed check becomes an exception with a stated reason, routed to a named person. The agent does not fill a missing statement with yesterday's figure and carry on; it shows the account as stale, with the age of the last balance received. A person reviews the exception, adjusts or accepts it, and the decision is logged alongside the original data, so an auditor or the CFO can see exactly how the morning figure was produced and who signed off each judgement.

These checks are distinct from bank reconciliation, which matches bank transactions to ledger entries after the fact, but the two draw on the same normalised statement data. Getting the statement feed right for cash visibility usually makes reconciliation easier as well, because the hard part of both is clean, complete and well-described bank data. Teams that treat them as separate projects often end up building the same statement parsing twice, with two slightly different answers.

6. How to build a daily cash report without a big treasury project

Start with the accounts that hold most of the group's cash, which in many organisations is a short list of relationship banks. Connect those properly through host-to-host, SWIFT or API, prove the consolidated position against what treasury already reports, then add the long tail of local accounts. Chasing real-time balances for every low-activity collection account is rarely worth the integration effort; a reliable end-of-day file is usually enough for those.

Resist the urge to start with the dashboard. A polished Power BI page on top of incomplete data simply moves the doubt to a new screen. Put the effort into the account master, the statement feeds and a governed data layer on Microsoft Fabric or a similar platform, so the position, the forecast and reconciliation all read from one source. Agents then work inside the systems treasury already uses, such as SAP, Oracle or Microsoft Dynamics 365, rather than replacing them.

AITHENTIC builds this capability as agents with a defined role, decision rights, escalation logic and a full audit trail, which matters more in treasury than in most areas because the output drives payments. Whatever the delivery route, the principle holds: agents prepare and check the position, and people decide where cash moves. Agents that can initiate transfers without approval are a design option most treasury teams should decline.

Key challenges

• Bank data arrives in different formats, channels and times across banks and countries.
• Incomplete or ungoverned bank account masters leave accounts out of the position without anyone noticing.
• Manual spreadsheet consolidation introduces stale balances, wrong FX rates and broken formulas.
• Ledger, available and value-dated balances get mixed without a stated basis.
• Known payments and receipts sit in the ERP and never reach the morning figure.

The framework

A practical operating model has four layers. Connectivity: every account reports through the best channel available, from SWIFT and bank APIs to governed portal downloads and PDF reading. Data: statements are normalised into one model tied to a governed bank account master on a shared data layer. Agents: collection, normalisation, classification and position agents each have a narrow role, defined decision rights and an escalation path. Control: completeness, continuity and reasonableness checks run before the figure is released, exceptions go to named treasury staff, and every adjustment is logged. Treasury owns the account master and the release of the position; the agents own its preparation.

How to implement it

1. Build and govern a complete bank account master that links every account to an entity, currency, bank, purpose and owner.
2. Rank accounts by typical balance and connect the largest banks first through SWIFT, host-to-host or API.
3. Normalise all statements into one data model and agree the balance basis treasury will use for funding decisions.
4. Add today's known flows from the ERP, tagging each item with its source and confidence.
5. Switch on completeness, continuity and reasonableness checks with exceptions routed to named people.
6. Run the agent-built position alongside the existing manual report until treasury trusts it, then retire the spreadsheet.

Frequently asked questions