採購審批流程圖（按金額門檻的審批矩陣）
採購審批流程圖範本：資本開支與營運開支分類、預算檢查、按金額門檻的審批權限矩陣、競爭性報價門檻、首選供應商核查與專業評審。
甚麼是採購審批流程圖（按金額門檻的審批矩陣）流程
採購審批是關於一筆支出承擔是否可以推進的決定，它在採購訂單產生之前作出，而不是之後。觸發點是一項帶有大概金額和類別的採購需要，本圖跟隨一份申請，由這一刻一直走到它最終變成一張採購訂單或被正式駁回：預算是否可用、資本開支還是營運開支的判斷、按金額分流的授權審批權限矩陣、是否需要競爭性報價或首選供應商的核查，以及需要時的專業評審。繪製這張圖的意義，是將一份原本散落在多份政策文件中的矩陣，變成任何人都能依循的一條路徑。
本圖只涵蓋審批這一層治理，並且刻意夾在另外兩個流程之間，而不是重複其中任何一個。它不涉及申請如何被寫明規格、編碼或退回修改，那部分文書工作屬於請購流程，本圖假設一份帶有金額和類別的申請已經存在。它亦不會延伸到採購訂單之後的收貨、發票核對或付款，那條交易鏈屬於採購訂單流程，本圖在同一步移交予它。它同樣不是更廣泛的尋源決策，例如自製或外購、招標還是框架下單、合約談判，那屬於採購流程的範疇。本圖真正涵蓋的部分較窄，也最容易在書面政策中被輕輕帶過：誰必須在甚麼金額、甚麼類別下簽署，以及採購未能通過某道關口時會發生甚麼。請把它當作一個起點，按照你們自己的授權審批權限矩陣、會計科目表和財務管控去調整，而不是取代它們。
三個判斷撐起這套流程。資本開支還是營運開支的判斷放在最前面，因為資本開支通常執行一張不同的門檻表，評估週期亦比營運開支慢，把兩者併入同一條鏈是審批矩陣中最常見的錯誤。直屬經理的判斷放在預算負責人 / 直屬經理泳道，有三條分支而不是兩條：批准、駁回，或者當金額超出經理可簽署的範圍時升級到高級審批人泳道，正是這一點令本圖成為一張真正的授權審批權限矩陣，而不是單一的門檻關口。專業評審的判斷出現得較遲，放在採購泳道，因為它取決於最開始那一步登記的類別，也正是這道關口，攔住了帶有資料、安全或法務因素的採購僅憑金額簽核就直達採購訂單。
本流程圖涵蓋的內容
本範本包含
- 五條泳道——申請人、預算負責人 / 直屬經理、採購、財務與高級審批人（按金額門檻）——橫跨六個階段：申請與分類、預算檢查、審批權限矩陣、尋源管控、專業評審，以及決策與開立採購訂單。
- 最開始的'資本開支還是營運開支採購？'判斷，令資本開支在預算檢查之前先向財務登記資本開支評估，而營運開支則直接進入預算檢查，不再把兩者當成同一條路徑處理。
- '直屬經理是否在權限範圍內批准？'判斷有三條分支，不是兩條：直接批准、直接駁回，或者當金額超出經理可簽署的範圍時升級到高級審批人（按金額門檻）泳道，這正是令本圖成為一張授權審批權限矩陣、而不是單一是非關口的原因。
- 尋源管控被安排在審批本身之內：'超出門檻是否需要競爭性報價？'判斷，以及'是否已有首選供應商存檔？'判斷，新供應商的風險評估會在申請到達專業評審關口之前先行記錄。
- '該類別是否需要專業評審？'判斷，把特定類別轉交IT、安全或法務，之後申請才能繼續推進，簽核會被記錄為獨立的一步，而不是從一句口頭同意中被默認。
- 預算不可用時的'縮小範圍還是取消申請？'循環，以及一個統一的駁回記錄步驟——無論駁回發生在預算、直屬經理還是高級審批人哪一關——都要先經過它，才能到達'採購申請已取消'，讓記錄說明申請為何停止，而不只是停止了。
何時使用本範本
- 你們正在記錄誰必須在支出被承諾之前批准一宗採購，希望把金額和類別門檻一次過議定，而不是每次申請都重新爭論。
- 採購申請一再卡住，因為沒有人能夠說清接下來應該由直屬經理、高級審批人還是某位專業評審人簽署。
- 你們正在制定或重新設定一張授權審批權限矩陣，需要一張圖說清誰在甚麼金額、甚麼類別下批准甚麼。
- 財務或審計員問起資本開支和營運開支在承諾之前是如何區分並按不同方式批准的。
- 你們正在配置一套採購或ERP審批工作流程，需要先在紙面上把治理規則議定下來，再交給別人寫進系統。
運作方式
把泳道改成你們的角色
用你們機構中真正存在的角色，取代申請人、預算負責人 / 直屬經理、採購、財務與高級審批人（按金額門檻）。在小型團隊裡，直屬經理和預算負責人往往是同一個人：把這兩條泳道合併，而不要畫一次從不會發生的交接。每條泳道對應一位決策者，而不是一個具名的人，這樣機構人事變動時圖仍然成立。
設定資本開支與營運開支的門檻表
把你們自己的數字填進'資本開支還是營運開支採購？'這條分支：在你們的會計政策下，甚麼算資本開支，財務裡由誰在資本開支評估上簽署，這項評估通常要多久。如果兩張門檻表確實在某個金額上重合，就寫明這一點；否則把它們分開，避免一筆資本開支被靜靜按營運門檻批准。
訂定授權審批權限矩陣的具體金額
用你們授權審批權限矩陣中的實際數字，取代'權限範圍內'和'按金額門檻'這類表述，並統一用一種貨幣表示。寫明每一級的高級審批人具體是誰，只有在確實運作某一級時才增加它，因為每多一級就多一次交接，也多一分把申請拆細以避開門檻的誘因。
寫明報價與首選供應商的規則
把'超出門檻是否需要競爭性報價？'落實為你們採購政策中的具體金額和報價數量，並列出甚麼才算已存檔的首選供應商，讓這條分支不再是主觀判斷。決定新供應商的風險評估能否與索取報價並行，還是必須先完成，然後按實際情況畫出來。
界定甚麼會觸發專業評審
列出必須轉交IT、安全或法務的類別：通常是新軟件或SaaS、任何會涉及客戶或員工資料的採購，以及條款非標準的合約。寫明每類評審由誰簽署、預計要多久，讓'該類別是否需要專業評審？'可以按清單回答，而不是憑記憶。
決定駁回時必須記錄甚麼
確定'記錄駁回原因並通知申請人'必須捕捉哪些內容：是哪一關駁回的、寫明的理由，以及申請人是可以修改後重新提交，還是必須提出一份新申請。一次沒有記錄理由的駁回，和一份根本沒有人處理的申請是分不清的，這正是週期時間和駁回率報表變得不可靠的原因。
拿一份真實申請走一遍
取最近兩三宗採購，一宗順利通過、一宗卡住或被駁回，把它們放到圖上走一遍。凡是大家口中描述、卻沒有畫出來的審批人，或者畫出來了、實際卻被跳過的一步，都是在把這張圖定為正式流程之前值得處理的發現。
常見問題
採購審批流程包含哪些步驟？
一項採購需要被識別並登記支出類別和成本中心，隨後被分類為資本開支或營運開支；資本開支會在繼續之前先向財務登記資本開支評估，營運開支則直接進入預算檢查。若預算不可用，申請人要麼縮小範圍後重新提交，要麼取消申請。若預算可用，直屬經理會覆核，並直接批准、駁回，或在金額超出其權限時升級給高級審批人；高級審批人隨後批准或駁回。獲批的申請轉到採購部門，由其核查超出金額門檻是否需要競爭性報價，需要時再取得報價，並核查是否已有首選供應商存檔，若沒有則先記錄風險評估。隨後的判斷會把特定類別轉交IT、安全或法務作專業評審，並記錄簽核。財務記錄預算佔用和審計軌跡，採購部門開立採購訂單。任何一次駁回，無論發生在預算、直屬經理還是高級審批人環節，都要先記錄理由，申請才會被關閉。
採購審批和請購之間有甚麼分別？
請購是內部文件：規格說明、成本中心和總賬科目，以及採購部門對其規格是否寫得足夠清楚、可以據此採購的核查。採購審批則是疊加在其上的治理決定：金額和類別是否通過一張授權審批權限矩陣、這筆採購屬於資本還是營運、是否需要競爭性報價或專業評審，以及最終由誰簽署。實際操作中兩者是並行的，請購承載著審批矩陣要讀取的資料。本圖假設一份寫明金額和類別的請購已經存在，聚焦於審批決定本身；請購自身的規格說明和科目填寫步驟，則在請購流程中另行涵蓋。
一張授權審批權限矩陣應該設幾級？
比大多數機構一開始設定的要少。兩級就能涵蓋大部分支出：預算負責人或直屬經理負責其簽署權限內的一切，加上一位高級審批人，其門檻取自你們的授權審批權限矩陣。為極高金額或資本開支再設第三級也很常見，但每多一級都會拉長週期時間，並催生把一筆採購拆成幾份小申請以避開門檻的誘因——這正是矩陣自身覆核時應當留意的地方。具體數字屬於你們自己的矩陣；本範本把它們留作佔位符，由你們自行設定並定期覆核，而不是給出一個適用於所有機構的數字。
哪些採購在批准前需要IT、安全或法務評審？
決定因素應當是申請一開始登記的類別，而不是事後的主觀判斷。常見的觸發因素包括新軟件或SaaS訂閱、任何將處理客戶或員工資料的採購、與現有系統或基礎設施對接的採購，以及條款不同於標準範本的合約。同一類別下的採購未必需要同樣深度的評審：一件低金額、不涉及資料存取的工具，或許只需一份簡短的安全檢查清單；而一套處理個人資料的系統，則值得更完整的評審和法務對合約的簽核。列出你們自己的類別以及各自觸發的評審，並把簽核記錄為獨立的一步，這樣一筆採購就不能單憑金額審批到達採購訂單。
資本開支和營運開支應該如何區別審批？
資本開支一般是使用年期超過一個會計期間的資產，通常執行一張獨立的門檻表、由財務主導評估，週期亦比日常營運開支更慢，因為它影響的是資產負債表和折舊計劃，而不只是某一期間的成本。營運開支通常對照部門預算更快獲批。兩者之間的具體分界，以及各自確切的門檻和審批級別，來自你們機構的會計政策和授權審批權限矩陣，因此請把它們寫在圖上，而不要假定通用數字適用。對流程而言重要的是，這次區分要盡早發生，在兩條路徑到達共用的預算檢查之前，這樣一筆資本申請就不會被誤判在營運門檻上獲批。