A good AI prompt for internal audit does three things: it fixes the output format, it limits the tool to the facts you supply, and it forbids invented citations. Most prompts auditors try do none of the three, which is why the answer reads well and cannot go into the file.
This guide explains why prompts fail, sets out the parts of one that works, and gives six worked prompts from our free library, each with the shape of a good answer. They work in ChatGPT, Claude, Copilot, Gemini or whichever assistant your organisation has approved.
Start here:
| You want | Use |
|---|---|
| A prompt for any audit stage and process cycle, with a copy button | Internal Audit AI Prompt Library |
| All 110 prompts in one Excel file, with an AI use log | The Excel download on the same page |
| Somewhere to put the checked answer | RCM Builder, Walkthrough Memo Generator, Sampling Plan Generator, Observation Report Generator, ATR Tracker |
| Tool-specific set-up | ChatGPT for internal audit, Claude for internal audit |
Why most internal audit prompts fail
No format. "Prepare an RCM for procure-to-pay" returns an essay, or a table whose columns change every time you ask. Nothing maps to your working paper template.
No data boundary. The prompt does not say what the tool may use, so the answer blends the process note you pasted with what the model knows about purchase processes in general. A control that exists only in that general knowledge now sits in your RCM as if the company performs it.
No instruction about citations. Ask about cash payments, payroll deductions or related-party approvals and a section number, a limit or a due date appears, stated with confidence. An invented number looks exactly like a real one. The patterns are catalogued in AI hallucinations in audit.
A fourth failure follows: the prompt lets the tool make the auditor's decisions. It rates the observation, suggests a sample size, marks a control as key.
The anatomy of a good internal audit prompt
Every prompt in the library has the same six parts: a role line that says who decides; a task of one or two sentences; starting points for the cycle (sub-processes, risk themes, expected controls, records, common exceptions), labelled as general; the output format; the rules; and a description of what you paste.
The role line and the first four rules are identical in every prompt:
ROLE
You are assisting an internal auditor in India. The work relates to
[cycle] of [industry] company. The books are kept in [Tally / SAP /
other]. I am the auditor: you draft and structure, I verify every fact
and I decide every rating and conclusion.
RULES
1. Use only the facts in MY INPUT. The starting points above are general,
not facts about this company; anything you take from them that my
input does not confirm must be marked [ASSUMPTION].
2. Mark every other assumption as [ASSUMPTION] at the place where you
make it.
3. Do not invent section numbers, rule numbers, standards paragraphs,
thresholds, rates, due dates, circulars or case law. Where law, a
standard or a company policy seems relevant, describe the topic in
words and write TO BE VERIFIED.
4. If a fact you need is missing, do not fill it in. List what you need
under QUESTIONS FOR THE AUDITOR before the output, and write NOT
PROVIDED where the fact would have gone.
To save space, the six prompts below show the task, the output format and the stage rules, lightly shortened and without the cycle starting points. Put the role line above each and rules 1 to 4 before the stage rules, or copy the full assembled version from the prompt library.
Six worked prompts
The examples of output are illustrative. They show the shape of a good answer, not a real company or a real result.
1. RCM from a process narrative (order-to-cash)
TASK
Draft a risk and control matrix for the order-to-cash cycle from the
process narrative in my input. Record only the controls my input
describes, and show me where an expected control is missing.
OUTPUT FORMAT
- One table. Columns: Sub-process | Risk | Control (as described in my
input) | Control objective | Control type and frequency | Test of
design | Test of operating effectiveness | Evidence.
- Where my input describes no control for a risk, write CONTROL NOT
EVIDENCED IN INPUT and leave the test columns blank.
- After the table, list under EXPECTED BUT NOT DESCRIBED any control
from the checklist that my input does not mention.
STAGE RULES
5. One control per row.
6. Write each test so that a second auditor could repeat it: what to
obtain, what to compare, what counts as a failure.
7. Do not mark any control as key and do not rate any control. I will.
MY INPUT
Process narrative (roles, not names) and the delegation of authority
extract: [paste here]
A good answer (illustrative) is as useful for what it refuses to fill in:
| Sub-process | Risk | Control | Objective | Test of operating effectiveness |
|---|---|---|---|---|
| Credit limits | Sales beyond approved credit | Orders above the limit are held until the finance manager releases them | Authorisation | For held orders in the period, obtain the release record; compare releaser role and date with dispatch date; fail if dispatched before release |
| Credit notes | Unauthorised credit notes | CONTROL NOT EVIDENCED IN INPUT |
2. Walkthrough questions (hire-to-retire)
TASK
Prepare me for the walkthrough of the hire-to-retire (payroll) cycle:
one transaction followed from start to finish.
OUTPUT FORMAT
- Table 1, Questions. Columns: Step | Sub-process | Question to ask |
Document, screen or report to see | Control being confirmed | What a
design gap would look like.
- For each control, one question on what happens when the approver is
absent, the step is urgent, or the system check is overridden.
- Table 2, One transaction end to end. Columns: Stage | Document to
collect | What to note on it.
- Then a memo skeleton with headings only.
STAGE RULES
5. Write open questions (how, who, what happens when).
6. Do not fill in the memo. I complete it from what I see and hear.
7. Do not invent menu paths, screen names or transaction codes.
MY INPUT
RCM extract, the roles I am meeting, and prior-year observations on
this process: [paste here]
Illustrative output: "Step 3, employee master changes. Question: when a salary revision is entered, who sees it before the next payroll run, and what do they compare it with? Ask to see: the master change report for one month, with the reviewer's sign-off. Design gap: the person who enters the change also reviews the report."
3. Test design and sampling rationale (cash and bank)
TASK
Design the tests of operating effectiveness for the controls in my
input, for the cash and bank cycle. For each control give the test as a
sample test and, where the control leaves a data trail, as a test
across every transaction. Then draft the sampling rationale.
OUTPUT FORMAT
- Table 1, Test design. Columns: Control | Population and source | How
to confirm the population is complete | Attributes to test (numbered)
| What counts as an exception | Evidence to retain | Full-population
test in words, or NOT POSSIBLE with the reason.
- Table 2, Sampling rationale. Columns: Control | Unit of testing |
Period | Basis of selection with the reason | Suggested strata |
Sample size: AUDITOR TO DECIDE | Treatment of exceptions.
STAGE RULES
5. Do not propose a sample size, quote a sample-size table or calculate
one.
6. Do not select the sample. Selection is done by me in a spreadsheet so
that it can be repeated.
7. Each attribute must test whether the control operated, not only
whether the transaction turned out right.
MY INPUT
Controls with frequency and evidence, each population described with
its count, the risk rating, my sampling methodology: [paste here]
Illustrative output for a monthly bank reconciliation control: attributes "1. Reconciliation prepared for the month. 2. Reviewer is not the preparer. 3. Review dated before the next month's close. 4. Items older than one month carry an explanation." Full-population test: all twelve reconciliations for each account, since the population is small. Sample size: AUDITOR TO DECIDE.
4. Observation in five parts (procure-to-pay)
TASK
Draft one internal audit observation for the procure-to-pay cycle from
the verified facts in my input.
OUTPUT FORMAT
- Title: one line that states the condition, not the topic.
- Then, in this order: Condition | Criteria | Cause | Effect/Risk |
Recommendation.
- Then: Management response | Owner (role) | Target date. Write TO BE
OBTAINED FROM MANAGEMENT against each of the three.
- Then a table headed SOURCE TRAIL. Columns: Sentence | Fact from my
input that supports it.
STAGE RULES
5. Criteria: quote only the policy clause, contract term or requirement
I supply. If I supply none, write CRITERIA TO BE CONFIRMED BY AUDITOR.
6. Cause: state it only if my input establishes it. Otherwise write
CAUSE NOT YET ESTABLISHED and list the two questions that would
establish it.
7. Effect/Risk: keep actual loss and exposure apart, and use only my
figures.
8. Recommendation: address the cause, not only the instances found.
9. Do not rate the observation. Roles, not individuals.
MY INPUT
Verified facts with counts and amounts, the exact criteria text, the
cause as confirmed with the process owner: [paste here]
The source trail is what makes this prompt different. Illustrative lines: "'In 9 of 240 vendor bank account changes, no call-back was recorded.' Supported by: input line 2." and "'This exposes the company to payment to an unintended account.' Supported by: [ASSUMPTION], no loss reported in input." The second tells you the effect is the tool's reasoning, to accept or rewrite.
5. Management response review (inventory)
TASK
Review management's response to the internal audit observation on the
inventory cycle in my input. Tell me what it leaves unanswered. Do not
judge who is right.
OUTPUT FORMAT
- Table 1, Response review. Columns: Question | Answer (yes, no or
unclear) | Words in the response that support the answer.
- Questions: Are the facts accepted? Is the cause addressed, or only the
instances? Is the action specific enough to check later? Is there an
owner by role? Is there a date? Is there an interim control until then?
- Table 2, Closure. Columns: Agreed action | Evidence that would show it
is done | How I would re-test it.
STAGE RULES
5. Do not soften or harden the observation, and do not change its rating.
6. If the response says the risk is accepted, list what the acceptance
should record: who accepts it, at what level of authority, and until
when.
7. Quote the response exactly where you rely on it.
MY INPUT
The final observation, management's response word for word (roles,
not names), and my rating: [paste here]
Illustrative output: "Is the cause addressed, or only the instances? Only the instances. The response says 'the 14 adjustments have since been approved'; it does not say who will approve stock adjustments before they are posted from now on."
6. Follow-up on the action taken report (ITGC)
TASK
Prepare the follow-up on agreed actions from the internal audit of IT
general controls, using the action taken report extract in my input.
OUTPUT FORMAT
- Table 1. Columns: Observation ref | Agreed action | Owner (role) |
Agreed date | Status claimed by management | Evidence needed to close
| Re-test step | Times the date was revised | Escalate (Y or N, with
the reason).
- Evidence needed to close, by the rating in my input: high, a re-test
described in words; medium, the document that proves the change; low,
written confirmation from the owner.
- Then a note to action owners and a short summary for the audit
committee.
STAGE RULES
5. Do not mark any item as closed. Closure is my decision after I have
seen the evidence.
6. Do not compute days overdue unless my input gives both dates.
7. Do not reword the agreed action.
MY INPUT
ATR extract (ref, agreed action, owner role, agreed date, rating,
status, comment) and a description of evidence received: [paste here]
Illustrative output for a high-rated item on leavers' access: "Evidence needed: current user list with status, and the HR leaver list for the same period. Re-test: match every leaver since the agreed date to the user list; any active ID is a failure. Escalate: N, pending re-test."
A checking routine for every answer
- Search for the markers. Every [ASSUMPTION], TO BE VERIFIED and NOT PROVIDED is confirmed from evidence, filled from the source, or deleted. An answer to a thin input with no markers at all deserves suspicion.
- Answer the questions first. If the tool listed QUESTIONS FOR THE AUDITOR, answer them and run the prompt again.
- Agree every number to your test sheet.
- Open every source. Read the criteria in the policy or contract. Any section, standard paragraph or threshold that slipped through is opened in the law or the ICAI Internal Audit Standards Board compendium, or removed.
- Confirm with the process owner. A control exists when someone performs it; a cause is what the owner confirms and the evidence supports.
- Make the decisions yourself: key controls, sample sizes, ratings, conclusions, closure.
- Record it in the working paper: the tool, what it was given, what was verified, what was changed, preparer and reviewer. The AI governance working paper and the log in the Excel library both hold this.
None of this makes a chat assistant a testing tool. Whether a control operated across the year is settled by evidence and, where the data exists, by a test across every transaction, as described in continuous internal audit and full-population testing. That is the part of the work CORAA is built for.
Before any of it, settle what may be pasted. Names, PAN, Aadhaar, bank accounts and salary of employees, customers and vendors stay out of consumer tools; check your plan's data-use and retention settings and your organisation's policy. See can you upload client ledgers to AI tools and DPDP for CA firms.
AI prompts for internal audit FAQ
What are the best AI prompts for internal audit in 2026?
The best prompts fix the output format, restrict the tool to the facts you give it, and forbid invented citations. For an RCM that means named columns; for an observation, Condition, Criteria, Cause, Effect/Risk and Recommendation; for follow-up, a table that never marks an item closed. The prompt library has one for each audit stage and process cycle.
Can I use ChatGPT prompts for internal audit work in India?
Yes, for drafting and structuring, with your organisation's authority and without personal data. The prompts here are plain text and work in ChatGPT, Claude, Copilot or Gemini. The output is a draft to verify, not evidence.
How do I write an internal audit RCM prompt?
Give the process narrative with names replaced by roles, specify the columns (sub-process, risk, control, control objective, control type and frequency, test of design, test of operating effectiveness, evidence), and tell the tool to record only controls the narrative describes. Prompt 1 above is the worked version.
How do I stop an AI tool inventing section numbers in an audit observation?
Tell it not to cite from memory and give it a phrase to write instead, such as TO BE VERIFIED, and supply the criteria text yourself. Then check: if a number still appears, open the source or delete it. An instruction lowers the risk; it does not remove it.
Related CORAA resources
- Internal Audit AI Prompt Library
- AI in internal audit 2026: the stage-by-stage guide
- ChatGPT for internal audit: prompts, uses and limits
- Claude for internal audit: Projects, prompts and workflow
- Prompt engineering for auditors and the statutory audit prompt library
- Internal Audit AI Strategy Template
Sources
- ICAI Internal Audit Standards Board — Compendium of Standards on Internal Audit
- Companies (Accounts) Rules, 2014 — Rule 13, on scope, functioning, periodicity and methodology of internal audit