Module 3 — Prompting Technique for Accountants

Prompting is a professional skill, not a trick

There is a persistent myth that getting good results from an LLM is about knowing secret phrases — magic words that unlock hidden capability. It is not. Getting good results is about communicating a task clearly and completely to a fast but literal-minded assistant that knows nothing about your situation except what you tell it. If you have ever written precise instructions for a new staff member — a preparer who is capable and quick but has never seen this client, does not know your firm's conventions, and will do exactly what you say rather than what you meant — you already have the instinct. Prompting is that skill, applied to a text generator that is faster, more literal, and more prone to confident error than any human junior.

The difference between a mediocre result and an excellent one is almost never the model. It is the prompt. This module gives you a reliable structure for writing good ones, a set of techniques that measurably improve output quality, and several before-and-after examples worked in the kind of detail you can copy into your own practice tomorrow.

The four-part structure: role, context, task, format

Nearly every effective prompt for professional work contains four elements. You will not always label them, but when a prompt disappoints, the fix is almost always a missing one of the four.

Role tells the model what expertise to bring and what stance to take. "You are a senior accountant reviewing a client's trial balance" primes the model toward the vocabulary, priorities, and conventions of that work. This is not the model becoming an accountant — it remains a next-token predictor — but the role framing steers it toward the region of language associated with careful professional analysis rather than casual conversation. The effect is real and worth the one sentence it costs.

Context is the specific information the model needs and does not otherwise have: the situation, the client's circumstances (de-identified), the constraints, the relevant facts, and the actual source material. This is the element amateurs skip and professionals lean on. The model cannot see your files, know your firm's positions, or infer the business's industry unless you say so. A prompt that says "explain the variance" gives the model nothing to work with; a prompt that provides the two periods' figures, notes that the entity is a dental practice, and mentions that a new location opened in the second period gives the model everything it needs to be useful. Context is where accuracy comes from — a model with the source material in front of it is transforming, which it does well; a model asked to supply facts from memory is recalling, which it does badly.

Task is the specific, unambiguous instruction: what you want the model to do, stated as an action. "Summarize," "draft," "list," "compare," "identify," "reformat." Vague tasks produce vague output. "Look at this" is not a task; "list the five largest month-over-month account changes and, for each, propose one plausible explanation to investigate" is. The more precisely you specify the action and its scope, the more the output matches what you actually needed.

Format tells the model how to structure the response: a table with named columns, a bulleted list, a formal paragraph, JSON, a specific length. Accountants work in structured outputs, and specifying the structure both makes the result immediately usable and constrains the model in helpful ways. "Give me a table with columns Account, Prior, Current, Change, Percent Change, Possible Cause" produces something you can drop into a workpaper; "tell me about the changes" produces prose you have to re-organize.

Here is the structure assembled into one prompt, so you can see the parts working together:

Role: You are a senior accountant reviewing a client's month-over-month
general ledger for anomalies.

Context: The client is a single-location coffee roaster. Below are the
account balances for May and June. A wholesale account was signed in June.
[paste the de-identified account balances here]

Task: Identify the accounts with the largest dollar and percentage changes
between the two months. For each, state whether the June wholesale account
could plausibly explain it, and flag any change that it does not explain as
something to investigate.

Format: A table with columns: Account, May, June, $ Change, % Change,
Explained by wholesale? (Yes/No), Note. Below the table, list the top three
items to investigate, most important first.

That prompt will outperform "review these numbers and tell me what looks off" by a wide margin, every time, on every model, because it supplies all four elements the model needs and leaves far less to chance.

Few-shot prompting: show, don't just tell

One of the highest-leverage techniques for accounting work is few-shot prompting — giving the model one or more worked examples of the input-to-output transformation you want before asking it to do the real one. The model is exceptionally good at pattern continuation, so a concrete example of "when the input looks like this, the output should look like this" often communicates your intent better than any amount of description.

Suppose you want the model to classify expense descriptions into categories using your firm's specific scheme. Rather than describing the scheme in the abstract, show it:

Classify each expense description into one of these categories: Office
Supplies, Software, Professional Fees, Meals, Travel.

Examples:
"Staples - printer paper and pens" -> Office Supplies
"Annual QuickBooks subscription" -> Software
"Lunch with client, Riverside deal" -> Meals
"Delta flight to Chicago conference" -> Travel

Now classify these:
"Adobe Acrobat license renewal" ->
"Uber to airport" ->
"Legal review of lease agreement" ->

The examples pin down the boundaries far more precisely than prose could — they show the model that a software subscription is "Software" not "Office Supplies," and that a client lunch is "Meals" not "Professional Fees." Few-shot examples are especially powerful when your task follows firm-specific conventions the model could not know, when the desired output format is particular, or when there are edge cases you want handled a certain way. Two or three good examples are usually enough; you are demonstrating a pattern, not building a training set.

Ask for citations and for the model to show its work

Two requests dramatically improve both the quality and the checkability of output, and you should build them into your habits.

First, ask the model to show its reasoning — to work through the problem step by step rather than jumping to a conclusion. For any task with intermediate steps, "explain your reasoning as you go" or "show the steps you took to reach this" tends to produce more accurate results, because the model commits to a chain you can inspect rather than pattern-matching straight to an answer. More importantly for a professional, it produces a reviewable artifact: you can see where the reasoning went wrong instead of just seeing a wrong answer with no trail. When a conclusion depends on a calculation, ask to see the calculation. When a classification depends on a rule, ask which rule and why it applies.

Second, ask the model to ground its statements in the source you provided and to cite where each claim comes from. "For each figure in your summary, cite the line of the document it came from" turns an unverifiable summary into one you can spot-check in seconds. This technique has a second, subtler benefit: it constrains the model toward the source material and away from invention, because you have asked it to point at where each claim lives. It does not eliminate hallucination — a model can still cite a line that does not say what it claims — but it makes hallucination visible, which is most of the battle. We return to citation discipline as a full workflow in Module 5, because for tax and accounting research it is the single most important guardrail.

A caution that belongs right next to this technique: asking a model to cite is not the same as the citation being real. When the source is a document you provided and in the window, citations to it are checkable and usually reliable. When you ask a model to cite external authority from its own memory — a Code section, a case, a standard — you have entered the highest-risk zone for fabrication, and every such citation must be verified against the actual authority before it is used. The request for a citation is a tool for your verification, not a substitute for it.

Iteration and verification prompts

The first response is rarely the final one, and treating prompting as a conversation rather than a single shot is a large part of the skill. When output is close but not right, refine in place: tell the model what to change. "Good, but make the tone more formal and cut it to two paragraphs." "The third item is wrong because the wholesale account started in June, not May — redo the table with that corrected." The model retains the conversation in its context window, so you are editing a shared draft, not starting over. This iterative refinement is often faster than trying to write one perfect prompt, and it lets you steer toward exactly what you need through a few rounds.

A specific and underused move is the verification prompt — asking the model, in a fresh step, to check its own or a document's claims. After a model summarizes a document, "Review your summary against the source and flag any statement that the source does not directly support" will sometimes surface the model's own hallucinations. After you draft something, "Read this memo as a skeptical reviewer and list every claim that would need a source before I could rely on it" turns the model into a checklist generator for your own review. These do not replace your review — the model checking itself is still a fallible text generator — but they add a cheap first pass that catches obvious problems and organizes your verification.

Guardrail phrasing: telling the model what to do when it does not know

A small set of phrases meaningfully reduces confident fabrication, and they cost nothing to include. The core move is to give the model permission and instruction to admit uncertainty, because left to its default it will generate a plausible answer rather than decline. Add lines like:

• "If the document does not contain the answer, say 'not found in the source' rather than guessing."
• "If you are not certain, say so and explain what you would need to be certain."
• "Do not invent figures, dates, or citations. Use only what is in the material I provided."
• "List anything you were unable to determine from the information given."

These instructions genuinely change behavior. A model told to flag what it cannot determine will more often flag it, rather than papering over the gap with invention. For accounting work, where a missing figure is a fact you need to know and a fabricated one is a landmine, this framing is not optional polish — it is a core control. Notice how it pairs with the human-in-the-loop principle: the model surfaces its uncertainty, and you, the professional, resolve it.

Before and after: worked improvements

The techniques above are best absorbed by watching weak prompts become strong ones. Here are four, in the accountant's daily register.

Example 1 — from vague to structured.

Before: Summarize this bank statement.

After:

You are an accountant preparing a reconciliation. Below is a de-identified
bank statement. List every transaction over $5,000 in a table with columns:
Date, Description, Amount, Type (deposit/withdrawal). Below the table, total
the deposits and total the withdrawals separately. If any transaction's
purpose is unclear from its description, add it to a short "Needs
clarification" list. Do not infer amounts that are not printed on the
statement. [paste statement]

The "before" gets you an unpredictable paragraph. The "after" gets you a workpaper-ready table, two control totals, a clarification list, and an instruction against invented figures — all from adding role, format, and a guardrail.

Example 2 — from open-ended to few-shot.

Before: Categorize these transactions.

After:

Categorize each transaction using exactly these categories: COGS, Payroll,
Rent, Utilities, Marketing, Other. Examples:
"Gusto payroll run 6/15" -> Payroll
"Facebook Ads" -> Marketing
"PG&E electric" -> Utilities
Now do these, and for any you are unsure about, put "Other" and add a note:
[paste transactions]

The examples fix the category boundaries; the uncertainty instruction keeps guesses out of the confident categories.

Example 3 — from "trust me" to "show your work."

Before: Is this journal entry correct?

After:

Here is a proposed journal entry and the underlying transaction description.
Walk through, step by step, whether the debits and credits are appropriate
and whether they balance. Show the debit total and credit total explicitly.
State your conclusion only after showing the steps. If the transaction
description is too vague to judge, say what additional detail you would need.
[paste entry and description]

You now get a reviewable chain and explicit totals instead of an unverifiable yes.

Example 4 — from fabrication risk to grounded.

Before: What's the depreciation recovery period for a commercial roof?

After:

Explain, in general terms, how the recovery period for a commercial building
component like a roof is typically determined, and what factors an accountant
would check. Do not cite specific Code sections, Revenue Procedures, or case
names unless you are certain they are real; if you reference authority,
mark it as "to be verified against the primary source." Frame this as
background for a professional who will confirm the treatment independently.

The "before" invites a confident answer possibly wrapped around a fabricated citation. The "after" gets you usable background framed as something to verify, with the citation risk defused by instruction. Note the pattern: we did not ask the model to be the authority; we asked it to help us understand what to go confirm.

System prompts, reusable templates, and prompt chaining

Three techniques take you from writing one-off prompts to building repeatable firm processes, and they are where prompting starts to feel like engineering a workflow rather than chatting.

The first is the reusable prompt template. Once you have written a strong prompt for a recurring task — a variance narrative, a PBC list, a reconciliation triage — do not rewrite it each time. Save it with clearly marked placeholders for the parts that change, exactly as the workflow prompts in the next two modules are written, and fill the placeholders for each client. This does three things: it captures the effort of getting the prompt right so you spend it once, it standardizes the output across your staff so everyone's variance narrative has the same structure, and it makes the prompt itself reviewable — a good template can be improved over time as you learn what it gets wrong. A firm's library of vetted prompt templates is a genuine asset, and building one is a large part of what "adopting AI" concretely means.

The second is the system prompt, a concept some tools expose directly. A system prompt is a standing instruction that applies to an entire conversation or an entire tool configuration, setting persistent rules the model should follow throughout — the firm's tone, standing guardrails like "never invent citations," a reminder to flag uncertainty, the format conventions the firm prefers. Where a task prompt says "do this now," a system prompt says "here is how you should always behave here." If your tool supports it, encoding your firm's standing guardrails once in a system prompt means you do not have to repeat "do not fabricate figures" in every task prompt — though repeating a critical guardrail even when it is in the system prompt does no harm and adds safety.

The third is prompt chaining — breaking a complex task into a sequence of prompts, each handling one step and feeding the next, rather than asking for everything at once. A model asked to read a document, extract figures, analyze them, and draft a client memo in a single prompt will do each step less well than a model asked to do them one at a time, with you checking the output of each step before proceeding. Chaining also inserts natural review points: you verify the extraction before it flows into the analysis, so an early error does not silently propagate to the final memo. For any multi-step professional task, chaining with review between steps is both more accurate and more auditable than a single mega-prompt, and it mirrors how you would supervise a junior through the same work — one reviewed step at a time.

A prompting checklist you can keep at your desk

Before you send a prompt for real work, run it against six questions:

1. Role — have I told the model what expertise and stance to bring?
2. Context — have I given it the actual source material and situation it needs, de-identified?
3. Task — is the instruction a specific, unambiguous action with a defined scope?
4. Format — have I specified the structure I want back?
5. Grounding — have I asked it to use only the material provided, to show its work, and to cite the source for figures?
6. Guardrail — have I told it what to do when it does not know, and told it not to invent figures or citations?

If all six are present, you have written a professional prompt, and the output will reflect it. If the result still disappoints, the fix is almost always to strengthen one of these six, not to change tools. This is a learnable, repeatable skill, and it is the foundation the workflow library rests on. The next two modules put it to work across ten concrete accounting workflows, each with a copy-paste prompt built on exactly this structure — and each ending, as always, with the professional's review.