laptop

There's a comfortable delusion taking root across mid-market and enterprise finance departments. It's fuelled by the rapid evolution of AI models, and it's usually a version of this: 'We have Claude. We have ChatGPT. We have our live data hooked up to our ERP. We're all set!'

It is an intuitive argument but it's an operational trap that leads, at best, to a derailed pilot and, at worst, to mistaken decisions. Organisations are treating advanced AI tools as systems of record, when in reality their outputs are often castles built on sand.

This is reflected in recent findings, with Gartner reporting last year that AI adoption among CFOs has flattened as teams struggle with data quality and a lack of necessary technical skills. AI can't become trusted corporate infrastructure while it floats freely over disorganised source data or chaotic ERP pipelines.

It must be built on a finance-governed data layer; otherwise finance execs are just engineering a much faster way to generate chaos.

According to KPMG and others, that foundational layer is an AI finance operating system.

The second problem is people. I'll come back to it, because it's the one most finance leaders underestimate.

Why DIY Doesn't Deliver

Armed with an ERP and a powerful AI model, teams often think they're ready to generate finance-grade outputs.

However, they almost always hit the same brick wall: an inability to create a repeatable, auditable process, month in, month out.

I know the frustrations because I've heard them many times: hallucinated outputs, spiralling token costs, and more time spent checking responses than the team saved in the first place.

A financial model is a complex system. The real challenge happens when operational variables disrupt the clean data environment: mid-quarter reorganisations, metric conflicts, and late journal entries. When these shift in an unstructured AI environment, last month's work essentially vanishes.

AI models are designed to vary their answers each time. Yet, if you can't ask an AI tool the exact same question a week apart, introduce one minor data change, and generate a matching baseline response with a clear audit trail, you don't have finance-grade output because you don't have an AI finance operating system.

The 'AI Maintenance Tax' and Defining the Data

When leadership realises that standalone models struggle to navigate unstructured corporate tables independently, they assign data engineering teams to build a custom bridge. This introduces the AI Maintenance Tax.

Corporate accounting logic isn't static. Account mappings change, intercompany eliminations evolve, and allocation methodologies shift to match new strategic goals. In a setup where the AI is wired directly to raw data, the finance function becomes completely dependent on engineering to manage these shifts. Every minor adjustment requires opening a ticket, leaving finance waiting in line just to view their own numbers.

What's more, this structural ambiguity triggers a significant financial penalty in the form of runaway AI costs. When an AI tool is forced to read raw data tables directly, it has to figure out their structures and guess business intent on every single prompt.

Every time the model re-learns business logic from scratch, the company's paying for it. Those costs compound quickly and show up as a line item that's hard to justify to the board.

The fix is the business logic layer (known as a semantic layer) KPMG and others are talking about: one place where revenue definitions, allocation rules, and performance metrics are locked in before any AI tool is permitted to read them. Finance owns it and engineering doesn't need to touch it.

This layer takes chaotic, fragmented data and locks in an organisation's specific business logic before any AI tool is permitted to read it. By resolving definitions upstream, companies can fundamentally alter how the AI operates. The model is no longer required to do the heavy lifting of guessing what the data means; it is simply required to reason over safe, pre-verified financial figures.

This approach yields immediate operational advantages. Hallucinations drop because the model simply has far fewer places to go wrong; costs fall because prompts no longer need to re-explain the business every time; and finance regains direct ownership, adjusting mappings without opening a single engineering ticket.

This is why we built FinanceOS at Datarails. A semantic layer is one part of it. Underneath sit the consolidation logic, permissions and audit trail that let finance trace any AI answer back to the source transactions, so every application, report and AI tool the team uses works from the same governed numbers.

The Skills Gap Is the Other Half

A governed foundation solves Gartner's first problem. It does nothing on its own for the second. Most finance teams don't have the technical skills to turn that foundation into working AI agents and workflows, and they can't be expected to grow them in a quarter.

The usual response is to borrow engineers from IT or hire a data scientist. It rarely holds. A generalist engineer can wire a model to a database, but they don't know why an intercompany elimination matters, how the allocation logic changed last quarter, or which version of gross margin the board sees. Finance ends up explaining the business to engineering, and the project moves at the speed of that translation.

The tech industry already has a better model. AI companies such as OpenAI now place forward-deployed engineers inside customer organizations, so the people building the solution sit with the people who will use it. Finance needs the same approach, with one change: the engineers have to be finance people first.

At Datarails, we call them Forward-Deployed Financial Engineers (FDFEs). They come from finance, and they work alongside a customer's team to turn its processes, data and requirements into agents and workflows that run on FinanceOS.

Put the two together and both of Gartner's problems get addressed at once. Every workflow an FDFE builds inherits the consolidated data, shared definitions and permissions finance has already set. And the team gets those workflows without first having to become engineers. When the person building the agent already understands how the close works, what gets built is something finance can own and run every month.

Towards a More Mature Corporate Conversation

The corporate conversation surrounding AI needs to mature. Spending hours debating whether Claude or ChatGPT writes a better variance summary is focusing on the wrong side of the equation.

The key question is how to get the data ready in terms of quality, consolidation, context, and governance, and who will build on it once it is.

Connect AI directly to a data warehouse and you'll get numbers without finance logic. Connect it directly to an ERP and you'll get transactions without consolidation, planning context, or company-specific metrics. Neither understands how finance reports the business. AI fills those gaps with generic assumptions instead of the company's own definitions.

But anchoring world-class reasoning models to a permanent, controlled AI finance operating system gives the technology a home, and putting finance-fluent engineers alongside the team gives it builders who understand the business. Together they allow finance teams to transition away from being prompt librarians managing temporary chat windows, to becoming architects of a scalable, auditable, powerful and intelligent system that serves their needs.

That's the only way to ensure that even the smartest models hold up when it counts: at month-end, quarter-end, and year-end.

–

Didi Gurfinkel is the Co-Founder and CEO of Datarails, the AI finance operating system for the CFO's Office. He previously served as a Director and GM at Cisco. Under his leadership, Datarails has emerged as one of the fastest-growing companies in its space, being named the #1 Most Promising B2B Startup by The Information, as well as a Newsweek AI Impact award winner.