How to Write Finance Prompts That Do Not Hallucinate

Hallucination in financial analysis is usually a specification failure rather than a model failure. When a prompt omits a definition, a period, or a rule for handling gaps, the model does not ask: it supplies the most statistically common answer and continues. Six instructions close most of those gaps.

What follows will measurably improve the output you get from any general-purpose model. It will not make that output safe to act on unverified, and the last section explains why.

1. Define every metric inline

This is the highest-value instruction, because metric names are far less standardised than they appear.

Net revenue retention has several accepted formulas. So do CAC, EBITDA, and churn. Ask for one without defining it and the model picks a definition that is defensible in general and wrong for your board pack.

Weak:

Calculate our net revenue retention for Q2.

Strong:

Calculate net revenue retention, defined as (starting cohort MRR + expansion − contraction − churn) ÷ starting cohort MRR, excluding customers acquired during the period.

The second version cannot be interpreted two ways.

2. State the fiscal calendar and comparison basis

If your fiscal year does not start in January, the model's Q2 is not your Q2, and it will not tell you it has assumed one.

Specify the period, the fiscal calendar, and what you are comparing against:

For FY2026 Q2 (our fiscal year begins 1 April), compared against the same quarter of the prior fiscal year.

Comparison basis matters as much as period. Trailing twelve months, year to date, and annualised last quarter produce three different growth rates from identical data.

3. Tell it to stop rather than estimate

This is the instruction that prevents the failure mode you are least likely to catch. Faced with a missing month, a model will interpolate. The interpolated figure looks exactly like a real one.

If any period, account, or field required for this analysis is missing from the data below, list precisely what is missing and stop. Do not estimate, interpolate, infer, or substitute a value.

The instruction to stop is doing the work. Without it, a model will report the gap and then helpfully proceed anyway.

4. Require the formula and the inputs

A number without its derivation cannot be verified except by rebuilding it, at which point the tool has saved you nothing.

For every number you produce, show the formula used and the specific input values substituted into it.

This has a second benefit beyond verification: requiring the working makes certain classes of error visible. A formula that is stated and then not followed is much easier to spot than a bare wrong number.

5. Require arithmetic as code

A language model predicts tokens. Asked to sum a column, it predicts what the sum probably looks like rather than computing it.

Perform all arithmetic as executable code rather than generating numbers directly in prose. Show the code alongside its output.

Where a code execution environment is available, this converts predicted arithmetic into real arithmetic and eliminates an entire error class. Where it is not, the instruction at least makes the calculation legible enough to check.

6. Separate assumptions from conclusions

Without this, assumptions are woven into the narrative and read as findings.

Before your conclusion, list every assumption you made in a separate section titled ASSUMPTIONS. Mark any figure whose value depends on an assumption.

This frequently surfaces the most important thing in the response. An assumption you disagree with is far more useful to see than a conclusion built on it.

A template that combines all six

You are analysing financial data for my company.
Use ONLY the data provided below.

DEFINITIONS - use exactly these, not standard ones:
  - [metric] = [your formula]
  - [metric] = [your formula]

PERIOD: [period], fiscal year begins [month].
Compare against: [basis].

RULES:
  1. Show the formula and input values behind every number.
  2. Perform arithmetic as code, not prose. Show the code.
  3. If any data is missing, list it and STOP. Do not estimate.
  4. List assumptions in a separate ASSUMPTIONS section.
  5. If the answer cannot be derived from the data below, say so.

OUTPUT: [table structure], then at most five bullets of commentary.

TASK: [your question]

DATA:
[paste your data]

Two things not to do

Do not ask for confidence scores. A model's stated confidence is not calibrated against its actual accuracy. A number reported as "high confidence" is not more likely to be right, and treating it as a signal is worse than having no signal.

Do not paste data you are not permitted to. Check your organisation's policy and the provider's retention terms. Consumer tiers have historically differed from enterprise agreements on whether inputs may be used for training.

Where prompting stops working

Everything above is worth doing and will improve your results. It is also a mitigation rather than a solution, and it is worth being precise about why.

The underlying issue is architectural. As long as the model is the thing producing the numbers, a proportion of them will be wrong, and none of them will look wrong. No instruction changes that, because the instruction is processed by the same mechanism that produces the error.

The structural fix is to remove arithmetic from the model's job entirely: let it interpret the question and plan the analysis, execute the calculation as code in a sandboxed environment, validate the output, and return the formula and source rows alongside the result. The model contributes language and planning, which it is genuinely good at. The numbers come from somewhere you can inspect.

That is the difference between a prompt that reduces risk and a system where the risk does not arise.

A template you can reuse

Most finance prompts fail in the same four places. This structure closes all of them, and it is short enough to keep in a snippet:

CONTEXT
  Fiscal year: [start month]. Currency: [X]. Entity: [Y].
  These accounts are excluded and why: [list].

DATA
  [paste]. Columns are: [name each one and its units].
  Amounts are [thousands / units]. Dates are [format].

DEFINITIONS
  [Metric] = [exact formula], using [named fields].
  Exceptions: [list].

TASK
  [One question. Not three.]

RULES
  Show the formula for every number.
  If the data cannot answer this, say so and stop.
  Do not estimate, infer, or fill gaps.
  Flag any row you could not use and why.

Why each rule is there

• Naming the units stops the most common silent error in finance prompts. A model that reads thousands as units will produce an internally consistent answer that is wrong by three orders of magnitude, and nothing in the output signals it.
• "Show the formula" converts an unverifiable claim into a checkable one. It also, in practice, reduces errors: a model asked to state its method commits to one rather than pattern-matching an answer.
• "Say so and stop" is the single highest-value line. Without explicit permission to fail, a model will produce an answer from whatever is available, and a confident answer built on missing data is the worst output it can give you.
• "Flag rows you could not use" catches the parsing failures (a date format it did not recognise, a currency symbol, a merged cell) that otherwise silently shrink your dataset.

Testing whether a prompt is safe

Three checks, each about a minute:

1. Delete a required column and re-run. The correct behaviour is to refuse. If it still answers, the prompt has not closed the gap and neither has the model.
2. Run the same prompt twice. Materially different numbers from identical inputs means the arithmetic is being generated rather than computed, and no amount of prompting fixes that.
3. Plant a known error. Add a duplicate row. If the total does not move, it is not reading what you think it is reading.

Where careful prompting stops working

Prompting closes the context gap. It cannot close the architecture gap.

However precisely you specify the task, a language model answering in prose is still predicting the number as text rather than executing a calculation. A well-written prompt makes that prediction much more likely to be right, which is worth real effort, and it does not make the number verifiable, because there is no calculation to inspect.

It also does not persist. Every constraint above has to be restated in full, every session, by every person, forever. That works until the one time somebody is in a hurry, and the failure surfaces in a board pack rather than in the chat window.

What to do with a prompt that keeps failing

If a prompt fails the three tests above after two rewrites, the problem is not the prompt. It is that the task needs a calculation rather than a prediction, and no amount of instruction converts one into the other.

At that point the useful move is to change the tool, not the wording: put the arithmetic somewhere it executes and can be inspected, and keep the model for the language around it.