
Audit Support
Generate SOX 404 control-testing workpapers, pick audit samples, and classify deficiencies when your product must stand up to financial reporting audits.
Overview
Audit Support is an agent skill for the Operate phase that structures SOX 404 ICFR control testing, sampling, and deficiency documentation for audit-ready workpapers.
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill audit-supportWhat is this skill?
- End-to-end SOX 404 methodology: scoping, risk assessment, control ID, testing, and evaluation
- Sample selection approaches and testing documentation standards for workpapers
- Control deficiency classification aligned with ICFR expectations
- Coverage of common control types for financial reporting processes
- Explicit disclaimer: assists workflows; qualified professionals must review outputs
- Five-step SOX 404 methodology: scoping, risk assessment, control identification, testing, evaluation
Adoption & trust: 1.7k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know SOX 404 expects tested ICFR but lack a consistent way to scope controls, select samples, and document deficiencies without reinventing the methodology each cycle.
Who is it for?
Founder-operators or solo finance leads at SaaS companies subject to SOX who need repeatable control-testing templates and sample logic.
Skip if: Indie side projects with no financial reporting obligations, pure app-security reviews, or anyone treating skill output as final audit or legal sign-off.
When should I use this skill?
Generating testing workpapers, selecting audit samples, classifying control deficiencies, or preparing for internal or external audits.
What do I get? / Deliverables
You get SOX-aligned testing steps, sampling guidance, and deficiency classification patterns you can drop into workpapers for professional review before audit.
- Control testing workpaper structure and documentation
- Sample selection rationale and deficiency classification notes
Recommended Skills
Journey fit
ICFR testing and deficiency evaluation are ongoing compliance work after the product is live and reporting, not a one-time launch task. Iterate covers continuous control assessment, documentation updates, and audit-cycle preparation rather than initial build or distribution.
How it compares
Use for SOX control-testing methodology, not for codebase vulnerability scanning or mobile store analytics.
Common Questions / FAQ
Who is audit-support for?
Solo builders and small teams responsible for internal controls and audit prep at companies with ICFR requirements, especially SaaS with revenue recognition complexity.
When should I use audit-support?
During Operate-phase compliance cycles when generating workpapers, selecting samples, classifying deficiencies, or preparing for internal or external audits—not for day-one MVP coding.
Is audit-support safe to install?
It is documentation and methodology assistance only; review the Security Audits panel on this page and treat all workpapers as drafts requiring qualified financial professional review.
SKILL.md
READMESKILL.md - Audit Support
# Audit Support **Important**: This skill assists with SOX compliance workflows but does not provide audit or legal advice. All testing workpapers and assessments should be reviewed by qualified financial professionals. While "significance" and "materiality" are context-specific concepts that are ultimately assessed by auditors, this skill is intended to assist professionals in the creation and evaluation of effective internal controls and documentation for audits. SOX 404 control testing methodology, sample selection approaches, testing documentation standards, control deficiency classification, and common control types. ## SOX 404 Control Testing Methodology ### Overview SOX Section 404 requires management to assess the effectiveness of internal controls over financial reporting (ICFR). This involves: 1. **Scoping:** Identify significant accounts and relevant assertions 2. **Risk assessment:** Evaluate the risk of material misstatement for each significant account 3. **Control identification:** Document the controls that address each risk 4. **Testing:** Test the design and operating effectiveness of key controls 5. **Evaluation:** Assess whether any deficiencies exist and their severity 6. **Reporting:** Document the assessment and any material weaknesses ### Scoping Significant Accounts An account is significant if there is more than a remote likelihood that it could contain a misstatement that is material (individually or in aggregate). **Quantitative factors:** - Account balance exceeds materiality threshold (typically 3-5% of a key benchmark) - Transaction volume is high, increasing the risk of error - Account is subject to significant estimates or judgment **Qualitative factors:** - Account involves complex accounting (revenue recognition, derivatives, pensions) - Account is susceptible to fraud (cash, revenue, related-party transactions) - Account has had prior misstatements or audit adjustments - Account involves significant management judgment or estimates - New account or significantly changed process ### Relevant Assertions by Account Type | Account Type | Key Assertions | |-------------|---------------| | Revenue | Occurrence, Completeness, Accuracy, Cut-off | | Accounts Receivable | Existence, Valuation (allowance), Rights | | Inventory | Existence, Valuation, Completeness | | Fixed Assets | Existence, Valuation, Completeness, Rights | | Accounts Payable | Completeness, Accuracy, Existence | | Accrued Liabilities | Completeness, Valuation, Accuracy | | Equity | Completeness, Accuracy, Presentation | | Financial Close/Reporting | Presentation, Accuracy, Completeness | ### Design Effectiveness vs Operating Effectiveness **Design effectiveness:** Is the control properly designed to prevent or detect a material misstatement in the relevant assertion? - Evaluated through walkthroughs (trace a transaction end-to-end through the process) - Confirm the control is placed at the right point in the process - Confirm the control addresses the identified risk - Performed at least annually, or when processes change **Operating effectiveness:** Did the control actually operate as designed throughout the testing period? - Evaluated through testing (inspection, observation, re-performance, inquiry) - Requires sufficient sample sizes to support a conclusion - Must cover the full period of reliance ## Sample Selection Approaches ### Random Selection **When to use:** Default method for transaction-level controls with large populations. **Method:** 1. Define the population (all transactions subject to the control during the period) 2. Number each item in the population sequentially 3. Use a random numbe