月次の残高を見ていて、見覚えのない勘定に金額が乗っていることがある。伝票を開くと、自動転記で立った行で、起票者は「バッチ」になっている。誰も入力していない仕訳が、誰の承認も通らずに、当月から発生している。原因をたどると、前月末に本番へ入った設定の移送に行き着く。
このとき経理が受ける衝撃は、金額の大小とは関係がない。仕訳の承認ワークフローを二段にし、上位者の電子承認まで整えたのに、その外側から数字が変わったという事実のほうが重い。 そして実際、統制の穴はたいていそこに開いている。伝票の承認は一件を見る仕組みであり、設定の移送は以後の全件を変える仕組みだからだ。粒度が違うものを、同じ承認の考え方で守ろうとしても届かない。
勘定の行き先を決めている設定は、伝票の外にある
まず、何が動くと数字が変わるのかを具体名で押さえる。会計の数字に直接効く設定は、SAPの中では限られた場所に集まっている。
税額の転記先を決めるのはOB40である。税コードと勘定の対応表がここにあり、対応を一行変えれば、その税コードを使う以後の伝票の税額が別の勘定に落ちる。在庫と請求書照合まわりの自動転記はOBYCで、在庫勘定、消費勘定、価格差異、入荷/請求勘定の割当がここに集まる。販売側の収益勘定決定はVKOAで、勘定決定グループと品目グループの組み合わせから収益勘定を導く。原価要素ごとに初期の原価センタや内部指図を指定するのはOKB9。伝票タイプと番号範囲、許可される勘定タイプはOBA7。
この一覧に共通するのは、いずれも「取引を入力する画面」ではないという点である。 経理が日常的に触るのはFB50やFB60であって、OB40やOBYCではない。だから設定が変わったことは、変わった後の残高でしか気づけない。
伝票の承認は一件を見るが、設定の移送は以後の全件を変える
そして重要なのは、これらの設定変更が伝票の承認ワークフローの対象外だという構造だ。ワークフローは起票された一件を見る。設定は、これから起票される全件の行き先を変える。一件あたりの承認回数を増やしても、この差は埋まらない。 権限側で職務分掌を切る話とは別に、変更そのものの承認経路が要る（SAPの権限設計と職務分掌（SoD）、内部統制を仕組みで担保する実務と判断基準）。
移送の器を、経理が自分の目で一度見る
議論を抽象論にしないために、画面を四つ挙げておく。情報システム部門に依頼して、参照権限で一度ずつ見せてもらえばよい。所要は合計で30分ほどである。
変更リクエストの一覧は、SE09またはSE10で見る。誰が、いつ、どのオブジェクトを含むリクエストを作ったかが並ぶ。SE01は同じものの拡張ビューにあたる。ここで見るべきは件数ではなく、リクエストの説明欄がどれだけ具体的かである。 「FI修正」「設定変更」としか書かれていないリクエストが並ぶ会社は、後から影響を追跡できない。
移送の経路と取込の記録は、STMSで見る。開発機、検証機、本番機の並びと、どのリクエストがいつ本番へ入ったかの履歴がここにある。月次の残高に説明のつかない動きが出たとき、最初に照合すべきはこの取込日時である。
本番クライアントの変更可否は、SCC4で見る。クライアント依存オブジェクトの変更とトランスポートの設定が「変更不可」になっているか、クライアント非依存オブジェクトの変更が許可されていないかを確認する。ここが開いていれば、本番で直接設定を変えられる状態にある。
システム全体の変更可否は、SE06とSE03のシステム変更オプションで見る。グローバル設定が「変更不可」になっているのが本番機の標準的な姿である。
この四つを見た経理担当者の多くは、同じ感想を持つ。設定変更は思っていたより追跡可能で、しかし思っていたより承認されていない。 追跡可能なのは技術の側が整っているからで、承認されていないのは業務の側が誰も引き受けていないからだ。
変更管理は一本の線でなく、四つの工程を毎回たどる輪
カレント設定という、移送を通らない正規の経路
ここが実務で最も抜ける論点である。SAPには、本番クライアントのロックがかかっていても直接保守できる設定がある。SAPはこれを「カレント設定（current settings）」と呼ぶ。
代表格が会計期間のオープンとクローズである。OB52が保守するのはビューV_T001Bで、これはカレント設定として扱われるため、本番クライアントが変更不可であっても直接更新できる。為替レートも同様で、OB08が保守するV_TCURRがこれにあたる。
移送の経路は画面で追えるが、カレント設定はその外を通って本番に入る
この設計は合理的である。 月次の締めのたびに移送を起こしていては業務が止まるし、日々変わる為替レートを開発機から運ぶ意味もない。問題は、合理的な設計が「承認も記録も要らない」と読み替えられている現場が多いことだ。
会計期間を一度閉めた後で開け直す操作は、締め済みの月に伝票を追加できる状態を作る。これは監査で問われる論点である。誰が、いつ、どの会社コードの、どの期間を、どういう理由で開け直したのか。答えられる仕組みは二つある。テーブル変更ログと、運用ルールである。
テーブル変更ログは、プロファイルパラメータ rec/client でシステム側のログ記録を有効にしたうえで、対象テーブルの技術設定でログ属性が立っている必要がある。両方が揃って初めて記録が残る。記録の閲覧はSCU3で行う。自社でこの二つが有効になっているかは、情報システム部門に一問投げれば分かる。有効でなければ、監査の質問に答える手段が存在しない。 期間クローズ後の修正をどう統制するかという論点は、別稿で運用の型を扱っている（SAPの会計期間クローズ（OB52）で締め後の修正を統制する運用の作り方）。
運用ルールのほうは単純でよい。開け直しは経理部長の書面承認を要件とし、開けた期間・理由・戻した日時を月次で一覧化する。カレント設定は移送の記録に残らないため、この一覧が唯一の証跡になる。
情報システム部門に承認させると、判定できないことを判定させることになる
多くの会社で、移送の承認者は情報システム部門の管理職になっている。悪意も怠慢もない。単に、変更管理の仕組みをIT側が作ったので、承認欄もIT側に置かれただけである。
だが、この配置には構造的な無理がある。情報システム部門が判定できるのは、技術的に壊れないか、他の設定と矛盾しないか、検証機で正常に動いたかである。判定できないのは、この変更によってどの勘定に、いくら、いつから影響が出るかである。 判定できない人が承認欄に印を押している状態は、統制としては空欄と変わらない。
だから、承認の設計は二層にする。技術的な整合は従来どおり情報システム部門が見る。金額影響の判定は経理側に移す。そのために必要なのは、全件を経理に回すことではない。設定オブジェクトを「勘定と金額に効く／効かない」で二分する台帳である。
台帳の作り方は難しくない。過去1年の移送リクエストから、含まれていたオブジェクトを抜き出す。会計と管理会計に関係するものを拾い、上に挙げたOB40、OBYC、VKOA、OKB9、OBA7、FTXP、そして会社コードや原価要素などのマスタ構造に関わるものを「効く」に分類する。画面レイアウトやレポートの表示順など、転記結果を変えないものは「効かない」に置く。二分の境界が曖昧なものは、いったん「効く」に寄せる。
分類の運用は一行のルールに落ちる。「効く」に分類されたオブジェクトを含むリクエストは、経理の指定者が承認するまで検証機から本番へ移送しない。 承認の実体は、検証機で会計伝票を一件起票し、転記先を目視で確認したうえでの署名である。書類のやり取りではなく、画面を見る行為が承認の中身になる。受入テストで経理が何を見るかという設計と、考え方は地続きである（SAPの受入テスト（UAT）で経理は何を見るか、シナリオの粒度とテストデータ）。
承認は二層にする。技術の整合は情報システム部門、金額への影響は経理が見る
内部統制の基準は、この工程を明示的に評価対象にしている
社内で「そこまでやる必要があるのか」という反論が出たときのために、根拠を押さえておく。
財務報告に係る内部統制の評価及び監査に関する実施基準は、ITに対する統制活動を全般統制と業務処理統制の二つからなるものとし、完全かつ正確な情報の処理を確保するためには両者が一体となって機能することが重要であるとしている。そのうえで、ITに係る全般統制の具体例として次の四つを挙げる。システムの開発、保守に係る管理。システムの運用・管理。内外からのアクセス管理などシステムの安全性の確保。外部委託に関する契約の管理。
続く記述が、まさに本稿の主題そのものである。実施基準は、ITを利用した情報システムでは一旦適切な業務処理統制を組み込めば意図的に手を加えない限り継続して機能する性質があるとしたうえで、その後のシステムの変更の段階で必要な内部統制が組み込まれなかったり、プログラムに不正な改ざんや不正なアクセスが行われるなど、全般統制が有効に機能しない場合には、適切な業務処理統制を組み込んだとしてもその有効性が保証されなくなる可能性があるとしている。
言い換えれば、移送の運用が緩い会社では、どれだけ丁寧に作り込んだ業務処理統制も「有効」と主張しづらくなる。 基準はそこまで書いている。
全般統制が有効に機能しないと、業務処理統制の有効性も保証されなくなる可能性がある
この基準と実施基準は2023年4月7日に改訂され、2024年4月1日以後に開始する事業年度における財務報告に係る内部統制の評価および監査から適用されている。あわせて評価の実務で効く記述も押さえておきたい。実施基準は、ITに係る全般統制はIT基盤の概要をもとに評価単位を識別して評価するとし、一方でITに係る業務処理統制の評価は基本的に個々のシステムごとに行う必要があるとしている。
そして、変更管理を整える経済的な理由がここにある。実施基準は、ITに係る全般統制の項目のうち、財務報告の信頼性に特に重要な影響を及ぼす項目を除き、前年度の評価結果が有効であり、かつ前年度の整備状況と重要な変更がない項目については、その旨を記録することで前年度の運用状況の評価結果を利用できるとしている。変更管理が機能していて記録が残っている会社は、翌年の評価工数を圧縮できる。機能していない会社は毎年ゼロから積み直す。 三点セットの更新運用と同じ構図である（内部統制の3点セットの作り方と更新、形だけの文書にしない運用）。
移送の順序が入れ替わると、直したはずの設定が戻る
もう一つ、月次で原因不明の数字が出る典型を挙げておく。移送の追い越しである。
検証機では、リクエストAを入れ、その後にリクエストBを入れて確認した。ところが本番への取込で、Bが先に入り、Aが後から入った。AとBが同じテーブルの同じキーに触れていれば、最後に入ったAの内容が残る。検証したのはBが上書きした状態なので、本番の結果は検証と違う。誰も間違った設定を作っていないのに、間違った設定が本番にいる。
対策は運用側にある。第一に、リクエスト単位のバラ取込を禁止し、決められた時刻に一括で取り込む。取込の順序がリリースの順序と一致していれば、追い越しは起きない。第二に、取込のウィンドウを固定する。毎日随時ではなく、週に一度か二度、時刻を決めて開ける。締めの期間中は原則閉じる。第三に、リクエストの粒度を揃える。一つのリクエストに複数の会社コードや複数の論点を詰め込むと、部分的に戻すことができない。差し戻したいときは「戻すための移送」を新たに作るしかなく、その移送がまた追い越しの種になる。
取込の順序が入れ替わると、検証した状態と違う設定が本番に残る
緊急移送については、禁止しないほうがよい。締めの最中に真の緊急は起きるし、禁止すれば運用は別の抜け道を作る。代わりに、二つの条件を置く。実施から24時間以内に経理と情報システム部門の双方が事後承認の記録を残すこと。そして月次で緊急移送の一覧をレビューし、同じ原因が二度目に出たら恒久対応の課題に上げること。 緊急の件数そのものではなく、繰り返しの有無を見る。
監査の依頼リストに合わせて、証跡の出し方を先に決める
変更管理を整えた会社が翌年の監査で詰まる箇所は、統制の中身ではなく証跡の出し方である。監査人が求めるのは、まず母集団、次にそこからの抽出だからだ。
母集団の定義を先に決めておく。対象期間内に本番機へ取り込まれた移送リクエストの一覧が基本形で、STMSの取込履歴がそのまま母集団になる。ここで論点が二つ出る。一つは、開発機や検証機での作業を母集団に含めるかである。財務報告への影響は本番への取込で発生するため、本番の取込を母集団とするのが素直だが、そう定義したことを説明できるようにしておく。 もう一つは、カレント設定の扱いである。会計期間の開け直しや為替レートの更新は移送を経ないため、この母集団に一件も現れない。母集団に載らないものは抽出もされず、統制が評価されないまま通過する。 別の母集団として、期間開け直しの一覧を用意する。
抽出に耐えるかどうかは、リクエストの説明欄で決まる。監査人が20件を抽出したとして、説明欄が「FI修正」しか書かれていなければ、20件すべてについて中身の調査から始めることになる。監査工数はそのまま監査報酬に跳ね、社内の対応工数も膨らむ。説明欄の書式を三行に固定するだけで、この負荷はかなり落ちる。対象の会社コード、影響する勘定、既存取引への影響の有無。書式を決めるコストはゼロで、効果は毎年出る。
依頼リストの運用方法そのものを事前に合意しておくと、期末の衝突も減る（監査法人の資料依頼（PBCリスト）の管理方法、期末に締めと監査を衝突させない分担）。移送の証跡は、期末になってから集められる種類の資料ではない。取込のたびに残るか、残らないかのどちらかである。
化学品の商社で、四半期の連結パッケージを集めている最中に、ある会社コードの売上原価が前月比で大きく振れた。経理は取引量の変動を疑い、品目別に洗ったが、数量にも単価にも説明がつかなかった。行き着いたのは、前月末に本番へ入った移送だった。OBYCの割当が一行変わっており、特定の評価クラスの消費が別の勘定へ流れていた。 変更そのものは正しい対応で、新設した製品カテゴリーのために追加されたものだった。誤っていたのは、既存の評価クラスに紐づく行にも影響が出る構成になっていた点である。検証機では新カテゴリーの取引だけをテストしていたため、既存分の転記先が変わることに誰も気づかなかった。移送の承認欄には情報システム部門の課長の名前があり、承認の根拠は「検証機で正常終了」だった。この会社が翌月から変えたのは、承認者ではなく承認の中身である。 会計に効くオブジェクトを含むリクエストについて、検証機で「新しく作った取引」と「既存の代表的な取引」の両方を起票し、転記先の勘定を並べた画面写真をリクエストに添付することを条件にした。添付がなければ取込のリストに載らない。運用を始めて半年で、同種の差し戻しが3件出た。いずれも本番に入る前に止まっている。経理部長の言い方はこうだった。承認する人を替えても意味はなかった。承認するときに何を見るかを決めたら、止まるようになった。 付随して、リクエストの説明欄の書式も固定した。対象の会社コード、影響する勘定、既存取引への影響の有無の三つを一行ずつ書く。書式を決めただけで、後追いの調査時間が目に見えて縮んだ。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
決めるのは承認者でなく、承認の中身
第一に、設定オブジェクトを「勘定と金額に効く／効かない」で二分する台帳を作り、効くものは経理の指定者の承認なしに本番へ移送しない。 過去1年の移送リクエストからオブジェクトを抜き出せば、初版は数日で作れる。曖昧なものは「効く」に寄せておき、運用しながら削る。
第二に、カレント設定の経路に、移送とは別の承認と記録を置く。 会計期間の開け直しと為替レートの更新は、移送の履歴に残らない。rec/client と対象テーブルのログ属性が有効かを確認し、有効でないなら有効化を検討する。有効化が難しければ、書面の承認と月次一覧で代替する。
第三に、取込のウィンドウを固定し、一括取込に統一する。 随時のバラ取込は、検証済みの状態と本番の状態を静かに乖離させる。締めの期間は閉じる。緊急は禁止せず、24時間以内の事後承認と月次レビューで受ける。
この三つは、どれもシステムの改修を必要としない。決めれば来月から運用できる。 それでも多くの会社で手つかずなのは、変更管理が情報システム部門の仕事だと分類されているからだ。分類を直すのが最初の一手になる。
