SAP FICO解説：導入を頓挫させる7つの落とし穴

SAP FICOは、2つのモジュールが1つとして機能するものです。財務会計（FI）は、監査人や規制当局が目にする数字を作ります。管理会計（CO）は、経営陣が事業を動かすために使う数字を作ります。S/4HANAでは、どちらも単一のユニバーサルジャーナルに転記されます。この記事は、S/4HANAの財務ワークストリームをこれから始める方、進めている方、立て直そうとしている方に向けて書きました。財務責任者、プログラムディレクター、FICOコンサルタントの皆さんです。FIとCOがどう組み合わさるのか、SAPのほかの領域とどこでつながるのか、そして導入を頓挫させる7つの判断を解説します。ユーザー受入テスト（UAT）に入る前に、終盤のレディネスチェックリストを使ってください。

私は25年、ブループリントからサポートまでのライフサイクル全体にわたってSAP FICOのプロジェクトに携わってきましたが、同じパターンが繰り返されます。技術的な問題もあります。ただ、より多いのは、早い段階で急いだ判断や見落とした判断に起因する問題です。

2026年というタイミングには意味があります。SAP ECCのメインストリームメンテナンスは2027年末に終了します。そのため、ECC上にいる財務チームの多くは、移行の途中か、これから着手するところです。以下のミスは、ECCのときよりもS/4HANAのプログラムのほうが高くつきます。ユニバーサルジャーナルでは、まずい設計を後から吸収する余地が小さいからです。

財務会計（FI）は外向きです。法定要件への対応、貸借対照表、損益計算書といった、会社の外に出ていく数字を扱います。SAPのすべての財務取引は、最終的にFIに行き着きます。

管理会計（CO）は内向きです。経営判断のための原価の追跡、予算管理、収益性の把握を担います。原価センタは、お金がどこで使われているかを示します。収益性分析は、顧客別、地域別、製品別のマージンを示します。

実際には、この2つを切り離すことはできません。買掛管理の仕入先請求書は総勘定元帳に転記され、原価センタのレポートにも流れます。固定資産の購入は帳簿を更新し、原価計画にも影響します。FIがどこで終わり、COがどこから始まり、どこで重なるのか。それを理解しているかどうかが、財務の知識と、ボタン操作だけの知識との分かれ目です。

S/4HANAでは、この境界がさらに曖昧になります。ユニバーサルジャーナル（テーブルACDOCA）は、FIとCOの明細を1つのレコードに格納します。設計上、重要な帰結が2つあります。1つ目は、原価要素が独立したマスタデータではなくなり、原価要素カテゴリを持つ総勘定元帳勘定になったことです。2つ目は、SAPが推奨する収益性モデルがマージン分析（勘定ベースのCO-PA）であることです。原価ベースのCO-PAは、オンプレミスとプライベートエディションにはまだ残っています。ただ、SAPの学習コンテンツははっきり述べています。S/4HANA Cloudでは利用できず、新規の投資はマージン分析に向かっています。

FICOチームが設定する主なコンポーネントは次のとおりです。

コンポーネント	領域	管理する内容
総勘定元帳（FI-GL）	FI	すべての財務取引の中核となる記録。法定報告の基礎
買掛管理（FI-AP）	FI	仕入先請求書、支払、債務
売掛管理（FI-AR）	FI	顧客請求書、回収、与信
固定資産会計（FI-AA）	FI	固定資産の取得、減価償却、除却
銀行会計	FI	銀行明細、照合、資金ポジション
原価センタ会計	CO	部門や機能別の原価
内部指図書	CO	イベント、キャンペーン、小規模プロジェクト向けの一時的な原価集計
利益センタ会計	CO	事業単位別の収益と原価
マージン分析（CO-PA）	CO	顧客、製品、チャネル、地域別のマージン

FIとCOの照合は不要になりました。 ジャーナルが1つで、別個の集計テーブルもないため、ECCでコンサルタントの工数を食っていた期末の照合作業は、ほぼなくなります。その裏返しとして、原価センタの設計と収益性特性は、設計時点で正しくなければなりません。ミスを覆い隠してくれる集計レイヤーはないからです。

連結とプランニングの行き先が変わりました。 SAPは、連結についてはS/4HANA Group ReportingをSAP Business Planning and Consolidation（BPC）の後継と位置づけ、プランニングについてはSAP Analytics Cloudを位置づけています。BPCのメインストリームメンテナンスは2027年に終了します。まだBPCを使っている場合にどうすべきかは、私のSAP BPCガイドで解説しています。

Jouleは実在しますが、守備範囲は狭いです。 SAPの2025年半ばのAIリリースノートには、Jouleによる固定資産マスタデータの作成や銀行明細のモニタリングといった、財務のユースケースが挙がっています。期日を過ぎた売掛金を督促する売掛管理エージェントについても説明があります。2025年5月から一般提供されているSAP Joule for Consultantsは、SAP NoteやActivateのコンテンツをもとに、設定に関する質問に答えます。どれも、きれいなデータの上でこそよく機能します。どれも、まずい設計を直してはくれません。

クリーンコアによって、「カスタマイズ」の意味が変わりました。 S/4HANA Cloud Public Editionでは、コアを一切変更できません。プライベートエディションとオンプレミスでは変更できますが、変更のたびにアップグレードの工数とリグレッションのリスクが増えます。ECC時代の習慣は、いまや標準設定か、SAP BTP上のサイドバイサイド拡張に属します。転記ルールのためのZテーブル、税ロジックのためのエンハンスメント、CO-PAでのABAP導出といったものです。これによって、後述するミス4の重みが増しています。

FICOは、ほぼすべてのSAPモジュールとつながっています。統合の問題の大半は、その受け渡しの部分で起きます。各チームが自分の領域をテストし、つながりそのものは誰もテストしないからです。

モジュール	統合ポイント	S/4HANAでの動作
MM（資材管理）	GR/IR清算、請求書転記、在庫評価	入庫でACDOCAにGR/IR仕訳が転記され、仕入先請求書がそれを清算して買掛管理に転記される
SD（販売管理）	請求、収益、売掛金、与信	請求がユニバーサルジャーナルの収益と売掛金を更新する。契約で必要な場合、IFRS 15ではRevenue Accounting and Reportingを使う
PP（生産計画）	製造原価、仕掛品、差異	指図原価はACDOCAに蓄積され、仕掛品と差異は同じジャーナル内で精算される
HCM／給与	給与の転記、原価の割当	給与結果が費用と負債としてFIに転記され、原価センタに流れる
PS（プロジェクトシステム）	予算、精算、プロジェクト収益	プロジェクトの原価と収益がFI/COに転記され、すぐに確認できる
PM（プラント保全）	保全指図の原価	労務費と材料費が指図に集計され、COに精算される
Group Reporting	連結	ACDOCAを直接読み込む。別個の連結用データベースはない

ユニバーサルジャーナルによって、こうした統合の失敗の現れ方が変わります。ECCでは、FIとCOの差異は照合の問題として表面化しました。S/4HANAでは、誤った勘定に転記されたMMの転記は、取り消して転記し直さなければならない実際の仕訳になります。監査上の指摘も早く届きます。こうした受け渡しのロジスティクス側については、私のSAP SDとSAP PPのガイドをご覧ください。

1. 01MMでの入庫在庫と棚卸資産が更新される
2. 02勘定決定評価クラスが総勘定元帳勘定を決める
3. 03ACDOCAへのGR/IR仕訳FIとCOで共通の、ユニバーサルジャーナルの一明細
4. 04仕入先請求書GR/IR仕訳を清算する
5. 05買掛管理総勘定元帳に転記され、原価センタレポートにも流れる

FIとCOの両方が読み取る一つの仕訳

1. 誰も担当者がいないマスタデータ

多くのプロジェクトでは、第1週に、マスタデータのクレンジングが必要だという合意ができます。その後、設定作業が主役になり、締切が迫り、マスタデータは後回しになります。テストが始まるまでは。

UAEの小売のお客様に、一見完成しているように見える原価センタ階層がありました。名称は一致していました。合計も合っていました。ところが結合テストで、店舗の原価が意味の通らない地域責任者の下に表示され、データがまるごと欠けている箇所もありました。

その構造は、店舗の実際の運営と照らし合わせて確認されたことがありませんでした。導入チームの想定に基づいて作られていたのです。原価センタのマッピングとレポートのロジックを作り直すのに、優秀なメンバーが専念しても2週間かかりました。

よくある原因は、おなじみのものです。現在のレポート要件を確認しないまま旧システムからコピーした総勘定元帳勘定。古い税データや銀行情報の欠落がある仕入先マスタ。原価の流れではなく組織図に沿った原価センタ階層。後から追加される利益センタ。ブループリントを締める前に、マスタデータに名前の挙がった担当者を置いてください。構造、使われ方、抜けを大まかに確認するだけでも、後のクレンジングの大半は防げます。

2. コントローラが関与しないまま設定されるCO

管理会計は、たいてい後回しになります。FIは早い段階で設計され、レビューされ、テストされます。COはそれより注意を払われないまま後に続きます。COのほうが単純で、後から固められるという理屈です。

そうはいきません。

私が関わった通信業のプロジェクトでは、CO-PAの設定が遅れて行われました。テストは問題なさそうに見えました。転記は通り、レポートも動きました。ところが営業と財務がマージンをレビューすると、売上上位の製品が赤字として表示されたのです。主要な原価要素がマッピングされておらず、導出ルールも不完全でした。直すには、すでに承認済みだったレポート構造を設計し直す必要がありました。

COが機能するのは、レポートを読む人、つまりコントローラと財務ディレクターが設計に加わったときだけです。彼らが考えるのは、システムのフローではなく、原価の挙動とマージンです。UATではなく、ブループリントの段階で巻き込んでください。

3. 業務ユーザーが初めてシステムを見るのがUAT

UATは問題が表面化する場ですが、見つけるには最も高くつく場所でもあります。設計は固まり、設定はほぼ終わっているからです。

東南アジアの持株会社の財務変革プロジェクトでは、UATは自信を持って始まりました。スクリプトは整い、技術的なチェックも通っていました。そこへ財務チームがログインしました。多くのメンバーにとって、画面を見るのはそれが初めてでした。毎日使っていた項目が消えていました。説明のないステップが加わっていました。ワークフローは、技術的には筋が通っていても、業務としてはまったく筋が通らない形に作り替えられていました。

主要なフローを見直し、一部のロジックは作り直さなければなりませんでした。プロジェクトは数週間を失いました。

未完成の画面を、早い段階でユーザーに見せてください。完成した画面を遅い段階で見せるより、必ず安く済みます。

4. 設定で済むところでのカスタム開発

カスタムコードは、速くて制御しやすいように感じられます。頼んだとおりのものが手に入ります。しかし時間が経つと、テストしにくく、変更しにくく、壊れやすくなります。S/4HANAでは、変更のたびにアップグレードの工数も増えます。

以前、6か国にまたがるグローバル導入に関わったことがあります。そこでは税ロジックがすべてABAPで作られていました。国ごとのルール、例外、製品別の税率です。動くことは動きました。ただ、標準のSAPには、条件タイプ、税計算手順、国別設定で対応できる仕組みがすでにありました。

ある国が税率を変更すると、業務側は開発依頼を起票し、待ち、すべてを再テストしなければなりませんでした。最初は効率的に思えた作りが、税の変更のたびにボトルネックになったのです。こうしたケースでの解決策は、カスタムテーブルを廃止し、ロジックを標準設定に移し、本当に固有のルールだけを小さな拡張として残すことです。

同じパターンは、ほかでも見られます。設定ですでに対応できる転記ルールのためのカスタム検証。標準のFioriアプリやCDSビューがあるのに作り直されるレポート。変更の余地なくハードコードされた承認ステップ。そのたびに、1つの問いを立ててください。このロジックはどこにあり、次のアップグレードでプロジェクトを立てずに持ちこたえられるか。答えが「コアの中」や「確認していない」なら、設定かBTPに移してください。

5. 確認されない統合ポイント

テストの間、チームは自分のモジュールに集中します。境界は確認されないままです。

ある製造業のロールアウトでは、入庫はMMで正しく処理されました。在庫も更新されました。ロジスティクス部門から苦情はありませんでした。ところが、FIにはその入庫に対する仕訳が1件もありませんでした。

原因は、勘定決定に評価クラスが抜けていたことでした。MMはエラーなく処理を終え、財務の転記は生成されませんでした。原因の特定に2日。その間に転記された分の後始末に、さらに数日かかりました。

私が見てきた似た失敗は次のとおりです。勘定決定の抜けによって、SDの請求が誤った収益勘定に転記される。PMでの資産振替が固定資産会計に届かない。MMとFIのチームで理解が食い違っていたGR/IRのロジック。財務責任者が1人、MMとSDのテストスクリプトをレビューするだけで、こうした問題の大半は防げます。転記がどのような形になるべきかを知っているのは、財務です。ロジスティクスのテスト担当者は、知らないことが多いのです。

6. 最後のスプリントで設計されるレポート

財務情報を作るために存在するモジュールなのに、プロジェクトは驚くほど一貫して、レポートを最後に回します。まず転記を動かし、レポートは後で片づけよう、という考え方です。

本稼働後のフェーズを支援したヨーロッパの消費財のお客様では、CO-PAが構築され、項目がマッピングされ、導出も設定されていました。最初のセグメント損益計算書は、見出しこそ正しいものの、原価が散らばり、断片化していました。収益は問題ありませんでした。一部の値項目は、まったく入力されていませんでした。

財務チームはExcelに逆戻りしました。またしても、です。私が間に入って整理するしかありませんでした。レポートへの信頼は、いったん失われると、自然には戻ってきません。

チャネル別のマージンやプロジェクト別の原価が事業にとって重要なら、その要件が、設計時のデータの取得方法を決めなければなりません。2026年時点で一般的なレポート層は、ユニバーサルジャーナルを読み取るSAP Analytics Cloudです。GROWやRISEのパッケージに含まれる場合もあれば、別売りの場合もあるので、契約を確認してください。整った収益性設計の上に載せたAnalytics Cloudは機能します。中途半端な設定の上に載せたAnalytics Cloudは機能しません。詳しくは、私のSAP Analytics Cloudガイドをご覧ください。

7. チーム間の谷間に落ちる例外ケース

プロジェクトが大量処理のプロセスに集中するのは当然です。その結果、例外ケースは表面化するまで後回しにされます。

あるロールアウトで、お客様には3つの会社コードがあり、会計年度バリアントが3種類ありました。暦年のもの、4月から3月のもの、4-4-5のものです。設計の段階では、誰も指摘しませんでした。

それが表面化したのは、会社間照合のときでした。期間が合わなかったのです。会社コードごとにカットオフが違うため、財務は期限どおりに締められませんでした。この1件だけで、連結が2週間ずれ込みました。

計画の中に1時間を確保し、各ワークストリームに、自分の領域で普通ではないことを挙げてもらってください。問いは3つです。まだモデル化されていない法規制や地域ルールはないか。SAPの外で手作業の回避策を運用しているチームはないか。前払金や前受金、保留伝票、会社間ネッティングといった機能は使われていないか。例外ケースは必ず表面化します。問題は、それが設計セッションで出てくるのか、月次決算で出てくるのか、だけです。

UATが始まる2週間前に、このリストを実施してください。「いいえ」はすべて、担当者と期日を付けてリスクとして記録します。

1. マスタデータの担当者を指名済み。 1人が、勘定コード表、原価センタ階層、利益センタ、仕入先マスタと顧客マスタを承認します。担当：財務ディレクター。
2. 原価センタ階層を、実際の原価の流れでテスト済み。 組織図ではありません。担当：ファイナンシャルコントローラ。
3. コントローラが収益性の設計をレビュー済み。 特性、導出ルール、セグメント損益計算書の最初のドラフトです。担当：管理会計部門の責任者。
4. キーユーザーが画面を見ている。 UATスクリプトを書く前に、プロセスごとに少なくとも1回のウォークスルーを行います。担当：財務プロセスリード。
5. カスタムコード一覧をレビュー済み。 すべてのエンハンスメントに、標準設定ではできなかった理由があります。担当：ソリューションアーキテクト。
6. 勘定決定をモジュール横断でテスト済み。 入庫、仕入先請求書、顧客への請求、製造指図の精算が、それぞれ想定どおりの仕訳を生成します。担当：FICOリード（MM、SD、PPのリードと共同）。
7. 経営レポートを実際のテストデータで構築済み。 モックアップではありません。担当：レポートリード（CFO室と共同）。
8. 会計年度バリアント、通貨、会社間設定を会社コード間で比較済み。 担当：FICOリード。
9. 例外ケースのセッションを実施済み。 未払計上、前払金や前受金、保留伝票、会社間ネッティング、国別の税ルール。担当：プログラムマネージャー。

SAP FICOとは何ですか。各文字は何の略ですか。

FIはFinancial Accounting（財務会計）、COはControlling（管理会計）の略です。この2つで、SAPの中核となる財務モジュールを構成します。

FIは外部報告を担います。総勘定元帳、買掛管理、売掛管理、固定資産会計、銀行会計です。COは社内の管理会計レポートを担います。原価センタ、内部指図書、利益センタ、収益性分析です。

両者は密接に結びついています。S/4HANAでは1つのユニバーサルジャーナルを共有するため、一方だけを理解することはできません。

SAP FICOはSAP MM、SD、PPとどのように統合されますか。

MMからFI：入庫によって、GR/IR仕訳が自動的に転記されます。仕入先請求書がそれを清算し、買掛管理に転記されます。勘定決定が正しくなければ、MMは処理を終えるのに、財務の仕訳は現れません。

SDからFI：請求によって、収益と売掛金が更新されます。SDの勘定決定に抜けがあると、収益は誤った勘定に転記されるか、どこにも転記されません。

PPからFI/CO：製造指図は、材料費、労務費、間接費を集計します。COが仕掛品と差異を精算します。収益性の設計が弱いと、それらの原価はマージンレポートに届きません。

3つに共通する対処法は同じです。財務責任者が、ほかのワークストリームの書いた統合テストスクリプトをレビューすることです。

SAP HANAとSAP FICOの違いは何ですか。

両者は別のレイヤーです。SAP HANAはインメモリデータベースです。SAP FICOは、会計担当者やコントローラが使う財務アプリケーションです。

S/4HANAでは、HANAがユニバーサルジャーナルを現実的なものにしています。FIとCOのデータが1つのテーブルに入り、バッチでの照合なしにリアルタイムで報告できます。HANAのパフォーマンスの問題は、FICOレポートの実行速度に影響します。FICOの設定の問題は、そのレポートに何が載るかを決めます。

2026年のS/4HANAでも、SAP FICOは有効ですか。

はい。中核となるスキルは引き継がれます。勘定決定、原価センタ設計、収益性の設定、期末決算です。企業は、取引だけでなく財務プロセスを理解している人材を、これからも必要としています。

変わったのは、求められる人材像です。企業が求めているのは、ユニバーサルジャーナル、マージン分析、Group Reporting、クリーンコア拡張を理解し、移行の際にECCのどのカスタマイズを廃止すべきか助言できるFICOコンサルタントです。ECCのメインストリームメンテナンスが2027年に終了するため、移行案件が需要を高い水準に保っています。

FICO分野でのキャリアチェンジを考えているなら、SAPopediaのキャリアパスが職種別のスキルを整理しており、ERPCVキャリアパックはS/4HANAの財務経験を履歴書に反映するのに役立ちます。

2026年、JouleはSAP FICOの導入をどう変えますか。

マーケティングが示すほどではありませんが、懐疑的な人が思うよりは変えます。SAP Joule for Consultantsは、SAPのNoteやActivateのコンテンツをもとに、設定やコードに関する質問に答えるため、標準スコープの調査が速くなります。システム内では、Jouleは固定資産マスタデータの作成や銀行明細のモニタリングといった作業を処理します。SAPは、期日を過ぎた債権を督促するエージェントなど、財務向けのエージェントもリリースしています。

複数国にまたがる税務、グループレポーティングの構造、収益認識における設計判断を置き換えるものは、ひとつもありません。しかも、その下にあるデータの質に見合った性能しか出ません。パートナーの提案を評価するときは、AIツールが工数見積りにどう反映されているかを尋ねてください。

新規導入におけるFICOの主な設定ステップは何ですか。

基盤は、おおむね次の順序で設定します。

1. 会社コード：財務諸表を作成する法的主体です。
2. 会計年度バリアント：暦年、4月から3月、4-4-5。相互に取引する会社コード間では、一貫させてください。
3. 勘定コード表：総勘定元帳勘定の一覧で、可能な限り会社コード間で共有します。ここでの判断は、システムの寿命を通じてあらゆるレポートに影響します。
4. 転記期間バリアント：どの期間に転記できるかを定めます。
5. 項目ステータスバリアント：どの項目を必須、任意、非表示にするかを定めます。
6. 税設定：税コード、税率、国のマッピング。ローカライゼーションの複雑さの大半はここにあります。
7. 管理会計の構造：管理領域、原価センタ、利益センタ、内部指図書、収益性特性を、コントローラと共同で設計します。
8. 勘定決定：MM、SD、PPの取引がどのようにFIの転記になるか。本稼働前に、エンドツーエンドの結合テストで検証してください。