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-Q4, 2024, 2024-H2)

ワークフロー

1. テスト対象のコントロールを特定する

コントロール領域に基づいて、主要なコントロールを特定します。コントロール マトリックスを提示します:

コントロール #	コントロール説明	タイプ	頻度	キー/非キー	リスク	主張
[ID]	[説明]	Manual/Automated/IT-Dependent	Daily/Weekly/Monthly/Quarterly/Annual	Key	High/Medium/Low	[CEAVOP]

コントロールタイプ:

• Automated: システム強制のコントロール、手動介入なし
• Manual: 判断を伴う人員による実施コントロール
• IT-dependent manual: システム生成データに依存する手動コントロール

主張 (CEAVOP):

• Completeness — すべてのトランザクションが記録されている
• Existence/Occurrence — トランザクションが実際に発生した
• Accuracy — 金額が正確に記録されている
• Valuation — 資産/負債が適切に評価されている
• Obligations/Rights — 企業が資産に対する権利、負債に対する義務を有する
• Presentation/Disclosure — 適切に分類・開示されている

2. サンプルサイズを決定する

コントロール頻度とリスクに基づいてサンプルサイズを計算します:

コントロール頻度	母集団規模 (概算)	推奨サンプル
Annual	1	1 (インスタンスをテスト)
Quarterly	4	2
Monthly	12	2-4 (リスクに基づく)
Weekly	52	5-15 (リスクに基づく)
Daily	~250	20-40 (リスクに基づく)
Per-transaction	様々	25-60 (リスクおよび取引量に基づく)

以下を調整:

• リスクレベル: より高いリスクのコントロールはより大きいサンプルが必要
• 前年度の結果: 前年度に欠陥があったコントロールはより大きいサンプルが必要
• 依存: 外部監査人によって依存されているコントロールはより大きいサンプルが必要な場合がある

3. サンプル選択を生成する

適切な方法を使用して母集団からサンプルを選択します:

ランダム選択 (トランザクション レベル コントロールのデフォルト):

• ランダム番号を生成して、母集団から特定のアイテムを選択
• 全期間にわたるカバレッジを確保

システマティック選択 (定期的なコントロール用):

• ランダムな開始点で固定間隔でアイテムを選択
• すべてのサブ期間にわたる表現を確保

ターゲット選択 (リスクベースのテストの補完):

• 特定のリスク特性を持つアイテムを選択 (高額、異常、期末)
• ターゲット選択の根拠を文書化

サンプルを提示:

SAMPLE SELECTION
Control: [コントロール ID] — [説明]
Period: [テスト期間]
Population: [カウント] 件, $[合計額]
Sample size: [N] 件
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. テスティングワークペーパーを作成する

各コントロールのテスティングテンプレートを生成:

SOX CONTROL TESTING WORKPAPER
==============================
Control #: [ID]
Control Description: [コントロール活動の完全な説明]
Control Owner: [役職/タイトル — テスター が記入]
Control Type: [Manual/Automated/IT-Dependent Manual]
Frequency: [コントロールの実施頻度]
Key Control: [Yes/No]
Relevant Assertion(s): [CEAVOP]
Testing Period: [期間]

TEST OBJECTIVE:
[コントロール説明] がテスト期間全体を通じて有効に機能していたかどうかを判定すること。

TEST PROCEDURES:
1. [ステップ 1 — 検査、確認、または再実施すべき内容]
2. [ステップ 2 — 取得すべき証拠]
3. [ステップ 3 — 比較または検証する内容]
4. [ステップ 4 — 実施の完全性を評価する方法]
5. [ステップ 5 — 実施のタイムリーネスを評価する方法]

EXPECTED EVIDENCE:
- [ドキュメントタイプ 1 — 例: 署名入り承認フォーム]
- [ドキュメントタイプ 2 — 例: レビューを示すシステムスクリーンショット]
- [ドキュメントタイプ 3 — 例: 作成者の署名入り照合]

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 — コントロール有効, 例外なし
[ ] Effective with exceptions — コントロール有効; 例外は限定的
[ ] Deficiency — コントロール無効
[ ] Significant Deficiency — 欠陥は無視できないレベル以上
[ ] Material Weakness — 重大な誤表示が防止・検出されない合理的な可能性

Tested by: ________________  Date: ________
Reviewed by: _______________  Date: ________

5. 共通コントロール テンプレートを提供する

コントロール領域に基づいて、事前に構築されたテストステップテンプレートを提供:

売上認識:

• 販売注文の承認および認可を確認
• 納品/パフォーマンス証拠を確認
• 契約条件に対する売上認識タイミングをテスト
• 契約/価格表への価格精度を確認
• 返金メモの承認および妥当性をテスト

調達から支払:

• 購買注文の承認および認可限度額を確認
• 三者マッチング(PO、領収、請求)を確認
• ベンダー マスターデータ変更コントロールをテスト
• 支払承認および職務分離を確認
• 重複支払防止コントロールをテスト

財務クローズ:

• アカウント照合の完全性およびタイムリーネスを確認
• 仕訳の承認および職務分離をテスト
• 財務諸表に対する経営管理レビューを確認
• 連結および消去仕訳をテスト
• 開示チェックリスト完了を確認

ITGC:

• ユーザー アクセスのプロビジョニングおよびデプロビジョニングをテスト
• 特権アクセス レビューを確認
• 変更管理の承認およびテストをテスト
• バッチジョブの監視および例外処理を確認
• バックアップおよび復旧手順をテスト

6. コントロール評価を文書化する

特定された欠陥を分類:

Deficiency (欠陥): コントロールが、経営者または従業員がタイムリーに誤表示を防止または検出することを許さない場合。以下を検討:

• 誤表示の可能性
• 潜在的誤表示の規模
• 代替コントロールが存在するか否か

Significant Deficiency (重大な欠陥): 物質的弱点ほど深刻ではないが、監督責任者の注意を引くに値する重要度の欠陥 (または組み合わせ)。

Material Weakness (物質的弱点): 物質的誤表示がタイムリーに防止または検出されない合理的な可能性がある欠陥 (または組み合わせ)。

7. 出力

以下を提供:

1. 選択した領域のコントロール マトリックス
2. 方法論文書化を含むサンプル選択
3. 事前設定されたテストステップを含むテスティングワークペーパーテンプレート
4. 結果の文書化テンプレート
5. 欠陥評価フレームワーク (例外が特定された場合)
6. 特定された欠陥に対する推奨改善措置