There’s a question circulating in many organisations right now, and it arrives as often through the board as it does through the CFO’s own curiosity: “Are the finance folks using AI?”
It’s the wrong question, and the fact that it keeps getting asked at this level of abstraction is responsible for most of the bad AI adoption decisions currently happening in finance. The question treats AI as a single category of thing when it is, in practice, several very different categories of things that happen to share a name. A probabilistic language model generating a narrative summary of your quarter and a deterministic system calculating MRR from a fixed formula applied to your warehouse data are both “AI” in the same way a scalpel and a bandage are both medical tools. What determines whether you should use either of them isn’t the category. It’s what the output is being used for, who sees it, what they do with it, and what the cost of an error is.
In this article, we aim to provide a practical framework for answering the more specific question that the binary one (“are we using AI?”) keeps obscuring: for any given finance task, which properties does the tool handling it need to have, and how do you verify that a vendor actually has them?
A note on what this piece isn’t: this is not a guide to finding the best AI tool for finance. There’s no scoring table at the end, no vendor ranking, no recommendation that’s actually a thinly disguised product pitch. The framework applies regardless of which tools you’re evaluating, and it’s designed to be used before the first demo, not after it.
Why the binary question produces bad decisions
When finance leaders approach AI adoption at the category level, they tend to end up in one of two failure modes.
The first is blanket resistance. The logic is reasonable on its surface: if AI can hallucinate, and finance requires accuracy, then AI has no place in finance. The problem is that this conflates a property of some AI systems (probabilistic output generation) with all AI systems, including the deterministic ones that have been running quietly inside most finance tech stacks for years without anyone calling them AI. Resistance calibrated at the wrong level of abstraction keeps out tools that would be genuinely safe while offering no protection against the ones that wouldn’t.
The second failure mode is blanket adoption, which runs the same conflation in the opposite direction. If competitors are using AI and it’s working for them, the reasoning goes, the risk of not adopting outweighs the risk of adopting. Tools get brought in on the strength of a demo and a reference call, evaluated primarily on surface criteria (integrations, UI, price), and deployed into workflows that never got a serious reliability audit. This is where the real risk lives, not in the resistance camp.
What drives both failure modes is the same thing: the evaluation is happening at the wrong level of abstraction. The right level is the task, not the category. Not “should we use AI?” but “for this specific output, going to this specific audience, with this specific accountability requirement, what does the tool handling it need to be able to do?”
The five criteria below are how you answer that.
Five questions every finance task needs answered before AI touches it
Any finance task being considered for AI automation calls for five pieces of information first. These aren’t gatekeeping criteria for rejecting AI outright. Rather, they determine how much a system should be trusted and for what kind of work. Every classification that follows in this piece is built from these five questions.
1. What is the cost of being wrong, and is it recoverable?
Every system produces errors, so the question is never whether an error is possible, it’s what happens when one occurs.
An internal exploratory analysis that gets a metric slightly wrong is annoying; someone catches it, it gets corrected, and operations continue. A board-reported MRR figure that turns out to be wrong is a governance failure with real downstream consequences for investor confidence and internal credibility. A number that ends up in a regulatory filing or a due diligence data room is a legal exposure. The cost of being wrong isn’t uniform across finance tasks, and the tools handling those tasks shouldn’t be either.
2. Where does the output go?
The destination of an AI-generated output determines the reliability floor required to produce it. An internal dashboard that the CFO looks at every morning to get a directional read carries different accountability requirements than a QBR deck going to the board, which carries different requirements than a filing going to an auditor.
The same output, produced by the same system with the same level of reliability, may be perfectly acceptable in one context and completely unacceptable in another. The destination has to be evaluated alongside the system, not after it.
3. Can the derivation be traced to source data, step by step?
This is different from asking whether the system can explain what it did.
Language models are very good at producing coherent, plausible narratives about computations they performed, regardless of whether those narratives are accurate. A model that generated a number probabilistically can describe, in convincing detail, a rule-based derivation that never actually happened. True traceability in a financial context means the actual query, the actual formula, the actual definition, all existing independently of the model’s explanation and inspectable by someone who wasn’t in the room when the output was generated.
The sub-question here is: where do your metric definitions live in the system? Your definition of MRR, of churn, of net revenue retention, wasn’t handed down from a standards body. It was shaped by your business model, your contract structures, and the edge cases you’ve accumulated over years of operation. In a well-built finance AI system, those definitions sit in a layer you can read, edit, and audit. When someone changes a definition, you can trace which downstream numbers move as a result. In a poorly built one, those definitions are baked into the model’s prompt context, where they drift between queries, degrade when the model updates, and silently conflict when two analysts phrase the same question differently. None of this shows up in a demo. It shows up three months later in a board meeting when two numbers that should match don’t.
4. Is this a calculation or a judgment call?
Rule-based calculations have a right answer. MRR calculated by applying a defined formula to actual contract data has the right answer. Budget vs. Actual variances have a right answer. Churn cohort math has a right answer.
A deterministic system can produce all of these reliably, every time, for every user who asks, regardless of how they phrase the question.
Judgment calls don’t have a right answer in the same sense. The narrative framing of a difficult quarter, the selection of scenarios to present to a board, the interpretation of a covenant clause in ambiguous circumstances: these require context and discretion that no rule can fully encode. AI can assist with all of these, but the nature of that assistance is different: surfacing relevant data, generating a draft for human review, flagging anomalies for human investigation. Treating a judgment call like a calculation, by automating it fully and trusting the output, is where the most consequential AI errors in finance tend to originate, not because the model is unintelligent, but because it’s doing something fundamentally different from what the task requires.
5. Is this a recurring automated workflow, or a one-time exploratory analysis?
A one-time exploratory analysis has a relatively benign error profile. A human is watching the output in real time, and an error surfaces quickly. A recurring automated workflow that runs every month and feeds into board reporting has a very different profile: errors compound invisibly across cycles, and by the time one surfaces, it may have propagated through months of decisions made on the basis of a number nobody questioned because the system had always looked authoritative.
The distinction matters for how much reliability you should require before trusting a system, and it matters for how much ongoing monitoring you build in once you do.
The decision that should inform your AI choices
Running any finance task through the five criteria above should land it in one of three zones.
Zone 1: Automate fully
The task is a deterministic calculation with a right answer.
The derivation is traceable to source data. The metric definitions involved are fixed, readable, and version-controlled. The output goes to internal dashboards or standard reporting where errors are catchable before they propagate. A human reviews the output rather than the process, which is the appropriate mode when the process is reliable.
Most core close outputs belong here: MRR and ARR calculation from contracted data, Budget vs. Actual variances, churn cohort math, bookings reports from CRM, P&L from defined GL mapping. The reason they belong here isn’t that accuracy is less important; it’s the opposite. These tasks have a defined right answer, a deterministic system can produce it, and removing human recalculation from the process actually reduces the error surface rather than expanding it.
Zone 2: Automate with mandatory human review
The task involves some degree of interpretation, narrative generation, or forward-looking projection.
The AI produces a complete draft output, but a human reviews it before it leaves the finance function. The human is not recalculating from scratch; they’re applying judgment to a draft that’s already grounded in reliable data. The efficiency gain is real, but the accountability transfer is not.
QBR narrative summaries, rolling forecast commentary, pipeline coverage analysis, collections prioritization recommendations, and month-end variance commentary all sit here. So does any AI-generated content that will be presented to the board in the CFO’s voice, because that voice carries an implicit warranty that the content reflects human judgment, not just computation.
Zone 3: Human-led, AI as a supporting tool only
The output has legal or regulatory accountability attached to it, or the judgment involved is complex enough that no rule can encode the relevant context.
AI can assist by retrieving data, surfacing patterns, and generating drafts for human interrogation, but a human owns the output in a way that means something: they’ve thought it through, they can defend it, and they’re accountable for it.
Anything going into a regulatory filing belongs here by default. M&A scenario modeling, covenant compliance assessment, strategic board narrative involving forward guidance, and any analysis that could have material legal consequences also belong here. The appropriate question for Zone 3 tasks isn’t “which AI tool should handle this?” but “how can AI help the human who owns this task do it better?”
Where common finance tasks fit with AI
Applying the decision tree to specific tasks makes the abstract framework practical. The following section covers the outputs most finance teams deal with on a recurring basis.
- MRR and ARR calculation: Zone 1, provided the system applies fixed definitions to live warehouse data and the derivation is inspectable
- Budget vs. Actual report: Zone 1, same conditions
- Churn cohort analysis: Zone 1
- P&L report from defined GL mapping: Zone 1
- Bookings report from CRM: Zone 1, assuming the integration is live rather than snapshot-based
- QBR narrative commentary: Zone 2
- Rolling twelve-month forecast and scenario analysis: Zone 2, with the human reviewer taking explicit ownership of scenario selection and assumption documentation
- Pipeline coverage analysis: Zone 2
- Collections prioritization: Zone 2
- Month-end variance commentary: Zone 2
- Covenant compliance assessment: Zone 3
- M&A due diligence modeling: Zone 3
- Any output included in a regulatory filing: Zone 3
- Strategic board narrative involving forward guidance: Zone 3
One thing the list makes visible: the tasks most commonly showcased in AI vendor demos — narrative generation, Q&A against financial data, trend summaries — are Zone 2 tasks. They’re genuinely useful applications of AI assistance, and they’re also exactly the ones that require human review before the output goes anywhere with real accountability attached to it.
What AI auditability actually means in a finance context
Auditability gets used as a selling point by almost every AI vendor in the finance space, which has made it nearly meaningless without a more specific definition.
In a financial context, auditability means one thing: the derivation of an output can be independently verified by someone who had no involvement in producing it. Not described or explained, but actually verified by following the actual computation from input to output.
This excludes natural-language explanations generated by the model that produced the output. A model explaining its own computation is doing something fundamentally different from a transparent system exposing the computation itself, because the model’s explanation is itself a generated output, produced by the same probabilistic process and subject to the same failure modes. Models are very good at generating plausible narratives about what they did regardless of what they actually did, which means a fluent, detailed, confident explanation of a derivation is entirely consistent with a system that cannot actually produce that derivation on demand.
The test is simple: can you retrieve the actual query, formula, and definition file that produced this specific number, without going through the model to get them? If yes, the output is auditable in the financial sense. If the only path to understanding the derivation runs through the model’s explanation of it, it isn’t.
This matters beyond just technical architecture. It matters for how a CFO responds when a board member questions a number, when an auditor asks for support, or when a month-end figure doesn’t reconcile with a prior period and someone needs to trace exactly where the discrepancy entered the calculation.
For a fuller treatment of how deterministic architecture differs from probabilistic AI generation, and why the distinction is the most important one in finance AI, read this piece on deterministic vs. non-deterministic AI. For what happens when financial teams rely on systems that can’t pass the auditability test, our CFO and AI trust relationship piece covers that in detail.
Evaluating AI vendors against this framework
In a nutshell, take these four tests and ask one overarching question. The tests should be run during the demo, not after it, because a demo is by design the best version of the product running under conditions the vendor chose. The objective is to find conditions they didn’t choose.
Test 1: The Consistency Test
Ask the vendor to run any query. Then ask them to run the identical query again, while you’re still in the room.
If the outputs differ, or if anyone says something like “results may vary slightly based on context,” a probabilistic system is making decisions somewhere in the pipeline that should be handled deterministically. Also, try running the same query with different phrasing and observe what happens. Consistent output across phrasings signals a system grounded in data and defined rules. Wildly different outputs signal a system that’s pattern-matching to your words rather than reasoning from your data.
Then push further: what happens when the underlying data changes between runs? Does the output update live? Can you trace which specific numbers shifted and why? What you’re really testing is whether this product maintains a live connection to your warehouse or whether it’s working from a snapshot that will quietly fall out of sync while continuing to look authoritative.
Test 2: The Derivation Test
Pick any number in the demo output. Ask the vendor to show you exactly how it was derived — not a narrative explanation, but the actual computation: the query, the formula, the rule. If they can surface that, the output is as trustworthy as the logic and the source data, both of which are now inspectable. If what they produce is a natural-language explanation generated by the same model that produced the number, the system cannot be meaningfully audited, because the explanation is itself a generated output rather than an independent record of the computation.
This question tends to change the energy in the room. Products built for finance accountability can answer it without hesitation. Products built for impressive demos cannot.
Test 3: The Definitions Test
Ask where your metric definitions live in their system and who controls them. In a well-built product, the definitions sit in an editable layer that is independent of the model, versionable, and traceable to downstream numbers. In a poorly built one, they’re embedded in prompt context, which means they drift between queries, degrade when the model updates, and silently conflict when two analysts phrase the same question differently. None of this is visible in a pilot; it becomes visible three months into production when a board number and a dashboard number don’t match and there’s no clear record of why.
Test 4: The Limitations Test
Ask the vendor to name something their product handles badly or doesn’t handle at all. The quality of the answer to this question has higher predictive value for post-implementation outcomes than almost anything else you could ask.
A good answer is specific and confident: “we haven’t built logic for X yet” or “we keep Y out of the deterministic layer because it requires judgment that a rule can’t encode.” These are the words of a team that understands their own architecture well enough to know where it stops working. A bad answer is some version of “we can handle pretty much anything you throw at us,” which either reflects a system without meaningful architectural constraints or a sales team that hasn’t been asked this question before. The vendor who volunteers their own limitations isn’t showing weakness; they’ve thought carefully enough about the problem to know which parts of it they should and shouldn’t touch. That’s the vendor you want.
The Overarching Question
Every test above is really a version of one question: where in this pipeline does a probabilistic system make a decision, and what happens downstream when it’s wrong? A vendor who can answer that with specificity has built something with a real architecture. One who can’t is selling general-purpose AI capability in a finance-colored wrapper. Both look identical in a 45-minute demo, because a demo is a curated experience. Your actual data, your edge cases, and your auditor will not be curated.
Run the tool in parallel with your existing close process for a full month before committing. It’s double the work for thirty days and worth every hour, because a live run on your actual data exposes what a demo was designed to hide. The vendors who survive that test tend to be the ones who’ve already been asked the hard questions.
For what it’s worth: AskEnola is built to the Zone 1 standard for core finance outputs, with all computation running deterministically through SQL and defined rules, LLM capability confined to the conversational layer, and metric definitions sitting in an editable layer that is independent of the model. The four tests above apply to AskEnola the same way they apply to any vendor. \
The framework we discussed above doesn’t expire. AI capabilities are being released fast enough that the specific tools available for finance tasks will look quite different in less than eighteen months from what they look like today. The five criteria, the zone classification, the vendor tests: none of those change with each model release. A CFO who has internalized them doesn’t have to start the evaluation from scratch every time a new capability lands, which, given current release cycles, would be a full-time job on its own.
The binary questions about AI usage will keep coming for every business question including Finance. The useful habit is to replace them automatically with a set of questions that actually determine whether a specific AI application is appropriate for a specific finance task. The answer to those questions isn’t always yes, and it isn’t always no, and that’s precisely the point.