claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルKnowledge Work

📋sox-testing

プラグイン
Finance
引数
<control area> [period]

説明

SOXのサンプル選定、テスト用ワークペーパー、およびコントロール評価を生成します。 次のような場合に使用: 四半期または年次のSOX 404テストを計画する場合、コントロール(収益、P2P、ITGC、決算)のサンプルを抽出する場合、テスト用ワークペーパーのテンプレートを作成する場合、またはコントロールの不備を評価・分類する場合。

原文を表示

Generate SOX sample selections, testing workpapers, and control assessments. Use when planning quarterly or annual SOX 404 testing, pulling a sample for a control (revenue, P2P, ITGC, close), building a testing workpaper template, or evaluating and classifying a control deficiency.

ユースケース

  • SOX 404テストを計画するとき
  • コントロールのサンプルを抽出するとき
  • テスト用ワークペーパーを作成するとき
  • コントロールの不備を評価・分類するとき

本文(日本語訳)

SOX コンプライアンステスト

見慣れないプレースホルダーが表示される場合、またはどのツールが接続されているか確認が必要な場合は、CONNECTORS.md を参照してください。

重要: このコマンドは SOX コンプライアンスワークフローを支援するものですが、監査や法律上のアドバイスを提供するものではありません。 すべてのテスト用作業調書および評価は、監査文書として使用する前に資格を持つ財務専門家によるレビューを受けてください。

財務報告に係る内部統制(SOX 404)を対象に、サンプル抽出、テスト用作業調書の作成、統制評価の文書化、およびテストテンプレートの提供を行います。


使い方

/sox <control-area> <period>

引数

  • control-area — テスト対象の統制領域:
    • revenue-recognition — 収益サイクル統制(受注〜入金)
    • procure-to-pay または p2p — 購買・買掛金統制(発注〜支払)
    • payroll — 給与処理および報酬統制
    • financial-close — 期末決算・報告統制
    • treasury — 資金管理・財務統制
    • fixed-assets — 固定資産ライフサイクル統制
    • inventory — 棚卸資産の評価・管理統制
    • itgc — IT 全般統制(アクセス管理・変更管理・運用)
    • entity-level — 全社的統制・モニタリング統制
    • journal-entries — 仕訳処理統制
    • その他、特定の統制 ID または名称
  • period — テスト対象期間(例: 2024-Q420242024-H2

ワークフロー

1. テスト対象統制の特定

統制領域に基づき、主要統制を特定します。以下の統制マトリクスを提示します:

統制 # 統制の説明 種別 頻度 キー/非キー リスク アサーション
[ID] [説明] 手動 / 自動 / IT 依存 日次 / 週次 / 月次 / 四半期 / 年次 キー 高 / 中 / 低 [CEAVOP]

統制の種別:

  • 自動(Automated): 手動介入なしにシステムが強制する統制
  • 手動(Manual): 担当者が判断を伴って実施する統制
  • IT 依存手動(IT-dependent manual): システム生成データに依存する手動統制

アサーション(CEAVOP):

  • Completeness(網羅性)— すべての取引が記録されている
  • Existence/Occurrence(実在性・期間帰属)— 取引が実際に発生している
  • Accuracy(正確性)— 金額が正しく記録されている
  • Valuation(評価)— 資産・負債が適切に評価されている
  • Obligations/Rights(権利・義務)— 資産に対する権利、負債に対する義務が存在する
  • Presentation/Disclosure(表示・開示)— 適切に分類・開示されている

2. サンプルサイズの決定

統制の実施頻度とリスクに基づき、サンプルサイズを算定します:

統制の実施頻度 母集団規模(概算) 推奨サンプル数
年次 1 1(その実施事例をテスト)
四半期 4 2
月次 12 2〜4(リスクに応じて)
週次 52 5〜15(リスクに応じて)
日次 約 250 20〜40(リスクに応じて)
取引ごと 件数による 25〜60(リスクおよび件数に応じて)

以下の要素に応じて調整してください:

  • リスクレベル: リスクが高い統制ほど大きいサンプルが必要
  • 前年度の結果: 過去に不備が確認された統制は、より大きいサンプルが必要
  • 依拠度: 外部監査人が依拠する統制は、より大きいサンプルが必要な場合がある

3. サンプルの抽出

適切な手法を用いて母集団からサンプルを抽出します:

ランダム抽出(取引レベル統制のデフォルト):

  • 乱数を生成し、母集団から特定の項目を選択
  • 対象期間全体をカバーするよう確認

系統的抽出(定期的な統制向け):

  • ランダムな開始点を設定し、一定間隔で項目を選択
  • すべてのサブ期間にわたって代表性を確保

目的的抽出(リスクベーステストにおけるランダム抽出の補完):

  • 特定のリスク特性を持つ項目を選択(高額取引、異常な取引、期末取引など)
  • 目的的抽出の根拠を文書化

サンプルの提示形式:

サンプル抽出
統制: [統制 ID] — [説明]
期間: [テスト対象期間]
母集団: [件数] 件、合計 $[金額]
サンプル数: [N] 件
抽出方法: [ランダム / 系統的 / 目的的]

| サンプル # | 取引日 | 参照番号 / ID | 金額 | 抽出根拠 |
|-----------|--------|-------------|------|---------|
| 1         | [日付] | [参照番号]  | $X,XXX | ランダム |
| 2         | [日付] | [参照番号]  | $X,XXX | ランダム |
| ...       | ...    | ...         | ...    | ...    |

4. テスト用作業調書の作成

統制ごとにテストテンプレートを生成します:

SOX 統制テスト作業調書
==============================
統制 #: [ID]
統制の説明: [統制活動の詳細な説明]
統制オーナー: [役割 / 職名 — テスト担当者が記入]
統制種別: [手動 / 自動 / IT 依存手動]
実施頻度: [統制が機能する頻度]
キー統制: [はい / いいえ]
関連アサーション: [CEAVOP]
テスト期間: [期間]

テスト目的:
[統制の説明] がテスト期間を通じて有効に機能していたかどうかを確認する。

テスト手続:
1. [手順 1 — 検査・閲覧または再実施の対象]
2. [手順 2 — 入手すべき証拠]
3. [手順 3 — 比較・検証する内容]
4. [手順 4 — 実施の網羅性を評価する方法]
5. [手順 5 — 実施の適時性を評価する方法]

期待される証拠:
- [文書の種類 1 — 例: 署名済み承認フォーム]
- [文書の種類 2 — 例: レビューを示すシステムスクリーンショット]
- [文書の種類 3 — 例: 作成者の署名付き照合表]

テスト結果:

| サンプル # | 参照番号 | 手順 1 | 手順 2 | 手順 3 | 結果 | 例外あり? | 備考 |
|-----------|---------|--------|--------|--------|------|----------|------|
| 1         |         | 合格 / 不合格 | 合格 / 不合格 | 合格 / 不合格 | 合格 / 不合格 | Y/N | |
| 2         |         | 合格 / 不合格 | 合格 / 不合格 | 合格 / 不合格 | 合格 / 不合格 | Y/N | |

確認された例外事項:
| サンプル # | 例外の説明 | 根本原因 | 補完的統制 | 影響 |
|-----------|-----------|---------|----------|------|
|           |           |         |          |      |

結論:
[ ] 有効 — 例外なく統制が有効に機能した
[ ] 例外付き有効 — 統制は有効に機能した。例外は個別事例の範囲内
[ ] 不備(Deficiency)— 統制が有効に機能しなかった
[ ] 重要な不備(Significant Deficiency)— 監視責任者が注目すべき、軽微でない不備
[ ] 重要な欠陥(Material Weakness)— 重要な虚偽表示が防止・発見されない相当の可能性がある

テスト担当者: ________________  日付: ________
レビュー担当者: _______________  日付: ________

5. 統制領域別の標準テンプレートの提供

統制領域に応じて、あらかじめ構築されたテスト手順テンプレートを提供します:

収益認識(Revenue Recognition):

  • 受注承認および権限確認
  • 引渡し・履行の証拠確認
  • 契約条件に基づく収益認識タイミングのテスト
  • 契約書・価格表に対する価格正確性の検証
  • クレジットメモの承認と有効性のテスト

購買〜支払(Procure to Pay):

  • 発注書の承認と権限限度額の確認
  • 三点照合(発注書・受取証・請求書)の確認
  • 仕入先マスタデータの変更管理統制のテスト
  • 支払承認と職務分離の確認
  • 重複支払防止統制のテスト

決算(Financial Close):

  • 勘定照合の網羅性・適時性の確認
  • 仕訳の承認と職務分離のテスト
  • 財務諸表に対する経営者レビューの確認
  • 連結・消去仕訳のテスト
  • 開示チェックリストの完成確認

IT 全般統制(ITGC):

  • ユーザーアクセスの付与・剥奪プロセスのテスト
  • 特権アクセスレビューの確認
  • 変更管理の承認・テストプロセスの確認
  • バッチジョブの監視と例外処理の確認
  • バックアップおよびリカバリ手続のテスト

6. 統制評価の文書化

特定された不備を以下のように分類します:

不備(Deficiency): 統制が、虚偽表示を適時に防止または発見することを経営者や従業員に許容しない状態。 以下を検討します:

  • 虚偽表示の発生可能性
  • 潜在的な虚偽表示の重要性
  • 補完的統制の有無

重要な不備(Significant Deficiency): 重要な欠陥ほど深刻ではないが、監視責任を担う者が注目するに足る、単独または組み合わせによる不備。

重要な欠陥(Material Weakness): 単独または組み合わせにより、重要な虚偽表示が適時に防止または発見されない相当の可能性がある不備。


7. アウトプット

以下を提供します:

  1. 選択した領域の統制マトリクス
  2. 方法論の文書化を含むサンプル抽出結果
  3. テスト手順があらかじめ入力されたテスト用作業調書テンプレート
  4. 結果文書化テンプレート
  5. 不備評価フレームワーク(例外事項が特定された場合)
  6. 確認された不備に対する是正措置の提案
原文(English)を表示

SOX Compliance Testing

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.

Usage

/sox <control-area> <period>

Arguments

  • 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 controls
    • financial-close — Period-end close and reporting controls
    • treasury — Cash management and treasury controls
    • fixed-assets — Capital asset lifecycle controls
    • inventory — Inventory valuation and management controls
    • itgc — IT general controls (access, change management, operations)
    • entity-level — Entity-level and monitoring controls
    • journal-entries — Journal entry processing controls
    • Any specific control ID or name
  • period — The testing period (e.g., 2024-Q4, 2024, 2024-H2)

Workflow

1. Identify Controls to Test

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:

  • Automated: System-enforced controls with no manual intervention
  • Manual: Controls performed by personnel with judgment
  • IT-dependent manual: Manual controls that rely on system-generated data

Assertions (CEAVOP):

  • Completeness — All transactions are recorded
  • Existence/Occurrence — Transactions actually occurred
  • Accuracy — Amounts are correctly recorded
  • Valuation — Assets/liabilities are properly valued
  • Obligations/Rights — Entity has rights to assets, obligations for liabilities
  • Presentation/Disclosure — Properly classified and disclosed

2. Determine Sample Size

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:

  • Risk level: Higher risk controls require larger samples
  • Prior year results: Controls with prior deficiencies need larger samples
  • Reliance: Controls relied upon by external auditors may need larger samples

3. Generate Sample Selection

Select samples from the population using the appropriate method:

Random selection (default for transaction-level controls):

  • Generate random numbers to select specific items from the population
  • Ensure coverage across the full period

Systematic selection (for periodic controls):

  • Select items at fixed intervals with a random start point
  • Ensure representation across all sub-periods

Targeted selection (supplement to random, for risk-based testing):

  • Select items with specific risk characteristics (high dollar, unusual, period-end)
  • Document rationale for targeted selections

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          |
| ...      | ...             | ...          | ...    | ...             |

4. Create Testing Workpaper

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: ________

5. Provide Common Control Templates

Based on the control area, provide pre-built test step templates:

Revenue Recognition:

  • Verify sales order approval and authorization
  • Confirm delivery/performance evidence
  • Test revenue recognition timing against contract terms
  • Verify pricing accuracy to contract/price list
  • Test credit memo approval and validity

Procure to Pay:

  • Verify purchase order approval and authorization limits
  • Confirm three-way match (PO, receipt, invoice)
  • Test vendor master data change controls
  • Verify payment approval and segregation of duties
  • Test duplicate payment prevention controls

Financial Close:

  • Verify account reconciliation completeness and timeliness
  • Test journal entry approval and segregation of duties
  • Verify management review of financial statements
  • Test consolidation and elimination entries
  • Verify disclosure checklist completion

ITGC:

  • Test user access provisioning and de-provisioning
  • Verify privileged access reviews
  • Test change management approval and testing
  • Verify batch job monitoring and exception handling
  • Test backup and recovery procedures

6. Document Control Assessment

Classify any identified deficiencies:

Deficiency: A control does not allow management or employees to prevent or detect misstatements on a timely basis. Consider:

  • Likelihood of misstatement
  • Magnitude of potential misstatement
  • Whether compensating controls exist

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.

7. Output

Provide:

  1. Control matrix for the selected area
  2. Sample selections with methodology documentation
  3. Testing workpaper templates with pre-populated test steps
  4. Results documentation template
  5. Deficiency evaluation framework (if exceptions are identified)
  6. Suggested remediation actions for any noted deficiencies

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。