The quarterly SOX control testing cycle is a familiar source of friction for finance teams. You know the drill: auditors request evidence, your team scrambles through shared drives and email threads to find the right invoice, the right approval timestamp, or the right system log. Then someone manually re-performs the control in a spreadsheet, pastes the result into a workpaper, and hopes the formatting matches the prior quarter’s template. The cost is not just hours—it is the cognitive drain on your best controllers, who spend more time hunting for evidence than analyzing risk.
Claude Code changes that dynamic. Instead of treating SOX testing as a data retrieval problem, you can treat it as an automation workflow. Claude Code can read your control matrices, navigate your file structures, extract the exact evidence fields from PDFs and Excel exports, and draft the workpaper narrative in your firm’s established tone. The result is a first-pass workpaper that your team reviews in minutes, not days. This post gives you two production-ready prompts to start automating your walkthroughs and test of operating effectiveness (TOE) procedures today.
The key insight is that Claude Code works best when you give it structure, not just a request. The prompts below follow an anatomy that forces clarity: define the task, specify the inputs, extract the pattern from a reference, and demand a plan before execution. That discipline is what turns a generic AI assistant into a reliable control-testing analyst.
Why Manual Testing Persists (and Why It Shouldn’t)
Most teams resist automation because they assume it requires a technical integration with their ERP or GRC tool. That is a false barrier. Claude Code operates on the files you already have: control matrices in Excel, evidence in PDF, prior workpapers in Word or Markdown. It reads, extracts, and drafts. The only prerequisite is that you organize your evidence folders consistently—which is a best practice anyway for audit readiness. Once that is in place, the prompts below will cut your testing cycle time by 40–60% on the first run.
Below is your first prompt, designed for a walkthrough of a key control. This is the narrative-heavy portion of SOX testing where you document who does what, in what system, and with what review. Use this when you need to draft the walkthrough narrative from raw system documentation and interview notes.
First, read these files completely before responding:
[control_matrix.xlsx] — contains the control description, frequency, key reports used, and the control owner.
[system_architecture.md] — describes the applications involved, data flow between systems, and user roles.
[interview_notes.md] — raw notes from the control owner interview, including who performs each step and what they review.
Here is a reference for what I want to achieve:
[upload_prior_quarter_walkthrough.md] — a clean, auditor-approved walkthrough narrative from last quarter.
Here’s what makes this reference work:
– It uses a chronological narrative style: “The process begins when…”
– It names specific system fields and approval timestamps, not generic language.
– It explicitly states the control objective in the first paragraph.
– It flags any exceptions or overrides observed during the walkthrough.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A narrative workpaper, 500–700 words, structured in three sections: Process Overview, Control Steps, and Exceptions Noted.
Recipient’s reaction: The auditor should be able to sign off on the walkthrough without asking for clarification.
Does NOT sound like: A generic template with placeholders like “the user then approves the transaction.” It must reference actual field names and system names from the control matrix.
Success means: The narrative is complete enough that a new hire on the audit team could re-perform the walkthrough from the document alone.
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
This prompt works because it forces Claude Code to ground its output in your actual evidence. The reference file is critical—it teaches the model your firm’s narrative style, which the auditor already approved. The success brief prevents the model from producing generic fluff. When you run this, expect Claude Code to ask you two or three clarifying questions about the control matrix format or the interview notes. Answer them, and it will produce a narrative that reads like your best senior associate wrote it.
Automating the Test of Operating Effectiveness
Walkthroughs are only half the battle. The heavier lift is the TOE, where you select a sample, re-perform the control, and document the results. This is where most teams drown in spreadsheet gymnastics. The prompt below handles the mechanical parts: extracting sample items from your evidence folder, checking each against the control attributes, and drafting the workpaper with pass/fail conclusions and exception analysis.
First, read these files completely before responding:
[sample_selection.xlsx] — contains the list of sample transaction IDs, the sample size per the audit plan, and the selection method (random or haphazard).
[evidence_folder/] — contains subfolders for each sample ID, each holding the invoice, approval email, and system log export.
[control_attributes.md] — lists the specific attributes to test (e.g., approval date within 5 business days, amount matches PO, system timestamp present).
Here is a reference for what I want to achieve:
[upload_prior_quarter_toe_workpaper.md] — the approved TOE workpaper from the prior quarter, including the exception handling format.
Here’s what makes this reference work:
– It uses a table format for sample attributes with columns: Sample ID, Attribute Tested, Result (Pass/Fail), Evidence Reference, and Comments.
– It flags any exception with a clear “Exception” label and a separate paragraph explaining root cause and management response.
– It includes a summary conclusion paragraph that states whether the control operated effectively.
– It cites the exact file path for each piece of evidence.
Here’s what I need for my version / SUCCESS BRIEF:
Type of output + length: A structured workpaper with a summary table (one row per sample), an exception analysis section (if any), and a conclusion paragraph. Total length 800–1000 words.
Recipient’s reaction: The manager can review and approve without re-opening the evidence files to verify your claims.
Does NOT sound like: Vague language like “evidence was reviewed.” Must state what was checked and the specific result for each attribute.
Success means: Every sample row has a definitive pass/fail, and any exception includes a proposed management action that aligns with our remediation policy.
My context file contains my standards, constraints, audience. Read it fully before starting.
DO NOT start executing yet. Ask clarifying questions first.
Give me your execution plan (5 steps max) before you begin.
The second prompt is more demanding because it requires Claude Code to read across multiple files and cross-reference them. That is exactly where manual testing breaks down—humans get tired and miss a mismatched timestamp. Claude Code does not. It will read the sample list, open each evidence subfolder, and check the attributes against the control definition. If it finds a discrepancy, it will draft the exception narrative for you, including a suggested root cause based on the evidence.
One practical tip: before you run either prompt, clean up your evidence folder names. Use a consistent convention like SampleID_Invoice.pdf and SampleID_ApprovalEmail.msg. Claude Code uses filenames to infer context, so clear names reduce the number of clarifying questions you have to answer. Also, make sure your control matrix lists the system field names exactly as they appear in the evidence—if the matrix says “approval_date” but the log says “appr_dt,” Claude Code will flag that as a potential exception. That is actually a feature: it surfaces data quality issues you might have missed.
Start with the walkthrough prompt on one low-risk control. Review the output, adjust the reference file if the tone is off, and then scale to your full control set. Within two quarters, you will have a library of approved narratives and TOE templates that make each subsequent test faster. The auditors will notice the consistency, and your team will get their evenings back.
Published on 4 August 2026 on growwithgpt.com