部門別の損益が出るようになった、と胸を張って役員会に持っていく。事業部長がその一枚を見て、開口一番こう言う。「この本社費の配賦、うちが決めた費用じゃないですよね」。次の月から、その資料は誰も開かなくなる。SAPで利益センタ会計を入れた会社が最初に踏む地雷は、たいていここにある。数字は正しく出ている。集計もシステム上は合っている。それでも使われないのは、利益センタを組織図どおりに切ったせいで、損益の責任を負えない単位にP/Lが立ってしまったからだ。
「組織図をそのまま切る」が最初の分岐点
利益センタの階層を作るとき、手元にある組織図をそのまま持ち込むのが最も自然に見える。実際、多くのプロジェクトがそこから始める。ところが組織図には、損益の責任を負えない単位が大量に含まれている。総務、人事、情報システム、品質保証。これらを利益センタにすると、売上がゼロでコストだけが立つP/Lができ、その赤字をどこかに配賦する仕事が発生する。配賦先の事業部は自分が決めていない費用を負わされるので納得しない。この構図は、SAPを入れる前の部門別損益でも同じことが起きていた（部門別損益（事業部別P&L）の作り方：共通費配賦で揉めない設計）。
切り分けの基準は、決定権と引受人の二つだ。売上の水準と主要なコストの両方に決定権があり、その結果責任を負う人がいる単位を利益センタにする。片方しか持たない単位は、原価センタに留めて上位の利益センタに束ねる。
階層をひとつ決めるとき、忘れがちなのが変更の頻度だ。SAPでは利益センタの標準階層は一本で、それ以外の見方は利益センタグループとして別に持つ。組織改編のたびに利益センタコードを廃止して新設していると、前年同期との比較ができなくなる。実務では、コードは事業の実体に紐づけて長く保ち、組織の見え方は階層やグループの側で組み替えるほうが持ちこたえる。
数字が入ってこない——導出をどこで設計するか
設計を終えて動かし始めると、次の問題が来る。「うちの利益センタに売上が入っていない」という申告だ。利益センタは伝票に直接入力されるより、他のオブジェクトから導出されて入るほうが多い。原価センタ、内部指図、WBS要素、固定資産、そして品目マスタや販売伝票——これらのどこに利益センタを割り当てるかで、伝票に何が乗るかが決まる。
だから設計時に確認すべきは、階層の絵ではなく、取引パターンごとの導出経路だ。製品販売の売上はどこから利益センタを拾うのか。仕入の原価は。減価償却費は資産マスタの割り当てから入るのか。工事や案件を持つならプロジェクト側からか。主要な取引を十種類ほど並べ、それぞれについて「この明細の利益センタは何を見て決まるか」を一行で書けるまで詰める。ここを詰めずに稼働すると、月次で原因不明の欠落が出て、経理が手作業で振り替える運用に落ちる。
導出できなかった明細は、受け皿となる利益センタに落ちる。この受け皿の残高を毎月確認する運用を最初から組んでおく。ここが増えているときは、マスタの割り当て漏れか、想定していなかった取引パターンが発生している合図だ。放置すると期末に部門別P/Lの合計が全社と合わなくなり、決算直前に原因を追う羽目になる。
貸借対照表まで見るなら、文書分割は最初に決める
損益だけでなく、事業部ごとの投下資本や運転資本まで見たい——ROIC経営を志向する会社なら必ずこの要求が出る。だが売掛金や買掛金、在庫といった貸借対照表項目は、そのままでは利益センタに割れない。
ここで効くのが新総勘定元帳の文書分割（ドキュメント・スプリッティング）だ。利益センタを分割特性として設定すると、一つの伝票の中で債権や債務の明細が損益側の利益センタに応じて分割され、利益センタ単位で貸借が均衡した帳簿が作れる。結果として、利益センタ別の貸借対照表が組める。
問題は、この設定が導入後に変えにくいことだ。文書分割は伝票の記帳ロジックそのものに関わるため、稼働後に有効化するには過去データの移行を伴う大掛かりな作業になる。「まずは損益だけ、B/Sは将来」と先送りすると、その将来が来たときの費用が跳ね上がる。事業部別の資本効率を見る構想があるなら、設計の初期に判断しておく。セグメント情報の開示を見据える場合も同じで、SAPではセグメントを利益センタから導出する作りになっているため、利益センタの切り方がそのまま開示の単位に効いてくる（S/4HANAの新総勘定元帳（New G/L）で連結・セグメント報告を軽くする）。
CO-PAと軸を分ける
利益センタとCO-PAは似た数字を出すので、どちらで管理するかで議論になる。分け方は明快で、問いが違う。利益センタが答えるのは「誰が責任を負うか」、つまり組織の軸だ。CO-PAが答えるのは「どの製品・どの顧客・どのチャネルが儲かるか」、つまり市場の軸になる（CO-PA（収益性分析）で「どの製品・顧客が儲かっているか」を出す）。
事故が起きるのは、両者の利益を一円単位で一致させようとしたときだ。CO-PAには利益センタ会計では扱わない見積原価や引当の配賦が入ることがあり、集計の目的が違う以上、完全一致を前提にすると設計が窮屈になる。差異が出る箇所と理由を説明できる状態にしておけば足りる。COの全体像における両者の位置づけは別稿で整理した（SAP CO（管理会計）で原価と採算を見える化する｜FIとの違いと使いどころ）。
稼働前に決着させておく五つ
設計フェーズで先送りされやすく、稼働後に直すと高くつく論点をまとめておく。
| 論点 | 先送りしたときに起きること |
|---|---|
| 利益センタの粒度 | 細かく切りすぎると配賦と調整の工数が毎月発生し、粗すぎると事業の実態が見えない。責任者がいる単位を上限にする |
| 取引パターンごとの導出経路 | 稼働後に欠落が出て、経理が手作業で振り替える運用が固定化する |
| 間接費を配賦するか、しないか | 決めずに始めると、月次のたびに配賦基準の議論が再燃する。配賦するなら管理可能費と不能費を分けて段階表示する |
| 貸借対照表を利益センタ別に見るか | 文書分割の要否がここで決まる。後から有効化すると移行を伴う |
| 階層とマスタの維持責任者 | 組織改編のたびに誰が更新するかを決めていないと、階層が実態から遅れて数字が信用されなくなる |
このうち経理部門だけで決められるのは、実は一つもない。粒度と配賦は事業部長の責任範囲の話であり、B/Sを見るかどうかは経営がROICをどこまで事業単位で問うかの話だ。設計の議論をシステム部門とコンサルタントの中で閉じると、稼働後に「そんな話は聞いていない」が必ず出る。
