IT業務処理統制と会計システム連携｜J-SOXで見るべき入力・処理・出力・データ連携の実務

J-SOX対応において、IT業務処理統制は「システムで処理しているから大丈夫」と説明するための論点ではありません。

販売管理システムで売上データが作られ、在庫管理システムで出荷情報が確定する。購買管理システムから仕入・債務データが会計システムへ連携され、給与計算システムの結果が人件費として仕訳化される。こうした処理が財務報告に影響するのであれば、会社は「そのシステム処理がなぜ信頼できるのか」を説明できなければなりません。

IT業務処理統制とは、財務報告に関係するアプリケーション上の入力、処理、出力、データ連携、エラー処理、マスタ管理、承認ワークフローなどを通じて、会計数値の網羅性・正確性・正当性を支える統制です。

金融庁の内部統制実施基準では、企業が業務プロセスにITを利用している場合、ITを利用した統制が行われている部分について、IT全般統制および業務処理統制の評価を検証することにより、業務プロセスに係る経営者評価の妥当性を検証することとされています。IT業務処理統制については、入力情報の完全性・正確性・正当性、エラーデータの修正と再処理、マスタ・データの維持管理、システム利用に関する認証・操作範囲の限定などが評価項目として示されています。
出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準

この記事では、J-SOX上のIT業務処理統制を、業務システムと会計システムの連携、財務報告リスク、証跡、監査法人対応という観点から整理していきます。

IT業務処理統制とは何か

IT業務処理統制とは、財務報告に関係する業務処理を、アプリケーション・システム上で正しく実行するための統制です。

IT全般統制は、アクセス権限、変更管理、運用管理、バックアップ、障害対応など、システムそのものを信頼するための基盤を支えます。これに対してIT業務処理統制は、個別の業務プロセスの中で、取引データや会計データが正しく処理されることを支えるものです。

たとえば、次のような統制がIT業務処理統制に該当します。

• 販売管理システムで、承認済みの受注データだけが出荷処理に進める
• 出荷確定データに基づき、売上計上データが自動生成される
• 得意先マスタに登録されていない得意先コードでは請求処理できない
• 会計システムに連携する仕訳データについて、件数と金額の一致を確認する
• 入力必須項目が未入力の場合、エラーとして処理を止める
• 与信限度を超えた取引を自動的に警告または承認待ちにする
• ワークフロー上、承認権限者の承認がなければ支払データが作成されない
• 給与計算システムの計算結果が、会計仕訳として自動連携される
• 固定資産システムで減価償却費が自動計算され、会計システムへ連携される

経済産業省のIT統制ガイダンスでも、販売業務、購買業務、在庫管理業務等の業務プロセスでは、各種アプリケーション・システムにより取引が処理され、会計システムへ財務情報が流れていきます。そのため、IT業務処理統制はアプリケーション・システムで処理される財務情報の信頼性に直接関係するとされています。
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

つまりIT業務処理統制は、IT統制の中でも財務報告リスクに最も近い領域だといえます。

IT業務処理統制は「自動化された統制」だけではない

IT業務処理統制というと、自動計算、自動仕訳、自動照合、自動承認制御のように、完全にシステムへ組み込まれた統制だけを思い浮かべがちです。

しかし、実務上はそれだけではありません。

J-SOXで見るべきIT業務処理統制には、システムに完全に組み込まれた自動統制だけでなく、人の判断やレビューがシステムから出力されたデータに依存する統制も含まれます。

たとえば、会計システムから出力した売掛金年齢表をもとに、経理担当者が貸倒引当金の要否を検討する場合、その統制自体は人によるレビューです。しかし、そのレビューが会計システムから出力された年齢表の正確性に依存しているのであれば、当該帳票の生成過程や元データの信頼性まで確認しなければなりません。

内部統制の実務でも、IT業務処理統制は「自動化された業務処理統制」と同義に捉えられがちです。しかし実際には、会計システムから得意先別の売掛金年齢表を出力し、それに基づいて回収可能性を検討するようなIT依存統制も含まれると考えるべきです。

この点は重要です。

完全自動化された統制だけを評価し、システム帳票を利用した人のレビュー統制を見落としてしまうと、財務報告上重要な判断過程の信頼性を説明できなくなります。

IT業務処理統制で見るべき4つの基本領域

IT業務処理統制は、細かく分類すれば多くの論点があります。ただ実務上は、次の4つに整理すると理解しやすくなります。

• 入力統制
• 処理統制
• 出力統制
• インターフェース統制

この4つは、会計システム連携を考えるうえでも基本になります。

入力統制

入力統制は、システムに入力されるデータの完全性、正確性、正当性を確保するための統制です。

販売管理システムであれば、受注日、得意先コード、商品コード、数量、単価、出荷予定日、税区分、請求条件などが正しく入力される必要があります。給与計算システムであれば、人事マスタ、勤怠データ、手当、控除、社会保険料、源泉税などの入力が誤っていれば、会計上の人件費や未払金にも影響が及びます。

入力統制の例としては、次のようなものが挙げられます。

• 必須項目が未入力の場合に処理を進められない
• 金額欄に文字列を入力するとエラーになる
• 得意先コードや商品コードをマスタと照合する
• 上限値・下限値を超える金額や数量について警告を出す
• 承認済みデータだけが次工程へ進む
• 入力者と承認者をシステム上分離する
• 入力後の修正には承認を必要とする
• 変更履歴や操作ログを残す

日本公認会計士協会の監査基準報告書315実務ガイダンスでは、入力内容が予定された様式・内容と一致するかを確認するエディット・バリデーション・チェックとして、フォーマットチェック、必須項目チェック、貸借バランスチェック、リミットチェックなどが例示されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

入力統制の弱さは、後工程の会計処理にそのまま影響します。会計システムに到達した時点で数字が整っているように見えても、入力段階で誤ったデータが入っていれば、財務報告上の虚偽表示リスクは残ったままです。

処理統制

処理統制は、システムに入力されたデータが、会社の会計方針、業務ルール、承認条件、計算ロジックに従って正しく処理されることを確保する統制です。

たとえば、次のような処理が該当します。

• 売上計上日の自動判定
• 売上金額、消費税、値引、リベートの自動計算
• 仕入計上、債務計上、支払予定データの自動生成
• 在庫単価、移動平均単価、評価減対象データの計算
• 固定資産の減価償却費の自動計算
• 給与、賞与、社会保険料、源泉税の自動計算
• 為替換算、外貨建債権債務の換算差額計算
• 連結消去仕訳、内部取引照合、連結修正処理
• 勘定科目、補助科目、部門コードへの自動変換

ここで重要になるのは、システム処理が「会社の採用する会計方針や業務ルールと整合しているか」という点です。

たとえば、会社が出荷基準で売上を計上しているにもかかわらず、システム上は出荷予定日をもとに売上データが生成される設計になっていたとします。この場合、実際には出荷されていない取引が売上計上されてしまう可能性があります。JICPAの実務ガイダンスでも、出荷基準で売上を計上する企業において、出荷の事実ではなく出荷予定をもって出荷があったとみなすシステムを構築した場合、売上計上に重要な影響を及ぼすことがあるとされています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

処理統制を見るときは、単に「自動計算されているか」ではなく、「何を根拠に、どの条件で、どの会計処理が自動生成されているか」まで確認する必要があります。

出力統制

出力統制は、システムから出力される帳票、データ、一覧表、レポート、エラーリストなどが、正確かつ完全で、承認された者に適切に利用されることを確保する統制です。

たとえば、次のような帳票・データがJ-SOX上重要になりやすいところです。

• 売上明細表
• 請求一覧表
• 売掛金年齢表
• 入金消込一覧
• 仕入債務一覧
• 支払予定表
• 在庫受払表
• 棚卸差異一覧
• 固定資産台帳
• 減価償却費計算表
• 給与支給集計表
• 振込データ一覧
• 連結パッケージ
• 内部取引照合表
• 開示基礎資料

出力帳票は、単なる結果資料ではありません。多くの場合、経理担当者、部門責任者、内部監査、監査法人がレビューするための基礎資料になります。

したがって出力統制では、次の点を確認する必要があります。

• 帳票の元データは何か
• 抽出条件は適切か
• 対象期間や対象部門は正しいか
• 出力後に手作業で加工していないか
• 出力帳票の版管理はされているか
• 誰が出力し、誰がレビューしているか
• レビュー結果や差異対応の証跡が残っているか
• 監査法人に提出する帳票と社内利用帳票が同一条件で作成されているか

JICPAの実務ガイダンスでは、レポート出力について、明細レポート、集計レポート、入力内容を表示するプルーフ・リスト、エラー内容を表示するエラーリストなどが例示されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

出力帳票に依拠したレビュー統制をキーコントロールにしている場合は、その帳票がどのように生成され、どこまで信頼できるのかを説明できることが求められます。

インターフェース統制

インターフェース統制は、システム間でデータを受け渡す際に、データの欠落、重複、誤変換、未取込、誤取込、エラー放置を防ぐための統制です。

J-SOX上、最も手戻りが起こりやすいのがこの領域です。

販売管理システムから会計システムへ売上仕訳を連携する。購買管理システムから会計システムへ仕入・債務データを連携する。在庫管理システムから原価計算・会計システムへ在庫データを連携する。給与計算システムから会計システムへ人件費仕訳を連携する。経費精算システムから会計システムへ経費仕訳を連携する。

これらの連携がある場合、次の点を確認する必要があります。

• 連携元システムと連携先システムは何か
• 連携対象となるデータ項目は何か
• 連携頻度は日次、月次、随時のいずれか
• 自動連携か、CSV出力・手作業取込か
• データ変換ルールは文書化されているか
• 件数、金額、税額、科目、部門、補助コードの照合をしているか
• エラーリストが出力されるか
• エラーの修正、再処理、再取込の責任者は誰か
• 取込後の仕訳修正が承認され、履歴として残るか

月次の監査実務においても、新たに業務システムから会計システムへ仕訳連携を行う場合には、業務システムから連携データが出力され、会計システムに仕訳を読み込むまでの一連の流れを把握しておく必要があります。

システム連携は、見た目には自動化されているように見えても、途中にCSV加工、手修正、再取込、例外処理が入っていることがあります。ここを見落とすと、J-SOX評価の場面で「自動連携」と説明していたはずが、実際には重要な手作業統制が未設計だったという手戻りが生じます。

会計システム連携で最初に確認すべきこと

会計システム連携を評価するとき、いきなり連携仕様書やシステム設定を見るだけでは不十分です。

最初に確認すべきなのは、「どの財務諸表項目が、どの業務システムから来ているのか」という点です。

経済産業省のIT統制ガイダンスでは、財務会計システム以外のアプリケーション・システムにも、財務情報に関連する部分と関連しない部分があるとされています。そのうえで、IT業務処理統制の評価対象となるのは、会計システムおよび評価範囲として選定された業務プロセスに係るアプリケーション・システムの機能のうち、財務情報に関係する部分であると整理されています。
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

したがって会計システム連携の整理では、次のような対応関係を可視化しておくことが重要になります。

• 売上高、売掛金は、どの販売管理・請求・入金消込システムから来ているか
• 売上原価、棚卸資産は、どの在庫・物流・生産・原価計算システムから来ているか
• 仕入高、買掛金、未払金は、どの購買・債務・支払システムから来ているか
• 人件費、未払費用、預り金は、どの勤怠・給与・人事システムから来ているか
• 固定資産、減価償却費は、どの固定資産管理システムから来ているか
• 現預金、借入金、支払データは、どの資金管理・インターネットバンキング・会計システムから来ているか
• 連結財務諸表は、どの連結決算システム、子会社パッケージ、Excelから作られているか
• 開示資料は、どの会計データ、連結データ、開示基礎資料から作られているか

この対応関係が整理されていないと、監査法人から「この数字はどのシステムから来ていますか」「元データは誰が承認していますか」「連携漏れはどう確認していますか」と問われたときに、説明が断片的になりやすくなります。

マスタ管理はIT業務処理統制の中核である

会計システム連携を考えるうえで、マスタ管理は非常に重要です。

マスタは、単なるシステム設定ではありません。得意先、仕入先、商品、品目、単価、税区分、勘定科目、補助科目、部門、プロジェクト、従業員、固定資産、支払先口座などのマスタは、会計処理の結果そのものを決める基礎情報です。

たとえば、得意先マスタの締日・支払条件が誤っていれば、売掛金管理や回収予定に影響します。商品マスタの税区分や売上科目が誤っていれば、売上計上や消費税処理に影響します。仕入先マスタの支払条件や振込口座が誤っていれば、債務管理や支払処理に影響します。従業員マスタや給与計算条件が誤っていれば、人件費や未払費用に影響します。

JICPAの実務ガイダンスでも、連結会計システムにおける仕訳、為替、税率等の各種マスター設定や、退職給付債務パッケージにおける給与基準・ポイント基準・割引率・死亡率等の設定について、設定・入力・変更手続が適切な申請、承認等を経て行われているかを検証することが考えられるとされています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

マスタ管理で確認すべき主な論点は、次のとおりです。

• 新規登録の申請者、承認者、登録者が明確か
• 登録内容の根拠資料が保存されているか
• 変更時に承認と変更履歴が残るか
• 削除・停止処理のルールがあるか
• 会計処理に影響するマスタ項目を識別しているか
• 業務システムと会計システムでマスタの整合性が取れているか
• 子会社や外部委託先が管理するマスタを親会社が把握しているか
• 定期的なマスタレビューが実施されているか

マスタが誤っていれば、どれだけ会計システムへの連携が正確でも、誤った会計データが正確に連携されるだけです。

自動計算は「計算式」だけでなく「前提条件」を見る

自動計算は、IT業務処理統制の代表的な論点です。

ただし、評価すべきなのは計算式だけではありません。計算に用いられる前提条件、基礎データ、パラメータ、マスタ、そして適用する会計方針との整合性まで含めて確認する必要があります。

たとえば固定資産システムで減価償却費が自動計算されている場合、次の点が問題になります。

• 取得価額は正しく登録されているか
• 取得日、供用開始日、耐用年数、償却方法は正しいか
• 資本的支出と修繕費の判断結果が反映されているか
• 除却・売却・減損の情報が適時に反映されているか
• 会計システムに連携される仕訳科目、部門、金額は正しいか

給与計算システムであれば、給与計算ロジックだけでなく、人事マスタ、勤怠データ、手当、控除、社会保険料率、源泉税、退職者・休職者情報、振込データとの整合性が重要になります。給与計算の実務でも、勤怠管理システム、給与計算システム、会計システム、インターネットバンキングが連携する一方で、システムの結果は担当者が検証すべきものと考えるべきです。

自動計算を信頼するには、次の3つを確認する必要があります。

1つ目は、計算ロジックが正しいこと。

2つ目は、入力される基礎データが正しいこと。

3つ目は、計算結果が会計処理や開示資料に正しく反映されること。

この3つのどこかが欠けると、自動計算は統制ではなく、誤りを大量に再生産する仕組みになりかねません。

承認ワークフローは「承認ボタン」だけでは足りない

クラウドサービスやワークフローシステムの普及により、稟議、発注、経費精算、支払、契約、マスタ登録などを電子承認で行う会社が増えています。

電子承認は、適切に設計されていれば、紙の押印よりも統制上有効な場合があります。承認者、承認日時、承認内容、差戻し、変更履歴が残るためです。

しかしJ-SOX上は、「ワークフローで承認されています」だけでは不十分です。

確認すべきなのは、次の点です。

• 承認ルートが職務権限規程と整合しているか
• 金額、取引内容、部門、例外条件に応じた承認経路になっているか
• 承認権限者以外が承認できないよう制御されているか
• 承認前後で申請内容を変更できるか
• 変更できる場合、再承認が必要か
• 承認履歴、差戻し履歴、修正履歴が残るか
• 承認後のデータが会計システムへどのように連携されるか
• 承認ワークフローの設定変更が適切に管理されているか

JICPAの実務ガイダンスでも、承認プロセスがワークフロー化されている場合には、ログイン認証機能、承認ルート、承認権限者と非承認権限者の画面、承認前後の申請データ、承認履歴、承認後修正の可否などを確認することが例示されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

承認ワークフローは、権限設計、証跡管理、会計システム連携の接点です。ここが弱いと、「承認された取引だけが会計に反映されている」という説明が崩れてしまいます。

エラー処理は「発生しないこと」ではなく「検知して処理できること」が重要

IT業務処理統制では、エラーが発生しないことだけを目指すのではありません。エラーを検知し、修正し、再処理し、その過程を説明できることが重要になります。

システム連携において、エラーは珍しいものではありません。

• マスタ未登録
• コード不一致
• 税区分不一致
• 桁数制限
• 日付エラー
• 金額不一致
• 貸借不一致
• 重複取込
• 未取込
• 承認未了
• 締め処理後の取込エラー

問題は、エラーが発生したこと自体ではありません。

問題は、エラーが発見されず、修正されず、再処理されず、そのまま会計数値に影響していることです。

J-SOX上のエラー処理では、次の点を確認します。

• エラーリストが出力されるか
• エラー通知を誰が受け取るか
• エラーの原因分析を誰が行うか
• 修正は元システムで行うのか、連携データで行うのか、会計システムで行うのか
• 修正内容に承認が必要か
• 再処理結果を確認しているか
• エラーが未解消のまま決算に進まない仕組みがあるか
• エラー件数や未解消状況が管理者に報告されているか

売上を自動計上するシステムについて、JICPAの実務ガイダンスでは、システム間インターフェースが適切に行われているか、エラーデータが適切にフォローアップされているか、物流システムでの取消・変更が売上計上時までに売上システムへ反映されるか、商品マスタが適切にメンテナンスされ同期しているかなどが留意点として示されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

エラー処理の統制が弱い会社では、担当者が個別にCSVを修正し、再取込し、最終的に会計残高だけ合わせている、ということがあります。これでは、後から「どこで、なぜ、何を修正したのか」を説明できません。

売上プロセスで見るIT業務処理統制

IT業務処理統制を最も慎重に見るべき領域の一つが、売上プロセスです。

売上は財務諸表上の重要性が高く、不正リスクとも結びつきやすいためです。KAM事例でも、顧客管理システム、課金計算システム、会計システム間のインターフェースや、顧客契約データ・従量データ・単価データを利用した請求金額の再計算、課金計算システム等に係るIT全般統制が、監査上の対応として検討された例があります。

売上プロセスでは、次のような統制を確認します。

受注段階

• 得意先マスタに登録された顧客だけ受注できるか
• 与信限度を超える受注が承認待ちになるか
• 単価、値引、販売条件が承認済みマスタまたは契約に基づくか
• 受注取消・変更の履歴が残るか

出荷・検収段階

• 出荷確定データが売上計上の起点になっているか
• 出荷予定ではなく、実際の出荷・検収データに基づいているか
• 出荷取消や返品が適時に反映されるか
• 物流・在庫システムとの整合性があるか

売上計上段階

• 売上計上日が会社の会計方針と整合しているか
• 収益認識基準に照らして、本人・代理人、履行義務、取引価格、期間帰属が必要な範囲で反映されているか
• 税区分、勘定科目、部門コードが正しく付与されるか
• 会計システムへの仕訳連携後に件数・金額照合が行われるか

請求・債権管理段階

• 売上データと請求データの整合性が確認されるか
• 請求漏れ、二重請求、請求取消が検知されるか
• 入金消込データが売掛金残高に正しく反映されるか
• 滞留債権一覧や年齢表が正しく生成されるか

JICPAの実務ガイダンスでは、売上計上予定日に自動的に売上を計上する場合について、売上予定の登録が適切な承認または信頼できるデータに基づくか、取消・変更が適時に入力されているか、エラーデータがフォローアップされているか、売上計上予定日と実際の売上計上日に不整合がないかなどが示されています。出荷できなかった場合に取消入力が適時に行われないと、架空売上が計上される結果となる点にも留意が必要です。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

売上プロセスでは、業務フロー、会計方針、システム処理、証跡、不正リスクを一体で見る必要があります。

購買・支払プロセスで見るIT業務処理統制

購買・支払プロセスでは、発注、検収、請求書照合、仕入計上、債務計上、支払承認、振込データ作成がシステム化されることが多くあります。

ここで重要になるのは、支払までの流れが「承認された取引」「実際に検収された取引」「正しい金額で請求された取引」に基づいているか、という点です。

確認すべき主な統制は次のとおりです。

• 承認済みの発注データだけが検収処理に進むか
• 検収データと請求書データが照合されるか
• 発注、検収、請求、支払の数量・単価・金額が整合しているか
• 仕入先マスタの登録・変更が承認されているか
• 支払先口座の変更が厳格に管理されているか
• 未承認の支払データが作成されないか
• 支払データと会計仕訳が整合しているか
• 支払取消、再振込、例外支払の証跡が残るか

特に、支払先口座マスタ、支払データ、ワークフロー承認、インターネットバンキング連携は、不正支払や資産流用リスクとも関係する部分です。システム上は承認済みであっても、承認権限や口座変更権限が過剰であれば、IT業務処理統制としての有効性は弱くなります。

在庫・原価プロセスで見るIT業務処理統制

在庫・原価プロセスでは、数量、単価、受払、棚卸差異、評価、原価配賦がシステムに依存することがあります。

在庫管理の目的は、在庫の正確な数量を把握し、適切な水準にコントロールすることにあります。在庫量を誤って把握すると、購買・生産・販売判断だけでなく、棚卸資産残高や売上原価にも影響が及びます。

IT業務処理統制として確認すべき論点は、次のとおりです。

• 入庫、出庫、移動、返品、廃棄が適時に入力されるか
• 倉庫間移動や外部倉庫在庫が正しく反映されるか
• 実地棚卸結果がシステム在庫に正しく反映されるか
• 棚卸差異の承認と原因分析が行われるか
• 標準原価、移動平均単価、総平均単価などの計算ロジックが会計方針と整合しているか
• 滞留在庫、評価減対象在庫を抽出する帳票が信頼できるか
• 原価配賦、仕掛品、製品原価の計算条件が適切に管理されているか

在庫・原価は、システム処理が複雑になりやすい領域です。評価範囲に含める場合は、在庫管理システム、生産管理システム、原価計算システム、会計システムのどこで数量・金額が確定するのかを明確にしておく必要があります。

給与・人件費プロセスで見るIT業務処理統制

給与・人件費プロセスでは、人事マスタ、勤怠データ、給与計算、賞与計算、社会保険、源泉税、支払データ、会計仕訳が連動します。

一見すると給与計算は人事労務の論点に見えます。しかしJ-SOX上は、人件費、未払費用、預り金、法定福利費などに影響する財務報告プロセスでもあります。

確認すべき論点は次のとおりです。

• 入社、退職、異動、給与改定が人事マスタに適時反映されるか
• 勤怠データが承認済みであるか
• 残業、手当、控除、休職、退職者処理が正しく反映されるか
• 給与計算結果が会計仕訳へ正しく連携されるか
• 給与台帳、支給集計表、振込データ、会計仕訳が整合しているか
• 支払承認と振込実行が分離されているか
• 個人情報へのアクセス権限が限定されているか

給与計算システムを導入していても、システムの結果は担当者が検証すべきものです。給与計算システム、勤怠管理システム、会計システム、IBシステムの連携がある場合は、どこで承認され、どこで支払データが作られ、どこで会計計上されるのかをフローとして整理しておくことが重要になります。

連結・開示プロセスで見るIT業務処理統制

IT業務処理統制は、日常取引だけでなく、連結決算や開示プロセスにも関係します。

連結決算システム、子会社パッケージ、Excel、開示資料作成ツールを使っている場合は、次のような論点が出てきます。

• 子会社パッケージの入力権限、承認、提出状況
• パッケージ入力データと子会社の試算表・会計システムとの整合性
• 内部取引照合のロジック
• 連結修正仕訳の承認と入力制限
• 為替換算レート、持分比率、連結範囲、勘定科目マッピングのマスタ管理
• 連結システムから開示基礎資料へのデータ連携
• 開示資料作成ツールやExcelでの数式・参照範囲・版管理

経済産業省のIT統制ガイダンスでは、連結決算および財務報告書の作成がスプレッドシート等によって行われている場合もあるとされています。決算・財務報告プロセスでは、スプレッドシートの計算式コピー忘れや計算式誤りが財務報告の正確性・網羅性に直接影響するため、スプレッドシート等の統制も評価対象になるとされています。
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

開示資料に使う数字は、会計システムや連結システムから出力されるだけではありません。多くの場合、Excelで加工、集計、注記作成、前期比較、組替、文章化が行われます。ここに統制がなければ、会計システム上の数字が正しくても、開示資料上の数字や注記で誤りが生じます。

IT業務処理統制とアサーションの関係

IT業務処理統制をJ-SOX上説明するには、「この統制がどの財務報告リスクに効いているのか」を明確にする必要があります。

単に「入力チェックがあります」「自動計算されています」「エラーリストがあります」では不十分です。

重要なのは、その統制が、どのアサーション、すなわち財務報告上のどの要件を支えているのかという点です。

主な関係は、次のように整理できます。

• 実在性：実際に存在する取引・資産・債務だけが記録されているか
• 網羅性：記録すべき取引・残高が漏れなく記録されているか
• 正確性：金額、数量、単価、税額、科目が正しく処理されているか
• 期間帰属：適切な会計期間に記録されているか
• 権利と義務：会社に帰属する資産・債務として適切か
• 評価の妥当性：評価額、引当、減損、評価減が適切か
• 表示の妥当性：財務諸表・注記・開示資料上の分類や表示が適切か

経済産業省のIT統制ガイダンスでは、経営者は、評価対象となる業務プロセスについて、実在性、網羅性、権利と義務の帰属、評価の妥当性、期間配分の適切性、表示の妥当性といった財務情報作成の要件のうち、どの要件に影響するかを理解することが重要であるとされています。そして、IT統制目標の「完全性」は、売上高の計上漏れによる虚偽記載リスクを低減する統制にあたると説明されています。
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）

RCMにIT業務処理統制を記載する場合は、「システム機能」ではなく「財務報告リスクへの対応」として記載する必要があります。

IT業務処理統制の評価で確認すべき証跡

IT業務処理統制の評価では、システム仕様だけでは足りません。統制が設計され、実際に運用されていることを示す証跡が必要です。

確認すべき証跡には、次のようなものがあります。

システム処理の理解に関する証跡

• 業務フロー
• データフロー図
• システム仕様書
• 連携仕様書
• ユーザマニュアル
• マスタ一覧
• 画面キャプチャ
• 帳票サンプル
• 取引開始から会計記録までのウォークスルー記録

JICPAの実務ガイダンスでは、システム上のデータの流れを追跡する方法として、データフロー図やシステム仕様書、ユーザマニュアルの閲覧、入力原票と出力帳票の照合、入力画面・照会画面の閲覧、インターフェース元・先システムのデータ照合、アクセスログ・操作ログの閲覧などが例示されています。
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

入力統制に関する証跡

• 入力承認記録
• 入力エラーリスト
• 入力必須チェックの画面
• マスタ照合エラーの記録
• 修正履歴
• 例外承認記録

処理統制に関する証跡

• 計算ロジックの説明資料
• テスト結果
• 再計算結果
• パラメータ設定一覧
• 科目変換テーブル
• 税区分設定
• 自動仕訳ルール
• 設定変更承認記録

出力統制に関する証跡

• 出力帳票
• 帳票抽出条件
• レビュー記録
• 差異分析記録
• 帳票の版管理
• 出力者・確認者・確認日

インターフェース統制に関する証跡

• 連携件数・金額の照合表
• 取込ログ
• エラーリスト
• エラー修正記録
• 再取込結果
• 連携元・連携先データの突合記録
• 会計仕訳取込後の確認記録

証跡で重要なのは、資料が残っていることではなく、判断過程が分かることです。誰が、何を、どのデータで、どの条件で確認し、なぜ問題ないと判断したのか。そこが読み取れる必要があります。

IT業務処理統制でよくある不備

IT業務処理統制では、次のような不備がよく見られます。

1. 「自動連携」と説明しているが、途中に手作業加工がある

業務システムから会計システムへ自動連携していると説明しているものの、実際にはCSVを出力し、担当者がExcelで加工し、手作業で取込ファイルを作成しているケースです。

この場合、CSV出力後の加工、承認、保存、再取込、修正履歴が統制対象になります。

2. 連携件数・金額の照合をしていない

販売管理システムの売上データと会計システムの売上仕訳について、件数や金額の照合をしていないケースです。

自動連携であっても、連携エラー、重複、未取込、除外データが発生する可能性があります。連携結果を確認する統制がなければ、網羅性や正確性を説明しにくくなります。

3. マスタ変更が会計処理に与える影響を見ていない

得意先、商品、仕入先、科目、部門、税区分、支払先口座などのマスタ変更が、業務部門やシステム担当者だけで行われているケースです。

マスタ変更は、仕訳、税額、売上区分、支払、残高管理に影響します。会計上重要なマスタについては、経理部門または適切な責任者の確認が必要です。

4. エラーリストが出ているが、フォローされていない

エラーリストは出力されているものの、誰が確認するか、いつまでに解消するか、未解消のまま決算に進む場合の扱いが決まっていないケースです。

エラーリストは、出力されるだけでは統制になりません。エラーが解消され、再処理され、結果が確認されるところまでが統制です。

5. システム帳票の生成条件が分からない

売掛金年齢表、滞留在庫一覧、支払予定表、連結パッケージ、開示基礎資料などをレビュー統制に使っているにもかかわらず、抽出条件、対象期間、対象データ、除外条件が明確でないケースです。

帳票に依拠する場合は、その帳票がどのように作られたかを説明できる必要があります。

6. ワークフロー承認後の修正が管理されていない

ワークフローで承認された取引が、承認後に修正可能になっているケースです。

承認後の修正が再承認なしに行える場合、承認統制の意味は弱くなります。承認後修正の可否、修正履歴、再承認ルールを確認する必要があります。

7. RPAやEUCが統制対象から漏れている

RPA、Excelマクロ、Access、スプレッドシート、BIツールなどを利用して会計データを加工しているにもかかわらず、J-SOX上のIT業務処理統制として識別されていないケースです。

RPAやEUCは、現場で柔軟に作れる一方で、変更管理、アクセス管理、版管理、レビューが弱くなりやすい領域です。

IT業務処理統制の整備は、どこから始めるべきか

IT業務処理統制を整備・見直しする場合、最初から細かいシステム機能を網羅しようとすると、現場が疲弊してしまいます。

まずは、財務報告への影響が大きいデータの流れから整理することが重要です。

1. 重要な勘定科目と業務プロセスを結びつける

売上、売掛金、棚卸資産、売上原価、仕入債務、人件費、固定資産、現預金、連結修正、開示注記など、重要な勘定科目を起点にします。

そのうえで、それぞれがどの業務プロセス、どのシステム、どの帳票、どの連携データから作られるかを整理していきます。

2. 取引開始から会計記録までを追跡する

代表的な取引を選び、受注、出荷、請求、売上計上、入金消込、会計仕訳、決算資料への反映までを追跡します。

購買、在庫、給与、固定資産、支払についても同様です。

業務フローを理解することは、内部統制を整備するだけでなく、全体最適化にもつながります。典型的な業務フローを知ることで、自社に不足している内部統制や、逆に過剰・重複している統制を見極めやすくなります。

3. システム処理と手作業処理の境界を明確にする

完全自動化されている箇所、システム出力を人がレビューする箇所、CSV加工が入る箇所、Excelで補正する箇所、会計システムで手修正する箇所を分けて整理します。

J-SOX対応では、この境界が非常に重要です。

4. キーコントロールを絞る

すべてのシステム機能をキーコントロールにする必要はありません。

財務報告リスクに対して、特に重要な統制をキーコントロールとして選定します。

たとえば売上プロセスであれば、出荷確定データに基づく売上自動計上、得意先・商品マスタの管理、会計システムへの売上仕訳連携、エラー処理、請求・売掛金照合などが候補になります。

5. IT全般統制との関係を整理する

IT業務処理統制は、IT全般統制に支えられています。

売上自動計上ロジックが正しくても、プログラム変更管理が弱ければ、そのロジックが期中に無承認で変更される可能性があります。ワークフロー承認が適切でも、アクセス権限管理が弱ければ、承認権限者以外が承認できる可能性があります。

したがってIT業務処理統制を評価するときは、関連するIT全般統制の有効性もあわせて確認する必要があります。

監査法人との協議で整理しておきたい論点

IT業務処理統制は、監査法人との認識合わせが重要な領域です。

特に、次の論点は早めに整理しておくべきでしょう。

• どの業務システムを評価対象に含めるか
• どのシステム機能をIT業務処理統制として識別するか
• 自動統制とIT依存統制をどのように区分するか
• 会計システム連携の網羅性・正確性をどの証跡で確認するか
• マスタ管理をキーコントロールに含めるか
• ワークフロー承認をどの範囲で評価するか
• システム帳票をレビュー統制の基礎資料として利用できるか
• EUC、Excel、RPAを評価対象に含めるか
• IT全般統制の不備がIT業務処理統制に与える影響をどう評価するか
• 期中のシステム変更や新システム導入時に追加評価が必要か

金融庁の内部統制報告制度Q&Aでは、ITを利用せず手作業による統制の方が適している場合もあり、IT利用の程度は各企業で適切に判断されるべきものとされています。一方で、IT基盤が複数ある場合には、個々のIT基盤を評価単位としてIT全般統制を評価することも示されており、会社のIT環境に応じた整理が必要になります。
出典：金融庁｜内部統制報告制度に関するQ&A

ここで重要なのは、「監査法人が求めるから対応する」のではないという点です。会社としてどのデータに依拠し、どの統制で財務報告リスクを低減しているのかを、自ら説明できる状態にすることが目的です。

IT業務処理統制を決算早期化・開示品質につなげる

IT業務処理統制は、監査対応のためだけに整えるものではありません。

業務システムと会計システムの連携が整理されると、月次決算、四半期決算、開示資料作成の手戻りが減ります。データ連携のエラーが早期に検知されれば、期末にまとめて修正する必要も減ります。マスタ管理が整えば、科目誤り、部門誤り、税区分誤り、支払先誤りを減らせます。ワークフロー承認と会計仕訳がつながれば、承認済み取引だけが会計に反映されていることを説明しやすくなります。

決算早期化では、単体決算、連結決算、開示業務を分断せず、最終成果物から逆算して業務を組み立てる「森を見る視点」が重要になります。経理部内で業務が縦割りになると、手待ち、手戻り、重複が生じ、決算工数が増大してしまいます。

IT業務処理統制も同じです。

販売管理、購買管理、在庫管理、給与計算、固定資産管理、会計、連結、開示を個別システムとして見るのではありません。最終的な財務報告・開示資料から逆算して、どのデータがどこで生まれ、どこで承認され、どこで会計に連携され、どの証跡で説明できるのかを見る必要があります。

J-SOX対応として整えたIT業務処理統制は、決算早期化、開示品質向上、業務標準化、子会社管理、権限移譲にもつながっていきます。

IT業務処理統制について専門家に相談すべき場面

次のような状況がある場合、IT業務処理統制と会計システム連携を社内だけで整理するのは難しくなりやすいところです。

• 業務システムから会計システムへの連携範囲が整理できていない
• 自動仕訳や自動計算のロジックを説明できない
• CSV、Excel、RPA、手作業加工が多い
• 連携件数・金額の照合証跡が残っていない
• マスタ管理が業務部門任せになっている
• ワークフロー承認後の修正や再承認ルールが曖昧
• エラーリストは出ているが、フォローアップが属人化している
• 監査法人からIT業務処理統制やシステム帳票の信頼性について指摘を受けている
• 子会社ごとに会計システムや業務システムが異なり、親会社として説明できない
• IPO準備や上場後運用に向けて、業務システム・会計システム連携を見直したい

IT業務処理統制は、情報システム部門だけで完結する論点ではありません。財務報告リスク、業務フロー、会計方針、システム処理、マスタ管理、証跡、監査法人対応をつなげて整理する必要があります。

犬飼公認会計士・税理士事務所では、J-SOX対応を形式的な文書化作業としてではなく、決算・開示・業務プロセス・IT・証跡管理をつなぐ「説明できる会社づくり」として整理する支援を行っています。

会計システム連携、自動仕訳、マスタ管理、システム帳票、EUC、RPA、監査法人からのIT統制指摘、IPO準備段階での内部管理体制整備などに課題がある場合は、現在のデータフローと財務報告リスクを整理するところから始めることが有効です。

J-SOXにおけるIT業務処理統制を、自社の決算・開示・経営管理にどう接続すべきかを確認したい場合は、犬飼公認会計士・税理士事務所HPのお問い合わせページよりご相談ください。

出典・参考情報

出典：金融庁｜財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準
出典：金融庁｜内部統制報告制度に関するQ&A
出典：経済産業省｜システム管理基準 追補版（財務報告に係るIT統制ガイダンス）
出典：日本公認会計士協会｜監査基準報告書315実務ガイダンス第1号

重要事項の振り返り

論点	実務上のポイント
IT業務処理統制の位置づけ	財務報告に関係するアプリケーション上の入力・処理・出力・連携の信頼性を支える統制
IT全般統制との違い	IT全般統制はシステム基盤を支え、IT業務処理統制は個別業務プロセスの会計処理を支える
入力統制	必須項目、フォーマット、マスタ照合、承認、入力者制限により誤入力・不正入力を防ぐ
処理統制	自動計算、自動仕訳、科目変換、税区分、会計方針との整合性を確認する
出力統制	システム帳票の抽出条件、元データ、レビュー、版管理、差異対応を説明できるようにする
インターフェース統制	業務システムから会計システムへの連携について、件数・金額・エラー・再取込を管理する
マスタ管理	得意先、商品、仕入先、科目、税区分、支払先口座などは会計処理の結果を左右する重要統制
ワークフロー承認	承認権限、承認ルート、承認後修正、再承認、履歴保存を確認する
エラー処理	エラーリストの出力だけでなく、原因分析、修正、再処理、未解消管理まで設計する
最終目的	IT業務処理統制を、J-SOX評価だけでなく、決算早期化、開示品質、業務標準化、経営管理体制の強化につなげる