A Four-Part Prompt Structure for Financial Variance Commentary (That Actually Holds Up)

Prompt engineering discussions online skew heavily toward code generation and RAG pipelines. There's a whole category of repetitive, structured business writing that gets almost no attention, and it turns out the same discipline (explicit roles, grounded data, defined constraints, strict output format) applies just as directly.

Case in point: financial variance analysis commentary. It's the short written explanation that accompanies a budget-versus-actual comparison in a monthly report. Structurally, it's a great fit for LLMs: the reasoning pattern (compare, flag, explain, ask a follow-up) repeats every period with only the numbers changing. It's also a task where a naive prompt fails in a very specific, very common way.

The failure mode

Prompt: "Explain why our expenses went up this month."

No data. No threshold. No constraint. The model produces a fluent, plausible, entirely fabricated explanation, because it has nothing else to base an answer on. This is the equivalent of asking an LLM to write a commit message with no diff attached. It'll comply. The output just won't mean anything.

The four-part structure that fixes it

1. Role and audience
Different personas produce meaningfully different output. "You are a financial controller" writing "for the CFO" reads differently than "you are a staff accountant" writing "for internal review." State both explicitly, every time. This is the same principle behind role-based system prompts in any agentic setup, specificity in the persona narrows the output distribution toward what you actually want.

2. Grounded input data
Paste the actual table. Not a text description of it. This is the single highest-leverage change you can make to any data-analysis prompt: never let the model infer numbers it wasn't given. If your data lives in a spreadsheet, copy the relevant rows as plain text or a simple markdown table directly into the prompt.

3. Explicit constraints (threshold + context)
Set a materiality threshold ("flag anything over 5% or $10,000") and supply any known context. Critically: instruct the model to state "no context provided" rather than infer a cause when you haven't given it one. This is functionally similar to telling an LLM "say you don't know" in a RAG setup to reduce hallucination, applied to structured financial reasoning instead of retrieval.

Anthropic's own prompting documentation makes a related point about structure: separating data, context, and instructions clearly (plain labels or XML-style tags) reduces the model conflating what's data versus what's directive, which matters a lot once your prompt contains a full table plus written notes. Reference

4. Output format
Specify the exact structure: table, numbered list, sentence-count cap per item. Financial readers scan for numbers and causes. A wall of unstructured prose defeats the purpose of automating this in the first place.

A working template

You are a senior accountant drafting expense variance notes for the monthly
close workpaper. Audience: the controller, for internal review before the
report goes to the CFO.

Expense data:
[Account | Budget | Actual | Variance $ | Variance %]

Known drivers: [anything you already know, or leave blank]

Instructions:
1. Flag every account where actual spend exceeds budget by more than 8%.
2. For each flagged account, write one sentence describing the variance
   and one sentence suggesting a specific follow-up question.
3. Do not suggest a root cause unless it was provided in known drivers.
4. Format as a numbered list, one entry per flagged account.

Things worth knowing before you productionize this

• LLMs are not calculators. Any arithmetic the model performs, percentage calculations, multi-step totals, needs independent verification. Treat model output as an unverified first draft, same as you'd treat a PR from a new contributor.
• Recurring, explainable variances need a standing context block. Payroll timing, annual renewals, seasonal patterns, these repeat every cycle. Without a persistent note describing them, the model re-flags the same non-anomaly every single period, which trains the reader to stop trusting the flags at all.
• Format consistency differs meaningfully by model. In testing across long, multi-section reports, Claude tends to hold a specified format more reliably than general-purpose chat interfaces, useful if your report has ten-plus line items needing identical structure. Shorter, single-section reports work fine with any of the major tools.
• Data handling terms differ by account tier. If real client financial data is going into any of these prompts, check whether you're on a business/enterprise tier with defined data retention terms before pasting anything identifiable.

Full writeup

I wrote a longer version of this with separate templates for revenue, cost of goods sold, and cash flow variances, a tool comparison table, and a full FAQ section: AI Prompts for Variance Analysis Commentary

If you're interested in the adjacent problem, agent-based automation of the reconciliation and categorization work that precedes variance analysis, I covered that separately here: AI Agents for Month-End Close in Small Firms

Would be curious if anyone here has built this into an actual pipeline (API call triggered off a reconciled ledger export, rather than manual copy-paste into a chat interface). That's the natural next step and I haven't seen much written about the productionized version of this specific workflow.