棚卸資産の残高が前月から動いている。金額の説明がつかない。経理が明細を開くと、仕訳の起票者はシステムで、参照元は入庫伝票である。倉庫に聞いても、入れたものを入れたとしか返ってこない。情報システム部門に聞くと、設定はベンダーが入れたと言う。ベンダーに聞くと、要件どおりですと言う。三者とも嘘をついていない。この勘定がなぜこの勘定なのかを説明する役を、誰も持っていないだけである。
「誰が仕訳を切ったか」を追っても、勘定にはたどり着かない
科目がおかしいときに経理が最初にやるのは、伝票をさかのぼることである。だがこの追い方は、途中で必ず止まる。自動転記の仕訳には、勘定を選んだ人がいないからである。
決めているのは五つの組み合わせで、そのうち経理が普段見ているものは一つもない。勘定表は会社コードから決まる。評価グループコードは評価エリアをまとめる設定で、工場ごとに違う勘定へ飛ばす必要がある会社だけが使う。転記トランザクションは業務イベントの側に固定で紐づく。勘定グルーピングは相殺側の分岐に使う。そして評価クラスは、品目マスタの側に載っている。
ここで多いのが、移動タイプが勘定を決めているという理解である。SAPの説明によれば、移動タイプは物の動きの方向を指定するだけでなく、在庫勘定と消費勘定の更新と、転記画面のレイアウトを決める。決めているのは更新の対象であって、勘定そのものではない。 同じ移動タイプでも、動かした品目の評価クラスが違えば別の勘定に行く。逆に、違う移動タイプが同じ勘定に集まることもある。移動タイプの一覧を眺めても、勘定の一覧にはならない。
この構造の帰結は単純である。在庫の仕訳の正しさは、品目マスタの登録品質に乗っている。 新しい品目を登録するとき、評価クラスを一つ選ぶ。その選択が、その品目の全取引の勘定を決める。品目マスタの登録権限が購買や生産技術にあり、経理が事後にしか見ていない会社では、勘定の決定権も同じ場所にある（SAPのマスタデータを稼働後に劣化させない｜登録権限とオーナーシップの決め方）。
相殺側は、もう一段細かい鍵で割れている
在庫側の勘定は評価クラスで割れる。厄介なのは相手勘定のほうである。
SAPのライブラリが述べるとおり、一つの転記トランザクションに複数の勘定が対応する場合には、勘定グルーピングという追加の鍵で分岐する。在庫転記の相殺に使う転記トランザクションが典型で、消費に落とすのか、棚卸差額に落とすのか、製造指図に落とすのかで行き先が変わる。この分岐は品目では決まらない。取引の目的で決まる。
だから、同じ品目を同じ数量だけ動かしても、出庫の相手が原価センタなのか製造指図なのか無償出荷なのかで、相手勘定が変わる。経理から見ると「消費が増えた」としか見えないが、増えているのは別の勘定である。 前月比較で異常を見つけたときに、品目の側だけを調べても答えが出ないのはこのためである。
したがって、勘定の一覧を作るときの粒度は、品目ではない。取引の目的を含んだ単位で作る。 ここを省いて評価クラスと勘定の対応表だけを作ると、在庫勘定の側は説明できるが、費用側が説明できない表になる。
売上側は、まったく別の仕組みで決まっている
在庫側の話をそのまま売上側に当てはめると、二度目の行き止まりに入る。収益の勘定決定は、条件テクニックという別の仕組みで動いている。
販売管理側の収益勘定決定では、価格設定手順の中で条件種別に付いた勘定キーと、得意先マスタの勘定設定グループ、品目マスタの勘定設定グループなどの組み合わせで勘定を引く。設定はトランザクション VKOA で保持され、条件テーブルとアクセスシーケンスの順に探索される。SAPの販売管理の勘定決定に関するサポート文書は、支払人の得意先マスタで勘定設定グループが設定されていないこと を、収益勘定決定のエラー要因として挙げている。
在庫側は品目マスタが効き、売上側は得意先マスタが効く。 この非対称が実務で効いてくる。品目マスタの登録は生産や購買が持ち、得意先マスタの登録は営業事務が持っている会社が多い。つまり、勘定の正しさは二つの部署に分かれて存在していて、経理はそのどちらの登録画面も見ていない。
新規取引先の初回請求で売上が別の科目に立つ、輸出の売上が国内売上に混ざる、値引きが売上のマイナスではなく販管費に落ちる。この種の事故は決算で発見され、修正仕訳で片づけられ、原因は翌月も残る。 得意先マスタの新規登録の承認項目に、勘定設定グループが入っていないからである。
なお、請求伝票については勘定決定の経路をたどる分析機能があり、SAPのドキュメントにも勘定決定分析を実施する手順の項が置かれている。この機能の存在を経理が知っているかどうかで、原因追跡が一日で終わるか一週間かかるかが分かれる。
在庫勘定は、手作業の振替では直せない
もう一つ、経理が先に知っておくべき制約がある。間違った勘定に落ちた在庫を、決算の振替仕訳で直してはいけない。
SAPのライブラリは、在庫勘定について明確な注意を置いている。在庫勘定を、在庫転記の転記トランザクション（BSX）以外の取引に使わないこと。 そして、その勘定に手作業で転記しないこと。 理由も書かれている。これを守らないと、品目マスタが持つ在庫金額と、総勘定元帳の勘定残高が食い違う。
残高を合わせるために切った仕訳が、翌月の不一致を作る。 そして不一致は、そのあと毎月引き継がれる。棚卸資産の残高が説明できない会社を調べると、数年前に一度だけ切った手の振替が起点になっていることが少なくない。
したがって、自動転記で誤った勘定に落ちた場合の直し方は二段になる。過去分は在庫の動きとして戻す。将来分は設定を直す。 仕訳で当てにいく選択肢が、そもそも用意されていない。この一点を経理が理解していないと、システムの誤りが会計の誤りに変換されたまま固定される（SAPから出したExcelが正本になる会社｜二次加工の集計表をどこまで許すか）。
経理が持つ正本は、設定画面ではなく一覧である
ここまでを踏まえると、経理が持つべきものが決まる。設定画面へのアクセス権ではない。取引と勘定を突き合わせた一覧である。
列は七つでよい。第一列、業務イベント。原材料の入庫、外注加工の受入、製造指図への出庫、棚卸差異、国内売上、輸出売上、返品といった単位で書く。第二列、移動タイプまたは請求タイプ。第三列、評価クラスまたは勘定設定グループ。在庫側と売上側で入る値が違う。第四列、転記トランザクションと勘定グルーピング。第五列と第六列、借方勘定と貸方勘定。第七列、この行を説明できる人の名前。
作成の手順も決まっている。設定を読み下すのではなく、シミュレーションで確かめる。 SAPのライブラリは、設定した内容について、移動タイプの入力項目制御と個々の勘定の入力項目制御を突き合わせ、必要な修正を行うためにシミュレーション機能を使うことを求めている。机上で設定表を読むより、業務イベントを一件ずつ通したほうが早いし、抜けが出ない。
そして、この一覧には必ず埋まらない行が出る。埋まらない行が、いま社内に説明できる人がいない仕訳である。 監査で聞かれて答えられないのも、決算で異常が出たときに追えないのも、その行である。一覧の目的は、正しさの証明ではなく、空欄の特定にある。
設定変更の承認を、経理に通す
一覧を作っても、設定が変われば古くなる。ここで最後の設計が要る。勘定決定の設定変更を、経理の承認事項にする。
自動転記の設定は、開発環境で変更され、移送で本番に入る。承認が情報システム部門の中で閉じていると、勘定が変わったことに経理は気づかない。気づくのは、翌月の残高が動いてからである。 移送の承認に会計側の承認を組み込む設計は勘定決定に限らず必要だが、勘定決定は影響が直接に財務諸表へ出るという点で優先度が高い（SAPの設定変更（トランスポート）を誰が承認するか｜統制の穴は移送の運用に開く）。
承認の対象は、設定そのものではなく一覧の行でよい。「この業務イベントの貸方勘定を変える」という日本語で回す。 設定キーの羅列で承認を求めると、経理は読めないまま押すことになり、統制としては形だけになる。
決めるのは三つ
第一に、取引と勘定の一覧を経理が正本として持つ。 自動転記の勘定は、勘定表、評価グループコード、転記トランザクション、勘定グルーピング、評価クラスの組み合わせで決まる。SAPのライブラリは、勘定表ごと、そして勘定表の中の評価グループコードごとに勘定決定を個別に定義する必要があるとし、在庫管理と請求書照合の会計関連取引には転記トランザクションが定義済みであるとする。伝票にも移動タイプにも勘定は書かれていないので、伝票をさかのぼる追い方は必ず途中で止まる。 一覧は設定を読み下すのではなく、シミュレーション機能で業務イベントを一件ずつ通して埋める。目的は正しさの証明ではなく、説明できない行の特定である。
第二に、在庫側と売上側で効くマスタが違うことを前提に、承認を設計する。 在庫側は品目マスタの評価クラスが勘定を分け、売上側は得意先と品目の勘定設定グループが条件テクニックの探索に乗る。SAPのサポート文書は、支払人の得意先マスタで勘定設定グループが設定されていないことを収益勘定決定のエラー要因として挙げている。品目マスタの登録権限と得意先マスタの登録権限が別の部署にあるなら、勘定の正しさも二か所に分かれている。 両方の登録承認に、経理の確認を一項目だけ入れる。
第三に、在庫勘定の誤りを、手の振替仕訳で当てにいかない。 ライブラリは在庫勘定について、在庫転記の転記トランザクション以外の取引に使わないこと、手作業で転記しないことを求めている。守らなければ品目マスタの在庫金額と勘定残高が食い違い、その不一致は翌月以降も引き継がれる。過去分は在庫の動きとして戻し、将来分は設定を直す。 そして設定変更は移送の承認に経理を通し、承認依頼は設定キーではなく一覧の行の日本語で回す。読めない依頼に押した承認は、統制として数えない。
