承認フローは、多くの業務システムに組み込まれている機能ですが、その設計次第で内部統制としての実効性は大きく変わります。誰が承認するか、どのような経路で承認が進むかという設計が、形式だけの承認になるか、実質的なチェック機能を果たすかを分けます。
形式的な承認になりやすい理由
承認フローが形骸化する典型的なパターンは、承認者が申請内容を精査する時間や情報を持たないまま、機械的に承認ボタンを押すだけの存在になっている状態です。承認件数が多く、一件ごとの内容確認に時間をかけられない場合や、承認者が申請の背景を十分に理解できる立場にない場合に、この状態は起こりやすくなります。承認フローが存在すること自体が目的化し、実質的なチェックが機能しなくなります。
承認経路の設計が結果を左右する
内部統制の観点から重要なのは、承認者が申請内容に対して実質的な確認能力を持っているかどうかです。金額の妥当性を確認できる立場の人が金額に関する申請を承認する、業務内容を理解している人が業務変更の申請を承認するというように、承認者の役割と申請内容を適切に対応させる設計が必要です。組織図上の上長というだけの理由で承認経路が設計されていると、実質的なチェックが機能しないまま形式だけが整うことになります。
承認の粒度をどう設定するか
すべての申請に同じ重さの承認プロセスを課すと、軽微な申請にまで時間がかかり、業務のスピードが損なわれます。一方で、承認を簡略化しすぎると統制が効かなくなります。金額や影響範囲に応じて承認の階層や必要な承認者の数を変える、段階的な設計が現実的な解決策になります。少額の申請は一段階の承認で完結させ、影響範囲の大きい申請には複数段階の承認を要求するといった設計です。
承認履歴を統制の証跡として残す
承認フローが内部統制として機能しているかを事後的に検証するためには、誰がいつどのような判断で承認したかという履歴が残っている必要があります。この履歴は、監査対応の場面だけでなく、承認プロセス自体の妥当性を見直す際の材料としても活用できます。承認の判断根拠が記録されていなければ、承認フローが形式的なものだったのか実質的なチェックだったのかを、後から検証することができません。
まとめ
承認フローが内部統制として機能するかどうかは、承認者が実質的な確認能力を持っているか、申請の重さに応じた承認の粒度が設計されているか、そして承認履歴が証跡として残っているかによって決まります。フローの存在自体を目的化させないための設計が求められます。