アプリケーション・コントロール

Definition

「コントロールは設定されています」で調書が終わっている。金融庁の監査実務指標（2024年）では、IT依存コントロールの「機能テスト不足」が指摘対象の上位3項に入った。設定されているかどうかではなく、実際に拒否記録が残っているかが検証のポイントになる。

キーポイント

> - アプリコンが機能していない場合、個々の取引のエラーや不正が検出されないまま財務諸表に反映される。 > - アプリコンに依存する場合、テスト証拠は機械的プロセスであるため、通常1件のテストで十分な監査証拠となる。ISA 330.A44がこの原則を支持している。 > - 多くの監査チームはアプリコンの「存在」を確認するが、ISA 330に基づく「機能」テストが欠けている。調書にトランザクション・ログやシステムレポートの証拠が残っていないケースは検査で差し戻し対象。 > - ITGC（全般統制）が崩れている環境では、アプリコンの信頼性自体が成り立たない。先にITGCを評価する。

仕組み

アプリコンは、人間が手入力する前やデータが次のシステムに移動する前に、エラーや異常を自動的にフィルタリングする。売上システムが顧客マスターに存在しない顧客コードへの請求を自動拒否するケースが典型例。ISA 315.A82はこうした自動的な防止・検出メカニズムを「IT依存の統制」と定義している。

検証作業は2段階で進む。第一に、システムへの問い合わせやシステム管理者からの確認により、そのコントロールが「存在」することを確認する。第二に、監査証拠（トランザクション・ログ、拒否記録、システムレポート）を検査して、当該期間中にそのコントロールが「機能」したことを検証する。プログラムされたコントロールは一貫性が高いため、機能テストは通常1件の実行テストで足りる。ISA 330.A44がその根拠。

実例：田中製造業株式会社

クライアントは東京都に本社を置く製造業。年売上6,400万円、IFRS適用。売上認識システムはSAP ERP。

コントロールの存在確認

SAP MM（マテリアル管理）モジュール内で、「注文と納品の数量照合」プログラムが有効になっていることを確認。システム管理者に書面で確認した。

作業記録：「SAP MM 4.7.2版納品検証ルール有効状態確認済み。設定画面スクリーンショット添付」

機能テスト

2024年1月〜3月の売上取引ファイルを抽出（全847件）。SAP機能リストより、自動拒否件数「3件」を確認し、それぞれの拒否記録を検査した。

- 拒否1：納品数量が発注数量を5%超過（システム閾値3%）。コントロールが機能。 - 拒否2：顧客マスターに登録なし。コントロールが機能。 - 拒否3：受け取り側部門コードが存在しない。コントロールが機能。

作業記録：「拒否トランザクション・ログ3件確認。理由コード、日時、ユーザーID記録済み。当該期間、納品照合ロジック変更なし」

判定

売上数量の自動検証コントロールは、テスト期間内で有効に機能していた。個別の請求エラーが47件レベルの誤謬へ拡大する可能性は低い。ISA 330に基づき、このアプリコンへの依存を実証的テスト計画に反映する。

監査人や実務者が見落とすこと

- 「設計」されていることを確認しても、ISA 330.A44に基づく機能テストを実施していないケースが多い。経験上、トランザクション・ログやシステムレポートによる検証証拠が調書に一切残っていない状態で審査に上がってくることがある。これは検査で差し戻しの典型。

- SAPや会計システムのシステム管理者確認書が「コントロール環境の概要」で留まり、当該期間の実績レポートを添付していないケースが目立つ。確認書はアプリコンが「存在する」証拠にすぎず、「機能した」証拠にはならない。拒否ログ、エラーフラグの件数、期中の設定変更履歴まで調書に綴じること。

- ITGC（全般統制）との依存関係を見落とす。アプリコンがどれだけ精緻に設計されていても、プログラム変更管理やアクセス管理が甘ければ、そのアプリコンが改竄されていないとは言い切れない。ISA 315.A83はこの依存関係を明示している。