ITアプリケーションから作成したレポートの検証
- ITAC
- 2026.01.16更新
― IT依拠手作業統制における“情報のインテグリティ”を確保する視点
延滞債権リストや滞留在庫リストのように、ITアプリケーションが自動で作成した帳票をもとに人手で行う統制は、企業の実務で非常に一般的です。これらは「ITを利用した内部統制」の代表例とも言えます。
しかし、ITが作ったリストだからといって、そのまま信頼して良いわけではありません。
監査人は、リストそのものの“見た目の正しさ”ではなく、元データの品質や抽出ロジックが正しく機能しているかを重点的に評価します。
■ なぜ「ITから自動生成されたリスト」でも評価が必要なのか？
ポイントは次の2つです。
- 元データが正しくなければ、どれほど立派なリストでも間違ってしまう
- 一度正しいリストが作れても、IT全般統制が弱いと継続的な正しさが保証できない
つまり、評価対象はリストそのものではなく、
（1）元データ →（2）集計・抽出ロジック →（3）ITGC
という“土台から上の階層まで一体の仕組み”になります。
■ 評価ステップ①：基礎データの正確性をまず確認する
延滞債権リストも滞留在庫リストも、最初は売掛金データや在庫データから生成されます。
そのため、監査人は次のような確認を行います。
- 具体例（売掛金データの場合）
・売掛金の総額が総勘定元帳の残高と一致するか
・顧客別の補助元帳や販売システムのデータと整合するか - 非財務データにも注意が必要
滞留在庫リストでは、入出庫日やロット情報など、会計システム外のデータが利用されることも多いため、倉庫システムの出庫伝票、仕入書、検収書など外部証憑との突合も有効です。元データが不完全であれば、作られるリストの分類精度や滞留期間の判断が全て狂います。
■ 評価ステップ②：抽出・分類・集計ロジックの妥当性をチェックする
次に、リストを作成するアプリケーション側のロジックが、業務ルールと矛盾していないかを確認します。
例：延滞債権リストの場合
- 何日以上入金が遅れたら「延滞」なのか（30日？60日？90日？）
- リストの対象は、当月だけなのか、累積の滞留も含むのか
- 貸倒引当の区分とどう連動しているか
例：滞留在庫リストの場合
- 滞留の起算日は入庫日か最終出庫日か
- 在庫項目の集計単位は SKU？ロット？仕入先別？
- 適正在庫と比較した分類（過剰・廃棄対象など）
業務側で決められた定義と、システムの抽出条件が一致していることが重要になります。
■ 評価ステップ③：リスト生成までの流れをウォークスルーする
リストがどのような過程を経て作られるのかを実際にたどることで、
データ蓄積 → 分類 → 集計 → 出力
の一連の処理が理解できます。
ウォークスルーでは次の観点が有効です。
- 売上・在庫データがどのテーブルに保存されるか
- どのタイミングで締め処理や更新処理が行われるか
- 抽出処理はバッチかリアルタイムか
- 前処理・後処理で何かフィルターが掛かっていないか
特にERPや倉庫管理システム（WMS）を使用している企業では、「在庫情報が複数システムで管理 → 会計に集約 → リスト作成」という複雑な流れになるため、ウォークスルーが必須になります。
■ 評価ステップ④：IT 全般統制（ITGC）の有効性を考慮する
仮にある時点では正しくリストが出力されていたとしても、プログラム変更管理・アクセス管理・運用管理といった ITGC が不十分だと、次のようなリスクが生じます。
- 誰かが抽出ロジックを書き換えても気づけない
- 権限のないユーザがデータを修正できてしまう
- バッチ処理が実行されず、古いデータが残ってしまう
そのため、監査人は“継続的に正しいリストが出る体制になっているか”という観点でITGCも合わせて評価します。