実務経験者が解説するIT統制の基礎 #4
大変長らくお待たせしました。
前回の投稿からさらに1年半以上も空いてしまいました…
「実務経験者が解説するIT統制の基礎マガジン」の第4回は、いよいよIT業務処理統制について解説していきます。
今回がマガジンの最終回となる予定です。
IT業務処理統制とは
第2回で解説した通り、IT業務処理統制は評価処理対象となった事業の業務処理プロセスのうち、ITにより自動化されているプロセスに対して実施する統制です。
ITAC（IT Apprication Control）と略されることも多いです。
IT業務処理統制は、業務処理統制の中の一部です。
そもそも業務プロセス統制とはどのようなものかを簡単に解説します。
業務プロセス統制とは
業務プロセス統制は、評価範囲となった事業ごとに実施する統制です。
各事業の業務フローを資料として可視化し、各プロセスで発生するリスクがあればそれに対するコントロールを定めます。
例）
「見積の際は営業担当者が値引きを設定する」というプロセスに対して、「不適切な多額の値引きが設定されるリスク」が想定される場合、「一定額以上の値引きについては、決裁権限表に従った上長承認を必要とする」といったコントロールを置く
上記の例はどのような事業でも発生する一般的な業務プロセスですが、事業固有のリスクとコントロールも当然発生します。
例）
採用課金タイプの人材紹介サービスであれば、企業側が課金が発生しないように採用したことを隠蔽するリスクを回避するために、求職者側に採用されたことを証明する証憑の提出を求めるなど
そのため、全社統制や決算・財務報告プロセス統制に対し、会社や事業により内容がまったく異なるのが業務プロセス統制となります。
決まった型は無いため、自社の事業に従って業務フローを作成する必要があり、事業のプロセスが変化した場合はそれに追従してアップデートしていく必要もあります。
IT業務処理統制の概要
IT業務処理統制は、業務プロセス統制のうちITにより自動化されたプロセスのリスクとコントロールを評価する統制です。
対象事業の業務がすべてITを使わずに紙の書類のみを使用したアナログな業務フローであればIT業務処理統制は発生しませんが、今時そんな事業の方が珍しいでしょう。
特に重要なのが、売上や原価など財務諸表に影響する数字を会計システムに連携する部分です。どのような事業でも、当月の売上を会計システムに反映するために、CSVでエクスポートした売上データを会計システムにインポートしたり、あるいはAPIを使用して直接会計システムに連携しているでしょう。
もし当月の売上を集計するプログラムにバグがあり誤った数字が会計システムに連携されて誰も気付かず決算報告書を作成してしまった場合、それは虚偽の報告となり大きな問題となります。こういった自体を防ぐために、IT業務処理統制を実施し、システムから出力される数字が本当に正しいかどうかを定期的にチェックします。
IT業務処理統制の具体的な内容
ではIT業務処理統制では具体的にどのような対応を実施するのかを見ていきます。
まず対象となる数字は、財務諸表に大きく影響を与える売上・原価・支払などに該当する科目です。
今回は例として、広告掲載サービスで考えてみます。
広告掲載サービスでは、クライアントから発注をいだたいた内容で一定期間自社のWebサイトに広告を掲載し、請求書を発行します。月単価は一定ですが、月中で掲載開始・終了した場合は日割りで売上金額を計算します。
※あくまで説明のための一例で、すべての広告掲載サービスが今回の解説の通りのスキームという訳ではありません
受注をいただいた場合、担当者は自社のWebサイトの管理システムから広告の内容・金額・掲載期間を入力して広告を掲載します。毎月末には当月の売上と請求の金額をシステムで集計し、CSV出力できる仕組みを備えています。
出力した売上CSVは会計システムにインポートして売上に関連する仕訳となり、請求CSVを元に担当者が請求書を手動で発行してクライアントに送付します。
上記の業務フローを簡単に図にすると、以下のようになります。
この業務フローにおいて、売上CSV・請求CSVをシステムで出力する部分がIT業務処理統制における「リスク」となります。
もし出力した売上CSVの数字に誤りがあれば当月の売上がおかしくなりますし、請求CSVに誤りがあれば売上と請求・振込金額が一致せずに入金消込が合わなくなってしまいます。
このようなリスクに対して、IT業務処理統制で「システムから出力されている数字が本当に正しいか」をコントロールとして定め、年次の評価のタイミングで確認します。
では具体的にどのようにシステムから出力される数字が正しいかどうか確認するのでしょうか。
基本的には各処理のインプットとアウトプットの数字が一致するかをチェックします。
たとえば今回の売上CSVであれば、売上の元になっているのは広告掲載データです。自社Webサイトの管理システムにはクライアントから受注した広告掲載データがDBに登録されているので、指定月の売上金額を出力するSQLを実行して指定月の理論上の売上明細を出力します。その明細を、通常の操作で管理システムから出力した売上CSVと突合し、金額が一致するかを確認します。
売上が日割り計算であったり、特定のクライアントが特価が適用されていたり、ロジックが複雑になりイレギュラー増えるほどSQLも複雑になり、チェックの難易度も上がってきます。
「プログラムで動作しているんだから、一度チェックすれば今後はプログラムに変更が発生していないことを確認すれば良いのでは？」と思われる方もいらっしゃるかもしれません。
自社内だけの監査であれば、たしかに売上出力を処理している箇所のコードに変更が加わっていないことをGitHubのコミット履歴などから確認するという方法も有効です。しかし、監査法人が実施する監査についてはそれだけでは不十分であり、年に一度はインプット・アウトプットの数字の突合まで求められるケースが多いです。
このようにIT業務処理統制ではSQLやコードレベルのチェックを行ったり、事業のDBのテーブル構成やビジネスロジックも理解する必要があります。そのため、内部統制担当者だけでは対応が難しくプロダクトのエンジニアの協力も必要な場合が多いです。
監査法人側もIT担当者がアサインされることが多く、SQLやコード、GitHubのコミット履歴などまで証憑として提出を求められる場合もあるため、それらについて理解して監査法人・エンジニアそれぞれと会話できる程度の知識が必要となってきます。
そのため、ITが分からない内部統制担当者だけではIT業務処理統制の対応が難しく、情シスなどITがある程度分かるメンバーに協力を依頼されるケースもあります。
今回は非常にシンプルな例で解説しましたが、実際の業務プロセスやIT業務処理統制はもっと複雑かつ対象事業の数だけ対応が必要なため、IT統制の中でも最も重い対応となることが多いと思われます。
IT業務処理統制を見据えた留意点
ここまで解説してきた通り、IT業務処理統制は非常に複雑かつ内部統制担当者だけではなくプロダクトサイドのエンジニアの協力も必要となります。
毎年の監査への対応を省力化したり、そもそもの売上数字の不具合といった大きな問題を発生させないために、いくつか気をつけるべきポイントがあります。
ビジネスロジックを分離する
売上や請求に関わるコードのリポジトリを分けるなど、プロダクトのフロント部分とビジネスロジックを分けておくことで、IT業務処理統制の際にチェックすべき箇所や影響範囲を明確になります。
逆にビジネスロジックもUIもごちゃ混ぜになったモノリシックなアーキテクチャの場合、数字に関係ないと思っていた箇所の改修で思わぬ影響が発生したりトラブルが発生する要因にもなります。
ビジネスロジックを分離しておけば、基本的には売上や請求に関連する業務プロセスに追加・変更が発生しない限りはビジネスロジックのコードの変更も発生しないため、コードのコミット履歴からも変更を追いやすくなります。
業務フローの変更が発生する場合は必ず内部統制担当に相談する
事業サイドで新しい商品が追加になったり、業務フローの変更が発生することはよくあります。その際、内部統制担当や経理担当に相談せずに事業部のみで業務フローを組み立てたり変更したりすると、トラブルの要因になります。
事業サイドは事業のプロではありますが、会計や内部統制のプロではありませんので、それらの観点が抜け落ちてしまっているケースも多々あります。極端な例ですと、プロダクトのエンジニアが売上と請求の違いが分かっていなかったり、売上の計上基準について理解しておらず役務提供期間で按分せずすべての売上を単月計上してしまうといったことも考えられます。
そのため、新しい商品の追加や業務フローの見直しを実施する際は、事前に必ず経理担当者や内部統制担当者などコーポレート部門に相談をしてもらい、それらの方々の視点からのアドバイスをもらいながら業務フローを設計していくようにしましょう。
この問題は特にスタートアップやベンチャー企業など、事業部の決裁権が強く事業スピードを重視する際に発生しがちです。トラブルを回避するためにも、各事業部長に会計や内部統制についての概要を説明して理解していただき、業務に変更が発生する際は都度相談をしてもらえる信頼関係を構築しておくことが重要となります。
まとめ
これまで4回にわたってIT統制について実務担当者目線で解説してきました。
繰り返しになりますが、内部統制やIT統制には正解がありません。
自社の業務のリスクを排除しつつ、事業のスピードを極力落とさず、監査対応の負荷をなるべく抑えることができるようなプロセスを継続的に検討する必要があります。
監査法人としっかりコミュニケーションを取りながら、押さえるべきところは押さえ、省力化できるところは省力化するような落とし所を見つけていくことが重要になります。
内部統制やIT統制は実務で実際に担当しなければイメージが湧きづらい業務だとは思いますが、自社の上場やガバナンスに直結する非常に重要な業務でもあります。もしこれから担当する方がいらっしゃれば、このマガジンの内容が少しでも助けになれば幸いです。
この記事が気に入ったらサポートをしてみませんか？