「案件別の採算がSAPから出てこない」という相談は、たいてい同じ形をしている。SAPには原価が入っている。工数も入っている。それなのに、案件ごとの粗利は経理がExcelで組み直していて、出てくるのは決算が締まった後だ。ここで多くのプロジェクトが「PSモジュールを入れれば解決する」という方向に進む。だが器を足しても、たいてい状況は変わらない。案件採算の設計とは、原価を集める器を作る作業ではなく、見積の一行と実績の一行を同じキーで並べられるようにする作業である。 営業はフェーズ別・役割別に工数を積んで見積り、実績は月別・社員別に入ってくる。この二つは、どれだけ精緻に原価を集めても突き合わない。
内部指図とWBS、どちらを使うか
判断は好みではなく、必要な機能で決まる。内部指図（KO01で作成、KO22で予算、KO88で決済）は単一階層のコストコレクタだ。軽く、大量に作れて、運用の教育コストが低い。展示会一回、金型一型、小規模な改善案件のように、始まりと終わりがあって階層を持たない仕事に向く。
WBS要素（CJ20Nのプロジェクトビルダーで作成、CJ30で予算、CJ88で決済）は階層を持つ。上位に予算を置いて下位に配分でき、日程を持ち、上位で集計しながら下位で実績を受けられる。フェーズごとに検収する案件、部分請求のある案件、進行基準で収益を認識する案件はWBSでないと組めない。
ここで一つ、設計レビューで必ず確認したい点がある。統計指図（統計転記のみの内部指図）を実績の受け皿にしようとする設計だ。統計指図は、実原価を受けている原価センタの横で「もう一つの見方」を持つための仕組みで、それ自体は決済されない。案件の原価を集めてCO-PAや資産へ流したいなら、実オーダとして立てる必要がある。この取り違えは、稼働してから決済が回らないことで発覚する。
見積の分解と、実績の分解を一致させる
WBSの階層を、社内の組織や工程の呼び名で切っている案件は多い。だが比較したいのは組織ではなく、見積だ。受注時に「要件定義200時間、設計400時間、開発900時間」と積んだのなら、WBSもその三つで切る。逆に、見積が一式で出ているのに実績だけを細かく分解しても、突き合わせる相手がいないので誰も見ない。
粒度を上げすぎる失敗も同じ頻度で起きる。WBSを50も100も切ると、現場は工数入力のたびにどこに付けるか迷い、迷った結果は「とりあえず一番上」に集まる。実績の粒度は、見積の粒度を超えてはいけない。 超えた分は入力精度の劣化として返ってくる。
工数は、活動タイプ単価を通って原価になる
ここがプロジェクト採算の心臓部で、同時に最も設計が雑になる場所だ。
工数はCATS（CAT2、S/4HANAのFioriなら「マイタイムシート」系のアプリ）で入力され、CAT5でプロジェクトへ、CAT7でCO（原価センタ・内部指図）へ転送される。転送された時点で金額に化けるが、その単価は給与実績ではない。原価センタと活動タイプの組み合わせに対してKP26で計画した活動単価だ。つまり期中に見えている案件原価は、実際の人件費ではなく、計画単価で評価された金額である。
差額は原価センタに残る。実際の人件費と、案件へ払い出した金額の差は原価センタの差異として滞留し、KSIIで実際の活動価格を計算し、KON2（内部指図）やCON2（プロジェクト）で再評価を転記するまで案件には落ちない。前提として、活動タイプのマスタ側で実際価格による再評価を許可しておく必要がある。多くの会社はこれを期末にしか回さない。だから「案件の実績原価は決算後にしか分からない」という状態が生まれる。裏を返せば、月次で回す設計にすれば月次で見える。
もう一段、経営に効く論点がある。活動単価の分母だ。原価センタの計画原価を年間の所定労働時間で割れば単価は低くなり、稼働率が80%なら残り20%分は吸収されずに原価センタへ残る。請求可能時間の計画値で割れば単価は高くなり、案件が部門の全コストを負担する。
収益を同じ器に載せないと、粗利は永久に出ない
原価側だけを整えて、収益側を忘れている設計は驚くほど多い。売上はSD（販売管理）から会社コード・利益センタへ流れるが、それだけではWBSに紐づかない。受注明細のアカウントアサインメントにWBS要素を指定して初めて、収益と原価が同じ器の上で並ぶ。ここを運用で徹底できないと、案件別P/Lは原価だけの表になる。
そのうえで、S/4HANAには収益認識のタイミングそのものを変える仕組みがある。従来のECCでは、月次の締め処理で結果分析（Results Analysis）を一括実行して仕掛品と収益を計算し、決済で財務へ落としていた。粒度は締めのバッチ単位で、転記の都度ではない。S/4HANAのイベントベース収益認識（Event-Based Revenue Recognition）は、工数の確定や仕入請求が転記されたその瞬間に、収益・売上原価・仕掛品を計算して仕訳を作る。ユニバーサルジャーナル（ACDOCA）に即座に載るため、締めを待たずに案件の粗利が見える。適用対象は顧客プロジェクトや受注明細に紐づくものが中心で、すべての案件に無条件で効くわけではないが、専門サービス型の事業ならまず射程に入る。
つまり、「締めが終わらないと案件の粗利が分からない」はS/4HANAでは設計の選択の結果であって、システムの制約ではない。 選ばなかった理由が「移行スコープに入らなかった」なのか「収益認識の要件を詰め切れなかった」なのかは、稼働後に問われる。
決済の設計が、案件の数字の行き先を決める
内部指図やWBSに集まった原価は、そこに置いたままでは会計の外にある。決済プロファイルと決済ルールで、どこへ落とすかを決める。費用で終わる案件ならCO-PAや原価センタへ、資産になる案件なら建設仮勘定（AuC）を経て本勘定へ。この設計を後回しにすると、稼働後に「指図に残高が残り続けている」という現象で表面化する。
決済先をCO-PAに置いておけば、案件の採算を顧客別・製品別の収益性分析と同じ土俵で見られる（CO-PA（収益性分析）で「どの製品・顧客が儲かっているか」を出す）。逆に、案件単位でしか見ない設計にすると、赤字案件が特定顧客に偏っているのか、特定の見積パターンに偏っているのかが分からないまま終わる。
「入れたのに出てこない」の答えは、たいてい入力の手前にある
案件採算がSAPから出ないとき、疑うべき順序は決まっている。収益が器に乗っているか。見積の軸と実績の軸が一致しているか。単価がいつの計画値か。決済が回っているか。この四つを確かめる前にモジュールを追加しても、出てこないものは出てこない。SAPは、集めろと言われたものしか集めない。何を集めるかを決めているのは、受注登録の画面と、見積を作っている営業の頭の中である（プロジェクト型事業の採算管理｜工数原価と稼働率で受注前に赤字を止める）。
