The Deterministic Boundary for Finance Agents

Step 1Separate the four things "deterministic" is used to mean.

When a controller says the process must be deterministic, the requirement usually bundles several properties that have different owners and different costs:

• Same bytes out. The same request returns an identical response. No major hosted API guarantees this (see STEP 6), and it is also the least useful of the four. A model can be deterministically wrong: if it returns the same wrong total every time, you have consistency, not correctness.
• Same run on replay. Re-performing a past period reproduces exactly what happened, because the model's replies were recorded and are fed back instead of regenerated. This is what an auditor means, and it is a storage problem you can solve today.
• Exact computation. Every amount, total, rate, allocation and rounding is done by code in decimal or integer arithmetic. The model never produces a number that is used as a number.
• Same facts, same decision. Whether something is approved, posted, paid or escalated is decided by a rule, a policy or a named person, so identical facts always lead to the identical outcome. The model may supply facts, flagged as proposals, but it does not decide.

A finance process needs the last three, and needs evidence that they held. Treating the first as the goal sends teams after seeds and temperature settings, which buys little. Treating the other three as the goal turns "can we trust the model?" into "which outputs of the model are checked, and by what?", and that question has an engineering answer.

Step 2Place each step by what its output does, not by how clever it is.

Break the process into steps and ask one question of each: if this output is wrong, what checks it before it has an effect? The answer sorts steps into six kinds, and the rule follows directly:

• Reading: extracting fields from invoices, statements, contracts or emails. The model may do this, provided its output is tied to something independent: a control total on the document, a citation to the exact span it read, a counterpart record in another system. A model reading an invoice is fine if the invoice's lines are checked to sum to its total.
• Matching and classifying: pairing records, choosing a GL account, tagging an exception. The model may propose. Code applies the constraints that make a proposal valid (equal amounts, open items, allowed accounts), and anything ambiguous goes to a person.
• Computing: totals, interest, fees, FX, allocations, tax. Code only. Not "code, unless the model is confident." In the reconciliation experiment, a run with both closing balances wrong still reported a difference of 0.00.
• Deciding: approving, posting, paying, declining, filing. Rules and people. This is where maker-checker, limits and segregation of duties live. The model can be the maker of a proposal, but never the checker.
• Explaining: commentary, variance narratives, client summaries. The model writes, and code verifies that every figure in the text is one the system computed.
• Researching and drafting: memos, first-pass analysis, policy look-ups. These are probabilistic by nature and fine to leave that way, because a person reads the result before it becomes anything else.

The boundary, then, is not drawn around the model. It is drawn around every output that can move money or change a record: on one side, outputs that are checked before they take effect; on the other, outputs that are the effect. A practical test of where your boundary really sits: pick any single model output and trace how far it can travel, through which tools and records, before code or a person looks at it. If the answer is "into the ledger", the boundary is in the wrong place.

Step 3Do the compounding arithmetic before choosing an architecture.

Accuracy per step multiplies across a pipeline. If each step is right with probability p and there are n unchecked steps in a row, the chance that the whole run is right is pⁿ:

per-step accuracy    5 steps    10 steps    20 steps
99.5%                97.5%      95.1%       90.5%
99%                  95.1%      90.4%       81.8%
98%                  90.4%      81.7%       66.8%
95%                  77.4%      59.9%       35.8%

Two things follow. First, an end-to-end agent that reads, matches, computes and posts in one loop is a long chain, and even excellent steps degrade it. Vals AI's Finance Agent benchmark (version 2.1, updated 19 October 2026) gives the scale: its best agent scores 67.85% on analyst-level tasks, with financial modelling at 57%. Second, the remedy is not a better model but a shorter chain. A deterministic check between steps resets the multiplication, because an error caught at step 2 does not carry into step 3. The reconciliation on the code page has one probabilistic step (proposing pairs for 12 lines), and every proposal is checked by code before anything depends on it.

Volume matters as well as rate. A 1% error rate on 400 lines a month is four wrong lines every month in one account. Multiply by accounts and entities, and any step that is not checked becomes a reconciling item of its own.

Step 4Know the mistakes that are specific to financial data, and the check for each.

Hallucination & Grounding explains why models invent things. In finance, the inventions take predictable forms, and each has a check that costs almost nothing:

• An asserted tie. The reconciliation "balances" because the model said it does. On the code page, every naive run that returned figures reported a difference of 0.00, the wrong ones included. Check: recompute the totals and tie them to the source statement, and never accept a difference as an input.
• A tie by construction. Carrying every unmatched line as a reconciling item on its own side always balances, whatever the lines are. Check: every reconciling item must have a category assigned by a rule, and uncategorised items block sign-off.
• Circular derivation. One total is worked backwards from another, so the two agree by definition. One run in the experiment worked its book balance backwards from the bank total. Check: compute each side independently from its own lines.
• Invented identifiers. A ledger ID that does not exist (one run returned one), an invoice number, a citation. Fabricated references are also behind the two best-known professional-services retractions, covered in the industry analysis. Check: every ID is resolved against the system of record, and every citation against its source span.
• The right number in the wrong frame. A figure from the wrong period, entity, subsidiary or share class; restated against originally reported; quarterly against year-to-date. Check: numbers travel with their period, entity and basis as typed fields, never as bare values.
• Scale and sign. Thousands read as millions, parentheses read as positive, a debit read as a credit. Check: declare the units, normalise parenthesised negatives in the parser, and run sign checks per account type.
• Currency. An amount attached to the wrong currency, or converted at a rate the model supplied. Check: currency is part of the amount type, and rates come from a dated, sourced rate table.
• Plausible precision. Rounding the model made up (a balance quoted to the cent that nothing computed). Check: every number in generated text must match a computed figure.

Step 5Do not use a second model as the arbiter of a number.

The tempting fix for a model that might be wrong is another model that checks it. For financial figures, the evidence says the checker has its own failure mode. In FinVerBench (May 2026), language models were asked to verify the XBRL financial statements of 43 S&P 500 companies into which errors had been injected. Under a guided checklist, 9 of the 14 model runs flagged 95 to 100% of the clean statements as wrong. A verifier that rejects everything costs as much in review time as having no verifier.

The ordering from the generator–verifier gap applies here with unusual force. Exact oracles (recompute, resolve the ID, tie to the source) come first; sound checkers (a policy engine, an SMT solver on encoded rules) second; people third. A model judge has a role in finance, but it is for tone, completeness and whether the commentary answers the question, not for whether 289,941.09 is right. Self-consistency, sampling several answers and comparing them, is worth using as a trigger: if the samples disagree, send the item to a person. Agreement proves nothing, because several samples can agree on the same wrong total.

Step 6Buy reproducibility from your records, because providers do not sell it.

The mechanics are in Reproducibility & Nondeterminism: inference servers batch your request with other people's, and kernels change their arithmetic with batch size, so identical greedy requests diverge. What matters for a finance design is the state of the knobs as of 22 October 2026:

• Anthropic: Claude Sonnet 5.5 returns a 400 error if you set temperature, top_p or top_k, according to its migration guide, and the API has no seed. You cannot even request greedy decoding.
• OpenAI: seed on Chat Completions is documented as beta and "best effort". Determinism "is not guaranteed", and you are told to watch system_fingerprint for backend changes. The Responses API parameters have no seed.
• Google: the Gemini seed is likewise "best effort".
• Self-hosted: bitwise-identical output is achievable at a cost. vLLM's VLLM_BATCH_INVARIANT=1 is in beta. SGLang's --enable-deterministic-inference averaged a 34% slowdown in its authors' tests (24 to 55%). Thinking Machines' reference kernels took 42 seconds against 26 for the same workload. You must also pin the weights, hardware, drivers and library versions, and any change to them breaks bit-identity.

So the design that works on every provider is to record and replay. Store each model reply keyed by the model version and the exact prompt, and feed it back when re-performing a period. Durable-execution engines (Temporal, DBOS, Restate) do this for every step by construction, which is why durable execution belongs in a finance agent's stack. Self-hosted deterministic serving is worth its cost only when you must regenerate rather than replay, for example to show that a pinned model, given last year's inputs, produces the same proposals today.

Step 7Do not demand determinism where it buys nothing.

Over-applying the boundary has its own cost. Research synthesis, first drafts of credit memos, triage of an exception queue, and answering a policy question for an employee are all probabilistic tasks whose output a person reads before acting. Forcing them through rules engines produces brittle systems that fail on the first unfamiliar document. The test from STEP 2 still applies: if a person or code checks the output before it has an effect, the step may be probabilistic. Spend the engineering on the steps where nothing checks it.

There is also the question of the baseline. The manual process you are replacing has its own error rate, and its four-eyes checks miss things too. The industry analysis takes up the argument that a model only needs to beat that baseline, and why it is incomplete. The short version: the boundary is what lets you compare error rates honestly, because it makes the model's errors visible.

Step 8Questions to ask of any finance agent design.

• List every output the model produces. For each one, what checks it, and does that check run before the output has an effect?
• Is there any number the model produces that is then used as a number? If so, why is that not code?
• What is the longest chain of unchecked probabilistic steps, and what is its compounded accuracy at your measured per-step rate?
• Can the agent be both maker and checker of anything, including through a tool that approves on its behalf?
• If an auditor asks you to re-perform last quarter, which recorded artefacts make that replay identical, and where are they kept?
• Which reconciling or exception categories are assigned by rule, and what happens to an item no rule claims?