期末監査の資料依頼リストが届く。214行のうち、131行が「明細を出力してください」である。 売掛金の得意先別明細、仮払金の相手先別の内訳、第4四半期に計上した修繕費の伝票一覧。経理の担当者はSAPから抽出し、Excelに整え、共有フォルダに置く。二日後、同じ明細を別の切り口で出し直してほしいという依頼が来る。 金額の大きい順に、あるいは計上日で、あるいは起票者で。監査チームの誰かが「画面を直接見られれば一瞬なのに」と言い、経理部長は「うちのシステムを外部の人に触らせるのは」と答える。その会話が、三年続いている。
参照権限で消える往復と、消えない提出
参照権限の是非を議論する前に、監査人からの依頼を種類で分けておく。分けないまま「直接見てもらえば依頼がなくなる」と期待すると、導入後に失望する。
第一の種類は、定型の残高明細である。 勘定ごとの得意先別・仕入先別の明細、固定資産の増減明細。毎期ほぼ同じ形で依頼され、多くの会社ではすでに定型の帳票がある。参照権限で減るが、ゼロにはならない。 監査人は監査調書に証拠として残す必要があり、定型の明細は会社が出したものを受け取るほうが早い場面も多い。
第二の種類は、追加の照会である。 明細を見て気になった取引の相手先、伝票の添付、同じ相手先との前後の取引。経理の工数を実際に押し上げているのは、ここである。 一件ごとの依頼は小さいが、依頼・抽出・送付・再依頼の往復が、締めと同じ週に何十回も発生する。参照権限が最も効くのは、この往復である。 監査人が自分で画面を辿れば、経理の手を経由しない。
第三の種類は、仕訳テスト用の全件データである。 監査基準報告書240第31項の手続のために、監査人は仕訳の母集団を受け取り、網羅性を確かめたうえで自分の道具で抽出条件を当てる。画面で一件ずつ見る方式では、この手続は代替できない。 参照権限を渡しても、全件データの受け渡しは年に一度か二度、確実に残る。
つまり参照権限で消えるのは、主に第二の種類の往復である。 依頼リストの行数そのものより、依頼と回答の往復回数で効果を測る。行数だけを追うと、第一と第三の種類が残っていることを「効果が出ていない」と誤読する（監査法人の資料依頼（PBCリスト）の管理方法、期末に締めと監査を衝突させない分担）。
判断材料は、会社コードと勘定で切れるかどうか
参照権限を渡すかどうかを「漏えいが心配か」で議論すると、結論が出ない。心配かと問われれば、誰でも心配だと答えるからである。 問いを置き換える。監査に要らない明細を、システムの権限の単位で切り出せるか。
SAPの権限は、権限オブジェクトと、その中の項目の値で制御される。会計伝票であれば、権限オブジェクトF_BKPF_BUKが会社コード（BUKRS）と活動（ACTVT）の組み合わせで伝票の処理を許可し、活動の値03が「表示」に当たる。 監査対象の会社コードにだけ表示を許すロールは、この単位で作れる。
もう一段細かく切る手段が、勘定の権限グループである。総勘定元帳の勘定マスタ（会社コード単位）に権限グループを設定しておくと、FB03・FBL3N・FAGLL03などの伝票や明細の照会トランザクションで、権限オブジェクトF_BKPF_BESによりその値が検査され、対応する値を持たないユーザーには、その勘定の明細が表示されない。残高照会、帳票、Fioriアプリで同じ検査が効くかどうかは、ロールを作ったあとに監査人のIDで実際に照会して確かめる。 設計書の上で閉じていても、画面の経路ごとに挙動が同じとは限らないからである。
ここで、画面から外す候補を書き出す。基準は一つで、監査に要らない明細かどうかである。
- 監査対象外の会社コード（同じSAPに載っているが、当該監査法人の監査範囲にない会社）
- 人事給与の明細データ（会計伝票ではなく人事系のデータとして別に保持されている個人別の明細）
- 個人事業主を含む仕入先マスタの口座情報や、従業員の振込口座などの個人の口座情報
一方で、役員報酬の勘定や、買収検討の外部費用を集めている勘定を、同じ感覚で「見せない候補」に入れてはいけない。 役員報酬は関連当事者や開示の論点に直結し、買収関連の費用は資産計上か費用処理か、後発事象や偶発債務の論点につながる。どちらも監査に必要な領域である。 そして会社法第396条第2項により、会計監査人はいつでも会計帳簿及びこれに関する資料を閲覧し謄写できる。
機微な勘定を画面では絞りたいなら、絞ることと出すことを一組にする。 画面の照会ロールからは権限グループで外す。そのうえで、監査チームの求めがあれば、経理部長など決めた担当者が別の経路で必ず明細を出すことを、監査計画の打合せで文書にして合意する。合意のないまま画面で外せば、それは範囲の設計ではなく、会計監査人の権限を会社の都合で狭めたことになる。
書き出した候補が、会社コードか勘定の権限グループのどちらかで切れるなら、参照権限は渡せる。 切れないなら、渡す前に勘定の設計を直すか、その領域だけ出力方式を残す。
見落とされやすいのが、権限グループが設定されていない勘定は、この検査で止まらないという点である。期中に新しく作った勘定に権限グループを入れ忘れれば、そこに計上された明細は照会できる状態になる。参照権限を渡す会社は、勘定マスタの新規登録の手順に「権限グループの要否」の一行を足す必要がある。 これが、参照権限の導入で最初に生まれる新しい仕事である。
データに届く経路は一つではない
会計伝票の照会ロールを会社コードと勘定で絞っても、それで閉じたことにはならない。データに届く経路が、画面の数だけある。
最も大きい抜け道が、テーブルの直接参照である。SAP Help Portalの説明によれば、標準のテーブル保守（SM31）、拡張テーブル保守（SM30）、データブラウザ（SE16）でのアクセスは、権限オブジェクトS_TABU_DISがテーブルの権限グループ単位で制御し、個別のテーブル単位で制御する場合はS_TABU_NAMを使う。会計伝票の照会画面が見る会社コードや勘定の権限とは、別の門である。 監査チームに「データを自分で抜きたいのでSE16を付けてほしい」と言われて付けると、それまでの会社コードと勘定の絞り込みの設計が、テーブル側で意味を失いうる。
だから参照ロールの設計書には、許可するトランザクションの一覧と同じ重さで、許可しないトランザクションの一覧を書く。 仕訳の全件が必要なら、テーブル参照を渡すのではなく、第三の種類の依頼として会社が抽出して渡す。こちらは件数と合計金額で母集団の網羅性を双方で確かめられる。
もう一つの経路が、画面から手元へのダウンロードである。照会専用のロールでも、表示した一覧はファイルに落とせることが多い。これを止めようとすると、監査人は証拠を調書に残せなくなる。 止めるのではなく、持ち出された範囲を、ロールの範囲と監査契約上の守秘の取り決めで押さえる。範囲を絞る設計が効くのは、ここである。
そして、誰がいつ何を見たかの記録である。SAPには、読み取りアクセスを記録するRead Access Loggingと、ログオンや権限検査などのセキュリティ上の事象を記録するSecurity Audit Logという別々の仕組みがあり、いずれも記録の対象と条件を設定してはじめて使える。監査人のIDについて何を記録し、誰がいつ確認するかを、ロールを渡す前に決めておく。 決めずに渡すと、記録は有効になっていないか、有効になっていても誰も見ていない（SAPの緊急時特権ID（Firefighter）は誰にいつ渡すか、本番の強い権限の運用）。
新しく生まれる三つの仕事
参照権限は、期末の往復を減らす代わりに、年間を通じた仕事を生む。この三つを誰の業務分掌に置くかを決めないまま導入すると、二年目に崩れる。
第一に、IDの期限管理である。 監査人のIDは、往査の期間だけ有効にする。中間期のレビューの週と期末監査の数週間。期間外は無効にしておき、次の往査の前に有効化する。 監査チームの交代があれば、個人IDを発行し直す。共用IDは使わない。誰が見たかを記録で辿れなくなるからである。
第二に、ロールの年次見直しである。 監査対象の会社コードは、子会社の設立や売却で変わる。画面で絞る勘定と、別経路で出す合意の対象も、新規の案件で増える。期初の監査計画の打合せで、監査チームから当期の重要な勘定と会社コードを聞き、ロールの範囲と別経路の合意をそれに合わせる。 範囲の根拠は監査計画であって、経理の感覚ではない。
第三に、ユーザー管理の統制の対象に入れることである。 監査人のIDも、財務報告に関わるシステムのアクセス管理の母集団に入れる。発行の承認、期限、棚卸の記録。監査人のIDだけ例外扱いにすると、IT全般統制の評価で不備を招く。 社内ユーザーと同じ手順に載せ、区分だけ分けておく（SAPの権限設計と職務分掌（SoD）、内部統制を仕組みで担保する実務と判断基準）。
加えて、ユーザーを一つ増やすことのライセンス上の扱いは、契約の区分によって変わる。導入前に、自社の契約で照会専用のユーザーがどの区分に当たるかを確認しておく（SAPのライセンスとデジタルアクセスを棚卸しする手順、未使用権限と外部連携）。
売上高1,450億円の電子部品メーカー。SAP S/4HANAに国内外12の会社コードが載っており、うち監査対象として監査法人が往査するのは9社だった。 期末監査の資料依頼は238行あり、そのうち146行が明細の出力依頼だった。経理部が記録を取ってみると、出力した明細に対する追加照会と切り直しの往復は、期末監査の6週間で延べ410回に上っていた。 経理部長と監査チームの主査は、期初の監査計画の打合せで参照ロールの導入を決めている。最初にやったのは、画面から外す候補の書き出しである。 監査対象外の3つの会社コードはF_BKPF_BUKの値で外した。人事給与の個人別明細は人事系のデータで、会計の照会ロールには最初から含めていない。仕入先マスタの口座情報を表示するトランザクションもロールに入れなかった。経理部長は当初、役員報酬の勘定と、買収検討の外部費用を集めていた仮払金の勘定も外すつもりだった。 主査から、どちらも当期の重要な論点で、会社法上もいつでも閲覧できる帳簿であると指摘を受け、扱いを変えている。二つの勘定は権限グループを設定して照会ロールの画面からは外したうえで、監査チームから求めがあれば経理部長が当日中に明細を出すことを、監査計画の打合せの議事録に記載して双方で確認した。 データブラウザ系のトランザクションはロールに入れず、仕訳テスト用の全件データは、期末後に会社が抽出し、件数と借方合計・貸方合計を添えて渡す運用にした。IDは監査人ごとに発行し、有効期間を中間期のレビュー期間と期末監査期間に限っている。 ロールを作ったあと、監査人のIDで伝票照会、明細照会、残高照会の画面を一つずつ試したところ、期中に新設した引当金の勘定二つに権限グループが設定されていないことが見つかった。 画面から外す対象の勘定ではなかったので実害はなかったが、経理部は勘定マスタの新規登録の申請書に、権限グループの要否の欄を追加した。導入初年度の期末監査で、明細の出力依頼は146行から52行に減った。 追加照会の往復は延べ410回から130回前後になっている。一方で、新しい仕事も数字で出た。ロールの範囲見直しとIDの有効化・無効化で年間およそ40時間、Read Access Loggingの記録の確認で四半期ごとに半日。 仕訳テスト用の全件データの提出は、従来どおり年2回残った。別経路での明細の提出は、期末監査の間に役員報酬の勘定で2回あった。翌期からは、期初の監査計画の打合せの議題に、ロールの範囲と別経路で出す勘定の一覧の見直しが常設されている。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
参照権限を渡す前に決める三つ
第一に、依頼を三つの種類に分けて、効果の測り方を決める。 定型の残高明細、追加の照会、仕訳テスト用の全件データ。参照権限が最も効くのは追加照会の往復で、全件データの受け渡しは残る。 監査基準報告書240（2024年9月26日最終改正版）第31項は、監査人に、経営者による内部統制の無効化リスクの評価にかかわらず、期末時点の仕訳入力及び修正の抽出を含む手続を求めており、この依頼は毎年来る。効果は依頼リストの行数ではなく、往復の回数で測る。
第二に、画面から外すのは監査に要らない明細だけにし、会社コードと勘定の単位で切れるかで判断する。 会社法第396条第2項により、会計監査人はいつでも会計帳簿及びこれに関する資料を閲覧し謄写できる。外してよいのは、監査対象外の会社コード、人事給与の個人別明細、個人の口座情報のような、監査に要らない明細である。 役員報酬や買収関連のように機微だが監査に必要な勘定を画面で絞るなら、求めがあれば別の経路で必ず出すことを監査チームと文書で合意する。会社コードはF_BKPF_BUKの値で、勘定は権限グループとF_BKPF_BESの値で切るが、権限グループが設定されていない勘定は止まらず、残高照会や帳票やFioriアプリでの挙動は監査人のIDで実際に照会して確かめる。 テーブル参照は別の門であり、S_TABU_DISとS_TABU_NAMの側を閉じないまま会計の照会ロールだけ絞っても、設計は効かない。
第三に、新しく生まれる仕事を業務分掌に置く。 監査人ごとの個人ID、往査期間に限った有効化、期初の監査計画に合わせたロール範囲と別経路の合意の見直し、読み取り記録の確認の担当と頻度。監査人のIDも社内ユーザーと同じアクセス管理の手順に載せ、区分だけを分ける。 これを置かずに参照権限を渡すと、期末の往復が消える代わりに、誰も見ていない記録と、範囲の外に落ちた勘定が残る。
参照権限を渡すかどうかは、「漏えいが心配か」ではなく、監査に要らない明細を会社コードと勘定の権限グループで切り出せるかで決まる。消えるのは主に追加照会の往復で、仕訳テスト用の全件データの受け渡しは残る。
導入を決めたら、画面から外す候補を書き出し、機微だが監査に必要な勘定は別経路で出す合意を文書にする。テーブル参照を含む許可しないトランザクションも設計書に書き、監査人のIDで各画面を実際に照会して確かめる。
