グループ会社が十二社、基幹システムは四種類。連結の数字を同じ定義で見たいという要求に対して、情報システム部門が出す答えはいつも同じである。全社をS/4HANAに寄せるしかありません。工期は五年、費用は数十億円。役員会は決めきれずに持ち帰りになり、翌年も同じ資料が出てくる。この会議に一度も出てこない選択肢が、Central Financeである。 ただし、これを「移行の縮小版」と理解すると必ず失敗する。これは、原本を動かさずに写しを一つ作るという、別の種類の意思決定である。
移行との違いは、原本がどこに残るかにある
全面移行は、源泉システムを止める。Central Financeは止めない。日々の業務は源泉システムで走り続け、その結果として生まれた仕訳が中央に複製される。 ここまでは説明資料にも書かれている。書かれていないのは、その先である。
複製が始まった時点で、同じ取引に対応する会計記録が二つ存在することになる。では、会社法上の会計帳簿はどちらなのか。 会社法第432条第1項は「株式会社は、法務省令で定めるところにより、適時に、正確な会計帳簿を作成しなければならない」と定め、同条第2項は「株式会社は、会計帳簿の閉鎖の時から十年間、その会計帳簿及びその事業に関する重要な資料を保存しなければならない」と定める。十年間保存する対象がどちらの側なのかを、導入の前に決めておく必要がある。 法人ごとの決算と申告を源泉システムで作り続けるなら原本は源泉側であり、中央は分析用の写しにすぎない。中央で法人単位の決算まで組むなら、原本の重心は中央に移る。この一点を曖昧にしたまま入れると、監査法人からの質問に誰も答えられない状態が二年後に来る。
文書番号の扱いも、この論点に直結する。SAPのカスタマイジングには「Central Financeシステムにおける元の文書タイプの置換」という設定があり、源泉システムでの転記の元の文書タイプが外部採番の番号範囲を持つ場合には、内部採番の番号範囲を持つ文書タイプに置き換える必要がある。 この置換が効く場面としてSAPは、反対仕訳と再転記、初期ロード、消込済明細の欠落分の再転記を挙げている。中央の伝票番号は、源泉の伝票番号と一対一で並ばないことがある。 突合の設計は、この前提から始まる。
なお、伝票の追跡についてSAPは、Document Relationship Browserを使えばFI文書から元の受注伝票へ遡れるとしたうえで、「取引に関連するすべてのビジネス文書は、源泉システムがSAPシステムである場合に限り、Document Relationship Browserで利用できる」 と注記している。非SAPの子会社を接続した部分では、この遡及は効かない。 数字は揃うが、明細の裏取りは現地に電話することになる。
飛んでこないものの一覧が、この仕組みの輪郭を決める
SAPは「転送から除外される転記」を明示している。ここを読まずに導入判断をする会社が多い。
初期ロードと継続複製のいずれにおいても転送されないものとして、SAPは次を挙げる。CO-FI照合元帳への転記、参照トランザクション（AWTYP）がGLYECである年度末決算転記、繰返し伝票、サンプル伝票、記帳指図（前受金要求と支払要求を除く）、保留伝票、残高繰越明細、そして各国の期末に行われる決算処理。 消込と消込取消については、初期ロードでは転送されず、継続複製での転送を有効化できるという扱いになっている。
さらに二つの注記が効く。第一に、ヘッダとアイテムの双方の長文テキストと添付は、文書の作成時にも変更時にも複製されない。 第二に、源泉システムの補助テーブルに保持されている取引データは複製されないため、その補助データに依存する処理は、SAPが例として挙げるブラジルのNota Fiscalのように、サポートされない。加えて、源泉システムでALE経由で作成された文書は正しく複製できないとされる。ALEのシナリオでは転記が簡略化されて処理されるためで、Central Financeのシナリオとは両立しない。
この一覧の意味は単純である。中央に集まるのは「仕訳とその金額」であって、「経理が普段見ている一式」ではない。 摘要の長文も添付証憑も来ない。年度末の繰越も来ない。中央で法人単位の決算を組もうとした瞬間に、この差が全部こちらに返ってくる。 逆に、目的が「グループ横断で同じ勘定科目と分析軸の数字を見る」ことに限られているなら、来ないもののほとんどは要らない。目的の狭さが、そのままこの選択肢の強さになる。
マッピングは設定作業ではなく、恒久的な組織機能である
Central Financeの費用は、導入時よりも運用時に出る。中心はマッピングの保守である。
SAPはマスタの種類ごとに対応付けの方法を分けている。総勘定元帳勘定、得意先、仕入先といったマスタは、カスタマイジングの一部として手作業で対応付けるか、SAP MDGを使って対応付ける。 製造指図や内部指図のようなコストオブジェクトに関するマスタは、コストオブジェクト・マッピング・フレームワークを使う。SAPの推奨は、マスタの対応付けにはMDGを使い、短命なコストオブジェクトを対応付ける場合にはMDGとコストオブジェクト・マッピング・フレームワークを併用することである。
対応付けは二層に分かれる。キー・マッピング（ID Mapping） は、ビジネスオブジェクトのインスタンスの識別子が源泉システムと中央で異なる場合に、その識別子どうしを結ぶ。バリュー・マッピング（Code Mapping） は、源泉システムごとに設定が異なるためにカスタマイジングのコード値が一致しない場合に、その値どうしを結ぶ。後者はフィールド単位で設定し、対象となる各グローバルデータ型についてList ID、List Agency ID、List Version IDを源泉システムごとに指定する。この作業は一度で終わらない。源泉側で新しい得意先が登録されるたび、新しい勘定科目が作られるたびに発生する。
初期の一括作成については、Master Data Governance, Consolidationを使う道がある。SAPの説明では、各源泉システムの既存マスタを分析し、設定可能なルールに基づいて、どのマスタをどのマスタに対応付けるべきかの提案を出せる。 対象は得意先、仕入先、ビジネスパートナー、品目で、プロジェクト単位で独自オブジェクトに拡張できる。しきい値を使って重複可能性の高いものを自動処理し、それ以外の提案は手動で処理する。 そして特定された対応関係がキー・マッピングのテーブルへ移され、中央で使う「ゴールデン」なマスタレコードが作られる。
ここで決めるべきは、技術ではなく担当である。新しいコードが源泉側で生まれたとき、誰が何営業日以内に中央のマッピングを更新するのか。 更新されなければ、その伝票はエラーとして止まる。止まったエラーを誰が見るかが決まっていない会社では、月末に数百件のエラーが溜まった状態で締めを迎える。
細かいが効く制約も一つ挙げておく。SAPは、Clearing Transfer、Central Tax、Central Paymentといったいくつかのシナリオでは、Central Finance側の通貨の小数桁を源泉システムより少なくすることを許容しないとし、継続複製を開始した後で小数桁を減らすとエラーになると注意している。通貨の設定は、後から足せない類の設計である。
ずれる前提で作られていることは、製品の側が示している
導入後に必ず来る問いがある。源泉システムの残高と中央の残高が合わない、どちらが正しいのか。
この問いに対する答えは、SAPが用意している比較レポートの一覧そのものである。財務会計側に 仕訳計上件数の比較（FINS_CFIN_DFV_FI_NUM）、選択した総勘定元帳勘定と伝票番号についてFI明細の合計金額が一致するかの比較（FINS_CFIN_DFV_FI_DOC）、勘定ごとの借方・貸方金額が一致するかの比較（FINS_CFIN_DFV_FI_BAL）、未決済明細管理における消込ステータスが一致するかの比較（FINS_CFIN_DFV_CLR） があり、管理会計側に CO文書の件数（FINS_CFIN_DFV_CO_NUM）、原価要素別の明細（FINS_CFIN_DFV_CO_DOC）、原価要素別の残高（FINS_CFIN_DFV_CO_BAL） がある。FIとCOで七本である。 これに加えて、受注伝票・得意先請求書・仕入先請求書・購買伝票について、Accounting View of Logistics Informationの比較レポートが四本ある。
製品がここまで比較の手段を揃えているという事実は、ずれることが前提だという意味である。 誰かの実装が下手だからずれるのではない。マッピングの更新漏れ、源泉側の後追い訂正、複製の遅延といった原因で、日常的にずれる。だから運用設計に必要なのは「ずらさない仕組み」ではなく「いつ、どのレポートで比べ、差が出た日に誰が直すか」である。
Central Paymentを入れた瞬間に、原本の重心が動く
Central Financeを「見るための写し」に留めるか、支払まで中央で行うかは、まったく別の意思決定である。
SAPの説明によれば、Central Paymentを特定の会社コードについて有効化すると、その会社コードのすべての得意先勘定・仕入先勘定の未決済明細処理が、完全にCentral Financeシステムへ移る。 そして得意先・仕入先の未決済明細に基づく後続処理はすべて、Central Financeシステムで行わなければならない。 仕訳が複製されると、源泉システム側の得意先・仕入先の未決済明細は自動的に技術的消込（technically cleared）される。 なお、SAP S/4HANA 2022以降は、会社コードのうち グループ間のAP／AR明細だけ を対象にCentral Paymentを有効化することもできる。
有効化の前に押さえる制約は多い。SAPは前提として、適切な有効化スコープの指定、月末または年度末の決算処理を終えた後にカットオーバー日を計画すること、源泉徴収税の累積期間、Central Payment有効化前の税整合性チェックの有効化、過去の未決済明細に関する後続処理、そしてSAP Application Interface Framework（AIF）に滞留しているエラーメッセージをすべて処理すること を挙げる。有効化の手順としても、Clearing Transferシナリオの有効化が前提であり、トランザクション FINS_CFIN_CC で整合性チェックを実行して不整合を修正し、Cross-System Process Control（CSPC）を有効化してからCentral Paymentを有効化するという順序が定められている。
最も実害が出やすいのが、過去の未決済明細である。SAPの定義では、Central Payment有効化より前に源泉システムで作成され、源泉側で消込済とされないまま複製された未決済明細がこれにあたり、源泉システムとCentral Financeシステムの両方で未決済のまま存在する。 対象となるのは債権、債務、現金割引清算勘定、未払税金勘定、銀行清算勘定、クレジットカード清算勘定である。SAPはこれについて「これらの過去の未決済明細の二重支払を避けるため」に、源泉システムで技術的消込としたうえで、消込と支払をCentral Financeシステムのみで行う必要があると書いている。 二重支払という言葉が、製品文書に明示されている。
そして機能制限が残っている。SAPは、Central Payment for SAP Central Financeが機能制限付きでリリースされており、制限はSAP Note 2827364に記載されているとし、本番利用の前に制限を完全に理解し、十分にテストすることを求めている。加えて、Central Tax Reportingがサポートされている国の会社コードについてのみCentral Paymentを有効化することを推奨し、特定の国では税務報告と税務処理に追加の制限があるとしてSAP Note 3290988を参照させている。日本を含め、自社の対象国がここに当たるかどうかは、構想段階ではなく採否の段階で確認する項目である。
決めるのは三つ
第一に、この仕組みで何を得たいのかを一行に絞る。 グループ横断で同じ勘定科目と分析軸の数字を見たいのか、法人単位の決算を中央で組みたいのか。前者なら、転送されないもの（繰返し伝票、記帳指図、保留伝票、残高繰越明細、各国の期末決算処理、長文テキストと添付、補助テーブルの取引データ）はほとんど支障にならない。後者を狙うなら、来ないものを中央でどう作るかという設計が別途必要になる。 そして目的が広がるほど、この選択肢は全面移行に近づき、費用も工期も全面移行に近づく。狭いままにできるかどうかが、採否の実質である。
第二に、会計帳簿の原本をどちらに置くかを、導入前に文書で決める。 会社法第432条第2項は会計帳簿の閉鎖の時から十年間の保存を求めており、保存対象が源泉側なのか中央側なのかは会社が決めるべき事項である。あわせて、外部採番の文書タイプが中央で内部採番に置換されうること、Document Relationship Browserによる元伝票への遡及が源泉システムがSAPである場合に限られることを、監査対応の前提として整理しておく。非SAPの子会社を接続した部分は、明細の裏取りが現地依存になる。
第三に、マッピングの保守と突合を、恒久的な業務として人に割り付ける。 キー・マッピングとバリュー・マッピングは源泉側でコードが増えるたびに発生し、更新されなければ伝票はAIFで止まる。突合は、財務会計四本と管理会計三本の比較レポートを締めのタスクに組み込み、差が出た日に誰が直すかまで決める。Central Paymentまで進むなら、決算処理を終えた後のカットオーバー、税整合性チェックとCSPCの有効化順序、そして過去の未決済明細の技術的消込を、二重支払を避けるための手順として先に固める。
