IT内部統制の実務～業務処理統制の運用状況の有効性評価

総論：

テストできなければ、有効性の「評価」は完結しない。

【運用テスト手続を「整備状況の評価」の段階で考えることの重要性】

運用テスト手続の妥当性を「整備状況の評価」の段階で吟味しておかないと、運用状況の評価の段階に来てから、手戻りになるリスクがある。手戻りの原因は、「実際にはテストが出来ない」という「見込み違い」や、「テスト手続が妥当ではない（照合の方向が違う、資料間の照合を行っていない、母集団の網羅性と正確性が確かめられていないなど「意味がない」）」として「テストやり直し」とされるなどである。

【テスト手続の三つの構成要素】

（１）種類（内容）－どんなことを
　　　実行可能性、照合の方向、母集団の特定、エラーの定義　に注意要
（２）時期　－どのタイミングで
（３）範囲（件数）－どのくらい

照合の方向：

【順進と逆進】

テストは殆どが「照合」という手続に落とし込まれるが、その照合の方向には「順進」（「事実から帳簿へ」＝「発生から記録へ」という時間の流れと同じ方向）と「逆進」（「帳簿から事実へ」＝「発生から記録へ」という時間の流れと逆の方向）の二つの方向がある。

【逆進が求められるケース】

１．「実在性」目的の照合では、順進ではなく逆進でなければ意味がない。なぜなら、発見したいのは「帳簿にあって、事実はない」というもの（事実を伴わない帳簿記録）だから。
２．「事実」「実体」との照合のできない取引は、その正確性・正当性を「承認」に大きく依存している場合が多い。ということは、その「承認」の漏れがない、と言う心証を得るような手続（＝承認漏れがあれば見つかるような手続）を実施する必要がある。その手続は、申請書上だけで承認の有無をテストしても意味がないし、申請書からサンプル抽出しても意味がない。（見つけたいのは承認なし、そもそも申請なしにエントリされた情報）
３．承認が重要性を持つ場合のテスト手続においては特に、承認証跡さえあればＯＫとするのではなく、承認者が承認要件を守っているかどうかも、テストの対象とすることが必要である。

【順進が求められるケース】

「網羅性」目的の照合では、順進でなければ、意味がない。なぜなら、発見したいのは、「事実はあるのに、帳簿にない」というもの（帳簿に反映されていない事実）だから。
一般的には「負債科目」の過小計上を防止・発見するための統制活動となる。

母集団の適格性：

１．テスト手続策定において、母集団に関して明確にすべき事項
（１）どのような母集団であるかの明示（例：ＸＸ月ＸＸ日付けのＸＸＸリスト）
（２）なぜその母集団でよいのかの説明
（３）その母集団の適格性を確かめる手続

２．母集団の適格性に関するポイント
（１）母集団自体の網羅性（いくつあるのか／それで全部か）
（２）一つの母集団の中の、明細情報の正確性と網羅性

３．母集団の中の、明細情報の「網羅性」について心証を得るための手続の一つは、その母集団の合計金額を再計算し、「しかるべき財務数値に照合することである。

４．母集団の中の、明細情報の「正確性」について心証を得るための手続の例は、その母集団の合計の再計算や、明細を何件か原票や関連帳票に照合するなどである。

【母集団の中の網羅性】

１．悪魔の証明（あることが『全くない』ということを、証明することは、世の中のすべての事象・事実を確かめなければ言えないので、現実的には不可能であるというもの）という考え方にあるように、「帳簿から漏れているものはない」と証明するのは無理。
合理的な保証を得るという観点から、「見つかりうる方法（テストの目的に照らして「意味のある」テスト手続）」であればいい。

２．マスタファイルや全般統制関係のような非財務情報は、ストックの概念（ある時点における断面）の明細は確保できても、フローの概念（ある期間の取引明細・更新履歴など）の明細は確保できない場合がある。

３．内部統制そのものは従来から存在するはずのものであるが、その「有効性評価」というものが義務付けられたために、その有効性の検証が求められるようになった。

４．つまり「全部しっかりやっています、ということを第三者に示すことが出来る」かどうかが重要である。それが出来ないのであれば「有効ではない」という結論となる可能性がある。

テストの実行可能性：

「自動化された統制活動」のテストは、ＩＴ側に丸投げするのではなく、どの統制活動をテストすべきか（業務側が詳しい）と、それをどのようにテストできるか（ＩＴ側が詳しい）とについて、両者で協働して詰めていく、というやり方が望ましい。

エラーとは何か：

１．エラー定義（サンプルテストにおいて、それが所定件数以上見つかると統制に「運用上の不備がある」と判断されるもの）をある程度は事前にしておかないと、有効性評価の結論の誤りや不整合だけでなく、本来不要なコストを生み出す危惧がある。

２．エラー定義は事前に完全に出来るものではないので、事例を蓄積しておき、共有するとともに、それを絶対的なものと見なさず常に議論しつつ見直していくといった工夫が必要である。

３．照合時の不一致の許容度の違いも考慮に入れる必要がある。

４．運用テスト段階で「エラー」が頻発したら、まず疑ってみるとよいのは、「実はそもそもルールがないのではないか？」、あるいは「ルールがあっても明確ではない・伝わっていない・不足であった」ということである。つまりある意味、整備状況の有効性評価への手戻り、ということになる。これを防ぐ意味で出てきた工夫が、「運用テストの1件前倒し」である。

ロールフォワード：

【会計監査におけるロールフォワード】

（１）必要件数のサンプルテストは期中に済ませ
（２）それ以降の期末日までの期間については「内部統制に重要な変更がないこと」を確かめるための最低1件のテスト（ウォークスルーなど）を期末日後など適時に行うことで補完する。
（３）しかも「それ以降の期末日までの期間」が一定期間内であれば、テストを省略し質問・観察等で済ますことも認められている。

ただし、（３）は前提条件として
（あ）もともとその期間中に「内部統制の重要な変更」が予定されていない
（い）期末実証手続で入手する資料や情報によって、実際に「内部統制の重要な変更」がなかったという心証をある程度は得ることができる。
（う）当然のことだが、そもそもその内部統制は有効である。

母集団の「束ね」：

ＩＴ内部統制に固有のポイント＝自動化された統制活動は、手作業の統制活動よりも「束ね」が合理性を持つ場合が多い。支店・営業所など場所が異なっても、それを司っているシステムが一つであれば、一箇所でテストすればいいということになる。