Blog

ChatGPT Prompts for Accountants, and the Review Each One Needs

Seven copy-paste ChatGPT prompts for accountants, each with the input to hand it, the inference to forbid, and the check a reviewer runs before it ships.

Accountably Editorial Team 13 min read Updated 2026-08-14

Published lists of ChatGPT prompts for accountants tend to be one clever sentence each, and the sentence is the easy part. What decides whether the output is usable is what you hand the model along with it, what you forbid it to work out on its own, and whether the answer arrives in a shape a reviewer can compare against the source without redoing the job. The federal standards agency has a name for the failure that design defends against: confabulation, the confident delivery of a wrong answer. Seven prompts follow, each with the check that has to clear before the output leaves your firm.

What a Prompt Has to Carry Before It Is Worth Running

A prompt worth pasting twice carries four things. Drop any one of them and you get a draft that reads well and takes longer to check than it took to write.

A role and a stated boundary. Naming the job the model is doing narrows the register and the vocabulary, and naming what the job is not stops the drift into advice. "You are abstracting a contract into fields, you are not concluding on classification" is a boundary. "Act as an expert accountant" is a job title with nothing attached to it.

The input itself, in a format you describe. The model should be reading your trial balance extract, your workpaper, your manager's answer. Telling it what the columns are, what order they sit in, and what has been removed is what separates reading from recalling.

The inference you forbid. This is the part that protects the file, and a one-sentence prompt has no room to carry it. Say plainly what the model may not work out for itself: a cause it cannot see in the data, a fee you did not state, a renewal probability, a clause you did not ask for.

The output shape, named precisely. Not "make it clear" but the exact object you want back: a table with these columns, one row per source line, nothing above it and nothing below it. A shape you named is a shape you can check.

Confabulation Is the Failure You Are Designing Against

The National Institute of Standards and Technology, the federal agency that writes measurement and technology standards, publishes a risk profile for generative AI. Its numbered risk list defines confabulation as "the production of confidently stated but erroneous or false content," and its own section on the term, at section 2.2, adds that confabulations "also include generated outputs that diverge from the prompts or other input or that contradict previously generated statements in the same context" (NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024).

Two words there are worth sitting with. The first is confidently, which is why a bad output does not look like a bad output. The second is diverge, because the failure includes answers that quietly leave the material you supplied, and that is what a firm cannot afford in a client-facing draft.

The same section says where the risk concentrates, and it reads like a description of accounting work: the dynamic is particularly relevant for "open-ended prompts for long-form responses and in domains which require highly contextual and/or domain expertise" (NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024). Open-ended and long-form is what a one-sentence prompt asks for. Narrow, structured and short is the countermeasure you control.

One more line there changes how a reviewer should read output. Generative outputs "may also include confabulated logic or citations that purport to justify or explain the system's answer," and large language models "sometimes provide logical steps for how they arrived at an answer even when the answer itself is incorrect" (NIST AI 600-1, Generative Artificial Intelligence Profile, July 2024). The explanation attached to an answer is not evidence for the answer. Treat a confident rationale as decoration until the figures tie.

An Output Shape Is a Verification Shortcut

The point of naming the shape is not tidiness. Verification cost is what decides whether any of this saves time, and shape is the lever you have on it. Three properties do the work.

Mirror the unit of the input. One row per account, one item per workpaper step, one field per clause. When the output shares the input's unit, checking is a comparison rather than a reading, and a missing row is visible instead of silent.

Force an explicit marker for absence. "Not stated," "cause not in data," "evidence not shown." Without a required token for the gaps, a model fills them, and a filled gap is indistinguishable from a real answer until someone traces it. With the token, the gaps are the first thing a reviewer sees.

Forbid anything outside the shape. No preamble, no summary, no helpful extra column. Every sentence outside the named shape is a sentence a reviewer has to evaluate, and it was not asked for.

Shape is not an approval gate. Deciding which actions software may commit without a person, and under whose login, is a separate question that arrives once a tool can act rather than answer, and it has its own answer.

Seven ChatGPT Prompts for Accountants, and What the Reviewer Confirms

Each prompt states a role, the input and its format, an explicit constraint, and the shape of the answer. Paste one, replace the angle-bracket fields with your own material, and run the reviewer step that follows it.

Variance Narrative From a Trial Balance

Month-end commentary is a good first candidate because the answer is fully contained in what you paste, so an invented driver has nowhere to hide from a reader holding the same material.

``` Role: You are a senior accountant preparing a month-end variance narrative for an internal reviewer.

Input: A trial balance extract, pasted below. Column one is the account label, column two is the current period, column three is the prior period. Account names have been replaced with generic labels.

Constraints: - Use only the numbers in the pasted extract as your inputs. Do not estimate, do not annualize, and do not infer a cause you cannot see in the data. - Where a driver is not visible in what I pasted, write "cause not in data" for that line rather than proposing one. - Repeat every pasted figure exactly as pasted. The only numbers you may produce are change and percent change: give change to the same decimals as the pasted figures, and percent change to one decimal.

Output shape: A table with one row per account that meets the threshold test below, and these columns: account label, current, prior, change, percent change, driver. The driver column holds either "cause not in data" or one sentence quoted from the notes I paste. Nothing above the table and nothing below it.

Threshold: include an account only where the absolute change exceeds or the percent change exceeds . Apply both tests and include the row if either is met.

Trial balance extract: Notes, if any: ```

What the reviewer confirms. That every pasted figure in the table matches the extract, that every populated driver quotes a note that actually exists, and that change and percent change recompute correctly on every row, since those two columns are the only numbers the model produced rather than copied. The rows marked "cause not in data" are the working list, not a defect in the output.

Engagement Letter First Draft

An engagement letter is a legal document, so the constraint here is doing less rather than more. It is written to produce a first draft for the partner to review, and for counsel where the firm uses one, and to surface what is missing instead of papering over it.

``` Role: You are drafting the first version of an engagement letter for a US accounting firm. You are not giving legal advice.

Input: The service description, the period covered, the fee basis, the deliverable list, and the firm's standard clause headings, all below.

Constraints: - Write only clauses that correspond to a heading I gave you. Do not add a clause I did not list, including limitation of liability, indemnification, arbitration, or termination. - Do not state a fee, a rate, a deadline, or a scope item that is not in my input. - Where my input is silent on something a clause needs, insert the line "OPEN: " and carry on.

Output shape: The clauses in the order of my heading list, each under its own heading, followed by a single consolidated list of every OPEN item. No cover note, no commentary. ```

What the reviewer confirms. That the scope, period and fee basis match what the firm agreed, that no clause appeared without a heading behind it, and that every OPEN item is resolved by a person before the letter goes out.

Client Email Explaining a Balance

Client email is where a helpful extra sentence becomes a commitment the firm did not make, so the forbidden inference is the load-bearing part of this one.

``` Role: You are writing a short client email for a firm reviewer to approve and send.

Input: The account, the balance, the period, the reason for the movement, and the one thing I need the client to do next, all below.

Constraints: - Explain only the reason I gave you. Do not offer a second possible explanation, a tax consequence, or advice I did not write. - No apology, no prediction about future periods, and no commitment to a date I did not give you. - Plain English for a business owner who is not an accountant. Define any accounting term the first time it appears.

Output shape: A subject line, then a body under 150 words, then one closing question asking for the single item I need back. Nothing else. ```

What the reviewer confirms. That the balance and period tie to the ledger, that the stated reason is the firm's actual conclusion, and that the email promises nothing about timing or outcome that has not been agreed internally.

Review Checklist Built From a Completed Workpaper

This one turns work you already did into a repeatable step for next period, and it is safer than asking for a checklist from scratch because every item has to trace to something visible.

``` Role: You are turning one completed workpaper into a review checklist another preparer can follow next period.

Input: The workpaper below, with client identifiers removed.

Constraints: - Every checklist item must correspond to a step visible in the workpaper. Do not add steps from general practice. - Do not name a software product, a standard, or a regulation unless the workpaper names it. - Keep the order the workpaper follows.

Output shape: A numbered list. Each item is one action written in the imperative, followed in parentheses by the tie-out or evidence the preparer must attach. Where a step in the workpaper shows no evidence, write "evidence not shown" in the parentheses. ```

What the reviewer confirms. That each item traces to a step in the source workpaper, and that the "evidence not shown" entries get a decision, because those are the places the current process is running on memory. A close checklist you already maintain is the benchmark to compare the output against.

A Technical Answer Rewritten for a Non-Accountant

Rewriting is one of the safer uses of a model in a firm and one of the easiest to get wrong, because a rewrite that improves the prose can quietly move the conclusion.

``` Role: You are rewriting an answer a manager has already written, for a client who does not work in accounting.

Input: The manager's answer, below, unchanged.

Constraints: - Change wording only. Do not add a fact, a number, a condition, or a caveat that is not in the original. - Do not soften or strengthen a conclusion. If the original says "may", it stays "may". - Keep every figure, date, and defined term exactly as written.

Output shape: Two blocks. First, the rewritten answer. Second, a list titled "Possible meaning changes" naming any sentence where you were not certain the rewrite preserved the original meaning. ```

What the reviewer confirms. The manager reads the "Possible meaning changes" list before reading the rewrite, then checks the figures and the hedges against the original. A hedge that disappeared is the defect to hunt.

A Job Description for a Role You Are Actually Filling

Hiring copy is where invented requirements enter a firm, and they are expensive because they filter out candidates who could have done the job.

``` Role: You are drafting a job description for a US accounting firm.

Input: The task list for the role, the software it uses, the review layer above it, the working hours, and the location policy, all below.

Constraints: - Every responsibility must map to a task I listed. Do not add duties, and do not add "other duties as assigned". - Do not invent a credential requirement, an experience figure, a pay range, or a benefit. - Mark each requirement as either required or preferred, never both. - Where my input is silent on something a section needs, write "not supplied" in that spot rather than filling it.

Output shape: A role summary in three sentences, then Responsibilities, then Required, then Preferred, then What This Role Does Not Do. ```

What the reviewer confirms. The person who will review this hire's work confirms that the responsibilities match the real task list, that What This Role Does Not Do is accurate, and that every "not supplied" has been resolved. Compare the result against a description written from the actual job before it is posted.

A Lease Abstracted Into Fields

Abstraction is a good fit because the answer is quotation rather than judgment, and the judgment stays with the accountant.

``` Role: You are abstracting one lease contract into fields for an accounting file. You are not concluding on classification.

Input: The lease document below.

Constraints: - Fill a field only from text in the document. Do not infer a renewal probability, a discount rate, or a classification. - Give the clause reference for every field you fill. - Where the document does not state a field, write "not stated" and nothing else in that field.

Output shape: A two-column table. Column one is the field name from my list. Column two is the value followed by the clause reference in parentheses. Field list: commencement date, initial term, renewal options and who holds them, termination rights, fixed payments, variable payments and their index, residual value guarantee, purchase option, restrictions or covenants. ```

What the reviewer confirms. That every filled field carries a clause reference that exists, and that the "not stated" rows are genuinely absent from the document. Discount rate, renewal assessment and classification are decisions the accountant makes under the lease standard, never fields a model fills.

Before You Paste Anything a Client Can Be Identified From

Sending client material to an outside tool is a disclosure decision, not a convenience decision, and the rules that govern disclosing a client's tax return information to an outside service provider do not stop applying because the provider is a chat window. That is why every prompt here runs on an extract with identifiers stripped, and why the input is described rather than dumped. What consent looks like, and when it has to be signed, sits with the rules a firm already follows before work goes to any outside provider. Whether the vendor is itself a tax return preparer, and where its processing physically happens, are the questions that decide whether consent is needed at all, and they are worked through where AI and offshore help are compared.

The practical version is short. Strip names, account numbers and anything that reconstructs them before pasting. Check what your subscription does with the content you submit, and check it at the account level rather than trusting the marketing page. Keep the source document inside your own systems, because the file, not the chat log, is what a reviewer and a regulator will ask for.

When a Better Draft Does Not Help

There is an honest limit here worth naming. A prompt improves the draft, not the queue. Where the binding constraint is review capacity rather than drafting speed, a cleaner first draft still lands with the same reviewer, faster drafting fills the queue faster, and the deadline does not move. That is a staffing question wearing a technology costume, and the answer to it is more review capacity, not a better prompt.

Questions Firms Ask

Can You Use ChatGPT for Accounting Work?

For drafting, restructuring and abstracting, yes, under the constraints above. For concluding, no. The judgment, the position taken, and the signature stay with the person whose name goes on the work, and nothing about a well-written prompt changes who is answerable for the file.

Why Did the Output Look Right and Still Turn Out Wrong?

Because confident presentation is a property of the system rather than a signal about the answer, which is what the confabulation definition names. The fix is structural: give the model the data instead of asking it to recall, forbid the inferences you cannot check, and demand a shape that makes a wrong answer visible next to its source.

What Should Never Go Into a Prompt?

Client identifiers, credentials, anything covered by a confidentiality agreement, and any material you would not be comfortable describing to the client as having left your systems. Hold back the conclusion you are hoping for as well. Ask for the analysis, then compare it against what you expected, rather than handing over the answer and asking for the support.

Write the Check Before You Write the Prompt

Decide what a reviewer will confirm, then write the prompt that makes confirming it fast. The order matters more than the wording, and it holds outside the chat window too: a preparer who knows the exact check their work will face produces work that passes it.

That is the same standard a firm should apply to any capacity it adds. Don't trust us. Test us. Our Free 40-Hour Proof Pilot runs a fixed block of your own representative work through the full review chain, so your reviewer grades real output before a client file is committed. See how the pilot works.

See the work before your name is on it

Run a Free 40-Hour Proof Pilot on your own representative work, through full multi-layer review, before a single client file moves.