Disclaimer: these thoughts, while backed by a number of interactions I regularly have with CFOs from our VC & PE portfolio and founders, are by definition limited — but more than happy to discuss and be challenged!
A lot has been written on why many of SaaS‘ traditional moats have been weakened by Anthropic’s recent progress. Earlier this year, more than $1Tr of market cap was erased from software stocks in a few days following Claude Cowork’s new releases.
It was broadly similar on private markets. Over the last 12 months, a huge chunk of venture funding has been carried by “AI-native” deals, mostly by a few hyperscalers and frontier labs (OpenAI, Anthropic, Kimi, AMI…). Let’s just say that it is harder than ever to compete in investment committees against those deals.
CFOs are wrongly generalized as conservative buyers only — I think they’re just being pragmatic.
Most CFO offices I’ve spoken with (large scale-ups but also traditional businesses) have undertaken a massive overhaul of their technology operations and have implemented newer solutions.
They’re just looking for a couple things in the age of AI:
It is fair to say finance is inherently risk averse. If a salesperson sends a bad email, it’s not a great look. But financial errors can result in serious consequences (terminations, lawsuits, immediate P&L loss), not just operational inefficiencies. And if AI can only deliver 80–90% reliability, a CFO will likely see it as a copilot for ad hoc analysis, not as the system of record for planning & reporting, or to reconcile invoices & bank statements, to keep track of one’s balance sheet…
It needs to be reliable but it also needs to be auditable. Claude might do wonders on your excels, but explaining to an auditor why and how it calculated accruals that way is another story. Not to get too technical, but on a data standpoint with classic REST APIs, each call returns a structured HTTP code, telling you if the query has been successful, rejected, if the server crashed.. MCPs are structurally different as you cannot build a reliable audit trail. The protocol exists to easily expose tools to an LLM, not to guarantee production-level reliability — or detect when an agent failed yet thinks it succeeded.
At the same time for some tasks, using LLMs feels like using a sledgehammer to crack a nut.
When your process is quite stable, data is clean and exceptions are low — you don’t really need an LLM. That comes on top when you get a high variability of inputs (e.g a vendor with 47 different formats of invoices), nuanced decisions that require context, process changes (e.g new payment terms every month). Just like when I see Claude burning my tokens to do a basic sensitivity analysis on excel, we have to remember CFO offices operate in the same financially constrained environment than the rest of the company and will optimize for whatever does the job at the best price possible.
All in all, I believe this bias towards reliability, governance and pragmatism further reinforces the role of structured platforms like Abacum or Embat, that also produce strong embedded gen AI. Abacum is deterministic by design, the same inputs generate the same outputs — you get a 100% reliable base, on which to build AI workflows. AI compresses the marginal cost of onboarding (suggestions, mapping, categorization) but the remaining 15–20% audit correctness remains as hard as before.
For CFOs, AI adoption is really a long game. Embat perfectly understands that — building trust through each layer of their product. It infuses its product with AI at every level, from a silent mode (e.g on accounting processes, executing autonomously) to a guided mode (e.g on cash management & forecasting, where you still need a human to validate recommendations) and ask mode (e.g on payment execution). It is building trust and confidence to evidently automate most of it in the near term.
I might be old school on this one, but I really believe solve-it-all AI companies have, so far, typically created more confusion rather than clarity. Implementing a horizontal AI app provider, and skipping the critical work of cleaning, mapping & modeling data usually leads to catastrophe — a founder of a very large french scale-up recalled he had a ~50% error rate on financial querying.It is largely consensus at this point, but AI is only as good as the structured data it receives. That’s why Abacum or Pigment’s semantic work of normalizing and harmonizing financial data across every system and defining metrics universally across every tool (ERP, CRM, BI, HRIS, Spreadsheet..) is both critical and underrated.
Without the semantic layer, the model guesses the previous steps. That’s why Abacum becomes the prerequisite infra for any AI layer on top. A purely Claude-like interface could be a query engine, create ad hoc tables and charts, and export things to Excel, but 1) Excel breaks at some point and most of all 2) this risks recreating the same chaos that FP&A platforms were built to solve. This scenario seems highly unlikely for finance teams that need governance, auditability, and structured collaboration.Connections & integration themselves are hard to build, and IMO an underestimated moat in CFO Stack software. API connection is one thing, but integrating business logic is a whole other pickle entirely as there is no NetSuite or SAP or whatever “standard” solution. Every instance is configured differently (custom fields, custom segments, custom record types) and two customers using the same ERP can look very different.Taking the example of Embat, when a payment is initiated:
And the list goes on for every financial object, all with different states; on journal entries, payments processing etc. Then you need maintenance, as APIs change, customers re-configure their ERP, and integrations can break silently.AI does significantly speed-up the human in the loop work (cleaning & normalizing columns) but does not for now remove the deterministic reconciliation requirement — and it’s too early to put a probabilistic layer in charge of deciding whether $2M reconciles or not…
Same goes for banking connectivity — PSD3 or Open Banking frameworks won’t get you very far (with low data granularity, and 0 incentives on the banks side to do better), tier-1 banks might have good APIs (to handle real-time payments, mass volume, status update) but most of the time you have to build manual connections handling different formats and probably getting to the bottom priority of the bank IT — resulting in 1–2 months go-live periods. That’s where Kyriba has probably built its strongest moat (having a catalog of +80,000 formats) and where Embat has shined early on.
Most software has the ambition of bundling adjacent capabilities. While LLM agents have a tendency to break feature bundling, as prompts can replace smaller add-ons — CFO stack companies have natural expansion avenues that can provide additional lock-in. The majority of it revolves around financial services, where compliance and license requirements create natural barriers to entry (which is pretty ironic considering pre-gen AI, regulatory concerns long acted as scarecrows in the venture industry).
Claude or ChatGPT makes it easier to handle compliance processes, but it changes absolutely nothing as to how hard it is to get an Electronic Money Institution (EMI) license, or a credit license, or even a MiCA/Vara license when touching web3.0 (like Flowdesk that we happily backed a few years ago).
That was one of our bets when partnering with Embat. The company recently started deploying EmbatOne, offering payment accounts to their customers. As a company, on your non-core markets or pure cost-centers, it removes the need to open a local bank account (which can take weeks), and makes it instant to open accounts in 30+ currencies, while remaining in the TMS environment (i.e embedded in you financial workflows). Not only does it enable 10x better UX on collections, holding and payouts, but it also adds yet another layer of complexity to the overall offering. So far, Embat has been leveraging Airwallex’ infrastructure and network, but once the company’s payment business becomes large enough, it’s completely conceivable to acquire its own license.
Our thinking is that when software starts processing payments, originating loans or settling trades, LLMs have no real effect — they’ll improve UI but not the rails themselves.
If you do the CFO stack right, you get way more barriers than meets the eye.
While this piece focuses mostly on 3 points, it goes without saying that we also believe the market opportunity is huge (40–50% still being greenfield on SMB & Mid Market globally..). The timing is right as many CFO offices are revamping operations or upgrading from Excel. Done right, you can tap into predictive tasks leveraging proprietary aggregated data… The list goes on & on.
Building in the CFO-stack area? Lets talk.
Disclaimer: these thoughts, while backed by a number of interactions I regularly have with CFOs from our VC & PE portfolio and founders, are by definition limited — but more than happy to discuss and be challenged!
NEWS