グループ全体の損益を一枚にまとめようとして、毎回Excelで科目を読み替えている会社は多い。A社の「販売手数料」がB社では「支払手数料」に紛れ、同じ「消耗品費」でも会社ごとに拾っている中身が違う。集計担当者の頭の中にだけ、その対応表が入っている。これは経理の努力不足ではない。勘定科目体系（COA）を、長年その場しのぎで継ぎ足してきた結果だ。そして継ぎ足しの歪みは、通常の運用のなかでは直せない。動いている勘定を全社一斉に付け替えるのは、業務を止めるに等しいからだ。だからこそ、SAP移行は数少ない再設計の窓になる。移行時にCOAを引き直さなければ、次に同じ窓が開くのは十数年後である。
継ぎ足したCOAが、何を壊しているか
勘定科目は、必要に迫られるたびに増える。新しい取引が始まれば科目を足し、部門が「うちの費用を分けて見たい」と言えば補助科目を足す。一つひとつは合理的な判断だ。だが十年も続ければ、全体は誰も設計していない地層になる。同じ経済実態に複数の科目が対応し、会社をまたぐと同じ科目名が別の中身を指す。この状態でグループ集計をすれば、Excelでの読み替えは必然になる。
問題は手間だけではない。数字の意味が人によってズレることが本質的な害だ。経営会議で「販管費が増えた」と言っても、どの科目で何を拾っているかが会社ごとに違えば、議論は噛み合わない。管理会計と財務会計の数字が合わない悩みの根も、多くはここにある（管理会計と財務会計の数字が合わない問題）。COAは単なる科目の一覧ではなく、全社が数字を共有するための共通言語なのだ。言語が方言だらけでは、同じ土俵で経営を語れない。
粒度は「科目」でなく「補助軸」で持つ
再設計でまず迷うのが粒度だ。細かく見たいからと科目を増やせば、継ぎ足しの二の舞になる。ここでS/4HANAの構造が効いてくる。財務会計と管理会計が単一の明細テーブル（ユニバーサルジャーナル）に統合されたことで、一つの仕訳に利益センタ・原価センタ・セグメント・プロファイトセンタといった複数の軸を同時に持たせられる。
つまり「部門別に見たい」「事業別に見たい」を、科目を割ることで解決する必要がない。科目は経済実態の種類（何の費用か）だけを表し、「誰の・どの事業の」費用かは補助軸で持つ。こう分けると、科目はむしろ減らせる。詳しくは新総勘定元帳とセグメント報告の仕組みで扱ったが（S/4HANAの新総勘定元帳（New G/L）で連結・セグメント報告を軽くする）、この「科目を薄く、軸を厚く」の設計思想が、継ぎ足しを二度と起こさない歯止めになる。
成否を分けるのは「付け替え表」を誰と作るか
新しいCOAを描くこと自体は、実はそれほど難しくない。難所は、旧科目から新科目への**マッピング（付け替え表）**だ。過去の残高と当年の取引を、新体系のどの科目に落とすか。ここを間違えると、移行後に過去比較ができなくなり、月次の数字が前年とつながらない。
この付け替えを経理だけで閉じてはいけない。旧科目に何が実際に入っているかは、その費用を発生させている業務部門が一番知っている。「この雑費には外注の一部が紛れている」「この手数料は本来は販促費だ」といった実態は、伝票を切っている現場でないと分からない。付け替え表を業務部門と一緒に作る過程そのものが、汚れたマスタや誤分類を洗い出す棚卸しになる。これは移行のデータ品質確保とも地続きだ（SAP移行のデータ移行で失敗しない｜マスタ品質を上げる進め方）。
逆に、付け替えをベンダー任せの機械的な変換で済ませると、旧体系の歪みがそのまま新科目に移し替えられるだけになる。箱を替えても、中身の混乱は残る。COA再設計は、科目を描く作業でなく、全社の費用の実態を一度たな卸しし直す作業なのだ。
