Every AI feature in financial planning software eventually runs into the same question, usually asked by a compliance officer: where did this number come from?
It is a deceptively simple question. The answer determines whether a plan can be reproduced, audited and defended. And as language models move into planning tools, the answer is no longer obvious from looking at the screen.
There are two fundamentally different ways an AI planning tool can produce a figure. Understanding the difference is the most useful thing an advisor can know when evaluating AI financial planning software.
Two Kinds of Software
A deterministic engine is the traditional heart of planning software. It takes inputs (ages, balances, contribution history, tax rules, assumptions) and applies explicit, coded rules to produce outputs. Given the same inputs, it produces the same outputs, every time. When the RRIF minimum at 71 is 5.28% of the January 1 balance, the engine applies 5.28%. When the client lives in Ontario, it applies Ontario's estate administration tax; when they move to Alberta, it applies Alberta's capped probate fee instead.
A language model works differently. It generates text by predicting what is likely to come next, based on patterns learned from a very large body of writing. It is remarkably good at reading documents, summarizing, explaining and answering questions in natural language. It can also produce numbers, and they often look right. But it is not applying coded rules, and it does not guarantee that the same question produces the same answer twice.
Both are useful. They are useful for different things.
Why Projections Need Determinism
Financial planning makes a promise that most software does not: the same client data must produce the same figures in the projection, in the on-screen chart, in the printed report, and in the plan you reopen next year.
That promise is what makes a plan auditable. A compliance review is an exercise in reproduction: take the inputs, follow the logic, and arrive at the same output. If the output depends on how a model happened to sample its answer on a given day, there is nothing to follow.
Consider a concrete case. A retired couple in British Columbia has a combined RRIF balance, two CPP pensions, OAS for both, and a non-registered account. The question is whether to draw down the RRIF faster in their late sixties to reduce exposure to the OAS recovery tax later and to shrink the taxable RRIF balance at the second death.
Answering that properly requires a year-by-year projection: RRIF minimums rising with age, federal and BC tax brackets, pension income splitting, the OAS recovery tax at 15% above the threshold, and the deemed disposition at death. Every one of those is a rule. A deterministic engine applies them consistently. A language model asked to "work it out" may produce a confident, well-formatted answer that is subtly wrong in year 14, and nothing on the page would tell you.
The danger is not that the model is obviously wrong. It is that it is plausibly wrong.
What Language Models Do Well
None of this is an argument for keeping language models out of planning software. It is an argument for giving them the right job.
Reading documents. A T4, a notice of assessment, a QPP Statement of Participation, a T2 return. Extracting figures from varied, messy documents is a task language models handle well, as long as the advisor confirms the result before it reaches the plan.
Explaining results. Once the engine has produced a projection, a model can explain it in plain English or French: why taxable income spikes at 72, why the holdco dividend strategy reduces lifetime tax, what the estate looks like under each scenario.
Answering questions from the plan. When a client asks "what if we sold the rental property in 2028?", a model can interpret the question, and the engine can run it. The model then explains the engine's answer, quoting its figures.
Checking for gaps. A model can read a completed plan and notice that the client with a holding company has no shareholder agreement recorded, or that one spouse has no beneficiary on a TFSA.
In each case, the model operates on language. The engine operates on numbers.
The Architecture That Works
The pattern that emerges is straightforward: the engine computes, the model reads and explains.
In practice that means a few specific things.
The model never generates a figure of its own. When it cites a number, the number comes from the engine's output for that client. If the engine has not produced it, the model should say so rather than estimate.
Changes go through the engine. When the model drafts a scenario, it sets up inputs. The engine produces the outputs. The advisor reviews both before anything is saved to the plan.
The trail is visible. The advisor, and anyone reviewing the file later, can see what the model was asked, what inputs it proposed, and what the engine produced.
This division of labour gets the benefit of both. The plan remains reproducible and defensible because the numbers come from explicit rules. The advisor still gets the speed of a model that reads, explains and drafts.
Why This Matters More in Canada
Canadian planning has an unusual amount of jurisdictional detail, which raises the stakes on where numbers come from.
There are thirteen provincial and territorial tax systems layered on the federal one. Quebec runs its own pension plan and its own tax return. Probate ranges from Alberta's capped fee to Ontario's 1.5% on estate value above $50,000, and a notarial will in Quebec avoids probate altogether. Incorporated clients bring the small business deduction, refundable tax pools and the passive income grind on top.
A general-purpose language model has seen a lot of text about Canadian tax, much of it outdated, approximate or American. Asking it to apply these rules directly invites exactly the kind of quiet error a projection cannot afford. A deterministic engine built for Canadian rules does not have that problem, because the rules are coded, versioned and testable.
Questions to Ask a Vendor
When the AI quotes a number, where does it come from? The only good answer is the engine.
If I ask the same question twice, will the figures match? Ask for a demonstration.
Can the AI change the plan without my approval? It should not.
Can I see what the AI did on a client file? There should be a reviewable record.
Which rules does the engine cover? Ask about QPP, provincial probate, and corporate structures specifically.
The Takeaway
AI in financial planning is genuinely useful, and the advisors who use it well will communicate faster and more clearly than those who do not. But the numbers in a plan are a different kind of thing from the words around them. They carry obligations of reproducibility and explanation that a language model, by design, cannot meet on its own.
Keep the arithmetic with the engine. Give the model the reading, the explaining and the drafting. That is how Finn works inside PlanBase: every figure it explains comes from the deterministic engine, and nothing reaches the plan until the advisor approves it.
PlanBase's engine models federal, provincial and territorial rules across all thirteen Canadian jurisdictions, including QPP and Quebec tax, so the same client data produces the same figures every time.