By: Eleanor Hill
Agents and co-pilots dominated the conversation in Rome, but arguably the most revealing contributions at TAC Insights’ SAP for Treasury and Working Capital Management Conference came from corporate teams confronting the data, process design, governance, and human effort required before autonomy becomes safe, useful – or even entirely possible.
Autonomous treasury arrived in Rome as both a product vision and a strategic idea. Across three days of workshops, corporate case studies, and debate at TAC Insights’ SAP for Treasury and Working Capital Management Conference, the future being described was one in which agents would monitor exposures, gather information, recommend responses, and eventually carry out routine treasury activity within limits set by the organisation.
Yet the companies making the most credible progress weren’t talking primarily about replacing work with agents. Rather, their stories focused on the considerable effort required to make an operation coherent enough for a machine to act on it – consolidating information held across systems and spreadsheets, deciding where responsibility should sit, redesigning controls, testing new architecture, and persuading hundreds of people to change habits built over many years.
Thomas Mehlkopf, Head of the Treasury and Working Capital Management Centre of Excellence at SAP, and Arif Esa, VP, Treasury and Working Capital Management at SAP, framed the destination as connected, trusted, and autonomous, with technology progressing from information and recommendation towards execution.
But the sharper test arguably came when corporate treasury teams described what getting there involved. And the corporate case study sessions across the conference were packed with treasurers taking notes and asking excellent questions – all trying to learn and adjust to our emerging technology landscape, while still managing the day job.
Start with the problem
Amdocs offered one of the conference’s strongest examples of AI being applied to a recognisable treasury problem rather than introduced in search of a suitable use case (a not uncommon issue with ‘trendy’ tech – discussed at length in the coffee breaks).
Eleni Smila, Head of Treasury at Amdocs, and George Andreou, Treasury Director, joined Peddy Hashemi, Global Head of Customer Success at SAP Taulia, and Chris Garrison, Global Head of Payables Product at SAP Taulia, to discuss how the company is moving out of the experimentation phase with AI towards practical deployment.
The major challenge was that liquidity information arriving several hours later, or on the following day, was already too old for some of the decisions Amdocs needed to make. To help resolve the issues, the treasury team has (much to the delight of many in the audience) incorporated machine learning into working capital models, helping it anticipate where cash might accumulate in regions with trapped-cash structures and move that liquidity into its in-house bank more quickly.
Collection patterns can also be assessed against quarter-end free cash flow targets, directing attention towards customers whose payment cycles might push receipts beyond the reporting period. Rather than producing another forecast for treasury to interpret, the technology can identify where intervention might still change the result, which gives much greater strategic value and flexibility.
Payment approval offers a related AI opportunity for the company. Amdocs is exploring how an agent could give signatories immediate context around a transaction, including whether the amount, currency, and recipient are consistent with previous behaviour. An approver could then investigate an anomaly without first having to reconstruct the payment history manually.
Nevertheless, arguably the most tangible application sits within invoice issuance. When a billing milestone is reached, information currently moves between the business and invoicing teams, with discrepancies resolved through exchanges that can stretch across several days and time zones. The planned agent checks the milestone against the system, issues the invoice when the information agrees and routes a specific exception to the responsible business owner when it doesn’t.
Of course, it goes without saying that judgment remains with the person best placed to exercise it, while the administrative delay surrounding that decision is removed.
Joining the dots
Naturally, none of these applications could have progressed far while the relevant information remained scattered across systems, departments, spreadsheets, and individual knowledge. Defining which information is relevant, how it should be classified and what context has to accompany it forms part of the intelligence itself, rather than being a preliminary exercise completed before the interesting work begins.
After all, a model can’t distinguish between an insignificant omission and the missing signal that changes the decision unless the organisation has already understood the difference.
Amdocs has taken a similarly deliberate approach to skills. Instead of placing an automation specialist inside every finance function, it has created a dedicated data science team working across treasury, accounts payable, accounting, tax, and financial planning and analysis.
Domain specialists remain responsible for explaining the process, locating the friction, and challenging the result, without every treasury professional being expected to become a part-time developer. The structure also reduces the risk of a technical team producing a sophisticated answer to a question the business never needed to ask.
Garrison described corporate AI adoption as a progression from making fragmented information usable, through recommending a response, towards execution, where a system is authorised to act on the company’s behalf. Despite the pace of development around agentic AI, few treasury functions have reached that final stage across any substantial end-to-end process.
Producing an answer faster isn’t the same as assuming responsibility for what follows. Once a system can execute, incomplete data, an ambiguous policy, or a poorly designed exception route no longer weakens only the analysis; it can move the actual position of the company.
Nor can architecture resolve the human challenge on its own. Smila discussed the difficulty of moving an established workforce away from processes some employees might have followed throughout their careers. Roadshows, practical demonstrations, and direct exposure to the technology will generally do more for adoption than a mandate from senior management, since confidence in a new process has to be earned rather than instructed.
The same issue extends to people who haven’t yet joined treasury. Analyst-level work has traditionally shown junior employees how information moves through a function, where mistakes arise, and why a decision that appears obvious on paper often proves more complicated in practice.
Should AI absorb much of that work, companies will need another route through which future treasury leaders can acquire judgement. Otherwise, an immediate efficiency gain might be followed years later by a shortage of people with enough practical experience to assume senior responsibility.
Connection isn’t completion
The conversation then moved from internal processes to the banking and technology infrastructure supplying the information on which treasury decisions depend.
Michel Verholen, Assistant Treasurer and Head of Global Treasury Operations at Zoetis; Kamil Jellonek, Lead Treasury and Risk at Partners Group; and Lisa Davis, Managing Director at J.P. Morgan, brought a noticeably unsentimental (or perhaps just inherently practical) perspective to the relationship between integration and intelligence.
Zoetis is incorporating SAP S/4HANA Treasury into a wider company transformation, moving away from a standalone treasury environment and towards an architecture connecting the function more closely with forecasting, sales, and manufacturing. Multi-bank connectivity and advanced payment management form part of a more flexible model intended to avoid dependence on a single banking channel across every institution and market.
Partners Group has already built numerous API connections for bank balance information, although its experience underlines how little the presence of an API reveals about the value flowing through it. Banks remain at very different stages of connectivity maturity, and a service offered by one institution might simply not exist at another.
Jellonek also drew attention to a problem that receives considerably less executive excitement than AI – the everyday friction created by bank communication, inconsistent formats, and evolving payment requirements. Those obstacles continue to absorb time, introduce errors and frustrate standardisation, even while the industry discusses systems capable of autonomous execution.
Cash flow forecasting exposes the limitations of partial integration particularly starkly. Automating perhaps 60% of the necessary input, Verholen explained, doesn’t make a forecast dependable when the missing 40% might contain the development that changes the position entirely. Management can see a polished analytical interface and assume that the view is comprehensive, while treasury remains conscious of commercial developments, local intelligence, and timing changes that haven’t entered the system.
Sophistication in presentation can therefore increase confidence faster than it improves the underlying forecast – which is worrying to say the least.
Coverage percentages tell only part of the story unless they’re weighed against the importance of what remains outside. Ninety per cent of the available information offers limited reassurance when the remaining 10% contains the event that determines whether the business remains within its liquidity headroom.
The panel also showed why AI can’t be considered separately from the architecture surrounding it. A model might analyse the information it receives exceptionally well while still producing an incomplete answer because a bank, subsidiary, or commercial system hasn’t supplied the necessary input.
Their conclusion was that connection improves the view, but it doesn’t guarantee completeness, and the boundary of what the system can’t see needs to remain visible to the people relying on its output.
Scale removes shortcuts
Meanwhile, in a packed breakout room, Shell’s cash management transformation showed how those questions only continue to expand once technology has to work across a global organisation.
Stuart Graham, Deputy Global Head of Cash Management at Shell International, outlined the development of a unified, scalable cash management platform designed to bring a highly complex banking landscape into a more standardised operating model. The programme drew 35 ERP environments into the new set-up, connecting cash forecasting, payment processing, and banking activity rather than leaving each process to operate through its own combination of systems, spreadsheets, and local practices.
The journey began with a proof of concept in 2023, moved into design and build in 2024, and progressed through the ERP deployments between February and November 2025. Although the final rollout was still being stabilised, the new forecasting process was already giving Shell a more complete picture of cash, with greater automation replacing much of the copying and pasting previously required to assemble information. Analytics could then be applied to areas such as reconciliation, trends, and regression, with further opportunities to bring forward the signals that treasury receives and improve decisions beyond the immediate cash position.
Payments added another order of magnitude. Shell processes around 500,000 each month, with values running into billions every day, so its 99.5% straight-through-processing rate supports continuity at enormous scale rather than serving as a presentational efficiency statistic. The platform had to preserve that performance while accommodating different ERP environments, banking connections, and transaction volumes, with automation applied where the activity justified the investment rather than imposing one route on every account.
The proof of concept established whether the proposed technology could satisfy Shell’s essential requirements, but detailed design still took approximately six months. Strengthening the model early reduced the likelihood that later changes would affect the build, controls, communications, and training simultaneously.
While a successful pilot can show that a system performs a selected task under chosen conditions, it can’t determine who owns the wider process, anticipate every exception or predict how a thousand employees will respond once the technology becomes part of their everyday work.
At certain points, therefore, Shell’s programme involved a substantial cross-functional team spanning finance, IT, controls, and security. Around 1,000 users were engaged through staggered training aligned with their deployment dates, rather than a single company-wide exercise delivered months before employees needed to apply what they had learned.
Future users participated in testing, allowing familiarity and feedback to develop before go-live. Governance stretched from regular operational discussions through weekly reviews to steering-committee oversight, while the programme continued to accommodate changes in entities, responsibilities, and personnel during implementation.
The resulting benefits reach well beyond the removal of manual data handling. Cash information is more complete and better standardised, payment flows are increasingly automated, controls have been consolidated, and ownership has become more explicit.
Encryption and tamper-resistant invoice processes have also allowed Shell to reconsider where payment authorisation belongs. Once an approved invoice can’t be altered before payment, treasury doesn’t necessarily need to perform another version of the same check. Manual payments still exist, but responsibility for initiating them can sit with the accounts payable, tax or finance team that owns the underlying transaction, supported by the relevant authority before cash management provides the final control.
Graham pointed out that technology achieved much more than simply accelerating Shell’s existing process. By joining forecasting, payments, and banking activity within a common platform, it forced the organisation to decide where work should sit, what an approval signifies, and who remains accountable when something goes wrong.
That operating model is what ultimately gives automation a safe foundation to build on and develop from.
Speed widens exposure
Once treasury technology starts crossing organisational and system boundaries, execution can’t be separated from resilience, either. And this was another message delivered loud and clear in Rome.
Dr Ruth Wandhöfer, whose career spans payments, banking, regulation, academia, and cyber security, placed treasury at the centre of several converging forces: real-time payments, AI, digital money, and a threat environment increasingly shaped by the same technologies companies hope to use defensively.
She explained how control over cash, bank relationships, liabilities, and payment execution makes treasury strategically important and an attractive target. And while the much sought-after prize of greater connectivity expands what the function can see and do, it also deepens its dependence on external systems and providers, she cautioned.
What’s more, third- and fourth-party exposures become particularly significant when a bank or fintech supplies the visible service but relies on another company’s model, cloud platform, data environment or security layer underneath. A diversified list of supplier names might still rest on surprisingly concentrated infrastructure.
Resilience has to progress alongside automation, with the ability to identify, contain, and reverse abnormal activity keeping pace with the speed at which legitimate decisions are executed.
Indeed, my own keynote at the conference approached the subject through the fault lines forming beneath money and financial infrastructure, including dollar dependence, digital assets, delegated machine authority, and provider concentration. A separate article will examine those themes in greater depth, although one principle carries directly into the autonomy debate – keeping a human in the loop doesn’t actually guarantee meaningful human control.
For example, an approver who receives only the final recommendation might technically remain involved while lacking the context needed to challenge it. Effective oversight depends on knowing which sources an agent used, what it was allowed to remember, whether its assumptions changed and why it selected one course of action over another.
A person can’t supervise reasoning they’ve been excluded from. And that’s a key point to bear in mind when designing agentic processes.
Earn the authority
Elsewhere on the TAC Insights programme, Pandora examined the creation of a unified banking, liquidity, and treasury foundation; JTI and Zanders explored predictive cash forecasting; NYK discussed its move from legacy infrastructure to the public cloud; and ČEZ shared its S/4HANA transformation journey. Other sessions considered working capital, real-time payments, fraud prevention, digital currencies, and in-house banking.
No single company was moving at the same speed across every process, nor should that be the expectation. Autonomous treasury is more likely to develop unevenly, with tightly bounded decisions delegated only once the information, as well as responsibilities and controls surrounding them, justify the additional authority.
Building and refining the AI model itself is rarely the only constraint and often isn’t the most difficult one. Fragmented data, unresolved ownership, uneven bank connectivity, incomplete forecasts and human resistance can stall progress long before the technology reaches its limits.
That said, treasury teams shouldn’t wait for every foundation to become perfect before experimenting, since perfection never comes – but time, tech, and business march on. Equally, AI can’t be poured over ambiguity in the hope that intelligence will compensate for the disorder underneath.
A much more sustainable route begins with a decision worth improving, then traces the information and dependencies shaping it, exposes what remains unknown, resolves who owns the process – and designs for the exceptions (including a manual handbrake). Only then should the system’s authority expand, once the organisation can explain what the tech is doing, understand exactly why and how, and intervene when the result no longer makes sense.
The good news is that autonomous treasury will eventually mean considerably less human intervention in routine execution. But getting there safely remains a profoundly human undertaking.
