Finance and the dice-rolling AI
Ask an AI the same question twice and you can get two different answers. Banks, insurers and accounting firms use it for money work anyway. Nobody has fixed the dice. What they have done is keep the dice away from everything that must be exact, and check everything else. This page shows where the errors come from and what each check does.
- Should the AI ever do the arithmetic itself? And if it writes the code or the formula instead, who checks that the code is right?
- How does messy data — scans, receipts, PDFs — get cleaned up before it reaches a spreadsheet?
- What happens to client names and account numbers when the work goes through a cloud AI?
- What checks sit between the steps of a pipeline, and who signs before a number reaches the board?
The whole idea in one picture
First, the worry, and it is real
An AI builds its answer one word at a time, and each word is picked by chance from a list of likely next words. That is the “dice”. Ask the same question on Monday and again on Tuesday and the sentences come out different, and once in a while so does a number. Nobody at the AI vendors or at the banks claims to have fixed this at the source. Everything below is what they do instead.
Under the hood
A language model samples each token from a probability distribution over its vocabulary, so outputs vary from run to run. Setting the temperature to zero reduces the variation but does not remove it in practice: batching, hardware and model updates all move the result. The engineering position across every deployment the source thread examined is the same: design around non-determinism rather than deny it. Push everything that must be exact into deterministic components, and limit the model to work where variation was always acceptable.
Three ways the dice go wrong in a long job
A single wrong word is rarely the problem. The damage comes from how one small slip grows over a long piece of work. Engineers call this token-prediction drift, and it happens in three ways. The rules you gave at the start fade as the conversation gets long. One misread number spreads, because the AI makes every later figure agree with it. And a tiny change in the input, an extra space or a different currency symbol, changes how the text is cut up and can shift the answer.
Under the hood
Context drift. In a multi-turn pipeline every turn carries forward the system prompt, tool definitions, chat history and intermediate tables. As the prompt grows, attention is spread across thousands of tokens and early instructions (“format dates as YYYY-MM-DD”, “never estimate a missing number”) lose relative weight. This is the same effect the AI chat guide calls “lost in the middle”.
Error cascade. Each token is predicted from all the
tokens before it, so an early mistake changes the conditional
probabilities of every token that follows. Once $105,000 is
in the context, the model works to keep later MRR figures, forecasts and
summaries consistent with it rather than with the source.
Tokenizer drift. " Total" with a leading
space and "Total" without one are different token IDs. Small
formatting differences move the input to a different region of token
space, alter attention weights, and can change a calculation or a schema
output.
The three standard mitigations are the three later sections of this page: deterministic code execution (section 4), schema validation between steps and context pruning (section 10), and a person who signs (section 11).
Money work was never one-answer work
Give the same company file to two analysts and you get two different memos: different words, different emphasis, slightly different comparisons. Firms have always accepted that, because only a narrow part must be exact: the sums, the source numbers, and the ledger. The AI is allowed into the part that was always allowed to vary. It is kept out of the exact part.
Under the hood
The question “how do they solve non-determinism?” carries a slightly wrong premise: finance work was never fully deterministic. Judgment, synthesis and drafting always varied between people; the firm tolerated it because the exact subset (arithmetic, source data, the system of record) was handled by deterministic computation. The model goes into the variable layer. The exact layer is handled the way it always was.
The AI never does the sums
This is the first rule, and the strictest. The AI is not allowed to calculate a number in its head. It writes the formula, or a short piece of code, or a database query, and a machine runs it. In a spreadsheet, that machine is the spreadsheet. The dice can change how a sentence is phrased. They cannot change what =SUM adds up to, no matter how long the conversation has become. This also stops the “one wrong number spreads” problem from section 2: a number that came out of code is exact, so there is nothing wrong to spread.
Under the hood
Claude in Excel reads formulas, edits them and processes data; the
spreadsheet engine computes the results. It is the same shape as any
tool-calling agent: the model writes the formula, the Python, the SQL or
the DAX, and a deterministic runtime executes it. Anything numeric routes
through code execution or a database rather than token prediction.
Sampling temperature cannot change what =SUM(B2:B14) returns,
and arithmetic done in Pandas or SQL stays exact regardless of prompt
length, which is what removes the error cascade.
But the formula it wrote can be wrong too
Moving the arithmetic into code removes one problem and leaves another. The AI can still write =SUM(B2:B10) when the data runs to row 12, or a query that forgets a filter or a join. The result is exact and wrong. The answer is the same one accountants have always used: a second, independent check. The parts must add up to a total known another way. The row count in must equal the row count summed. A second route to the same figure must agree. And a person reads the formula, not just the number it produced.
Under the hood
Generated code is validated the way any code is: not by the model that wrote it. Practical checks that catch a wrong range, a missed join or a hallucinated filter: control totals (the result must reconcile to an independently known figure, such as the bank balance or the prior period’s close); cardinality checks (rows in equals rows out, or the expected count after a join); dual computation (the same metric via a second path, for example a SQL aggregate versus a Pandas group-by, must match to the cent); and formula review, where the reviewer inspects the range or the query text rather than the output. Systems that generate spreadsheet formulas can add a mechanical range check: the referenced range must end at the last non-empty row of the source column.
Inbox data is cleaned before it reaches the grid
Receipts, scans and bank PDFs arrive messy and different every time. They do not go straight into a spreadsheet. First an AI copies each one into a strict form: every field has a type, a date is a date, and a value it cannot find is marked “not found”, never guessed. Then plain arithmetic checks the form: the lines must add to the total, the date must fall inside the period, and every value must point back to the page it came from. Only a form that passes is written to the grid.
Under the hood
Extraction runs against a typed schema (Zod or Pydantic): each field
has a declared type, missing means null, and the instruction
says “return null, do not guess”. Every extracted value is then
re-located in the page text and stored with its page and character span,
so an invented figure is visible as unlocated. Deterministic checks
(line items sum to the total, closing balance equals the next opening
balance, dates inside the period) run before any value is accepted, and
a failure raises needs_review rather than passing the value
on. This is the pattern Document Substrate uses; the
how it works guide
shows the whole line.
Facts arrive through pipes, not memory
The AI is not asked to remember what a company is worth or what its credit rating is. Governed connections bring in the real, current numbers from the official sources, so the model works with verified facts instead of recollections. If the facts are exact going in, the dice have nothing exact to spoil.
Under the hood
This is the connector ecosystem: governed, real-time access to data providers such as FactSet, S&P Global, Moody’s and LSEG. Dun & Bradstreet’s chief data officer makes the point directly: verified business identity data is what lets AI systems deliver the “deterministic, auditable outcomes” financial workflows require. The determinism lives in the data source, not in the model.
Names travel in disguise
Before anything goes to a cloud AI, a small piece of software at your end swaps every client name and account number for a code name and keeps the real values at home. The AI does all its work on the code names. The answer comes back in code and is swapped back on your screen only. This is a different protection from a vendor’s promise to keep nothing, and people often confuse the two. The promise is about what the vendor keeps. Privacy law is often about whether personal details may be sent at all. Serious setups use both.
Under the hood
Redaction and rehydration gateway. Local tooling
(Presidio, spaCy NER, checksummed regex rules) replaces PII with
deterministic placeholders such as [CUSTOMER_1] before the
prompt leaves; an encrypted, in-memory mapping swaps them back after the
response. The mapping never crosses the network.
Zero Data Retention (ZDR). A contractual commitment that the vendor processes requests in memory and does not log, persist or train on them. It typically covers the API path under an enterprise agreement, and often not a consumer desktop chat.
Why both. ZDR does not stop unredacted PII from being transmitted and processed on the vendor’s infrastructure, which strict regimes (GDPR, CCPA, the New Zealand Privacy Act 2020) may treat as a transfer needing a lawful basis regardless of retention. Redaction answers the transfer question; ZDR answers the retention question for the operational data that does travel. The personal information guide covers this in detail.
Every answer carries its receipts
This is the change in the requirement that makes everything else work. You do not need the same answer every time. You need an answer you can check, every time. Every figure in the output points back to where it came from, so a reviewer can follow the trail before anyone acts. Two identical memos that both invented the same number would be worse, not better: perfectly repeatable, and impossible to check.
Under the hood
Every output is source-attributed so teams can verify the work before acting on it, and every number can be traced to its source. That changes the requirement from reproducible to auditable, which is the standard firms already apply to human work: no two analysts were ever identical either.
A gate after every step
A finance pipeline is a chain: revenue is rolled up, reconciled, fed into the forecast, and reported. Between every two steps there is a gate that does three things. A form check: the step’s output must fit a strict form, every required field present and every value the right type, or it stops there. A threshold check: a month-on-month jump above an agreed limit is flagged for a person instead of passed on. And a clean desk: the next step starts fresh and receives only the checked results, not the whole conversation so far. That last one is what stops the rules from fading.
Under the hood
Schema enforcement between steps. Each step’s output is validated against a Pydantic or Zod schema before the next step sees it; a validation failure halts the pipeline at that step, so bad context never pollutes downstream work.
Circuit breakers. Deterministic threshold rules (for example, month-over-month variance above 5%, a negative balance, a duplicate invoice number) raise a flag that requires a person to clear it. Thresholds are set by false-positive rate: a rule that fires too often trains reviewers to ignore it.
Context pruning and state summarisation. Rather than appending raw CSV history to every prompt, the pipeline clears the context between steps and passes a compact, validated state object. This is the direct fix for context drift, and it also keeps each call small enough for the rules to hold their weight.
A person holds the stamp
The AI drafts; a person decides. The pitchbook, the credit memo, the filing: each is reviewed and signed by someone whose job is to find the draft’s mistakes before it goes anywhere. Anything the checks flagged, including a value the reader was not sure about, waits for that person. And some doors the AI simply has no key to: it cannot place a trade, write into the ledger, or approve a loan on its own.
Under the hood
Every vertical repeats the same split: the model assembles the analysis while you control the valuation call, structures the write-up while you own the credit decision, drafts the filing while you keep sign-off. Human-in-the-loop is mandatory on low-confidence extractions and on every flagged threshold, not optional. The agent templates add verification subagents (comparables selection, methodology checks), and managed deployments add per-tool permissions, credential vaults and a full audit log of every tool call. Absent from every deployment described: autonomous trades, bookings, or credit decisions. Even the anti-money-laundering example is about compressing investigations; the decision still goes to a person.
And at your kitchen table?
On a laptop you get the same tools: code that does the sums, connections to your real files and accounts, your own rules written down. What you do not get is the firm’s safety net. The reviewer of your tax working is you, the person who asked because you did not know. So borrow the discipline: make it do sums in code, feed it real documents instead of memories, ask it to show the actual rule, and let an accountant hold the stamp on anything that matters. The AI’s job is to make that conversation cheaper, not to replace it.
Under the hood
What transfers: code execution for anything numeric, MCP connectors to real data (accounting software, bank exports, actual invoices), and file-based skills that encode your own conventions the way the finance plugins encode a firm’s.
What does not: human-in-the-loop only works when the human can evaluate the output; there are no methodology-check subagents, eval suites or compliance readers on one pass with one reader; pasted-in numbers and recalled tax rules are unverified, and jurisdiction-specific thresholds are exactly what a model states confidently and wrongly; and the stakes concentrate, because no firm absorbs your mistake.
The translation: insist calculations run in code you can inspect, connect real sources, ask for the rule citation and check it, and route consequential positions through a qualified professional with the AI’s work as the prepared material.