cash-flow-forecasting について
資金が実際に入出金される時期を基に、EC事業者がキャッシュフローを予測するためのスキルです。13週間のローリングモデル、チャネル別の入金遅延、シナリオ分析、主要プラットフォームのデータ取得方法を解説します。
主な機能
- 0113週間のローリング予測の作成
- 02チャネル別の入金時期の整理
- 03基準・悲観・楽観シナリオの作成
- 04プラットフォームの売上と入金データの収集
- 05支出と資金余力の計画
活用シーン
- 01在庫仕入れに使える資金の確認
- 02売上減少時の資金余力の試算
- 03マーケットプレイスの入金遅延への対応
- 04季節的な資金不足の把握
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ finsilabs/ awesome-ecommerce-skills --skill cash-flow-forecastingインストール後、Claude Code で/cash-flow-forecastingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
tile.jsonevals/13-week-cash-model-with-inventory-and-ou/criteria.jsontask.mdevals/multi-channel-revenue-to-cash-conversion/criteria.jsontask.mdevals/seasonal-revenue-forecast-and-cash-runwa/criteria.jsontask.md詳細
キャッシュフロー予測
概要
キャッシュフロー予測では、売上が認識されるタイミングではなく、実際に銀行口座へ資金が入金され、口座から出金される時期を予測します。Eコマース事業では、キャッシュと売上のタイミングに大きなずれが生じます。決済プロセッサーが資金を数日から数週間保留する一方で、在庫は販売される数週間前に購入して支払う必要があり、マーケットプレイスからの入金は隔週であったり、アカウント審査により遅れたりします。
このスキルでは、プラットフォームのデータを使った13週間のローリングキャッシュフロー予測の作成方法を説明します。販売チャネルごとの主な入出金タイミングの違いを把握し、スプレッドシートまたはBIツールで週次更新するシンプルなモデルを設定します。
このスキルを使う場面
- キャッシュポジションを管理し、事業を継続できる期間を把握したいとき
- 在庫を仕入れる計画を立て、購入資金を確保できるか確認したいとき
- 資金調達に備え、投資家に12~18か月分のキャッシュモデルを提示したいとき
- 売上不足のシナリオに対する事業のストレステストを行いたいとき
- Amazonで販売し、隔週の入金タイミングを管理したいとき
- 季節的なキャッシュフローの不足(第4四半期のピーク後に訪れる第1四半期の落ち込み)に備えたいとき
基本手順
ステップ1:プラットフォームから過去の売上データと経費データを取得する
予測を作成する前に、過去12か月分の実績データを集めます。プラットフォームごとのデータの取得先は次のとおりです。
Shopify
- 売上データ: Analytics → Reports → Sales over time に移動し、CSVにエクスポートします。日次/週次/月次の総売上、割引、返品、純売上を取得できます。
- 注文レベルのデータ: Analytics → Reports → Orders over time に移動します。将来の注文数の予測に役立つ、注文数とAOVの推移が表示されます。
- 財務サマリー: Analytics → Finances summary に移動します。任意の日付範囲について、総売上、割引、返品、請求した送料、純売上が表示されます。
- 入金: Finances → Payouts に移動します。Shopify Paymentsから銀行に資金が振り込まれた正確な日時と金額が表示されます。これは売上認識の記録だけではなく、実際の入金履歴です。
- 注文のエクスポート: Orders → Export に移動し、財務データを含むすべての注文をダウンロードします。詳細なスプレッドシートモデルの作成に使用します。
Shopify Paymentsの入金タイミング:
- 標準的な入金:取引から2~3営業日後
- Finances → Payout schedule で入金スケジュールを確認し、この遅れを入金モデルに反映します。
WooCommerce
- 売上データ: WooCommerce → Analytics → Revenue に移動します。日次/週次/月次の総売上、返金、クーポン、純売上、税金が表示されます。CSVにエクスポートします。
- 注文のエクスポート: WooCommerce → Orders → Export に移動し、決済方法、日付、金額を含む注文履歴をダウンロードします。
- 決済ゲートウェイの入金タイミング: 決済ゲートウェイ(Stripe、PayPal、Square)のダッシュボードで、入金履歴と通常の遅延を確認します。
- Stripe:通常2営業日
- PayPal:1~3営業日(新規アカウントでは変動する場合があります)
- 経費: WooCommerceでは経費を標準機能で追跡できません。会計システム(QuickBooks、Xero)または銀行明細から取得します。
BigCommerce
- Analytics → Store Overview に移動します。売上、注文、コンバージョンの推移が表示されます。CSVにエクスポートします。
- Analytics → Purchase Funnel と Analytics → Marketing で、売上の内訳を追加で確認します。
- BigCommerce's data export API を使うか、Stitch または Fivetran 経由で接続し、複数か月分の分析用に注文データをスプレッドシートまたはデータウェアハウスに取り込みます。
ステップ 2:チャネルごとの入金タイミングを把握する
最も重要なのは、売上が計上されてから現金が入金されるまでのタイムラグを把握することです。チャネルごとの入金タイミングを表にまとめましょう。
| チャネル | 通常の入金までの期間 | 備考 |
|---|---|---|
| Shopify Payments(クレジットカード) | 2~3 営業日 | Shopify の Finances → Payout schedule で設定します |
| Stripe(直接) | 2 営業日 | 設定可能です。毎日の入金にもできます |
| PayPal | 1~3 営業日 | 新規アカウントでは保留期間が長くなる場合があります |
| Amazon FBA | 14 日 | 2 週間ごとの支払いです。Seller Central → Payments を確認してください |
| Amazon FBM | 14 日 | 同じく 2 週間ごとのスケジュールです |
| eBay Managed Payments | 2 営業日 | eBay Payments ダッシュボードを確認してください |
| Walmart Marketplace | 14 日 | 月次の支払いサイクルです |
| 卸売/Net-30 | 30 日 | 請求日から支払い予定日までの期間です |
| 卸売/Net-60 | 60 日 | 貸倒率 2~5%を考慮してください |
| Buy Now Pay Later(Afterpay、Klarna) | 2~3 営業日 | BNPL プロバイダーは販売事業者にすぐ支払うため、顧客による入金の遅れはありません |
このタイミングをキャッシュインのスケジュールに反映します。 各週の売上予測について、その現金が実際に入金される時期を示す行を別に作成します。今週 Amazon で得た売上は、2 週間後に入金されます。
ステップ 3:13 週間のローリングキャッシュフローモデルを作成する
次の構成でスプレッドシート(Google Sheets または Excel)を作成します。毎週月曜日の朝に更新してください。
モデルの構成(週ごとに 1 列、13 週間先まで):
WK1 WK2 WK3 WK4 ... WK13
OPENING CASH BALANCE
OPERATING INFLOWS
+ Shopify Payments (2-day lag from prior week sales)
+ Amazon disbursement (bi-weekly; map exact dates)
+ PayPal settlements
+ B2B/wholesale payments (net-30 invoices due this week)
OPERATING OUTFLOWS
- Inventory purchases (PO payments due this week)
- Inbound freight & duties
- 3PL / fulfillment fees (typically billed weekly)
- Outbound shipping not passed to customer
- Marketing & ad spend (credit card charge date, not spend date)
- Payroll (exact pay dates)
- Platform/software subscriptions
- Rent & facilities
- Customer refunds (process in same week issued)
- Sales tax remittances (quarterly — schedule known dates)
NET WEEKLY CASH FLOW
CLOSING CASH BALANCE
キャッシュアウトのデータを取得する方法:
- 在庫の支払い: 仕入先ポータルまたは在庫管理システムから未処理の発注書を取得し、それぞれの支払期日を記録します
- マーケティング費用: 広告プラットフォームへの請求が確定する時期(通常は月次請求サイクル)をクレジットカード明細で確認します。Meta と Google は後払い、または請求額がしきい値に達した時点で請求します
- 給与: 給与システム(Gusto、ADP、Rippling)で正確な支給日を確認します
ステップ 4:ベース/悲観/楽観のシナリオを作成する
次の 3 つのシナリオを実行します。
| シナリオ | 売上の想定 | 目的 |
|---|---|---|
| ベースケース | 現在の推移(直近 4 週間の平均) | 日々の計画 |
| 悲観ケース | ベースケースの売上の 70~75% | ストレステスト。「どれくらいの期間、事業を継続できるか」に答えます |
| 楽観ケース | ベースケースの売上の 120~125% | 成長に向けた計画。「成長資金を確保できるか」を確認します |
重要なルール: 悲観ケースでは、売上の不足率に応じてキャッシュインを減らしますが、固定支出(給与、賃料、ソフトウェア)は減らしません。売上に応じて変動させるのは、変動費(売上原価、マーケティング、変動するフルフィルメント費用)のみです。これは予測で最もよくある間違いです。売上が落ち込んでも固定費はそのまま残るため、キャッシュポジションが大幅に悪化します。
ランウェイの計算: 悲観ケースで、期末現金残高が最低限必要な現金のしきい値(通常は固定運営費の 4~6 週間分)に達する最初の週を特定します。その週までの週数が、悲観ケースでのランウェイです。
ステップ 5:リアルタイムデータと連携し、自動更新する
Shopify
Shopify の組み込み Finances エクスポート(週次の定期実行)を使うか、次の方法で連携します。
- Shopify + Google Sheets: Sheets for Shopify アプリをインストールすると、注文と入金データをキャッシュフロースプレッドシートに自動で同期できます
- Shopify + Xero/QuickBooks: Xero または QuickBooks の Shopify 連携機能で入金データを会計システムに同期し、その後、会計ツールで予測を作成します
WooCommerce
- WooCommerce → QuickBooks(公式の WooCommerce QuickBooks プラグイン経由)または WooCommerce → Xero(WooCommerce Xero 拡張機能経由)で連携します
- Metorik を使って週次の売上データを CSV にエクスポートし、スプレッドシートのモデルに取り込みます
専用のキャッシュフローツール(すべてのプラットフォーム)
これらのツールは銀行、決済処理業者、EC プラットフォームに接続し、キャッシュフロー予測を自動で作成します。
- Float(floatapp.com):Xero/QuickBooks に接続し、13週間のキャッシュフロー予測に最適です
- Pulse(pulseapp.com):手入力と銀行データフィードに対応した、シンプルなキャッシュフローツールです
- Dryrun:より高度なツールで、シナリオモデリングに対応し、会計システムに接続します
- Runway(runway.com):より包括的な財務計画ツールで、QuickBooks/Xero に接続します
ベストプラクティス
- 毎週月曜日の朝に13週間の予測を更新します — 前週の実績で最も古い週の予測を置き換え、予測期間を1週間先に進めます
- 毎週、予測と実際の銀行残高を照合します — 予測と実際の期末残高に差がある場合は、差が拡大する前に原因を特定します
- Amazon の支払いタイミングを明示的にモデル化します — Amazon の隔週の支払いは、マーケットプレイス販売者にとって、キャッシュタイミングの予想外の変動をもたらす最大の要因です。今後13週間分の正確な支払日を記録します
- 最低限必要な現金残高を設定します — 事業運営に必要な最低現金残高を定義し、予測上の現金残高がその水準に近づいたら通知を受け取れるようにします
- 広告費の発生日ではなく、現金の流出日を追跡します — Meta と Google は月ごと、または一定の利用額に達した時点で請求します。インプレッションが配信された日ではなく、クレジットカードの支払日に現金が流出します
- 税金の納付を既知の支出として予定に入れます — 売上税の納付、四半期ごとの予定納税、VAT の支払いは予測可能です。モデルのカレンダーに登録します
よくある落とし穴
| 問題 | 解決策 |
|---|---|
| 売上と現金を混同する | 3月に計上した5万ドルの卸売請求書でも、Net-60 の条件では5月まで現金化されません。必ずタイミングの要素を別途モデル化します |
| 季節的な在庫積み増しを無視する | 7月〜9月の大規模な在庫支出(第4四半期分の在庫購入)は、ホリデーシーズンの売上が入る数か月前に資金の谷を生みます。在庫の支払いスケジュールを明示的に予測します |
| 返品を現金流出としてモデル化しない | 返金は在庫を回収する前に発生する現金流出です。返品率の高いカテゴリーでは、週次支出に返品用の現金準備を組み込みます |
| 広告費のタイムラグを考慮しない | 広告プラットフォームの月次クレジットカード請求は、請求期間の終了から数日後に決済されます。日々の広告費の発生日ではなく、カードの支払日を現金流出としてモデル化します |
| 単一の予測値しか用意しない | 必ず基本シナリオと弱気シナリオを実行します。基本シナリオだけを示すモデルは、誤った安心感を与えます |
| 一時的な支出を見落とす | 税金の支払い、保険の更新、ソフトウェアの年間契約、展示会費用は予測可能です。先々の予定表に追加し、モデルに反映します |
関連スキル
- @ecommerce-budgeting-forecasting
- @financial-reporting-dashboard
- @profit-margin-analysis
- @unit-economics-tracking
- @marketplace-fee-reconciliation