How to Build an AI Audit Workflow in Claude Projects (Step-by-Step) [2026]
Most of us have stopped asking whether AI belongs in audit work. The live question now is narrower and more useful: how do you set it up so it actually saves time without becoming a documentation liability? A one-off chat with a public LLM is convenient, but you re-explain your firm's methodology every single time, you paste in fresh context, and nothing you build carries over to the next engagement.
That is exactly the gap "Projects" features close. Claude Projects — and the equivalent Custom GPTs in ChatGPT — let you create a persistent workspace with its own instructions and its own reference library. Build it once, and every chat inside that project already knows your firm's audit approach. This post is a hands-on guide to building such a workflow for an Indian CA firm: what to configure, what to upload, three concrete drafting flows, and where to draw the line so you stay inside ICAI documentation expectations and the DPDP Act. It is the working companion to our earlier piece on the NotebookLM and Claude Projects engagement working-paper workflow — read that for the conceptual frame; read this for the build.
What a Project actually is (and what it is not)
A Claude Project is two things bolted onto a normal chat: a custom instruction block that applies to every conversation in that project, and a knowledge base of files the model can read from. ChatGPT's Custom GPTs work the same way. The persistence is the whole point — you stop being a prompt typist and start being someone who has configured a tool.
What it is not: a system of record, an audit tool with reproducible outputs, or anything you should treat as evidence. The model assists; it does not attest. Keep that distinction front of mind through every step below, because it dictates what you upload and what you never do.
Step 1: Define the project and write the custom instructions
Create a project and name it for a role, not a client — "Statutory Audit Assistant - FY 2025-26" rather than "ABC Pvt Ltd Audit". The role framing keeps it reusable across engagements and keeps client identity out of the workspace.
The custom instructions are the most important thing you will write, so treat them like a delegation note to a sharp but inexperienced article assistant. Be explicit about jurisdiction, standards, output format, and limits. A workable starting block:
ROLE: You are an audit assistant for an Indian Chartered Accountancy firm.
You support statutory audits under the Companies Act, 2013 and the
Standards on Auditing (SAs) issued by ICAI.
CONTEXT: All work is Indian GAAP / Ind AS, Indian tax (GST, TDS) and
ICAI SA standards. Use Indian English and ₹ for currency. Assume the
audit follows our firm methodology in the uploaded reference files.
HOW TO RESPOND:
- Always cite the specific SA, CARO 2020 clause, or Companies Act section
you are relying on. If you cannot cite a source, say so.
- Draft in the structure used by our firm templates (uploaded).
- Flag any matter that requires auditor judgement as "JUDGEMENT REQUIRED"
rather than concluding it yourself.
- Never invent figures, balances, ratios or sample results. If data is
not supplied, ask for it.
LIMITS: You produce drafts and analysis for a qualified auditor to review.
You do not form audit opinions. Every output is reviewed and signed off
by the engagement team before it enters the audit file.
That last paragraph is not decoration. It sets the model's behaviour and, just as usefully, it reminds whoever uses the project of the boundary. If you want a deeper library of role and task prompts to drop in here, our tested library of AI prompts for auditors is built for exactly this.
Step 2: Upload the right reference docs — methodology, not PII
The knowledge base is where the project earns its keep. The rule is simple: upload your firm's reusable knowledge, never client data.
Good things to upload:
- Firm audit methodology — your standard audit programme, materiality calculation approach, risk-assessment framework, and house style for working papers.
- SA checklists — your internal checklists mapping each SA to required procedures (SA 230 documentation, SA 315 risk, SA 330 responses, SA 500 evidence, SA 700 reporting).
- CARO 2020 clause reference — the 21 clauses with your firm's standard wording and the evidence each clause needs.
- Standard templates — blank working-paper formats, management representation letter templates, audit report shells, and your engagement-letter format.
- Disclosure checklists — Schedule III, Ind AS / AS disclosure checklists, GST and TDS reconciliation formats.
Never upload: client trial balances, ledgers, PAN/GST numbers, bank statements, employee data, or anything that identifies a person or entity. We will come back to why in Step 7, but the short version is that a Project's knowledge base is persistent shared context, and persistent client PII in a third-party tool is precisely the exposure the DPDP Act asks you to avoid.
A sensible folder structure to assemble before uploading:
/Audit-Assistant-Reference
/01-Methodology (audit programme, materiality, risk framework)
/02-SA-Checklists (SA 230, 315, 330, 500, 570, 700 checklists)
/03-CARO-2020 (clause-by-clause wording + evidence map)
/04-Templates (WP formats, MRL, report shells)
/05-Disclosure (Schedule III, Ind AS, GST/TDS formats)
Step 3: Build a working-paper drafting workflow
With instructions and reference docs in place, the first high-value flow is drafting working papers. The model already knows your format and the relevant SA from the knowledge base; you supply the de-identified specifics and it produces a structured first draft.
A working prompt pattern:
Draft a working paper for the FIXED ASSETS / PPE area.
INPUTS (de-identified):
- Opening gross block ₹4.2 crore; additions ₹38 lakh; deletions ₹6 lakh.
- Depreciation policy: WDV, useful lives per Schedule II.
- Two additions above ₹5 lakh selected for vouching; both agreed to
invoice and board approval.
Using our firm working-paper template and SA 500 / SA 230, produce:
1. Objective and assertions tested.
2. Procedures performed.
3. Results and exceptions (mark "JUDGEMENT REQUIRED" where needed).
4. Conclusion, with the SA and CARO clause (3(i)) cited.
You get a structured draft in your house format in seconds. Your job is then the part that matters: confirm the procedures match what was actually done, check the figures against the file, and exercise the judgement the model deliberately deferred. The drafting is assisted; the assurance stays with you.
Step 4: Build a ledger analytical-review workflow
This is the flow practitioners most often want, and the one where you must be most careful. Analytical review under SA 520 means looking at ratios, trends and relationships and asking whether they make sense. The model is genuinely good at interpreting such patterns and suggesting where to probe — but it should never be the thing that computes them on live client data inside a chat.
The safe pattern is: you compute the numbers (in Excel, Tally, or a deterministic tool), strip identifiers, then ask the model to reason about the pattern.
Here are de-identified analytical-review figures for a manufacturing
entity (FY 2025-26 vs 2024-25):
- Gross margin: 28% (PY 34%)
- Debtor days: 96 (PY 61)
- Inventory turnover: 4.1x (PY 6.3x)
- Power & fuel as % of revenue: 11% (PY 7%)
Per SA 520, which of these movements warrant further audit attention,
what could plausibly explain each (legitimate and fraud-risk
explanations), and what corroborating evidence should we seek?
That gives you a sharp, SA-anchored list of follow-ups and risk hypotheses. What you have not done is let an LLM tot up a ledger — because LLMs do arithmetic by prediction, not by calculation, and they will occasionally produce a confident wrong total. For the actual computation over the full population, you want a deterministic engine. This is the dividing line we explore in 100 percent population testing versus sampling, and it is the reason CORAA's deterministic core computes figures the same way every time rather than generating them.
Step 5: Build a report-drafting workflow
Report drafting is where a well-configured project shines, because the structure of an audit report is highly standardised and your firm wording is already in the knowledge base. The model assembles the scaffolding; you insert judgement and verify every reference.
Draft the basis-for-qualified-opinion paragraph for the following matter.
MATTER (de-identified): The entity has not provided for a disputed
GST demand of ₹52 lakh which, in our view, meets the recognition
criteria for a provision under Ind AS 37. Management has disclosed
it as a contingent liability.
Using SA 705 and our firm report template, draft:
1. The "Basis for Qualified Opinion" paragraph.
2. The corresponding qualified opinion paragraph.
3. A note on the quantitative effect on profit and reserves.
Cite SA 705 and Ind AS 37. Mark anything needing partner judgement.
You will still rewrite phrasing to your partner's voice and confirm the quantification, but the cold-start problem — staring at a blank report — is gone. The model handles consistency of structure; you own the opinion.
Step 6: Verification and documentation discipline
This is the step that separates a defensible AI workflow from a risky one, and it is non-negotiable under SA 230. Three habits:
Cite, then check. Your custom instructions force the model to cite a source for every assertion. Use that. If it cites "SA 315", open SA 315 and confirm. AI hallucination in audit is real and specific — a plausible-sounding but non-existent clause, or a real clause mis-stated. We catalogue the failure modes in AI hallucinations in audit: how to detect and mitigate them; the practical discipline is that an uncited or unverified statement does not enter the file.
Keep the human review visible. Every AI-assisted working paper should carry a note: drafted with AI assistance, reviewed and verified by [initials], date. This is not bureaucracy — under NFRA scrutiny and peer review, the question will be "who exercised judgement?", and the answer must be a named, qualified person, not a tool.
Preserve the reasoning, not just the output. Where the model flagged a risk or suggested a procedure, note why you accepted or rejected it. That trail is your evidence that the auditor — not the AI — drove the audit.
Be honest with yourself about what a chat-based tool can and cannot give you here. A Project produces drafts; it does not produce reproducible, evidence-bearing audit steps. Run the same analytical-review prompt twice and you may get two slightly different answers. That is fine for ideation and drafting. It is not acceptable for an audit step that has to be re-performed identically in a quality review. For those, a deterministic audit engine is simply more defensible — which is the whole architecture behind CORAA, covered in AI audit workflow from Tally to signed report.
Step 7: DPDP-safe boundaries
The Digital Personal Data Protection Act, 2023 changes the calculus for every Indian firm pushing data into third-party AI tools. Audit files are full of personal data — directors, employees, customers, vendors — and your client is the data fiduciary while you, as auditor processing it, carry real obligations. A few hard boundaries for any Project workflow:
- No PII in prompts or the knowledge base. De-identify before anything reaches the model. Replace names with "the entity", "Director A", "Customer 1". Strip PAN, GST, Aadhaar, account numbers.
- No raw client data files uploaded. The knowledge base is for firm methodology only, per Step 2.
- Turn off training on your data. On business/enterprise plans, confirm your inputs are not used for model training, and keep that confirmation on file.
- Use figures, not source documents. Paste a summarised, de-identified ratio table — never the underlying invoice scan or bank statement.
Building these into a reusable, firm-wide prompt template is far safer than trusting each article assistant to remember. We have published a ready-to-adapt set in the DPDP-safe prompt template library for CA firms. For the broader governance view, Claude for Indian audit work: a 90-day practitioner's guide walks through firm-wide rollout.
Where Projects fit — and where they stop
A well-built Claude Project is a genuinely good audit assistant. It drafts working papers in your house format, reasons about analytical review against the right SA, scaffolds reports, and remembers your methodology so you never re-explain it. For a solo practitioner or a small firm, that is a real productivity gain at a modest subscription cost, and you can stand it up in an afternoon using the steps above.
But be clear-eyed about the ceiling. Projects assist with drafting and thinking. They do not give you reproducible computation over a full ledger, a tamper-evident audit trail, or outputs you can defend as evidence in a peer or NFRA review — because a generative model is non-deterministic by design. The mature setup is two-layer: a Project (or Custom GPT) for assistance and drafting, sitting alongside a deterministic audit engine for the evidence-bearing, reproducible steps. That is precisely the split between CORAA's AI agents for assistive work and its deterministic core for computation. If you want to see the difference in practice rather than in prose, the demo walks through both layers on a sample engagement.
Build the Project today — it will pay for itself this busy season. Just know which jobs to hand it, and which jobs need a tool that gives the same answer every single time.
Frequently Asked Questions
Is it safe to upload client data to a Claude Project knowledge base?
No. A Project's knowledge base is persistent, shared context, and putting client trial balances, ledgers, PAN or GST numbers, bank statements or any personal data there is precisely the exposure the DPDP Act asks Indian firms to avoid. Upload only your firm's reusable knowledge — audit methodology, SA checklists, CARO wording, templates and disclosure checklists. De-identify any specifics before they reach the model, and on business or enterprise plans confirm in writing that your inputs are not used for model training.
Can a Claude Project compute ratios or test a full ledger for me?
It should not. Large language models do arithmetic by prediction, not calculation, so they will occasionally produce a confident wrong total. The safe pattern is to compute figures yourself in Excel, Tally or a deterministic tool, strip identifiers, then ask the model to reason about the pattern under, say, SA 520. For reproducible computation over a full population you need a deterministic engine that returns the same answer every time, which is the design behind CORAA's deterministic core.
How do I document AI-assisted working papers for SA 230 and peer review?
Build three habits. First, cite then check — your custom instructions should force a source for every assertion, and you open that SA or CARO clause to confirm it before it enters the file. Second, keep human review visible by noting on each paper that it was drafted with AI assistance and reviewed and verified by a named person with a date. Third, preserve your reasoning for accepting or rejecting the model's suggestions, so the trail shows a qualified auditor — not the tool — drove the audit.
What should go in the custom instructions for an audit Claude Project?
Treat them like a delegation note to a sharp but inexperienced assistant. Set the jurisdiction and standards (Companies Act 2013, ICAI SAs, Indian GAAP/Ind AS, GST, TDS, ₹), require a cited source for every assertion, and instruct the model to flag anything needing auditor judgement rather than concluding it. Crucially, state the limit explicitly: it produces drafts for a qualified auditor to review, it does not form audit opinions, and every output is signed off by the engagement team before entering the file.
What can a Claude Project not do in an audit workflow?
It assists with drafting and thinking, but it cannot give you reproducible computation over a full ledger, a tamper-evident audit trail, or outputs you can defend as evidence in a peer or NFRA review — because a generative model is non-deterministic by design. Run the same analytical-review prompt twice and you may get two slightly different answers, which is fine for ideation but not for an audit step that must be re-performed identically. The mature setup is two-layer: a Project for assistance, alongside a deterministic engine for evidence-bearing steps. You can see both layers in a demo.