Almost every AI assistant for finance is sold on the same demo: someone types a question in plain English and a number comes back. We looked at roughly 1,700 real interactions with our own AI agent over two months. Ad hoc question-answering was 7.6% of them. Two thirds were people building, fixing or explaining the model itself.
That changes what you should evaluate. An assistant that reads a finished plan well is solving the smallest part of the problem. The work is in construction and repair, and that is where the capability differences between products are largest.
For variance analysis specifically, the question is not whether the assistant can tell you revenue missed by 4%. Every product can. It is whether it can trace the miss through the calculation chain to the assumption that caused it, which requires access to the model's logic and not just its output.
We run an AI agent inside our own planning platform, so we can see what people ask it rather than what they say they would ask it in a buying process. Over August and September 2026, across roughly 1,700 interactions, the distribution looked like this.
Formula work was the single largest category at 37%. Taken together, about two thirds of all turns were people building, fixing or explaining the model itself. Ad hoc data retrieval, the thing every demo shows, was 7.6%.
A fourth pattern was emerging by the end of the period: people asking the agent to change the model directly rather than describe it. Build this scenario. Solve for this target.
We are one vendor with one dataset and our customers skew toward large, complex models, so treat the exact percentages as directional. The shape is the point. The assistant is not mainly a reporting interface. It is a modelling interface.
It misleads in two directions at once.
It oversells, because retrieving a number from a finished plan is the easiest thing an AI assistant does. Any product with a semantic layer and a decent LLM does it well. It is not a differentiator, and buying on it tells you almost nothing.
It undersells, because the harder capability is the one that would actually change your week. If your analysts spend their time writing formulas, tracing broken dependencies and explaining to a business partner why a metric moved, an assistant that only reads the plan leaves all of that untouched.
The demo persists because it is easy to stage and it looks like magic. Ask for the other one.
Variance analysis is where the distinction becomes concrete, because it is not one task. It is three, and products are good at very different subsets.
Detection. What moved, by how much, against which version. Straightforward. Everything does this.
Decomposition. Breaking the variance into contributing drivers: volume against price, mix, timing, FX, one-offs. This needs the assistant to understand how the metric is built, not just what it returned. An assistant reading a warehouse table cannot do it, because the decomposition logic lives in the model.
Attribution. Tracing the variance back to the assumption or input that caused it, across the dependency chain. This is the answer people actually want, and it requires the assistant to read the calculation graph.
Most tools stop at detection and present it as variance analysis. When you evaluate, bring a real miss from your last close and ask the assistant to explain it. Then check whether the explanation is a description of the number or an account of what caused it.
Fintastic, Pigment, Anaplan, Workday Adaptive
The assistant sits inside the platform and can read the model's structure, not just its output. This is the only category that can do decomposition and attribution properly, because the calculation logic is there.
The differences within it are about scope. Some vendors embed a separate agent per application, so a finance question and a supply chain question go to different agents and cross-domain questions require switching. Others run one agent across the whole model.
Good at detection and at natural-language querying. Blind to planning logic, because they read outputs rather than models. Reasonable if your question is genuinely "what happened" and your planning process lives elsewhere.
ChatGPT, Claude or a similar assistant connected to your planning data through an API or a Model Context Protocol server. The advantage is that people already work there. The constraint is that the quality of the answer depends entirely on what the connector exposes. A connector that returns aggregated outputs gives you detection. One that exposes the model structure and the calculation engine can do more.
This category is moving fastest and is worth watching even if you do not buy into it now.
Does it read the model or the output? The single most consequential difference. Ask the vendor to explain a variance that requires walking a dependency chain three levels deep. You will know within one question.
Does it respect permissions natively? If compensation is masked from a department head in the platform, the assistant must not surface it in an answer. Ask whether permission enforcement happens in the model or in a filter applied to the assistant's response. Only one of those is safe.
Can it write, and can you audit what it wrote? Assistants are moving from describing models to changing them. Write access without a clear record of what changed, when and by whom is not something to put in front of a planning cycle. Ask what the audit trail covers today, not what is on the roadmap.
Does it verify its own output? An assistant that proposes a formula and cannot evaluate it before recommending it will be wrong some of the time, across every product in this category. That is survivable if the workflow assumes verification. It is not survivable if the assistant is presented as authoritative. Ask any vendor what their correction rate looks like. The honest ones have a number.
The Fintastic AI Agent runs inside the planning architecture rather than on top of it. It has access to the live model and the calculation engine, and it operates within the same permission structure as a human user, including column-level masking, so an answer never contains data the person asking could not open themselves.
One agent covers the whole model rather than one agent per domain, so a question that spans finance, headcount and operations does not require switching context. It is also reachable from outside the platform through a Model Context Protocol server, which means the AI tools your team already uses can query the planning model directly.
We are candid about where this sits today. The agent is strongest at exactly what our usage data shows people do most: explaining model structure, writing and fixing formulas, and tracing why a number moved. Direct model modification is the newest capability and the least mature, in our product and in the category. If a vendor tells you otherwise about theirs, ask to see it fail.
AI cannot compensate for a planning system it cannot reason about. If the model is fragmented across applications, if the calculation logic lives partly in the platform and partly in side spreadsheets, or if a full recalculation takes fifteen minutes, then an assistant sitting on top of it inherits every one of those constraints.
This is why the AI evaluation and the platform evaluation are not separable, however they are sold to you. The assistant is only as good as the model underneath it.
Usage figures are from Fintastic's own platform telemetry, August and September 2026, aggregated across all tenants. Competitor capabilities are described from publicly available product documentation as of Q4 2026 and may change.
Across roughly 1,700 interactions with Fintastic's AI agent in August and September 2026, about two thirds of turns were people building, fixing or explaining the planning model itself, with formula work the single largest category at 37%. Ad hoc data retrieval, the use case most vendors demo, was 7.6%.
Partly. Detection, meaning what moved and by how much, is straightforward and every product handles it. Decomposition into drivers and attribution back to the causing assumption both require the assistant to read the model's calculation logic rather than its output, which only assistants embedded in the planning platform can do.
An embedded assistant can read the planning model's structure and calculation chain. A copilot over a BI or semantic layer reads outputs only. That difference does not matter for simple lookups and matters completely for explaining why a number moved.
It depends on the audit trail, not on the AI. Write access is only as safe as your ability to see what changed, when and by whom, and to reverse it. Ask what the audit trail covers today rather than what is planned, and treat model modification as the least mature capability in the category.
They should, but enforcement differs. Permissions enforced in the model mean the assistant cannot retrieve data the user could not open. Permissions applied as a filter on the assistant's response are weaker. For workforce planning, where compensation is masked from some users, this distinction matters a great deal.
No. An assistant inherits the constraints of the system underneath it. If the model is split across applications, if calculation logic sits partly in side spreadsheets, or if a full recalculation takes minutes, the assistant is limited by all of that. The architecture evaluation and the AI evaluation are the same evaluation.
