The Problem Nobody Talks About
Today, new finance AI tools are launching faster than most teams can evaluate them.
Yet adoption among enterprise finance teams, especially for anything that touches the month-end close, remains cautious. Sometimes even resistant.
I’m Kaushik, co-founder and CPO at Consark. A significant part of my role sits in pre-sales conversations with finance teams evaluating AI. And every single time, regardless of the company, the size, or the geography, the same questions surface: how can I ensure the outcome is deterministic? How can I explain it? How can I trace it back to source data?
These are not technology questions. They are accounting questions. And they all point to one specific moment in the finance lifecycle: the audit.
When an auditor questions the numbers, the accountant must have answers. The answer that will not survive scrutiny is “the AI told me.” That answer ends the conversation in the wrong direction.
Here is the reality that most finance AI products are not designed around, and one that we spent a long time thinking through at Consark before we wrote a single line of product code: there is no regulatory framework today that audits AI outputs. Which means the accountant carries 100% of the liability for every number, regardless of how it was produced. A correct answer with no explanation or traceable logic is still an indefensible answer in an audit room.
So the right question for any finance AI product is not “can AI do this?” It is “can the accountant defend this?” That distinction is what most products miss. It is the distinction Consark was built around.
What Happens When AI Meets the Auditor
Consider this scenario. It will feel familiar if you have been through a finance close audit.
It is the end of the month. An accrual has been booked. The number was recommended by an AI agent based on vendor data, and the accountant approved it. Fast forward to the audit: the auditor asks how the number was derived.
If the accountant’s answer is “the system generated it,” the interaction fails. They cannot explain what signals the AI read, how it weighted them, or why it landed on that specific amount. They have a conclusion with no trail.
In a SOX environment, that is a serious risk. An auditor who cannot verify the logic behind a conclusion can issue a remark. That remark goes into the audit report, which goes to shareholders, rating agencies, and regulators. In serious cases, it triggers restatement conversations.
This is not a hypothetical edge case. This is the exact scenario that shaped how we designed Noa, our AI agents for the finance close. Every time we were in a room with a finance team and this concern surfaced, it reinforced the same product conviction: an AI that gives you the right answer but cannot show its work is not a tool a finance team can actually rely on.
The question is not whether AI can produce a correct accrual estimate. In our experience, it can, and it does. The question is whether the accountant can stand behind that estimate when it matters most. That is a design problem. And it is the one we set out to solve.
The Inference vs. Compute Distinction
In every pre-sales conversation where AI comes up, I draw one specific line. Between AI used for inference and AI used for compute. That distinction is what determines whether a finance team can actually defend the AI’s contribution to their conclusion.
| AI for Compute | AI for Inference | |
| What AI does | Executes calculations, runs accounting routines, produces financial outputs. | Reads signals, draws meaning from data, surfaces reasoned recommendations. |
| Who is the actor | AI is the actor. Human approves an output they didn’t produce. | Human is the actor. AI gives them better material to decide with. |
| Example in the close | AI auto-posts a journal entry, runs depreciation, generates an accrual amount. | AI reads vendor signals, weights them, recommends an accrual with reasoning. |
| Audit trail | Output exists. Logic does not. | Output exists. Logic is visible and traceable. |
| Accountant’s answer to the auditor | “The system generated it.” | “Here is what I evaluated and why I concluded this.” |
| Defensibility | Low. Accountant owns the output but not the reasoning. | High. Accountant owns both the conclusion and the argument. |
| Risk classification | High risk | Low risk |
AI for compute means AI is doing the accounting. It is running the calculations, executing the routines, producing the numbers. The accountant’s role in that chain is to approve an output they did not produce and may not fully understand. The AI is the actor. The human is the stamp.
AI for inference means something different. The AI is reading signals, drawing meaning from data, and surfacing a reasoned recommendation. The accountant is still the decision-maker. They are validating a conclusion, not inheriting one. The reasoning chain stays with the human.
That difference is everything when the auditor walks in.
When I presented Noa’s AI approach to the Chief AI Architect at one of the world’s largest marketing and communications holding companies, the assessment was clear: low risk. The reason was precise. We use AI only for inference, not for compute. That was not a characterisation we put on ourselves. It was an enterprise AI governance team, with their own framework, applying it to our product and arriving at the same conclusion independently.
I have used that framing in every enterprise conversation since. The response from IT risk teams, AI governance leads, and finance leadership has been consistent. It maps directly to how they are already thinking about AI risk inside their organisations. They are not looking for AI that does the accounting. They are looking for AI that makes their accountants better at defending their conclusions.
That is the line Noa is built on. Noa prepares and humans review. That’s the design.
What This Looks Like Inside Noa
Accruals are a good place to make this concrete.
Accruals are one of the most judgment-intensive tasks in the month-end close. There is no single correct answer. There is a defensible answer, one that a reasonable finance professional, given the same signals, would reach through sound judgment. That is exactly the kind of task where AI can add real value. And exactly the kind of task where defensibility matters most.
The simplest version of AI-assisted accruals would look like this: AI reads the vendor response, outputs an accrual amount, accountant accepts. That is faster than doing it manually. But the accountant still ends up with a number and no argument. The black box problem has not gone away. It is just faster now.
That is not what we built.
Noa doesn’t track your close. It runs it. When Noa’s accruals agent makes a recommendation, it gives the chain of thought behind it. The agent surfaces what signals it read, how it weighted those signals against each other, why it considered the primary signal a strong basis for accrual, and what the resulting recommendation is and why. Every step is visible. Every step is traceable back to source data.
Here is what that looks like inside Noa:
The accountant now has a conclusion and an argument. When the auditor asks “why did you accrue this amount?” the answer is not “the system said so.” The answer is: here is the vendor signal I received, here is how I evaluated it against the other signals available, and here is the conclusion I reached. The chain of thought is the audit trail.
The test every Noa agent has to pass before it ships: can the accountant stand in front of an auditor and defend this? And for that to hold, three things need to be in place:
- The outcome has to be deterministic, same inputs producing the same output every time.
- It has to be explainable, with the logic visible and not buried.
- It has to be traceable, connecting the output back to the source data that produced it.
Why We Made This Choice
Most finance AI products lead with efficiency. Time saved per close cycle. Percentage of tasks automated. Headcount that can be redeployed. Those are real outcomes and Noa delivers them too. But if efficiency is the primary design driver, you end up optimising for speed at the cost of explainability. You get a faster black box. And a faster black box is still a black box.
We made a different choice at Consark. Design for defensibility first. Efficiency follows from a process the accountant trusts and can stand behind.
Noa executes the work. The accruals, the reconciliations, the schedules. That is the point. But execution alone is not enough in a finance close context. Every output Noa produces comes with a full reasoning trail, visible, traceable, and reviewable by the accountant before anything is posted. The accountant’s role shifts from manual preparation to judgment and control. They are not signing off on a black box. They are reviewing work that shows its reasoning at every step. That is what makes the execution defensible.
The output is collective, scrutinised by auditors, and reported to shareholders. The bar is simply different.
There is also a regulatory tailwind behind this choice. Frameworks across the EU, the US, and Singapore are all moving in the same direction: greater accountability for AI outputs in financial processes, more documentation requirements, more mandatory human oversight. The inference-only approach is not just defensible today. It is what the regulatory environment is building toward. We built Noa for that world, not against it.
Noa is not a limited product. It is a deliberately scoped one. The inference-only decision is not a technical constraint. It is a design choice made with one question in mind: can the accountant stand behind this?
Most products are built to impress in a demo. Noa is built to hold up in an audit room. For enterprise finance, that is a more important test.
