SAP FI（財務会計）の導入で、本当に勝負が決まるのは最初の数週間だ。システムが動き出してから「どこをカスタマイズするか」を議論する人は多いが、その前に経理が腹を括って決めておくべき土台が3つある。ここを曖昧なまま走り出すと、後工程のテストや決算リハーサルでつまずきやすく、後から直すほど手戻りのコストは大きくなる。CFOzine編集部が、導入の現場視点でつまずきやすい点ごとに整理する。
まず前提：なぜ「今」FI導入の話なのか
決めごとの話に入る前に、時間軸を押さえておきたい。多くの日本企業が今使っているSAPの旧世代ERP「ECC」（正確にはBusiness Suite 7、拡張パッケージEHP6〜8の構成）の通常保守は、2027年末に終了する。追加費用を払えば延長保守を2030年末まで使えるが、これも期限付きだ。一方、移行先のS/4HANAは、SAPが2040年末まで「常に保守対象のリリースを1つは用意する」と表明している。
延長保守の追加費用は、保守料の計算基礎に2ポイント上乗せされる。たとえば標準的なEnterprise Support（保守率22%）の契約なら、22%が24%になる計算で、保守費そのものは相対的に1割弱増える。延命はできるが、新機能の追加はなく、あくまで時間を買うための支出だ。
つまり「いつか移る」ではなく「期限の中で移る」段階に入っている。だからこそ、最初の意思決定を雑にやっている余裕はない。以下の3つは、コンサルやベンダーに丸投げできない。経理が自分たちの事業の言葉で決めるべきものだからだ。
決めること① 勘定科目の体系をどう設計するか
勘定科目の体系（COA＝Chart of Accounts、勘定科目のマスタ一覧）は、財務会計の背骨そのものだ。これを設計し直すか、今の科目をそのまま持ち込むかで、その後の数字の見え方が変わる。
S/4HANAには標準の科目テンプレートが用意されており、これをベースに自社の科目を当てはめていくやり方がある。ゼロから自社流の番号体系を組むこともできる。ただ、編集部が現場で口を酸っぱくして言うのは**「今の科目を一対一でそのまま移すのが正解とは限らない」**ということだ。長年の運用で増えた、もう誰も使っていない科目。担当者しか意味の分からない補助科目。移行は、それを棚卸しできる数少ない好機でもある。
設計で経理が握るべき論点は、具体的に3つある。
- 科目の粒度：細かすぎると入力ミスと月次照合の手間が増え、粗すぎると後で分析できない。「誰が、何の判断に使うか」で1本ずつ判定する
- グループ共通の科目体系：連結・管理会計のためグループ全体の集約用科目（グループCOA）を別建てするか決める。後から変えるのは極めて重い
- 原価要素の扱い：管理会計の原価要素が総勘定元帳の科目に統合された。「損益の科目を原価要素としてどう括るか」をCO担当と一緒に決める
なお、後述する「管理領域」に複数の会社をぶら下げる場合、それらは同じ勘定科目体系を共有しなければならない、という制約がある。また原価要素の統合について補足すると、これまで別管理だった原価要素（管理会計で原価を集計する科目）が総勘定元帳の科目に統合されたことで、財務会計（FI）と管理会計（CO）で「数字が合うか」を突き合わせる作業が、構造上いらなくなる。COAを設計する時点で、この統合を前提に進めたい。
決めること② 会社コードと組織構造をどう切るか
会社コード（SAP上で独立して決算を締める単位）は、財務諸表を作る最小の法的単位だ。原則は「決算書を出す法人＝1会社コード」で、ここはあまり迷わない。判断が割れるのは、その上下に積み重なる組織の階層である。
- 管理領域（コントローリングエリア）：原価や収益を管理する単位。複数の会社コードを1つの管理領域に割り当てると、会社をまたいだ原価計算ができる。ただし前述のとおり、同じ管理領域に入れる会社コードは、勘定科目体系と会計年度（決算期）の定義を揃えなければならない。
- セグメント・利益センタ：会社コードより細かい単位で損益を切り出すための軸。事業別・拠点別にどう見たいかを、ここで設計する。
経理が最初に答えを出すべき問いは、**「うちは何を、どの細かさで、誰に見せるための数字を作るのか」**だ。法定の決算は会社コードで自動的に決まる。だが経営が本当に欲しいのは、事業別・地域別・製品別の損益であることが多い。それをセグメントや利益センタで持つのか、別の管理軸で持つのか。ここを設計の初日に決めておかないと、データが貯まってから「その切り口では出せません」となりがちだ。
決めること③ 標準に寄せるか、アドオンを作るか
3つ目は、導入の総コストと将来の保守負担を最も左右する論点だ。標準機能をそのまま使うか、自社向けに作り込む（アドオン＝追加開発する）か。
結論から言えば、編集部の立場ははっきりしている。まず標準に寄せる。アドオンは「標準では本当に業務が回らない、と説明できたもの」だけに絞る。 S/4HANAはそもそも「標準への回帰」を設計思想に据えており、データの持ち方も単純化された。
それでも作り込みを求める声は必ず出る。判断の物差しを、2つ持っておくとよい。
まとめ：最初の3つは「IT」ではなく「経営」の決断
勘定科目の体系・組織の切り方・標準とアドオンの線引き。この3つに共通するのは、いずれもベンダーが代わりに決められない、経理が事業の意思として決めるべきものだという点だ。技術的な実装はコンサルに任せられる。だが「うちは何を、どの単位で見たいのか」「どこまで自社流にこだわるのか」は、自分たちの言葉でしか答えられない。
そして、この3つは後になるほど変更が重くなる。設計の初期なら会議室の議論で済むことが、本番稼働の後ではシステム改修と再テストの大工事になる。
- 決めること①：勘定科目の体系（COA）。粒度・グループ共通科目・原価要素の統合を経理が握る
- 決めること②：会社コードと組織構造。確度の高い数年先まで織り込み、その先は広げられる構造だけ残す
- 決めること③：標準とアドオンの線引き。まず標準、アドオンは関所で一括承認・10年の総コストで判断
- 3つとも後になるほど変更が重い。期限が迫る今、走り出す前に腰を据えて答えを出すことが、成功と失敗を分ける最初の分岐点になる