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