一間公司準備決定明年的招募速度。FP&A 手上有一套 18 個月的整合財務模型，營收從客戶數與價格往下推，headcount schedule 算人事費用，CAPEX 進折舊，working capital 連到應收與應付，debt schedule 再把借款、還款與利息帶回三張財報。公式正常，cash flow 能從期初現金走到期末現金，balance sheet 每個月也都平。
新版模型比前一版更樂觀。未來幾季的 closing cash 變高，融資時點可以往後移，公司似乎也有空間先把人招進來。
後來 reviewer 找到一個很小的改動：應收帳款天數從 60 天變成 45 天。這個 45 天沒有新的付款條件支撐，也不是客戶組合真的改善。它只是某次測試留下的數字，沒有回到 assumption register，沒有 owner、日期，也沒有 change reason。
模型沒有因此壞掉。A/R 下降得更快，operating cash flow 變好，closing cash 上升，balance sheet 還是平。問題落在決策：公司正在用一個沒有被證明的收款改善，替提早擴編和延後融資背書。
這類錯誤很難靠「公式有沒有算錯」抓出來。財務模型同時包含商業假設、時間關係、會計連動、模型狀態與使用情境。算術正確，只說明其中一部分沒有出錯。
真正要驗的是另一件事：一個沒有參與建模的人，能不能從結果一路追回重要假設，知道模型當時用的是哪一版資料與邏輯，並且有足夠資訊挑戰這個結果是否適合眼前的決策。
先把財務模型看成一套 Decision System
把 workbook 拆成幾個 worksheet，並不會自動得到一個可靠的模型。比較有用的看法，是把它當成一條決策鏈：商業判斷先進入模型，再經過 drivers、schedules 與 accounting links，最後變成 management 會看到的輸出。
可以用這條線先抓住整體位置：
Assumptions → Drivers → Schedules → Three Statements → Controls → Validation → Version / Change Control
ICAEW 的 Financial Modelling Code 強調 inputs、calculations 與 outputs 要有清楚的流向。原因很實際。當 business assumption 藏在公式常數裡、使用者可以直接覆寫 output、計算區又和輸入區混在一起時，reviewer 看到的是答案，卻很難重建答案怎麼形成。
以 60 天變 45 天為例，如果它被放在清楚的 assumption layer，至少應該連著幾個資訊：適用期間與客群、來源或判斷依據、owner、更新日期，以及哪些 outputs 會受它影響。45 天本身不是可疑數字；「不知道為什麼是 45 天」才是問題。
這也是模型 architecture 要和用途一起看。用來做低金額、可逆決策的小估算，不需要背著一整套正式 validation 流程。若同一份模型要支援 liquidity、financing、投資或董事會承諾，review burden 就不能停在公式檢查。英國政府的 The AQuA Book 也採相似原則：assurance 應該跟分析的用途、複雜度和可能造成的影響相稱。
所以模型的第一個 architecture 問題很簡單：重要判斷放在哪裡？誰能改？改了以後，哪些 calculations 和 outputs 會跟著動？如果這三件事追不到，後面的三表再漂亮也很難審。
假設不是備註，而是模型的一級資料
很多 forecast 的危險點不在公式。下面這行可以完全正確：
Revenue = Customers × Conversion × Average Price
但 reviewer 還是要知道 Customers 的起點怎麼來、Conversion 是歷史資料、pipeline judgement 還是 sales target、Average Price 用的是 list price、realised price 還是 blended ASP。若 scope、period 和 unit 都不清楚，公式的正確性幫不上忙。
對 material assumption，比較實用的最低要求是把 value、unit、period、scope、source、owner 留在可追溯的位置，並記錄它和哪些 driver 或 output 有關。需要定期更新的假設，還要有 refresh trigger；會大幅改變決策的假設，最好有人負責 challenge，而不是等結果看起來太奇怪才回頭查。
Driver-based planning 在這裡扮演的是 traceability 工具。它讓「營收成長 20%」這種單一 plug，被拆回可解釋的營運量與費率。收入可以來自 volume × price；人事費用可以由期初員工、招募、離職、到職月份、薪資與 on-cost 推導；working capital 則能和 sales、purchases、付款條件與收款行為連起來。
不過 driver 的名字本身沒有證據力。欄位叫「conversion driver」或「DSO driver」，不代表它真的符合公司的商業機制。它仍然需要資料、合約或營運經驗支持。這裡只借 driver-based planning 的一個功能：讓結果的因果路徑能被 review；更完整的 forecast methodology 留給系列中的預測篇。
回到應收帳款。60 天改成 45 天時，模型應該讓 reviewer 看得到這條路：
付款條件／客戶組合 → DSO → A/R schedule → working-capital movement → operating cash flow → closing cash / debt need
只要 45 天被直接寫進某個公式，這條路就斷了一截。輸出仍然可以合理，卻不容易看出究竟是哪一個 business judgement 讓現金增加。
三表不是三張各自預測的報表
Integrated three-statement model 的重點，在於 statements 從同一組 supporting schedules 長出來。若損益表、資產負債表和現金流量表各自 hard-code，最後再靠 plug 或 reconciliation line 把它們湊在一起，三張表放在同一個 workbook 也沒有真正整合。
Headcount 是最直觀的例子。公司準備擴編時，人事費用可以從 opening headcount、hires、leavers、start dates、salary 與 on-cost 往下算。這比在 P&L 直接填「salary expense +18%」多了一個重要能力：當招募時點改變時，expense 和 cash effect 會跟著合理移動。
CAPEX 需要另一種時間關係。買設備時 cash 先出去，depreciation 則在之後的期間進入 P&L。沒有 asset roll-forward，模型很容易只把 depreciation 當費用趨勢預測，卻沒有把 investment cash flow 和 balance sheet asset 接回去。
Working capital 本身就是 stock-flow 問題。應收帳款至少要能回到：
Opening A/R + Credit Sales - Cash Collections = Closing A/R
這個 roll-forward 會逼模型交代兩件事：收入什麼時候認列，以及現金什麼時候真的收進來。DSO 從 60 天變成 45 天，正是透過這個 schedule 把 timing 差異帶進 cash flow。
Debt schedule 常讓關係更難看清楚。Opening debt、drawdown、repayment、interest、fees 與 closing debt 互相牽動；若再加入 cash sweep，還可能形成 circularity：debt 影響 interest，interest 改變 profit 與 cash，cash 又回頭決定需要多少 debt。可以用 iterative calculation、average debt、opening-balance approximation 或其他方法處理，但方法必須被說明，也要有 cross-check。用 unexplained plug 把 circularity 藏起來，只是把不確定性藏在看似平衡的數字裡。
税、FX 與 debt 的 integration 也是同一類問題。IAS 7 提供 operating、investing、financing cash flows 的會計分類背景；IAS 12、IAS 21 則分別處理 tax 與 foreign exchange 的會計脈絡。模型不需要把準則變成教科書，但 schedule 和 statements 之間的 mapping 必須明確，否則 cash、tax、FX 或 debt effects 很容易在不同區塊被重複或漏掉。
最後，net income 要進 retained earnings，balance-sheet movements 要在 cash flow 裡留下對應，financing 與 investing activities 要回到資產與負債，closing cash 也要同時落在 cash-flow statement 和 balance sheet。做到這裡，balance 才有意義，因為它是 integrated logic 的檢查點，而不是一條用來修飾三張獨立 forecast 的公式。
Balance 只是第一道門，不是品質證明
Assets = Liabilities + Equity 很值得檢查。它能抓出 movement 只進一邊、roll-forward 沒有閉合、cash-flow link 斷掉等結構錯誤。但開頭那個 45 天 DSO 已經說明了它的邊界：A/R 可以合理下降，cash 可以合理上升，balance sheet 仍然完全平衡。
如果假設本身沒有證據，balance check 不會替 reviewer 判斷商業世界是不是突然變好了。同樣地，一個 sign error 可能被另一條公式抵消；付款時間點錯一個月，全年 total 仍可能接近預期；workbook 也可能因 calculation mode 或外部連結顯示 stale value。這些問題需要不同的 control。
實務上可以把 controls 混合使用，而不是期待一個綠燈包辦全部品質：
- reconciliation：balance sheet、cash roll-forward、opening + movements = closing；
- sign / range：不合理的負數、比例、日期或 unit；
- reasonableness：gross margin、tax rate、interest rate、DSO 等突然跳動時要求解釋；
- control totals：aggregation 或 mapping 後回到 authoritative total；
- model-state checks：data cutoff、approved version、recalculation state 是否正確。
45 天這個例子甚至可能通過 range check，因為 45 天本身很合理。更有效的檢查可能是 assumption change report、prior-version variance review，或 material assumption 沒有 source、owner、change reason 就不能進 base case。
Control 的設計因此要先從 failure mode 出發。若公司最怕的是未核准 assumption 悄悄進入 liquidity forecast，再多做一個 balance check 幾乎沒有幫助；需要的是讓 assumption change 本身留下痕跡。
Verification 與 Validation 問的是兩件事
The AQuA Book 把 verification 和 validation 都放進 analytical quality assurance，但兩者解的不是同一種風險。Verification 檢查模型是否照設計正確實作；validation 檢查方法和設計是否適合 intended use。
Forecast accuracy 是一個簡單例子。假設團隊選 MAPE，公式寫對、資料引用也對，verification 可以通過。若某些產品的 actual 常接近 0，percentage error 的 denominator 會把結果放大，actual 為 0 時甚至失去意義。Hyndman 與相關 forecasting 文獻一直提醒，accuracy metric 要配合資料特性使用。
這時 reviewer 要換一個問題：這個 metric 能不能回答管理者現在想知道的事？公式正確不等於 metric 適合。
財務模型裡也常出現同樣情況。45 天 DSO schedule 可能完全照設計運作，但 45 天和客戶合約、collection behaviour 對不上；debt schedule 可以精準算 interest，卻用了不存在的 facility availability；sensitivity table 正常運作，卻沒有碰到真正會讓決策翻轉的不確定性；forecast horizon 也可能拉得太長，讓遠期數字帶著不必要的精準感。
因此，高影響模型需要有人做 independent challenge。這不代表每家公司都要成立 validation department。重點是讓 reviewer 有足夠獨立性去問：假設從哪裡來？方法適不適合？哪個錯誤會讓決策反轉？模型漏掉了什麼限制？
Versioning 是分析完整性，不是檔名管理
Forecast_Final.xlsx、Forecast_Final_v2.xlsx、Forecast_Final_v2_reallyfinal.xlsx 看起來很好笑，但真正麻煩的不是檔名。董事會上週看到的結果，如果今天已經無法指出對應的 data cutoff、assumption set、formula state 與 review status，之後就很難重建當時為什麼做出那個決策。
對 material model，一個 release 至少應該留得下這些狀態：model version、資料 cutoff、主要 assumptions、修改者與 reviewer、material change reason、calculation / release state，以及這個版本被核准拿來做哪些用途。這些資訊不一定要塞在同一張 worksheet，但必須能一起被找回。
Actualisation 特別容易破壞這件事。每月把 actuals 載入模型沒有問題；若新的 actual 直接覆蓋掉原本 forecast，三個月後做 forecast accuracy review 時，看到的已經不是「當時真的預測了什麼」。保留 forecast vintage，再建立新的 actualised state，才能回答當時知道什麼、相信什麼，以及後來是哪個 assumption 失準。
Calculation state 也屬於版本的一部分。Microsoft 對 Excel 的 stale values、recalculation state 與 circular reference 都有產品說明。重要模型在 release 前若需要 full recalculation，就把它當成 control 留下 evidence，不要假設 workbook 打開後一定已經是最新結果。
當這些 state 都能被識別，版本治理才真正支援分析。Forecast calibration、performance review 和事後責任判斷，都需要比較同一個時間點真的存在過的 model state，而不是事後整理出來的「最新版」。
Model Risk 要多重？看這個決策有多重
2026 年 4 月，Federal Reserve、OCC 與 FDIC 更新了美國銀行監理範圍內的 model-risk guidance。Federal Reserve SR 26-2 與 OCC Bulletin 2026-13 採 risk-based、tailored 的思路，要求治理方式考慮模型用途、重要性、複雜度與風險輪廓。
這是 banking supervision 的 guidance，不是一般公司的 spreadsheet 法律義務。一般企業可以借用的是 proportionality：同一種 modelling technique，用在不同決策上，assurance 的強度可以不同。
例如每週內部 rough cut，只用來快速看 cash direction，假設透明、影響低而且決策可逆，peer review 可能就夠了。若模型開始支援下面這些問題，review 需要升級：
- 公司能不能撐過未來 12 個月；
- 何時融資、需要多少資金；
- 是否一次承諾大規模招募；
- 是否核准重大 CAPEX；
- 哪些數字要進董事會或 investor materials；
- 是否成為多個部門長期重複使用的 planning model。
升級不一定等於「多一層簽核」。視風險而定，可能需要更完整的 documentation、independent review、assumption challenge、controlled changes、re-performance、sensitivity work 或定期 revalidation。
開頭的 18 個月模型就是一個很好的分界。FP&A 拿它做每週 rough cut 時，可以接受較輕的 assurance；當 management 開始拿同一份模型決定融資時點與招募規模，模型的 decision consequence 已經變了。這時仍沿用原本的 review 強度，才是 model-risk governance 真正該處理的問題。
最後不是問「會不會算」，而是問「能不能被挑戰」
如果接到一份不熟悉的財務模型，不必先從數千個 cells 開始 forensic review。先挑一個重要 output，例如 closing cash 或 debt need，往回追，再用六個問題判斷這份模型值不值得拿來做決策：
- 重要假設看得見嗎？ 能不能找到數值、期間、範圍、來源、owner 與最近一次 material change？
- 結果追得回去嗎？ Closing cash 或 debt need 能不能一路回到 schedule，再回到真正的 business driver？
- Controls 有覆蓋不同 failure modes 嗎？ 除了 balance，是否還有 reconciliation、sign/range、reasonableness、change 與 model-state checks？
- Verification 和 validation 都有人做嗎？ 有人確認 implementation，也有人挑戰 intended use？
- 決策當下的 model state 能重現嗎？ Data cutoff、forecast vintage、assumption set、版本與 review status 是否保留？
- Assurance 和後果相稱嗎？ 低影響估算保持輕量，高影響的 liquidity、financing 或重大承諾模型則有更強的 challenge？
回到那個 60 天變 45 天的 case。只要 reviewer 能沿著這六個問題找到 assumption change、看見 cash movement、確認 control coverage、挑戰 45 天是否合理，再重建當時使用的 model state，這個錯誤就不必等到公司真的延後融資後才被發現。
模型永遠可能有錯。決策流程能做的，是讓重要假設、計算路徑、版本與 review evidence 留得夠清楚，讓下一個人有機會在公司下注之前把問題翻出來。
References
- ICAEW, Financial Modelling Code: official guidance
- ICAEW, 20 principles for good spreadsheet practice, 2024 edition
- UK Government Analysis Function, The AQuA Book: official guidance
- Federal Reserve, SR 26-2: Interagency Guidance on Model Risk Management: official guidance
- Office of the Comptroller of the Currency, Bulletin 2026-13: official bulletin
- IFRS Foundation / IASB, IAS 7 Statement of Cash Flows, IAS 12 Income Taxes, IAS 21 The Effects of Changes in Foreign Exchange Rates
- Hyndman, R. J. & Athanasopoulos, G., Forecasting: Principles and Practice
- Hyndman, R. J. & Koehler, A. B., Another Look at Measures of Forecast Accuracy
- Microsoft, Stale Value Formatting and guidance on circular references in Excel