単価やBOMを勝手に変えさせない、マスタ変更の稟議化

顧客マスタの単価が変わる。部品表（BOM）の一行が安い代替品に入れ替わる。仕入先マスタの口座が変わる。これらの変更を誰も承認せず、なぜ変わったかの記録も残らない。そしてそのすべてが、請求書、在庫評価、製造オーダー、支払実行にそのまま流れていきます。

中堅企業の多くにおいて、マスタデータは基幹システムの中で最も手薄な部分です。正面窓口は銀行口座を守り、倉庫は鍵を守ります。しかし単価のフィールド、BOMの一行、与信限度額については、編集権限を持つ誰もが、二人目の目なしに触れてしまえます。経理が月末に漏れに気づくとき、被害はすでに帳簿に入っています。

本稿は、マスタの変更を「管理された変更」に変える話です。承認ワークフロー、版ごとの履歴、承認時点のスナップショット、この3つが揃うことで、マスタデータは開いた扉から統制された監査可能な管理ポイントへと変わります。変更管理の承認と版付き監査証跡は本日時点で稼働しています。承認された変更をマスタレコードに自動で書き戻す機能は開発ロードマップ上にあり、どこまでが完成品でどこからがロードマップなのか、正確にお伝えします。

サイレントなマスタ変更が内部統制の盲点になる理由

内部統制の枠組み（J-SOXや広く内部統制と呼ばれる領域）は、取引に対して巨大な労力を注ぎます。この発注を誰が承認したか。この支払に誰が押印したか。この仕訳を誰が認可したか。取引にはいずれも、確認と承認と痕跡があります。

マスタデータが同じ注意を受けることはほぼありません。マスタレコードとは、取引が依存する参照データです。請求書の単価は請求担当者が入力するのではなく、販売マスタから引き出されます。製造オーダーの構成はBOMから引き出されます。支払実行の振込先は仕入先マスタから引き出されます。マスタが間違っていれば、その上に乗るすべての取引が間違い、しかも取引レベルの統制では捕捉できません。取引自体は正しく生成されているからです。

これこそが、マスタデータの完全性が内部統制レビューで最も頻繁に指摘される理由です。リスクは一件の不良取引ではありません。ひそかに汚染された参照が、誰かが気づく前に何カ月も連続して不良取引を生み出すことです。大量出荷品目の単価が3%下がる。BOMの一行が現場で不具合を起こす代替部品に切り替わる。仕入先の口座が誰も知らない口座に変わる。いずれも、数百万円単位の金額を動かしうる1フィールドの編集です。

統制の空白は明確です。二人目の目がなく、理由が記録されず、変更前後のスナップショットもない。厳格にすべての取引を回している基幹システムが、その取引の土台となるデータの編集だけを暗闇の中に放置しているのです。

マスタ変更の承認が実際に統制するもの

解決策は、マスタの編集を発注や設備投資と同じように扱うことです。編集は承認を経る申請となり、証跡が添付されます。

最もこの統制を必要とする変更は、下流のお金に触れるものです。

単価・価格表の変更。 標準価格の改定、顧客別の特別単価、粗利率を下回る値引き。これらはすべての見積と請求に流れます。ひそかな値下げは売上の漏れであり、ひそかな値上げは顧客からのクレームの種です。

部品表（BOM）・設計変更。 部品の差し替え、代替材の採用、工程の改訂。これらは製造オーダー、所要量計算、原価計算、在庫評価に流れます。ひそかなBOM変更は、顧客へ誤った部品を出荷したり、丸一期間にわたって製品原価を歪めたりします。

顧客・仕入先マスタの編集。 仕入先レコードの新規口座。顧客の与信限度額の引き上げ。新しい支払条件。これらは支払実行や受注承認に流れます。ひそかな仕入先口座の変更は、まさに支払詐欺の教科書的な手口であり、不正調査で最も典型的な指摘事項の一つです。

在庫・原価マスタ。 標準原価の変更、ロットステータスの差し替え、評価減。これらは在庫が動いた瞬間に総勘定元帳に流れます。ひそかな原価変更は利益報告を歪め、貸借対照表の在庫評価を誤らせます。

これらすべてにおいてパターンは同じです。一人の人間が編集し、それが伝播し、承認も理由も記録も残らない。マスタ変更の稟議化は、そのループを閉じ、編集を他のあらゆる業務意思決定と同じ規律に通します。

3つの構成要素：承認・版履歴・スナップショット

まともなマスタ変更管理には稼働する3つの部品があり、それぞれが異なる理由で価値を持ちます。

承認ワークフロー。 価格、BOM、取引先レコードのいずれであれ、変更案は直接編集ではなく申請として入力されます。申請は変更前の値、変更後の値、理由を持ちます。ルーティングは他の稟議と同じ規則に従います。役職、部門、金額しきい値によるルーティングです。粗利の下限を超える単価変更は営業部長へ。規制対象製品に関するBOM変更は技術と品質の並列承認へ。仕入先口座の変更は、一金額の誤りのコストが極めて大きいため、購買、法務、情報システムの並列承認を必須にします。この承認ワークフローは本日時点で構築済み・稼働中です。

版付きの履歴。 承認されたすべての変更は、一つの版として保存されます。月初は1,200円だった単価が、14日の承認済変更後に1,160円になったこと、そして申請者が競合入札を理由として挙げたことが分かります。BOMの一行について1年間の変遷をたどり、技術変更メモ付きの部品差し替えをすべて確認できます。版履歴は本日時点で構築済み・稼働中であり、これがあることでマスタは監査可能となり、現在の状態しか見えないブラックボックスではなくなります。

凍結スナップショット。 内部統制およびJ-SOXの証跡要件を満たすのがこの部品です。変更が承認されると、システムは何が審査され承認されたか（値、承認者、タイムスタンプ、理由、添付証跡）を凍結します。数カ月後に監査人から「なぜ価格が変わり、誰が認可したか」を問われたとき、その答えは事後編集できない1件のレコードになります。スナップショットは本日時点で構築済み・稼働中であり、内部統制の指摘を受けるか、クリーンなレビューを通るかの分かれ目になります。

この3つが揃うことで、マスタレコードは自由入力のフィールドから統制された資産へと変わります。承認が門であり、版履歴が記憶であり、スナップショットが証明です。

事例：静岡の精密部品メーカー

静岡に本社工場を置き、東京に本社、沿岸部に工場を持つ、約280名の精密部品メーカーを考えてみてください。自動車および産業機械のOEM向けに部品を供給しています。製品原価は部品価格と各組み立ての設計構成に敏感で、1つのBOMに40〜50行が並び、1行の単価変更が数年にわたるOEM契約の利益を動かします。

マスタ変更を統制する前は、毎四半期同じことが繰り返されていました。購買担当者が仕入先からの圧力を受け、交渉で得た値引きを仕入先マスタの単価に直接下げて反映する。技術が不足解消のためにBOMの部品を差し替え、原価担当には知らせない。営業が受注を決めるために顧客別の特別単価を認め、編集権限のある誰かが顧客マスタに記録する。個々にはもっともな編集です。しかし承認者も、理由も、記録もありません。

症状は下流に現れます。月末の利益が予期せず振れるのは、原価計算が誰も知らないBOM変更を取り込んだからです。OEM監査で部品差し替えが指摘されるのは、製造記録と技術マスタが食い違っているからです。2週間前に変更された仕入先口座へ支払が走り、誰がいつ変更を承認したか説明できない。

マスタ変更を承認ワークフローに移したことで、運用モデルが変わりました。単価変更は、顧客、製品、旧単価、新単価、理由を明記した申請として入り、粗利の下限を超える変更は営業部長へルーティングされます。BOM変更は、規制対象のOEM向け製品であれば、技術と品質の並列承認に回ります。仕入先口座の変更は、購買、法務、情報システムの並列承認が揃うまでレコードに触れられない申請になります。

版履歴のおかげで、原価チームは四半期ごとに製品原価が動いた理由を追えます。凍結スナップショットは、OEM監査人に対して部品差し替えすべてについて、誰が申請し、誰が承認し、いつ効力を生じ、どんな証跡が添付されていたかを示すクリーンな記録を渡します。事後で利益の振れを説明していた工場が、事前に利益を統制するようになりました。

本日時点で構築済みのもの、ロードマップ上のもの

この領域はベンダーが過剰に約束しがちなだけに、正直な棚卸しが重要です。

構築済み・稼働中：マスタ変更の承認ワークフロー、版付き変更履歴、各承認変更の凍結スナップショット。単価、BOM、顧客、仕入先の変更を、役職としきい値で承認に回せます。統制対象のマスタレコードについて版の変遷をすべて見られます。承認された内容、承認者、理由を監査人に凍結レコードとして渡せます。これは現実に機能しています。

ロードマップ上（未構築）：承認されたマスタ変更の、マスタレコード本体への自動書き戻し。本日時点では、マスタ変更の申請が承認されると、承認とスナップショットが記録され、その後、権限を持つユーザーが承認済の変更を同じ統制下で稼働中のマスタレコードに適用します。承認が人手のステップを介さず直接マスタを更新する完全自動の経路は、次のマイルストーンです。レジストリと変更種別の定義は既に存在するため、各書き戻しハンドラの追加は包含された作業ですが、マスタデータについては本日時点で未実装です。

このことはロールアウトの順番に影響します。承認の門、版履歴、監査証跡は即座に手に入ります。マスタレコード更新の完全自動化は、統制の実践が成熟するにつれて手に入ります。無統制から移行する企業にとって、それは正しい順序です。まず規律を証明し、それから最後の一步を自動化する。

ERPの外ではなく、中に置くべき理由

マスタ変更を独立したスプレッドシートや別の変更台帳で統制しようとする誘惑があります。多くの企業が試み、失敗します。理由は、マスタ変更はそれが影響するレコードの文脈の中でしか意味を持たないからです。

単価変更は、次の請求書を変えるから意味があります。BOM変更は、次の製造オーダーと次の原価計算を変えるから意味があります。仕入先口座の変更は、次の支払実行を変えるから意味があります。承認が基幹システムの外にあるとき、承認済変更と影響を受けるレコードの結びつきは手作業の約束になります。誰かが変更を適用することになっている。誰かがマスタを更新することになっている。誰かが経理に知らせることになっている。その引き継ぎのすべてが、規律が崩れる場所です。

承認、版履歴、スナップショットがマスタデータを保持するのと同じ基幹システムの中にあるとき、統制とそれが守るレコードは決して切り離されません。承認者は実際の値を見ます。版履歴は実際のレコードに紐付きます。スナップショットは、別書類での説明ではなく、実際のマスタについての証拠です。これは承認ワークフローをERPの外ではなく中に置くべき理由と同じです。統制と、統制対象の取引は同じシステムを共有しなければならず、さもなければ統制は漂流します。

よくある質問

承認を通すと、単価やBOMの変更が毎回遅くなりませんか？

関わる人が変わるのであって、所要時間が伸びるわけではありません。マスタ変更の多くは緊急ではなく、緊急の少数（不足時の代替、請求実行前の単価修正）には適切な役職への特急ルーティングを使えます。承認ワークフローは代理承認に対応するため、出張中の管理者が変更を止めることはありません。また、ウォッチャー機能により、関係者は承認者にならずに変更を追えます。現実的な結果は、日常の変更は数分長くかかる代わりに記録が残り、リスクの高い変更には待望の二人目の目がつくことです。

うちのチームは信頼している。なぜマスタ編集に承認を？

問題は信頼ではありません。職務分掌です。単価を交渉する人と、それを記録する唯一の人は同じであってはなりません。部品差し替えを提案する技術者と、それを適用する唯一の人は同じであってはなりません。内部統制は、敏感な変更の開始と完了を単独の人物が兼ねないという考えの上に成り立ちます。マスタデータは、編集が小さく見えるがために、これまでこの原則を免れてきました。それは誤りです。版履歴と凍結スナップショットは、信頼が証拠で裏打ちされる（信頼に置き換わるのではなく）ために、まさに存在します。

マスタレコードへの書き戻しの空白については？

上で触れ、ここでもはっきりと言います。承認、版履歴、凍結スナップショットは構築済みです。承認済変更からマスタレコードへの自動更新はロードマップ上です。本日時点では、承認された変更は統制下で権限を持つユーザーが稼働中のマスタに適用し、その承認とスナップショットが記録されます。Kikan System はこの承認と監査証跡を今日提供し、最大2ユーザーまで無料、クレジットカード不要で単価やBOMのひそかな変更を止められます。完全自動の書き戻しは近日対応予定です。もしベンダーが自社のマスタ変更書き戻しが完全に構築済みだと主張したら、実際のハンドラと監査証跡を見せてほしいと尋ねてください。この領域は、現実を追い越す主張がまさに出やすい場所です。

J-SOXの内部統制証跡を満たしますか？

凍結スナップショットはまさにこのために設計されています。内部統制やJ-SOXのレビューは、敏感な変更について3つのことを問います。誰が開始し、誰が承認し、何が承認されたか。スナップショットはこの3点をすべて捕捉し、事後編集できないように固定します。個々の監査人がサインするか否かは全体の統制環境によりますが、スナップショットが提供する証拠は、枠組みが求める証拠そのものです。

重要なポイント

マスタデータは、基幹システムの中で最も露出し、最も統制が及んでいない場所です。単価、BOMの一行、仕入先の口座。いずれも下流に大きな影響を持つ小さな編集です。答えは、データを誰も触れないほど厳しく閉ざすことではありません。敏感なマスタ変更のすべてに、承認、版履歴、そして承認内容の凍結スナップショットを与えることです。承認と監査証跡は稼働中です。マスタレコードの自動書き戻しはロードマップ上です。この組み合わせが、いま統制を、実践が成熟するにつれて自動化を手に入れさせます。

Kikan System で始める

ひそかなマスタ変更が利益や支払を動かしてしまった経験があるなら、Kikan System をご覧ください。マスタ変更の承認ワークフロー、版付き変更履歴、承認時点の凍結スナップショットは、単価、BOM、顧客、仕入先の変更を、承認ワークフロー、経費精算、休暇申請、発注、ロット付き在庫、部品表の各モジュールとともに、一つの基幹システムの中で統制するために構築されています。2ユーザーまで無料、カード不要のプランで始められます。まずは /#get-started からどうぞ。

-> Related: 製造業60の承認ワークフローと、ERP一本化がもたらすROI

-> Related: 基幹システムで多階層BOMを正しく運用する

-> Related: 監査に耐えるJ-SOX対応の承認ワークフロー