「公司明明有營收，為什麼下週還可能付不出薪水？」常見原因不是沒有訂單，而是收款日比付款日晚。損益表上的收入，不代表銀行帳戶現在已有現金；只看月報，也容易漏掉兩個日期之間的空檔。這篇會帶你把已知收支排進13週預測表，再用延遲情境找出要提早處理的地方。13週是本文的教學範圍，不是每家企業都必須採用的標準。
先分清現金預測與損益預算
損益預算看一段期間預計有多少收入和費用；現金預測要回答的是：款項預計哪一天或哪一週進出企業帳戶？兩者相關，但時間口徑不同。假設公司六月底開出發票，客戶預計七月底付款，收入可能列在六月預算，現金則要排在七月預計入帳的週次。開票、成交或出貨，都不能直接當成已收款。
開始前先定義預測期間、納入的帳戶、幣別和資料截點，再逐筆核對客戶訂單、未收發票、付款條件與過往入帳紀錄，以及供應商帳款、排定付款和其他有憑據的支出。Microsoft Dynamics 365 Finance 的官方文件列出流動性帳戶、應收應付、訂單和付款時間等系統預測資料，可參考作為檢查欄位的外部工具範例；不必把它當成所有中小企業都要照搬的清單。Microsoft Learn：現金流量預測
把預算項目轉成預計收付日期、金額和資料來源。折舊等沒有現金進出的費用，不直接放進收付款欄；有對應實際付款時，才依付款日期列入。訂金、分期款、預收款或改期付款，都按各筆現金預計移動的時間拆開。日期或金額尚未確認的項目，要標示估計狀態和採用的假設，不要混成確定收入。若報價、訂單有不同版本，先確認有效版本；還在討論中的訂單，不算確定收款。
空白不等於零。資料不足時，標記「待補資料」、負責人和確認期限，並在延遲情境保留可能影響。交接資料至少要列出預算期間、預計收付日、金額、資料來源、確認狀態和負責人，讓接手者知道該追問客戶、供應商，還是回頭核對訂單與發票。
整理期初現金及收支日期
先訂預測起始日和期初餘額的基準時間，例如每週一開始前。列出納入的銀行與現金帳戶，核對銀行紀錄、帳上紀錄和未入帳款項。如果採用前一日結帳餘額，整份表都沿用同一基準；不要把不同日期的餘額加在一起，否則起點無法核對。
把可動用現金和暫時不能使用、或已有其他安排的款項分欄，並註明原因。未核准的融資額度和未撥入的借款，不是期初銀行存款，應列在備援方案，不要直接加進現金餘額。彙總多個公司帳戶時，帳戶間的內部轉帳要互相抵銷，避免同一筆錢被重複算成流入和流出。
接著整理已知交易。薪資、租金、分期款和供應商貨款，只有在公司資料能支持預計金額與日期時才列入；日期未定就留待確認，不要用習慣日期假裝確定。每筆交易最好有可追溯的識別資料，例如發票號碼、訂單編號或付款批次，避免同一張發票在應付清單和付款排程各算一次。
固定週期款項要核對最近一次實際付款與下一期日期。水電、物流或佣金等浮動金額，註明估算依據和目前區間。已付款但尚未從銀行扣帳的款項也要標示，以免在實際餘額和待付款清單重複計算。欄位可包括預計收付日、週次、項目、流入或流出、金額、幣別、憑據、狀態、負責人、實際日期、實際金額和異動原因。
日期未確認時，記下暫估日期及判斷依據，再指定誰要在何時確認。整理後的交接資料應包含期初基準日、帳戶範圍、不可混用的款項、已知交易和待確認清單；每筆數字都要能追溯到紀錄，或清楚標示為教學假設。
建立13週滾動收支表
先決定每週的起訖日，再排出未來13週。週期可配合公司習慣，但要前後一致，並留意月底、假日、薪資日或集中付款日落在哪一週。Oracle Cloud EPM 的產品文件將約12至26週列為一種中期現金預測範圍，並介紹每日、每週或每月的滾動預測；這是外部工具的設計情境，不代表所有企業都應採用相同範圍。Oracle：預測型現金預測概觀
每週用同一條算式：期初現金＋本週預計收款－本週預計付款＝期末現金。下一週期初現金，接續前一週期末現金。欄位可列週次與日期、期初現金、各類流入和流出、期末現金、與公司自訂基準的差額，以及本週變動的假設。追蹤多個帳戶時，可保留帳戶明細並另列合計，方便回查。
先填日期與金額較可靠的項目，再補上未確認交易。每筆收付款放在預計實際發生的週次；跨月不必換算法，跨週則依合約或有依據的付款安排拆分。一張訂單分三期收款，就列三筆和各自週次；同一張發票不能每週重複填全額。季節性、停工或大筆採購，只有在企業紀錄或已確認計畫支持時才納入，並註明依據。
跨出13週範圍的已知款項，先把落在預測期間的部分列入；期外應付款可記在備註，供下一輪移入。也別因表格只看13週，就漏掉已知的第14週大額付款。用上次預測對照實際收付，還能看出月底延遲是否反覆發生。
填完後，檢查每週期初是否接上前週期末、公式有沒有漏掉負數、收付款是否重複，以及估計值是否清楚標示。交接表應包含第1至第13週收支、期初與期末餘額、假設和資料負責人。若公司還沒設定最低現金比較線，先呈現預測餘額，不代替管理者訂出通用安全數字。
用教學假設比較基本與延遲情境
以下只示範計算，不是客戶案例或企業成果預測。假設期初現金為NT$300,000，第2週預計收NT$200,000、付NT$160,000，第3週付NT$210,000；其他週沒有新增收支，也不計利息、融資、稅費或其他現金項目。表格列每週期末現金，單位為NT$1,000。
| 情境 | 第1週 | 第2週 | 第3週 | 第4週 |
|---|---|---|---|---|
| 基本：第2週收到款項 | 300 | 340 | 130 | 130 |
| 延遲：收款延至第4週 | 300 | 140 | -70 | 130 |
基本情境第2週期末為300＋200－160＝340，第3週再減去210，期末為130。延遲情境只改一個條件：NT$200,000從第2週延到第4週。第2週變成300－160＝140，第3週再付210後為-70，第4週收到200後回到130。這個負數表示在教學假設下，該週收付時間不相配，不代表公司帳戶已出現實際負餘額。
比較自家情境時，先固定期初現金、已知付款和其他假設，再一次只改一個主要條件，例如某筆客戶款晚兩週入帳，或只收到部分金額。付款日也可能變動時，另列一個清楚標示的情境；一次改太多條件，就看不出餘額差異由哪筆交易造成。交接時保留兩種情境的逐週餘額、變動假設、資料來源和待確認負責人。收款日期若未核實，仍要留在延遲情境觀察。
保留變動前的基準，並註明假設來自內部估算、客戶確認或文件。若一筆收款拆成兩筆，列明各自日期與金額，確認加總仍等於未收餘額。不要為了讓期末數字好看，就把收款提前或刪掉付款。
找出缺口並安排可執行選項
先由企業設定現金比較基準，再找出第一個低於基準的週次。差額可用「比較基準－預測期末現金」計算。若公司採用零作基準，上例延遲情境第3週期末為負NT$70,000，差額就是NT$70,000；若另設營運緩衝額，就用公司自己的數字，不把單一門檻套用到所有企業。
找到週次後，先查原因：收款延後、付款提前、漏列或重複計算，還是資料尚未確認。將已證實金額和估計金額分開，回頭核對訂單、發票、銀行紀錄或付款排程。預測低於比較線是需要處理的訊號，不代表資金短缺已實際發生。
待辦清單可列負責人、確認期限、影響週次、估計金額、依據和所需同意。例如確認客戶預計付款日或是否分批入帳；與交易對象協調付款日期前，先核對原約定與內部授權；檢視非必要支出的時點時，也寫清楚可能影響。銀行額度屬於外部金融服務，須另外確認核准、費用、動用和還款條件；尚未確認能取得的資金，不列為確定流入。
先處理時間最近、影響最大的缺口，再依序確認可由內部更正的資料、需要對外協調的日期，以及待管理者核准的決定。行動尚未取得同意或回覆時，列為待辦，不要當成已完成；取得新資料後再看預測是否回到比較線以上。
交接結果應是一份依缺口週次排序的待辦表，分別標記「已確認」、「待協調」和「尚未決定」。每項待辦都要有期限和回填欄位；對方尚未確認時，保留原本較保守的情境，等有新資料再更新。
每週更新實收實付與預測差異
每週更新前先保留上一版預測，並取得期間內實際收付款的日期和金額。用銀行紀錄、收付款憑據及負責人確認的資料逐筆比對，記下差異是日期延後、實收金額不同、新增或漏列交易，還是原始資料有誤。不要用實際值直接覆寫舊預測，否則日後無從追查偏差何時開始。
已發生的收付款改填實際日期與金額；未來項目則重新確認日期、金額和狀態。若只收到部分款項，把未收餘額留在未來週次，並標記新的依據。某客戶多次晚於預計日期付款，可據此調整該客戶後續的情境假設，但不要把單次延遲套用到其他客戶。
每週結束後，把預測視窗往前推一週，新增第14週，持續保留未來13週。記下更新時間、資料來源、修改人、前版預測、實際差異、修改原因和未確認事項，讓接手者分得清哪些是已發生的事實、哪些仍是估計，以及誰負責確認。Microsoft 官方文件說明可定期重算預測；Oracle 官方文件也介紹實際值與滾動預測的比較。這些是外部工具功能範例，也可依現有表格和資料流程執行，不必因此採用特定軟體。
差異紀錄可同時保留金額差異和週次位移，例如原預計第2週收款、實際移到第3週；每筆只記一次，並連結更新後的未收餘額。若每週都發現同一來源缺資料，就把補資料工作交給來源負責人，避免下一輪繼續猜。
每週更新的重點，是讓預測跟著最新收付資料前進，而不是追求每筆都猜中。守住一致的帳戶範圍、日期口徑和紀錄方式，再把偏差轉成下一週要確認的問題。需要把方法套用到自己的企業時，可完成官方商戰思維測驗，或了解工作坊。