Why Treasury Will Be the First Back-Office Function to Go Fully Autonomous

Every CFO I've spoken to in the last year has an AI strategy. Or at least a slide deck that says they do. The typical plan starts with FP&A, moves to compliance, maybe touches procurement. Treasury barely gets a mention.

This is backwards. After seven years running treasury operations across 10 European markets at a €2.3B company, managing a €2B receivables portfolio, and spending the last year building AI agents for financial operations, I'm convinced that treasury will be the first back-office function to go fully autonomous. Not partially automated. Not "AI-assisted." Autonomous.

Here's why.

The Autonomy Trifecta

For any function to go fully autonomous, it needs three properties: the work must be repetitive, rule-based, and high-stakes enough to justify the investment. Treasury is the only back-office function that scores perfectly on all three.

Repetitive at industrial scale

Treasury operations are overwhelmingly pattern-matching. Cash application: match incoming payments to outstanding invoices. Collections: identify overdue accounts, determine the right communication cadence, send reminders. Cash forecasting: aggregate historical collection behaviours, apply them to current receivables, predict future cash positions. I personally managed a process where we tracked collections cohorts month by month, calculating what percentage of each invoice vintage was collected at 30, 60, 90, 120, and 150+ days. Every single month. Across 10 countries. The same structure, the same logic, the same patterns.

Rule-based with definable exceptions

This is the critical distinction that most AI strategists miss. Treasury isn't just repetitive; it follows explicit rules with a finite set of exceptions. When you receive a payment that doesn't match an invoice exactly, there are perhaps 15 common reasons: partial payments, early payment discounts, currency rounding, consolidated payments across multiple invoices, tax withholdings, bank fees deducted at source. I've seen all of them. They look messy at first, but they're classifiable. And once classified, the resolution follows a predictable path.

Contrast this with FP&A, where "analyse why revenue is down 12% in Germany" requires contextual business judgment that changes every quarter. Or with compliance, where regulatory interpretation requires legal nuance. Treasury exceptions are structured exceptions. That's exactly what AI agents handle well.

High-stakes economics

A single day of improvement in Days Sales Outstanding across a €2B receivables portfolio is worth roughly €5.5M in freed working capital. When I reduced overdue debt from €100M to €15M, the impact on the company's credit facilities, securitisation capacity, and investor narrative was immediate and material. Treasury automation doesn't just save FTE costs; it releases capital that was previously trapped in operational inefficiency. That's a CFO's dream ROI case.

Why Current "Solutions" Aren't Enough

The enterprise treasury software market (HighRadius, Kyriba, Coupa Treasury) has existed for years. These platforms are good at what they do: workflow automation, straight-through processing for clean matches, dashboard reporting. But they have a fundamental limitation: they automate the easy 70% and leave the hard 30% to humans.

The hard 30% is where most of the value is. It's the partial payment from a client who paid three invoices with one transfer and deducted a credit note you haven't processed yet. It's the payment that arrives in a different currency than expected because the client's treasury team decided to net across entities. It's the €25M discrepancy you discover when your forecast model assumes a simple average of historical collection behaviours but ignores seasonality and partial payment patterns.

I found that exact discrepancy. The root cause was threefold: the model was forecasting collections rather than actual cash-in, target behaviours weren't seasonally adjusted, and partial payments were falling through the cracks. Traditional software would never have caught it because it wasn't a data quality issue. It was a methodology issue. Fixing it required understanding how weighted moving averages with recency bias outperform simple averages for collection behaviour prediction, and why seasonal indices need to be calculated per bucket, not globally.

This is exactly the kind of problem where an AI agent, properly designed, outperforms both legacy software and manual processes.

The Autonomous Treasury Stack

Based on what I've built and what I've seen working, the autonomous treasury stack has three layers:

The key insight is that Layer 2 doesn't replace Layer 1. It complements it. Enterprise platforms are excellent at structured automation; AI agents are excellent at unstructured reasoning. The combination is what gets you from 70% automation to 95%+.

Why Operators Will Build This (Not Technologists)

The biggest risk in autonomous treasury isn't the technology. It's building the wrong thing. I've watched technologists design "intelligent" collections systems that send automated dunning emails based on days overdue. Anyone who has actually called a debtor knows that timing a collections call is about understanding the client's payment cycle, their internal approval process, their relationship with your sales team, and whether they're consolidating invoices this month. Days overdue is one input among twenty.

The best AI products in treasury will be built by people who have sat in the operations chair. Who have reconciled cash at 2am before a board meeting. Who have explained to a CFO why the forecast was off by €25M. Who know that the real bottleneck in collections isn't sending emails; it's knowing which emails to send, to whom, and when.

That operational intuition can't be learned from a product requirements document. It can't be specified in a user story. It lives in the judgment of people who've done the work.

Timeline: Faster Than You Think

The technology for autonomous treasury exists today. Large language models can reason about payment discrepancies. Tool-calling agents can query ERP systems, match invoices, and draft resolution emails. The cost of running these agents is dropping quarterly.

What's missing isn't capability. It's product design: someone who understands both the operational reality and the technical possibility, who can design the right level of autonomy for each sub-process, who knows where to keep humans in the loop and where to let the agents run.

My estimate: within 18 months, the first companies will have 90%+ autonomous treasury operations for standard receivables management. Within 36 months, the competitive advantage of having a fully autonomous treasury function will be so clear that every company managing €500M+ in receivables will be building or buying one.

The question isn't whether treasury goes autonomous. It's who builds it first.