販売管理システムの月次売上と、SAPに計上された売上が、毎月わずかに合わない。金額にすれば数十万円、売上比では誤差と呼べる幅だ。連携ジョブのエラーログはゼロで、ベンダーに確認すれば「インタフェースは正常に流れています」と返ってくる。それでも締めの最終盤で、経理の誰かが半日かけて明細を突き合わせている。この差異は、インタフェースが壊れているから起きるのではない。合わなくなる境目は、両側の締めの日付定義と、マスタの粒度の食い違いにある。 連携設計と呼ばれている作業の中身は、データの受け渡し方式を選ぶことではなく、業務の切れ目をどこに置き、ずれた時に誰が見るかを決めることだ。

POINT
サブシステムとSAPの数字が合わない原因の大半は、技術不良ではなく業務側の定義のずれにある。境目は三つ。第一に時間——サブシステムは取引日で世界を切り、SAPは転記日で切る。第二に粒度——明細と伝票行が一対一で対応せず、集約・値引・端数処理の持ち方で日々差が積む。第三に責任——差異が出た時に最初に見る人が決まっておらず、締めの最後で経理が拾う。設計で決めるべきは方式でなく、連携ごとの突合キー、締めの基準日を片側に固定する宣言、日次の差異検知、そして一次責任者の個人名。この四点が無い連携は、何度作り直しても同じ場所で合わなくなる。

技術が正常でも、数字は合わなくなる

差異の原因を分解すると、三つの境目に行き着く。

第一に、時間の境目。サブシステムは取引日（受注日、出荷日、申請日）で月を切り、SAPは伝票の転記日で切る。月末の夜に確定した出荷が翌営業日のバッチで流れれば、販売側は当月、会計側は翌月になる。さらに厄介なのが遡及だ。返品、取消、単価訂正が過去日付で入ると、サブシステム側の月次集計はさかのぼって書き換わるが、SAP側は締めた期間には転記できない。翌月の伝票で調整するしかなく、その瞬間に両者の月別の数字は永久に一致しなくなる。ここで目指すべきは一致ではない。ずれる金額を、毎月説明できる状態にすることだ。

第二に、粒度の境目。販売側の一明細がSAPの一伝票行に対応するとは限らない。日次で得意先ごとに集約して一伝票にまとめていれば、明細レベルでは追えない。値引・リベート・送料をヘッダに持つかフッタに持つか、消費税の端数を明細単位で丸めるか伝票単位で丸めるかで、円単位の差が毎日積み上がる。マスタも同じで、販売側の商品コードとSAPの品目コードが多対一なら、SAP側から販売側へは戻れない。

第三に、責任の境目。差異が出た時、誰が一次で見るかが決まっていない。情報システム部門は「連携は正常に流れている＝業務の問題」と言い、業務部門は「システムが出した数字が違う」と言う。結局、締めの最終日に経理が拾う。毎月の半日は、この空白から生まれている。

設計の本体は、突合キーと差異検知の担当を決めること

連携設計の議論は、往々にしてファイル転送かAPIか、リアルタイムかバッチかという方式の話に流れる。だが差異を止めるのは方式ではない。決めるべきは次の順序だ。

連携設計で決めるのは方式でなく、単位・キー・基準日・検知・責任者。
STEP 1
連携の単位を業務イベントで切る
「販売システムからSAPへ」でなく「出荷実績から売上計上へ」「入金から消込へ」のように業務イベント単位で分ける。単位が粗いと差異の切り分けができない
→
STEP 2
突合キーを両側に持たせる
SAP側の伝票に送信元システムの取引番号を必ず格納する（参照キーや割当欄）。これが無いと差異の照合が金額合計の引き算になり、原因にたどり着かない
→
STEP 3
締めの基準日を片側に固定する
その連携で「いつの取引か」を決めるのはどちらの日付かを宣言し、遡及訂正を元の月に戻すか翌月調整にするかを先に決めておく
→
STEP 4
差異を日次で自動検知する
送信件数・取込件数・未取込件数・金額差を毎日出力する。月末にまとめて見ると、原因が三十日分の中に埋まる
→
STEP 5
一次責任者を個人名で置く
差異が出た時に最初に見る人を業務部門側で決める。情報システムは仕組みの担保、業務部門は数字の担保と役割を分ける
土台土台＝送った件数と取り込まれた件数が、毎日突き合わされていること。件数が合っていない連携は、金額をどれだけ分析しても原因にたどり着かない。
連携設計とはインタフェース方式の選定でなく、キー・基準日・検知・責任者を決める業務設計である。

この中で最も飛ばされやすいのが突合キーだ。稼働時は金額が合っているように見えるため、参照欄への取引番号格納が「あれば便利な項目」として後回しになる。だが差異が出てからキーを足そうとしても、過去データには入っていない。締めた後の伝票を触れる範囲も、期間クローズの統制で限られる（SAPの会計期間クローズ（期間オープン管理）：締めた後の修正をどう統制するか）。キーは、差異が起きる前にしか仕込めない。

領域ごとに、崩れる場所が違う

サブシステム連携は一括りに語られがちだが、詰まる箇所は領域ごとに違う。設計時に潰しておく論点も変わる。

連携合わなくなる主因先に決めること
販売から売上出荷日と転記日のずれ、返品・取消の遡及、得意先単位の集約売上計上の起点日をどちらに置くか。遡及訂正を元の月に戻すか、発生月で処理するか
購買から買掛入荷計上と請求書照合のタイムラグ、未照合のまま滞留する残高入庫請求書勘定（GR/IR）の残高を毎月誰が説明するか。滞留の年齢別一覧を出す担当
経費精算から費用・未払申請日・承認日・支払日のどれで費用を切るか、部門やプロジェクトの付け漏れ費用の認識日の定義と、コストセンタ・WBSを必須入力にする範囲
給与から人件費給与計算の締めと会計期間の不一致、賞与引当や社会保険料の期間帰属支給月基準か発生月基準か。労務側と経理側のどちらの組織マスタを正とするか

四つに共通するのは、どれも「システム間の問題」に見えて、決めるべきことは業務側の日付定義とマスタの持ち主だという点だ。連携が原因だと思って調査に人を張り付けても、日付の定義が二つあるうちは終わらない。管理会計側の数字との橋渡しも、結局は同じ設計に帰着する（管理会計と財務会計の数字が合わない問題：差異を恒久的に橋渡しする設計）。

現場では
ある卸売業では、販売管理システムとSAPの売上が毎月ずれ、締めの最終日に経理が明細を突き合わせていた。原因は二つだった。月末日の出荷を連携するバッチが翌営業日に走っていたこと、そして返品を販売側では元伝票の取消で処理し、SAP側では発生月に赤伝で計上していたこと。対策はプログラムの修正ではなかった。月末日の連携ジョブを当日深夜に一本追加して当月分を流し切り、返品は元の月に戻さず発生月で処理すると業務ルールを固定し、販売伝票番号をSAP伝票の参照欄に必ず格納したうえで、件数と金額の突合表を日次で自動出力するようにした。翌月から差異は日次で数件に減り、締めの調査は無くなった。インタフェースのプログラムは一行も変えていない。

「連携が壊れている」と言う前に、日付とキーを見る

サブシステムとの数字のずれを、インタフェースの品質問題として扱っている限り、調査は毎月繰り返される。見るべきは四つだ。その連携で「いつの取引か」を決める日付はどちらのシステムのものか。遡及訂正をどう扱うと決めてあるか。SAP伝票から送信元の取引に戻れるキーが入っているか。差異が出た日に最初に見る人が決まっているか。ここが空欄のまま方式を作り替えても、同じ境目で同じずれが出る。締め作業の集計設計そのものを見直す局面でも、起点はこの四つになる（決算データを散らさない：Excel手作業から脱却する集計設計の考え方）。

まとめ
サブシステムとSAPの数字が毎月わずかに合わないのは、インタフェースの技術不良ではなく、業務側の定義のずれから生まれる。境目は三つある。第一に時間で、サブシステムは取引日、SAPは転記日で月を切るため、月末の取引と過去日付の遡及訂正が必ずずれる。第二に粒度で、明細と伝票行が一対一で対応せず、集約・値引・端数処理の持ち方によって円単位の差が日々積み上がる。第三に責任で、差異が出た時の一次担当が決まっておらず、締めの最終日に経理が拾う構造になっている。設計で決めるべきは方式でなく四点。連携の単位を業務イベントで切ること、SAP伝票に送信元の取引番号を突合キーとして必ず格納すること、その連携の基準日を片側に固定して遡及訂正の扱いを先に決めること、送信件数と取込件数の差異を日次で自動検知して一次責任者を個人名で置くこと。突合キーは差異が起きる前にしか仕込めない。領域別に見ると、販売は出荷日と遡及、購買は入荷と請求書照合の滞留、経費は費用認識日と部門の付け漏れ、給与は締め期間と期間帰属で崩れるが、どれも決めるべきは業務側の日付定義とマスタの持ち主である。目指すのは完全一致ではなく、ずれた金額を毎月説明できる状態だ。

関連記事