Purpose
Transform an unstructured auditor evidence request list into a clean, assignable tracker — each request parsed, categorized, owned, and dated — so the audit team knows exactly who owes what, by when, and what has already been delivered. Eliminates the scramble of managing PBC requests across email threads and spreadsheets.
When to Use
Invoke this skill when the user asks to:
- Turn a Prepared-By-Client (PBC) list or auditor request list into a tracker
- Assign owners and due dates to audit evidence requests
- Organize documents requested during a financial statement audit or review
- Build a status tracker for a SOC 1/SOC 2, tax, or regulatory examination
- Consolidate scattered auditor requests into one managed workflow
- Prepare a follow-up plan for outstanding evidence items
Inputs Required
Before starting, collect:
- Request list: The raw list of auditor requests (pasted text, email content, or bullet list)
- Audit type: Financial statement audit / review / SOC 1 / SOC 2 / tax / regulatory exam / internal audit
- Fieldwork start date: When the auditors begin (drives due-date sequencing)
- Team roster: Names and functional areas of people who can own items (e.g., "Jordan — AP/AR," "Priya — Payroll," "Sam — Fixed Assets")
- Audit period: Fiscal year or period under audit
- Delivery method: Where evidence is submitted (audit portal / shared drive / email)
If the team roster is missing, assign owners by functional area label (e.g., "Payroll Owner") and flag them for the user to name. If fieldwork start date is missing, sequence due dates relative to "Fieldwork Start" as a placeholder.
Instructions
Step 1: Parse and Normalize Each Request
Break the raw list into discrete, atomic tracker line items.
- Split compound requests into separate rows (e.g., "Bank statements and reconciliations for all accounts" → one row per deliverable type)
- Assign each item a sequential Request ID (e.g., PBC-001, PBC-002)
- Rewrite each request as a clear Document Description — what specifically must be provided, in what format, and for what period. Convert auditor shorthand into plain, actionable language.
Step 2: Categorize by Financial Area
Tag each request to a category so ownership and status roll up cleanly. Use these standard categories (add others as needed):
- Cash & Bank
- Accounts Receivable & Revenue
- Accounts Payable & Expenses
- Payroll & Compensation
- Fixed Assets & Depreciation
- Inventory
- Debt & Financing
- Equity
- Taxes
- Controls & Governance (policies, org charts, access lists — common for SOC engagements)
- General / Entity-Level (trial balance, GL detail, board minutes)
Step 3: Assign Owner
Map each category to a team member from the roster.
- Match the functional area to the owner's responsibility
- For cross-functional items (e.g., legal confirmations), assign the most accountable owner and note collaborators
- Never leave an item unowned — assign a functional-area placeholder and flag it if no name fits
Step 4: Set Due Dates
Sequence due dates so evidence lands before auditors need it.
- High-priority / walkthrough items (trial balance, GL, org charts): due before or on fieldwork start
- Substantive testing items (reconciliations, confirmations, invoices): due within the first 3–5 business days of fieldwork
- Detail-level samples and follow-ups: due within the first week
- Stagger due dates to avoid bottlenecking one owner with everything on the same day
Step 5: Assign Priority and Initial Status
- Priority: High (blocks auditor progress or walkthroughs) / Medium (needed for substantive testing) / Low (supplementary)
- Status: All items start as Not Started. Use this status set: Not Started / In Progress / Submitted / Accepted / Follow-Up Needed
- Add a Notes field for blockers, dependencies, or auditor clarifications
Step 6: Build the Follow-Up Cadence
Define how open items get chased:
- Daily during fieldwork: Review all High-priority items still Not Started or In Progress
- Every 2 days: Owner check-in on Medium items past 50% of their timeline
- Escalation rule: Any High-priority item overdue by 1 business day escalates to the Accounting Manager
- Auditor-facing update: A weekly status summary sent to the engagement team
Step 7: Generate the Summary Dashboard
Roll the tracker up into counts:
- Total requests
- Count by status (Not Started / In Progress / Submitted / Accepted / Follow-Up Needed)
- Count by owner
- Count of High-priority items still open
- Percent complete (Accepted ÷ Total)
Output Format
- Structure: A markdown table for the tracker, followed by the follow-up cadence and the summary dashboard
- Length: One row per parsed request (typically 15–50 rows); 400–700 words of supporting sections
- Format: Table for the tracker; bulleted lists for cadence and dashboard
- Sections: (1) Evidence Request Tracker table with columns — Request ID | Document Description | Category | Owner | Due Date | Priority | Status | Notes; (2) Follow-Up Cadence; (3) Summary Dashboard
- Tone: Organized and matter-of-fact — the voice of an accounting manager running a tight fieldwork process
Quality Checklist
Before delivering output, verify:
- [ ] Every raw request is represented — compound requests split into separate atomic rows
- [ ] Every row has a unique sequential Request ID
- [ ] Every row has an assigned owner (named or flagged functional-area placeholder)
- [ ] Every row has a due date sequenced relative to fieldwork start
- [ ] Every row has a Priority and a Status (all starting as Not Started)
- [ ] Summary dashboard counts reconcile to the total number of tracker rows
Notes
- Auditor request lists frequently bundle multiple deliverables into one line — splitting them is the single highest-value step, because it prevents "partially done" items from hiding in a single row
- For SOC engagements, weight the Controls & Governance category heavily; for financial statement audits, Cash, AR/Revenue, and AP/Expenses usually carry the most items
- Recommend exporting the final table to the team's spreadsheet or audit portal and updating status daily during fieldwork — the tracker's value comes from being kept current, not just built once
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills