Base、Upside、Downside 三個版本都做了，Downside 最低現金還有 11。如果公司現在有 30 單位的 usable cash，自己設定的最低安全線是 8，這張表看起來很容易讓人放心。

問題是，11 只證明「這一條 Downside 沒有跌破 8」。它沒有告訴你需求、價格與收款一起惡化時會怎樣，也沒有告訴你在現金碰線之前，管理層到底還剩多少時間可以動作。

這篇沿用同一家公司、同一組 driver，把 Forecast、Scenario、Sensitivity、Stress Test 和 Reverse Stress Test 放回各自該做的工作。所有數字都是 synthetic teaching data，不代表任何特定公司的實際資料。要找的不是一個更悲觀的數字，而是四件事：什麼先壞、哪裡會翻面、什麼條件會穿過現金邊界，以及行動最晚什麼時候要開始。

Forecast 只是其中一條路，不是整張不確定性地圖

Forecast 是 expected path。它回答的是：照目前最合理的資訊，接下來大概會怎麼走。前面把 AOP、Budget、Forecast 拆開，就是因為它們本來就不是同一份數字換名字；到了 Scenario 也一樣，不能要求 Forecast 順便包辦所有不確定性。

幾個方法其實可以直接按「工作」分開看：

方法它要回答的問題
Forecast目前最合理的 expected path 是什麼？
Scenario一組互相連動的假設一起改變時，會形成什麼替代路徑？
Sensitivity一個或少數 driver 改變，結果會動多少？
Stress Test在刻意不利的 hypothetical path 下，公司撐不撐得住？
Reverse Stress Test先定義失敗，再倒推哪些組合會把公司推過那條線？

最常被混在一起的是 Downside 和 Stress Test。美國聯準會的 stress-testing scenario 文件會直接標示這些情境是 hypothetical scenarios, not forecasts。銀行監理和一般公司的情境不同，但這個方法邊界很好用：Stress Test 不是「猜一個最可能發生的壞未來」，而是故意把公司推進一個足以暴露 vulnerability 的狀態。

因此，Base、Upside、Downside 就算各自放在不同 tab，只要本質仍是同一份 Forecast 乘上幾個比例，得到的還是三條數字線，不是完整的 uncertainty map。

Downside 不是把營收乘 0.9，而是讓假設一起動

先把這家公司的 baseline 放出來。Volume 與 price/mix 用 index 表示，避免教學模型被不必要的金額細節淹沒。

DriverBaselineOrdinary DownsideSevere Stress
Demand / volume index1009082
Realised price / mix index1009794
Gross margin45%40%35%
Collection timing / DSO45 days60 days75 days
Fixed-cost response不需要6 週後開始6 週後開始，初期效果有限

Ordinary Downside 裡，需求從 100 掉到 90，但模型沒有停在 Revenue × 0.9。需求變弱時，mix 或折扣可能一起惡化，gross margin 會受到影響；客戶付款拖慢，DSO 從 45 天拉到 60 天；薪資、租金、系統費等 fixed cash cost 則不會跟著需求即時消失。

這才是 Scenario 和 one-way sensitivity 的分界。Sensitivity 可以只問「price/mix 少一點會怎樣」；Scenario 則必須讓幾個假設彼此說得通，而且一路穿過營運模型與 cash model。TCFD 的 scenario-analysis 技術文件原本用於氣候風險，但其中對 coherent assumptions 與 driver interdependencies 的要求可以借來當方法論。借的是建模紀律，不是把氣候揭露義務套到一般公司。

所以 Revenue -10% 當然可以留下，它對局部問題很有用。只是不要因為那格數字被放在 Downside tab，就誤以為公司已經測過一條真正的替代未來。

先找哪個值會讓決策翻面

接著不用急著談機率。先看哪一個值會讓管理層開始改變行動。

Baseline 的六個月 projected cash trough 是 18。公司另外設一條 management decision line：只要 projected trough 低於 12，就開始準備 contingency。這條線比最低現金 8 高，因為「該準備」和「已經快撐不住」本來就是兩件不同的事。

把其他條件先固定在 baseline，可以得到兩個簡單的 switching values。Realised price/mix index 從 100 降到約 95 時，projected trough 會逼近 12；DSO 從 45 days 拉長到約 63 days 時，也會碰到相近的決策邊界。

這些數字描述的是 headroom，不是 probability。從 100 到 95 的距離，不能翻譯成「跌 5% 的機率」；63 天也不是某種自動生成的風險機率。英國 Department for Transport 的 uncertainty toolkit 用 switching values 來測 robustness，看的正是「結論在什麼點改變」。離那個點多遠，只能說明決策還有多少餘裕。

Break-even 也要放在同一個邏輯下看。公司可以在會計上接近損益兩平，卻因為收款慢而先碰到流動性問題。損益沒有先壞，不代表現金也有同樣的耐受度。

Stress Test 問的是公司撐不撐得住這條惡化路徑

現在把幾個 driver 一起往不利方向推。Basel Committee 的 stress-testing principles 會要求 adverse conditions、material risks 與 scenario consistency。它是銀行監理框架，這裡只借用測試紀律，不把銀行的監管義務改寫成一般非金融公司的規定。

模型跑出三條 usable closing cash path：

時點BaselineOrdinary DownsideSevere Stress
Opening303030
Month 1282624
Month 2262219
Month 3231713
Month 421147
Month 519116
Month 618129

這裡的 cash 不是帳上看到多少就全部算進來。真正要放進 runway 的，是需要時可以動用的 liquidity。受限制的現金、卡在其他 legal entity 的資金、已承諾給近期待付款的部位，或日常營運一定得保留的 cash，都可能讓 headline cash 高於真正可用的數字。

最低安全線 8 也不是一條通用公式。這家 synthetic company 把它當 operating/risk boundary；真實公司要把固定付款、現金流波動、融資可得性、資金限制與營運彈性一起算進去，不能套一個「幾個月 burn」就結束。

Ordinary Downside 的 trough 是 11，所以原本那句「Downside 沒破線」沒有錯。Severe Stress 則不同：Month 4 已經降到 7，Month 5 最低 6。更麻煩的是，管理行動不是模型裡可以瞬間切換的開關。Cost plan 約要 6 週才會對現金產生實質效果；新的 liquidity action 從正式啟動到資金可用，約要 8 週。

也就是說，不能等 cash 跌到 8 才寫一句「refinance」或「cut costs」讓模型自己救回來。AFP 與 Deloitte 對短期 cash forecasting 的實務材料之所以重視 13-week view，就是因為壓力下需要看收款、薪資、稅、固定付款、一次性支出與 financing event 的實際時間點，而不是只拿歷史平均 burn rate 推 runway。

對這條 Severe Stress 而言，結論很具體：如果沒有額外 liquidity intervention，公司會在 Month 4 穿過 8，並在 Month 5 觸及 6 的 cash trough。

三條可用現金路徑比較圖：Baseline 與一般 Downside 都維持在最低現金 8 以上，但 Severe Stress 在第 4 個月跌破 8、第 5 個月觸底 6；決策觸發線設在 12，並標示成本行動約需 6 週、流動性行動約需 8 週。

Reverse Stress 從失敗開始往回找

Forward stress 是先選 adverse scenario，再看模型會不會失敗。Reverse Stress 不從「多壞算夠壞」開始，它先鎖失敗條件。

這家公司把 failure condition 定成：

在 planned liquidity action 能真正生效之前，usable cash 已經跌破 8。

假設 Month 1 結束時啟動 liquidity action，正常 lead time 是 8 週，資金最快約在 Month 4 初期可用。Reverse Stress 就往回找：哪些需求、price/mix、收款與 action delay 的組合，會在那之前把 cash 壓到 8 以下？

CombinationVolumePrice / mixDSOCost-action delayMonth 3 usable cash
A809472 days6 weeks7.6
B849688 days6 weeks7.8
C869368 days10 weeks7.5

A、B、C 都是 breaking combinations，但它們不是 forecast，也不是 10%、20%、30% 這種機率權重。它們證明的是另一件事：公司不只一種方式會在反應來不及之前破線，而且「我們測過一條很差的 Severe Downside」不能被拿來當成整個 business model 都安全的證明。

PRA 與 EBA 的 reverse-stress 材料來自 prudential regulation，其中 failure-first 的思路很適合移植到企業策略財務：先定義 business model 在什麼狀態下變得 unviable，再往回找原因。監理要求本身不跟著移植，這裡仍然是方法借用。

邊界要接上 Trigger、Owner 與 Action

如果最低現金是 8，卻等到 8 才開始處理，前面算出的 8 週 liquidity lead time 已經把答案寫死了：太晚。

所以這家公司的管理 trigger 放在 12。它不是第二條「安全公式」，而是故意留出執行時間的 decision boundary。13-week forecast 一旦顯示未來 cash 會跌破 12，管理層就開始動作，而不是等帳上真的只剩 12。

欄位設定
Observable signal13-week projected usable closing cash
Trigger threshold低於 12
Severe-path trigger timingMonth 1 結束時已經看到未來 13 週會跌破 12
OwnerCFO，Finance 負責 cash forecast，Operations 負責 cost action
Liquidity action立即啟動預先準備的 liquidity package，目標增加 7 單位可用資金
Cost action啟動已預先定義的 cost plan，約 6 週後每月改善現金 1.5
Liquidity lead time約 8 週
Prerequisites最新 13-week forecast、board approval path、lender/investor data pack、collection action list
Escalation若 projected cash < 10，或 action schedule 延誤超過 1 週，升級至 CEO + Board / Finance-Risk forum
Expected effect在 Severe Stress 穿越 8 之前增加 liquidity headroom，並讓後續月度 cash burn 下降

這張卡把前面的分析接成一個可執行流程。Switching value 告訴我們 threshold 在哪；cash forecast 和 minimum cash 告訴我們還剩多少時間；liquidity planning 把 6 週、8 週這些執行延遲放回模型；governance 則處理誰負責、何時升級。FRC 關於 agreed escalation triggers 的 guidance 可以當治理 analogue，但正式情境是 UK corporate governance，不能改寫成所有公司的普遍法律要求。

「raise capital」、「refinance」、「cut costs」如果沒有 owner、前置條件、lead time 和可走的執行路徑，仍然只是 spreadsheet 裡的一句願望。Trigger 的價值就在於把 failure boundary 往前翻譯成管理動作。

用 Forecast Error 校準下一輪，而不是永遠 ±10%

模型跑完一次不代表 ranges 就可以永久固定。下一輪 Scenario 應該被 actuals 修正。

可以把迴圈寫得很簡單：

forecast → actual → error / bias / calibration → 更新 driver ranges 與 scenario assumptions → 重跑 switching values / stress / triggers

假設 collection timing 連續幾個 cycle 都比 forecast 慢，真正該改的是 DSO 的 baseline 與 downside range，不是機械式把 revenue 的 ±10% 再放大。如果 demand forecast 大致沒有 bias，但 realised price/mix 持續高估，下一輪就應把更多不確定性放在 price/mix，而不是平均灑在所有 driver 上。

評估 forecast 也不要只留一個「看起來很直觀」的指標。Hyndman 與 Koehler 指出，actual 接近零時，MAPE 可能變得不穩定甚至失去意義；而 forecast accuracy 要看 genuine、out-of-sample 的結果，不能拿模型已經看過的資料替自己背書。

如果 Forecast 本來就輸出 prediction intervals 或 quantiles，評估也要看 interval coverage、quantile performance 等與分布相符的結果，不能只抓 midpoint 算 error。不過這不會讓 Base / Upside / Downside 自動變成機率分布。Scenario label 要有 probability，仍然需要額外的 probabilistic modelling 與 evidential basis。

最後回到日常管理，其實只需要一直重問六件事：目前 expected path 是什麼；哪些 linked assumptions 形成另一條路；哪些 driver value 會讓決策翻面；adverse path 下 cash trough 距離最低可用現金多遠；哪些組合會在反應來不及前破線、哪個 trigger 能留出時間；actuals 回來後，又是哪一種 error、bias 或 calibration 問題該改掉下一輪假設。

這六個問題如果能由同一套 model 接起來，Scenario 就不只是 Forecast 的悲觀版本。它開始把不確定性、現金邊界和「什麼時候必須做什麼」放進同一個決策流程。

References