Generates SOX 404 sample selections, testing workpapers, and control assessments for financial controls including revenue, P2P, ITGC, and close processes.
From financenpx claudepluginhub cy-wali/knowledge --plugin financeThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Important: This command 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 before use in audit documentation.
Generate sample selections, create testing workpapers, document control assessments, and provide testing templates for SOX 404 internal controls over financial reporting.
/sox <control-area> <period>
control-area — The control area to test:
revenue-recognition — Revenue cycle controls (order-to-cash)procure-to-pay or p2p — Procurement and AP controls (purchase-to-pay)payroll — Payroll processing and compensation controlsfinancial-close — Period-end close and reporting controlstreasury — Cash management and treasury controlsfixed-assets — Capital asset lifecycle controlsinventory — Inventory valuation and management controlsitgc — IT general controls (access, change management, operations)entity-level — Entity-level and monitoring controlsjournal-entries — Journal entry processing controlsperiod — The testing period (e.g., 2024-Q4, 2024, 2024-H2)Based on the control area, identify the key controls. Present the control matrix:
| Control # | Control Description | Type | Frequency | Key/Non-Key | Risk | Assertion |
|---|---|---|---|---|---|---|
| [ID] | [Description] | Manual/Automated/IT-Dependent | Daily/Weekly/Monthly/Quarterly/Annual | Key | High/Medium/Low | [CEAVOP] |
Control types:
Assertions (CEAVOP):
Calculate sample sizes based on control frequency and risk:
| Control Frequency | Population Size (approx.) | Recommended Sample |
|---|---|---|
| Annual | 1 | 1 (test the instance) |
| Quarterly | 4 | 2 |
| Monthly | 12 | 2-4 (based on risk) |
| Weekly | 52 | 5-15 (based on risk) |
| Daily | ~250 | 20-40 (based on risk) |
| Per-transaction | Varies | 25-60 (based on risk and volume) |
Adjust for:
Select samples from the population using the appropriate method:
Random selection (default for transaction-level controls):
Systematic selection (for periodic controls):
Targeted selection (supplement to random, for risk-based testing):
Present the sample:
SAMPLE SELECTION
Control: [Control ID] — [Description]
Period: [Testing period]
Population: [Count] items, $[Total value]
Sample size: [N] items
Selection method: [Random/Systematic/Targeted]
| Sample # | Transaction Date | Reference/ID | Amount | Selection Basis |
|----------|-----------------|--------------|--------|-----------------|
| 1 | [Date] | [Ref] | $X,XXX | Random |
| 2 | [Date] | [Ref] | $X,XXX | Random |
| ... | ... | ... | ... | ... |
Generate a testing template for each control:
SOX CONTROL TESTING WORKPAPER
==============================
Control #: [ID]
Control Description: [Full description of the control activity]
Control Owner: [Role/title — to be filled by tester]
Control Type: [Manual/Automated/IT-Dependent Manual]
Frequency: [How often the control operates]
Key Control: [Yes/No]
Relevant Assertion(s): [CEAVOP]
Testing Period: [Period]
TEST OBJECTIVE:
To determine whether [control description] operated effectively throughout the testing period.
TEST PROCEDURES:
1. [Step 1 — What to inspect, examine, or re-perform]
2. [Step 2 — What evidence to obtain]
3. [Step 3 — What to compare or verify]
4. [Step 4 — How to evaluate completeness of performance]
5. [Step 5 — How to assess timeliness of performance]
EXPECTED EVIDENCE:
- [Document type 1 — e.g., signed approval form]
- [Document type 2 — e.g., system screenshot showing review]
- [Document type 3 — e.g., reconciliation with preparer sign-off]
TEST RESULTS:
| Sample # | Ref | Procedure 1 | Procedure 2 | Procedure 3 | Result | Exception? | Notes |
|----------|-----|-------------|-------------|-------------|--------|------------|-------|
| 1 | | Pass/Fail | Pass/Fail | Pass/Fail | Pass/Fail | Y/N | |
| 2 | | Pass/Fail | Pass/Fail | Pass/Fail | Pass/Fail | Y/N | |
EXCEPTIONS NOTED:
| Sample # | Exception Description | Root Cause | Compensating Control | Impact |
|----------|----------------------|------------|---------------------|--------|
| | | | | |
CONCLUSION:
[ ] Effective — Control operated effectively with no exceptions
[ ] Effective with exceptions — Control operated effectively; exceptions are isolated
[ ] Deficiency — Control did not operate effectively
[ ] Significant Deficiency — Deficiency is more than inconsequential
[ ] Material Weakness — Reasonable possibility of material misstatement not prevented/detected
Tested by: ________________ Date: ________
Reviewed by: _______________ Date: ________
Based on the control area, provide pre-built test step templates:
Revenue Recognition:
Procure to Pay:
Financial Close:
ITGC:
Classify any identified deficiencies:
Deficiency: A control does not allow management or employees to prevent or detect misstatements on a timely basis. Consider:
Significant Deficiency: A deficiency (or combination) that is less severe than a material weakness but important enough to merit attention by those responsible for oversight.
Material Weakness: A deficiency (or combination) such that there is a reasonable possibility that a material misstatement will not be prevented or detected on a timely basis.
Provide: