S/4HANAへの移行を終えた翌年、財務部から資金管理の機能を使いたいという提案が上がってきた。毎週、各事業部から入金と支払の見込みをエクセルで集め、財務の担当者が2日がかりで資金繰り表にまとめている。 SAPの中には請求書も発注書も受注も入っているのだから、そこから予測を出せば集計はいらない、という理屈である。CFOは導入を認めたが、半年後の報告は歯切れが悪かった。画面は動いている。予測も毎朝更新される。ただ、4週間先の残高の予測が、エクセルの資金繰り表より外れる。 財務の担当者は、SAPの予測を見たうえで、結局エクセルを作り直していた。機能が足りないのかと問われたベンダーの答えは、入っているデータのとおりに計算しています、だった。 その答えは正しかった。
支払期日が実際の入金日とずれる原因は、支払条件のマスタにある
最初に確かめるのは、得意先ごとの支払期日と実際の入金日のずれである。SAPの債権の明細には、支払期日を計算する元になる日付と支払条件が入っていて、消込の済んだ明細には消込の日付が残っている。 過去1年分の消込済みの明細を取り出し、得意先ごとに、支払期日から実際の入金日までの日数を集計すれば、ずれの大きさと向きがわかる。
ずれの原因として多いのは、日本の締め払いの条件を、日数で近似した支払条件のコードで登録している場合である。 月末締め翌月末払いの得意先に、請求日から30日の条件が付いていれば、月初の請求は1か月近く早く、月末の請求は数日早く並ぶ。20日締め翌月10日払い、月末締め翌々月15日払いのように、得意先ごとに違う条件を、手近な既存のコードで代用していることも多い。SAPの支払条件は、締め日と支払日を日付で持てる。 機能はある。移行のときに条件の数を減らそうと丸めた結果が、そのまま予測のずれになっている。
もう一つの原因は、支払条件が二か所に登録されていることである。 得意先のマスタには、会社コードの単位で持つ支払条件と、販売エリア（販売組織、流通チャネル、製品部門の組み合わせ）の単位で持つ支払条件がある。受注と請求で使われるのは販売エリアの側で、経理が会社コードの側を直しても、請求から生まれる債権の支払期日は変わらない。仕入先も同じで、購買組織の単位の支払条件が発注書に入り、請求書の照合を経て債務の支払期日になる。 条件の改定のたびにどちらか一方しか直していないと、同じ取引先の明細が、伝票によって違う期日に並ぶ（SAPのマスタデータが稼働後に劣化する原因と、登録権限と責任部門の決め方）。
三つ目は、得意先が合意した条件どおりに払っていない場合である。 条件は正しく登録されていても、大口の得意先が自社の支払の周期で払い、毎回10日遅れる。マスタを直しても、これは当たらない。遅れが恒常的なら、営業が条件を交渉し直すか、合意した条件で払ってもらうよう督促するかを決める。 決めずに予測の側で遅れを補正すると、遅れが正式な条件のように扱われ、延滞の管理がゆるむ（売掛金の督促は営業と経理のどちらが担うか、経過日数で担当を移す設計）。
受注の入金予定は、営業の見込みのままでは使えない
未決済の債権と債務で予測できるのは、おおむね支払サイトの長さまでである。月末締め翌月末払いが中心の会社なら、請求済みの債権だけで見通せるのは1か月から2か月先までになる。 その先を埋めるのが、受注と発注から取り込む予定のキャッシュフローである。
受注から入金を予測するには、出荷の予定日、請求の予定日、支払条件の三つがそろっている必要がある。 量産品の受注で納期の回答が正しく入っていれば、この三つは比較的信頼できる。問題になるのは、受注の段階で納期が仮の日付のまま入る品目や、検収で請求が決まる個別受注の案件である。営業が受注を登録するときに、客先の希望の日付や、期末に間に合わせたい日付を納期に入れていれば、予測の先の方は営業の希望の並びになる。 検収の遅れで請求が一か月ずれれば、入金は一か月以上ずれる。
直し方は、日付の責任者を決めることである。 出荷の予定日は生産管理や物流が回答した日付にし、営業が手で上書きできないようにする。検収で請求が決まる案件は、検収の予定日を案件の担当者が月次で見直し、見直した日付を受注の明細に反映する。見直されない受注は、予測から外すか、別の流動性項目に分けて、確度の低い流れとして区別する。 確度の違う流れを一本の線に足してしまうと、予測が外れたときに、どの流れが外れたのかを追えない。
伝票に現れない流れも、同じ画面に入れておく。 法人税や消費税の納付、賞与、配当、借入の返済、設備投資の支払は、債権や債務の明細になる前に日付と金額がほぼ決まっている。これらはメモレコード（伝票によらない予定の入出金を手で登録する機能）で入れる。金額の大きいこうした流れが抜けた予測は、どれほど債権の期日が正確でも、残高の予測として使えない。 月中の納税や賞与の支給が資金の谷を作る仕組みは、13週キャッシュフロー予測の作り方、月次の資金繰り表では見えない月中の谷で扱った。
精度は、時期のずれと金額のずれに分けて測る
導入の効果は、予測が当たるようになったかどうかで測る。 感覚で判断してはいけない。半年後に冒頭の会社と同じ状況になる。
測り方は、毎週の予測を保存し、実績と比べることである。 1週先、4週先、8週先の予測を、それぞれの週が来たときの実績と比べ、差を流動性項目ごとに記録する。そのうえで、差を二つに分ける。一つは時期のずれで、入金や支払そのものはあったが、予測した週とは別の週に来たものである。 もう一つは金額のずれで、予測になかった入出金や、予測した金額と違った入出金である。
時期のずれは、入力の側の問題であることが多い。 支払条件のマスタか、受注の日付か、得意先の支払の遅れのどれかに戻せる。金額のずれは、予測の範囲の外にあった流れを示していて、メモレコードの漏れか、伝票になっていない取引の存在を示す。二つを混ぜて精度を一つの数字で出すと、どこを直せばよいのかがわからない。
エクセルの資金繰り表と並べて比べる期間も決めておく。 3か月ほど並行し、4週先の予測の外れ方がエクセルと同じ水準まで下がった時点で、エクセルの集計を止める。止める日を決めずに並行を続けると、二つの表のどちらが正しいかの説明に、財務の担当者の時間が使われ続ける。
それでも表計算を残す領域と、SAPに任せる領域
SAPの流動性予測が得意なのは、伝票になった取引の日付を、漏れなく正確に並べることである。 支払条件と受注の日付が直っていれば、1か月から2か月先までの予測は、人がエクセルで集めるより速く、漏れも少ない。銀行の入出金明細を取り込めば、当日の口座残高と合わせた現金の位置も同じ画面で見られる。
苦手なのは、伝票になる前の判断を含む予測である。 半年先の売上の見込み、新しい借入の実行の時期、為替の前提を変えたときの資金の動きは、伝票からは出てこない。ここは計画の領域で、SAP Analytics Cloudのような計画の道具か、エクセルで持つことになる。このとき、計画の起点となる足元の数字は、SAPの予測から取る。 足元をSAPから取り、先の方の前提だけを人が置く形にすれば、二つの表の数字を突き合わせる作業はなくなる（SAP Analytics Cloud（SAC）で計画と実績を一つのモデルにつなぐ進め方）。
グループで資金を集中している会社では、子会社の予測も同じ仕組みに載せたくなる。その前に、子会社の支払条件のマスタと受注の運用が、親会社と同じ水準にあるかを確かめる。 子会社のマスタが古いまま集約すれば、グループ全体の予測は子会社の分だけ外れる（CMS・キャッシュプーリングの導入判断、効果が出る会社の三条件）。
産業機械の部品メーカー（売上高480億円、3月決算）。S/4HANAの稼働の翌年に資金管理の機能を入れたが、4週先の残高の予測は、エクセルの資金繰り表より平均で2億円ほど大きく外れていた。 財務部が過去1年分の消込済みの債権を得意先別に集計すると、入金額の上位50社のうち18社で、支払期日と実際の入金日が15日以上ずれていた。原因の多くは、月末締め翌月末払いや20日締め翌月10日払いの得意先に、請求日から30日や60日の支払条件が付いていたことだった。 移行のときに、旧システムの80種類の支払条件を25種類に絞った名残である。さらに7社は、会社コードの側だけ条件を直し、販売エリアの側が古いまま残っていた。経理と営業管理で、締め日と支払日を日付で持つ支払条件を作り直し、両方の単位の条件をそろえた。 受注の出荷予定日は、生産管理が回答した日付以外を入れられないようにし、検収で請求が決まる設備の部品の案件は、担当者が月初に検収予定日を見直すことにした。納税と賞与と借入の返済はメモレコードで入れた。4か月後、4週先の予測の外れは平均で6,000万円まで縮み、エクセルの資金繰り表の集計は止めた。 各事業部から見込みを集める2日の作業は、半日の見直しに変わった。
※設例。会社、数値は説明のために置いた架空のもので、特定の会社の実績ではない。
導入の前に決める三つ
第一に、予測の精度を決めるのは伝票の日付だと認める。 流動性予測の計算は、支払期日と予定日を並べるだけである。消込済みの明細で、支払期日と実際の入出金日のずれを取引先別に測ることから始める。
第二に、支払条件のマスタと受注の日付を直す。 締め払いを日数で近似した条件をやめ、会社コードと販売エリア、購買組織の単位の条件をそろえる。出荷と検収の予定日には責任者を置き、見直されない受注は予測から分ける。
第三に、精度を時期のずれと金額のずれに分けて週次で測り、エクセルを止める日を決める。 伝票にならない判断を含む先の方の計画は、SAPの予測を起点に別に持つ。
