キャッシュフロー予測：13 週ローリング予測法

このガイドでは、会社の流動性を管理するための、CFO グレードの簡単な方法を紹介します。13 週ローリングキャッシュフロー予測を構築することで、週ごとのキャッシュランウェイを把握し、戦略的に入金と支払いを管理し、財務上の不測の事態を回避できます。これは、Beancount レジャーと完全に連携して動作する、創業者向けに構築されたシステムです。

なぜ 13 週なのか？​

13 週予測がオペレーショナルキャッシュマネジメントのゴールドスタンダードである理由はいくつかあります。

• 短期的なコントロール： 約 1 ビジネス四半期をカバーし、直近の流動性を明確に把握できます。この期間は、2 ～ 3 回の給与サイクル、税金の納付、および一般的なベンダーの支払い条件を含むのに十分な長さですが、非常に正確で実用的な状態を維持できるほど短いです。
• 入金と支払いのビュー： この予測は「直接法」を使用し、現金の入金と支払いにのみ焦点を当てています。これは発生主義会計や収益性に関するものではなく、実際に銀行口座に入金または出金される金額に関するものであり、予測が銀行残高に直接結び付くようにします。
• ローリング方式、静的ではない： これは 1 回限りの予算ではありません。毎週、直近の 1 週を削除し、最後に新しい 1 週（13 週目）を追加して、仮定を更新します。これにより、将来の見通しが一定に保たれ、予測が動的な週次業務になります。

構築するもの​

1. 単一のスプレッドシート： システムの中核は、13 個の列（1 週目から 13 週目まで）と明確に定義されたセクション（期首現金残高、入金、支払い、純現金、期末現金残高）がある 1 つのシートです。
2. カテゴリマッピング： レジャーからのトランザクションを予測カテゴリにマッピングする簡単なシステム（例：Stripe からのすべての支払いは「顧客からの入金」にマッピングされ、Gusto からの支払いは「給与」にマッピングされます）。
3. 週次のリズム： 予測を更新し、差異（予測対実績）を追跡し、財務上のしきい値に達した場合にアクションを実行するための事前定義されたトリガーのセットを備えた、再現可能なプロセス。

構成（必要な行）​

すべての現金の動きを把握するために、予測シートは次の行で構成する必要があります。

• 期首現金残高（これは前の週の期末現金残高と一致する必要があります）

• 入金（現金の流入）

  • 顧客からの入金： 既存の請求書（売掛金）から回収する予定の現金。
  • 新規予約 / 前払い： 13 週間のウィンドウ内で成立する新しい取引から予想される前払い金。
  • その他の流入： 税金の還付、利息収入、助成金など、その他に入ってくる現金。

• 支払い（現金の流出）

  • 給与： 従業員への正味給与とすべての雇用者側の給与税を含む、現金の総費用。
  • 請負業者とフリーランサー： 従業員ではない人への支払い。
  • クラウド/ホスティング（売上原価）： AWS、GCP などの主要なインフラストラクチャコスト。
  • SaaS / ツール： すべてのソフトウェアサブスクリプション。
  • マーケティング： 広告費、代理店手数料、その他のブランド関連費用。
  • 賃料 / オフィス： 物理的なオフィスの費用。
  • 法務および会計： 専門サービス料。
  • ハードウェア/設備投資： ラップトップやその他の機器の購入。
  • 売上税の納付： 政府機関への徴収された売上税の支払い。
  • 債務返済： ローンに対する元本と利息の両方の支払い。
  • 一時的な費用： 年間の保険料や保証金など、まとまった金額の不定期な支払い。

• 純キャッシュフロー（= 総入金 - 総支払い）

• 期末現金残高（= 期首現金 + 純キャッシュフロー）

ローリングの仕組み（これらの数式をコピー）​

ローリング予測のロジックはシンプルで強力です。

• 期首現金 (n 週目) = 期末現金 (n-1 週目)
• 純現金 (n 週目) = Σ 入金 (n 週目) − Σ 支払い (n 週目)
• 期末現金 (n 週目) = 期首現金 (n 週目) + 純現金 (n 週目)

毎週月曜日の朝のリズム：

1. ウィンドウをローリング： 予測全体を 1 週間進めます。古い 2 週目が新しい 1 週目になります。直近の 1 週を削除し、最後に新しい 13 週目を追加します。
2. 実績で更新： 先週の予測を、銀行とレジャーからの実際の現金の動きに置き換えます。
3. 将来を再見積もり： 今後 2 ～ 4 週間の予測を、最新の情報（新しく送信された請求書、今後のベンダーへの支払い、確定した給与日）で更新します。

Beancount から予測へのマッピング​

• 現金の実際額のソース： 週次の実際額は、Assets:Bank:* へのすべての転記と Liabilities:CreditCard:* からの支払いの合計を、日付でグループ化したものです。
• 入金カテゴリ： Stripe、PayPal などからの支払いを「顧客からの入金」行にマッピングします。非営業の流入を「その他」にマッピングします。
• 支払いカテゴリ： ベンダーから予測バケットへの簡単なマッピングを作成します。たとえば、AWS と GCP は「クラウド/ホスティング」に、Gusto または ADP は「給与」に、法律事務所は「法務/会計」にマッピングします。
• 売上税の処理： 売上税は収益ではありませんが、キャッシュフロー項目です。売上税の徴収を現金の入金として扱い、政府への納付を支払いとして扱います。収益への影響は発生主義会計の本に記載されていますが、現金の動きはここで重要です。

ヒント： スプレッドシートに小さな「ベンダーマッピング」タブを保持します。これにより、ベンダーへの支払いを毎月一貫して分類できます。これは、正確な差異分析に不可欠です。

更新リズム（毎週 30 ～ 45 分）​

1. 実績の取得 (15 分)： 銀行およびクレジットカード口座からトランザクションをダウンロードします。前の週の「期末現金」が実際の銀行残高と完全に一致することを確認します。この調整は必須です。
2. 売掛金のレビュー (10 分)： 未払いの請求書をすべてリストアップし、支払いが見込まれる週に割り当てます。控えめに見積もり、過去の実績に基づいて現実的な回収遅延を適用します。
3. 買掛金と給与のレビュー (10 分)： 既知の今後の請求書の期日を割り当てます。四半期全体の給与日と金額を事前に入力します。週中に現金のオプションを維持するために、重要でない支払いは金曜日に実行するように準備します。
4. 差異会議 (10 分)： 先週の予測と実際の結果を簡単に比較します。重大な差異の原因をメモし、今後の予測ルールを調整する必要があるかどうかを判断します。

精度と意思決定​

精度に関する経験則​

• 1 ～ 2 週目： ±5 ～ 10% の誤差を目指します。これらの日付と金額は非常に確実である必要があります。
• 3 ～ 6 週目： ±10 ～ 20% の誤差を予想します。この期間は、既知の請求書とパターンベースの見積もりが混在します。
• 7 ～ 13 週目： 予測のこの部分は方向性を示します。これは、販売パイプラインとランレート費用によって左右されます。

信頼度コード： 予測を読みやすくするために、各予測行に信頼度コードをマークします。確実 (例: 給与、賃料)、可能性が高い (例: 優良顧客への請求書)、または アップサイド (例: パイプラインからの新しい取引)。

トリガーとアクション（事前に決定）​

計画なしの予測は役に立ちません。特定のしきい値に達した場合のアクションを事前に定義します。

• 最低現金下限： たとえば、「常に次の満額の給与額の 1.5 倍以上の現金を維持する必要がある」というルールがあるとします。予測でこの下限を下回ることが示された場合は、直ちに、事前に合意された計画（回収スプリントやすべての裁量支出の一時停止など）を実行します。
• ランウェイガードレール： たとえば、「13 週目の期末現金が X か月未満のバーンを示唆している場合は、資金調達計画を開始する」とします。これには、タームシートの取得、収益の前払いのための顧客への割引の提供、またはクレジットラインの利用が含まれる場合があります。
• 大規模な流出ルール： たとえば、「現在の現金残高の 5% を超える単一の非給与の支払いは、2 週間前に承認され、フォールバックプランが必要である」とします。

テンプレートとシナリオ​

シンプルなカテゴリセット (シードステージ SaaS 向け)​

• 入金： 顧客からの入金、その他の流入 (利息、払い戻し、助成金)
• 支払い： 給与 (正味 + ER 税)、請負業者、クラウド/ホスティング (売上原価)、ソフトウェア/SaaS (OpEx)、マーケティング (有料/ブランド)、賃料/オフィス、法務/会計、税金と手数料、債務返済、一時的な費用/年間費用
• 計算： 純現金、期末現金

テンプレート（スプレッドシートにコピー）​

各列に週の開始日 (例: 2025-08-18、2025-08-25 など) のラベルを付けます。ヘッダー行と最初の列を固定します。

シナリオトグル (軽量に保つ)​

複雑なモデルを作成せずに、簡単なシナリオプランニングを構築できます。主要なドライバーのシートの上部に「トグル」セルを追加します。次に例を示します。

• 回収日数トグル：[1.0] (コレクションの 20% の減速をモデル化するには、1.2 に変更)
• 新規予約トグル：[1.0] (計画と比較して 20% のミスをモデル化するには、0.8 に変更)

関連する予測行にこれらのトグルを掛けて、影響を確認します。

学習と間違いの回避​

差異追跡 (学習を組み合わせる)​

直近の週に、「先週の予測」と「実績」の 2 つの列を追加します。差異を計算します。レビューするときに、大きな違いの理由 (回収の遅延、範囲のずれ、計画外のベンダーの購入、タイミングのずれ) にタグを付けます。同じタイプの差異が繰り返される場合は、モデルの基礎となるルールを変更します。たとえば、コレクションが常に 1 週間遅れている場合は、デフォルトのコレクション遅延の仮定を 21 日から 28 日に変更します。

よくある落とし穴（避けるべきこと）​

• 発生主義と現金の混同： この予測は 現金のみ を対象としています。認識された収益、減価償却、およびその他の発生主義の概念は、ここではなく、メインのレジャーに属します。
• まとまった年間の費用を忘れる： 年間の保険料、大規模な SaaS の更新、および四半期ごとの税金の支払いは、大きな驚きになる可能性があります。それらについて知ったらすぐに、予測にスケジュールします。
• 売上税の現金を無視する： たとえそれがパススルー負債であっても、現金は納付するまで銀行口座にあります。流入と流出の両方をモデル化します。
• 調整しない： 予測の期末現金が実際の銀行残高と一致しない場合は、マッピングエラーがあります。予測を信頼する前に修正する必要があります。
• 明確なオーナーがいない： 毎週予測を更新する責任を 1 人に割り当てます。休暇の代理人を指名します。

簡単な Beancount 連携​

• 勘定科目： 現金バケットをクリーンに保ちます (例: Assets:Bank:Checking、Liabilities:CreditCard:Amex)。これにより、毎週の実際額の取得が簡単になります。
• Fava チェック： Fava で interval: week を使用して損益計算書を実行し、予測されたバーンレートを最近の実際のバーンレートと照合して、正当性を確認します。
• ドキュメント： 大規模な一時的な項目がある場合は、請求書 PDF を Beancount の documents/ フォルダに添付し、予測のメモ列でリンクします。

取締役会/投資家向けパック (1 スライド)​

1. グラフ： 全 13 週間の週ごとの期末現金の簡単な折れ線グラフ。最低現金下限を示す水平線を追加します。
2. テーブル： W1 ～ W13 の期末現金の数値を示す小さなテーブルと、四半期に予想される上位 5 件の最大の流入と流出の箇条書きリスト。
3. メモ： 前回の更新以降に変更された主要な仮定と、発生した、または発生すると予想されるトリガーに関するいくつかの箇条書き。