採購到付款（P2P）流程圖（由需求到付款）
採購到付款流程圖，由識別出需求到付清供應商款項：請購、預算與授權額度審批、合約查核、發出訂單、收貨、三方核對、無訂單異常與付款批次。
甚麼是採購到付款（p2p）流程圖（由需求到付款）流程
採購到付款是幾乎每一間機構都在運行、卻幾乎沒有人真正擁有的流程。採購擁有訂單，預算負責人擁有審批，倉庫擁有收貨，應付帳款擁有發票；這四方各自只按自己那一段被考核，於是每一段都很有效率，而整條周期很慢。損失永遠落在最後一端。一張發票核對不了，可能是因為沒有人登記收貨，可能是因為訂單在貨到之後才補開，也可能是因為訂單上的價格從來就不是當初談定的價格。應付帳款於是承受幾星期前由一班永遠不會看到異常隊列的人所作決定的後果，而他們用的補救辦法是事後補開一張採購訂單——積壓清掉了，承擔支出的帳同時亦毀掉了。沒有人把請購到付款當成一個數字去量度，所以整條周期的時間，就連抱怨它的人都看不見；反而是在催款的那位供應商，是唯一一方看得見全貌的。
本頁是營運層面的端到端流程，而且它刻意畫的是縫線，不是細節。圖上每一個階段本身都已經有自己的一頁：一項需求在任何訂單存在之前所走的內部路徑，在 /yue/templates/請購流程。訂單的開立與發出在 /yue/templates/採購訂單流程。收貨區在 /yue/templates/收貨入倉流程。單張發票的路徑在 /yue/templates/發票審批流程。而整個應付職能，包括付款批次和期末應計，在 /yue/templates/應付帳款流程。如果你只需要其中一個階段，請去那一階段的頁面——那裡的深度是這裡給不到的。尋源策略、招標、評選，以及之後的供應商關係，屬於 /yue/templates/採購流程。它由同一個識別出來的需求出發，卻是向左轉進市場，而不是轉入帳簿。而如果你真正需要的，是同一條周期為 SOX、ICFR（財務報導內部控制）或外部走查而作的控制點寫法，/yue/templates/採購到付款流程 就是為那批讀者而寫的。這張圖，是給那位被要求令整條周期運作起來的人。
書面的 P2P（採購到付款）程序留作預設的三件事，在這裡被畫成分支。審批關卡分成兩道，因為「成本中心是否有預算餘額？」和「是否超出授權額度？」是兩條由不同人負責的不同問題——預算說這筆錢是計劃過的，授權說這個人可以代機構作出承擔——把兩者混為一談，正是一張有預算的訂單會由無權簽核的人簽出去的原因。核對同樣分成兩道，理由一樣。「貨品或服務的收貨是否已登記？」要問在「三方核對是否在容差範圍內？」之前，因為欠缺收貨要退回申請人，而價格差異是要同供應商談的一件事，把兩者混在同一條隊列裡，那條隊列就永遠處理不完。容差是一道門檻，不是一個及格分——它是整條周期裡唯一一處，機構要用數字說明自己願意不問就付多少差異；一旦沒有寫下來，每位同事都會用出不同的一套。而無訂單那條路是畫出來的，不是否認掉的。「發票是否引用採購訂單？」會把沒有引用訂單的發票送去預算負責人泳道的「事後補開訂單是否獲批？」，結果要麼是一張獲批的訂單重新進入核對，要麼終止於「發票未付退回，未補開訂單」——因為一條沒有例外路徑的「無訂單不付款」政策不是政策，只是一條隊列。
本流程圖涵蓋的內容
本範本包含
- 六條泳道——申請人、預算負責人、採購、供應商、應付帳款與財務——鋪在六個階段上：請購、審批、尋源與訂單、收貨與發票、核對與異常，以及付款與報表。
- 分成兩道的審批關卡：「成本中心是否有預算餘額？」在答「沒有」時把請購單否決或押後；而「是否超出授權額度？」會把超出簽核人額度的請求，先送去財務泳道的「取得更高層級的簽核」，然後採購才會看到它。
- 「是否已有合約或框架協議？」這個直接下單與對外尋源的分岔：答「有，直接下單」的走到「向供應商發出採購訂單」，答「沒有，需尋源」的要先繞經「進行尋源並決標」。
- 令核對成為可能的那條承擔鏈：採購訂單、「交付貨品或提供服務」、「按採購訂單登記收貨」與「提交發票要求付款」，每一步都放在真正動手那個人的泳道裡。
- 核對畫成兩個關卡而不是一個：「貨品或服務的收貨是否已登記？」把卡住的發票退回申請人泳道的「按採購訂單登記收貨」；「三方核對是否在容差範圍內？」則把差異送去「登記異常並向供應商查詢」，由供應商「更正發票或開出貸項通知單」，再由「異常是否已解決？」決定是重新核對，還是在「爭議依合約條款處理」離開本流程。
- 無訂單的例外路徑，以及沒有人會畫的那條尾巴：「事後補開訂單是否獲批？」要麼繞回核對，要麼終止於「發票未付退回，未補開訂單」；而乾淨的那條路徑經「將已核對的發票入帳待付」、「向供應商放行付款批次」與「更新供應商主檔與支出紀錄」，走到「周期關閉，支出已納入報表」。
何時使用本範本
- 你們要編寫或更新採購政策，需要一張圖交代整條周期，而不是四份各自停在交接點、又互相矛盾地說著下一步該由誰做的階段文件。
- 你們的應付帳款異常隊列越積越多，需要說明大部分成因其實在上游——欠缺的收貨紀錄，以及事後才補開的訂單——而不在應付帳款組身上。
- 你們正在推行或收緊「無訂單不付款」的政策，需要在第一張發票被退回之前，先議定好例外路徑、豁免類別和批核人。
- 你們正在導入或搬遷 ERP 或 P2P 系統，而容差數字、審批門檻、收貨規則和異常原因代碼，必須在有人打開設定畫面之前先作為流程議定下來。
- 你們要培訓申請人、預算負責人或新成立的共享服務中心，希望用一張圖把整條周期、兩條否決路徑和爭議的交接一次講清楚。
運作方式
把泳道改成你們的組織
把申請人、預算負責人、採購、供應商、應付帳款和財務換成你們真實存在的角色。只有在入帳發票和放行付款批次由不同的人負責時，才把應付帳款和財務分開；如果一個人兩件事都做，就把它們合併，而不是留下一條從不做事的泳道。如果發票工作放在共享服務中心，就把它具名寫出來。如果收貨是由倉庫團隊而不是申請人負責，就加一條倉庫泳道，並把收貨那一步搬進去。
把兩道審批門檻都寫成數字
「成本中心是否有預算餘額？」和「是否超出授權額度？」在你附上數字之前都是空的。把授權審批權限表按角色列出金額，寫明測試的是訂單金額還是合約的全期總值，並決定同一預算科目下已承擔而未結的請購單和採購訂單如何計入。然後寫下把一項需求拆成兩張未達門檻的訂單會如何處理，因為拆單以避開下一個簽名，是這項管控最常見的被繞過方式。
訂下三方核對的容差
把你們真實的數字放到「三方核對是否在容差範圍內？」上：價格同時設一個百分比和一個絕對金額上限，以較低者為準，而數量的容差要訂得比價格緊。運費、關稅、進位差異和匯率差異另外訂規則，因為打斷核對的往往是它們，而不是貨品本身。寫明誰有權推翻一次核對失敗，並且每一次推翻都要留下紀錄——一次沒有記錄的推翻，與完全沒有管控無從分辨。
不只為貨品、也要為服務定義收貨登記
「貨品或服務的收貨是否已登記？」是把異常隊列塞滿的那道關卡：貨品在收貨區有一張收貨單，服務往往甚麼都沒有。指定由誰確認服務已經交付——通常是提出需求的申請人，而不是下單的採購——並以訂單的預計完成日期起算期限。對於按里程碑或按期收費的合約，決定收貨是逐個里程碑登記還是逐期登記，並把未登記收貨的未結訂單放進某個人的報表裡，好讓它們在月結之前被追。
議定無訂單的例外路徑與豁免類別
「事後補開訂單是否獲批？」是令「無訂單不付款」真正行得通的關鍵。決定哪些類別是真正豁免的，例如水電費、租金、稅費與政府規費，以及部分專業服務年費，並在「發票是否引用採購訂單？」這道關卡就把它們排除，而不是逐張發票去爭論。然後指定批核人——那位本來就應該批准原請購單的預算負責人，永遠不是應付帳款——並按部門每月匯報事後補開的訂單，好讓例外維持在例外的水平。
同真正做事的人走一次，然後發佈一個版本
把定稿的圖拿去給一位申請人、一位預算負責人、一位採購同事、一位應付帳款文員，以及放行付款批次的那個人，按實際發生的情況去改，而不是按政策寫的去改。逐一問他們：哪一步你已經悄悄不做了？議定由「更新供應商主檔與支出紀錄」產出的那些指標，然後發佈該版本並保留此前的版本，令日後打開這張圖的人知道自己看的是哪一版。
常見問題
採購到付款（P2P）流程包含哪些步驟？
一條完整的周期是：識別需求；提交附規格說明與成本中心編碼的請購單；確認預算餘額；按授權審批權限表核對金額，超額的往上呈；查核是否已有獲批的合約或框架協議涵蓋該需求，沒有就對外尋源；向供應商發出採購訂單；收到貨品或服務並按訂單登記收貨；接收供應商發票，檢查它是否引用了有效的採購訂單、以及該訂單之下是否已有收貨紀錄；進行訂單、收貨與發票的三方核對；把超出容差的差異當作異常，與供應商解決；把已核對的發票入帳；在付款批次中放行；並更新供應商主檔與支出紀錄，好讓下一輪尋源有憑有據。難的從來不是這份清單。真正打斷周期的，是沒有人登記的那張收貨，和背後根本沒有訂單的那張發票。
甚麼是三方核對？容差應該訂多少？
三方核對是指：只有在採購訂單、收貨紀錄與發票三者對品項、數量和價格都一致時，才把發票付出去。定義是容易的部分，數字才是工夫所在。要求分毫不差，幾乎每一張發票都會掉進隊列，所以價格上同時訂一個百分比和一個絕對金額上限，以較低者為準；數量的容差要訂得比價格緊——價格上的小差異是一場關於進位的爭論，數量上的小差異則是少了的貨。運費、關稅、進位差異和匯率差異要另外寫規則，打斷核對的往往是它們，而不是貨品本身。然後決定服務怎麼辦：服務往往根本沒有可以點算的收貨，機構通常退而求其次，改為只與訂單做兩方核對，或者由申請人確認某個里程碑已完成。公佈誰有權推翻一次失敗的核對，並且每一次推翻都要記錄在案：一個沒有寫下來的容差，每位同事都會用出不同的一套；而一次沒有記錄的推翻，即使當時真的做對了，這項管控也拿不出證據。
「無訂單不付款」在實務上是甚麼意思？
意思是：沒有引用有效採購訂單的發票不予付款，會退回供應商。理由是沒有訂單就沒有談定的價格，帳上沒有記錄這筆承擔，也沒有證據顯示有權簽核的人在支出發生之前批准過。實務上，一刀切的政策若沒有先把兩件事議定好，一定會失敗。第一，必須公佈一份豁免類別清單——常見的是水電費、租金、稅費與政府規費，以及部分專業服務年費——並在關卡處直接排除，而不是逐張去爭論。第二，其餘一切都必須有一條界定清楚的例外路徑：在本圖中，沒有引用訂單的發票會走到預算負責人泳道的「事後補開訂單是否獲批？」，於是本來就應該提出請購的那個人要事後批准它，這件事會被記錄，並按部門匯報。沒有這條路徑，應付帳款那張桌子就會自己悄悄補開訂單，而政策淪為紙上作業。
本頁與 ERP 的採購到付款流程範本有甚麼不同？
兩者是同一條周期，只是為不同的讀者而寫。/yue/templates/採購到付款流程 上的那份採購到付款流程範本，把整條周期寫成一組控制點，服務 SOX 與 ICFR（財務報導內部控制）的需要：每一步的流程負責人、來源系統、審批關卡與佐證，正是外部審計師做控制測試時逐項走過的那種形式。本頁則是給真正在運行它的人看的營運流程——六條泳道、分成兩道的審批關卡、容差決策、異常迴路和無訂單路徑——它是寫來讓你改成自己的門檻，而不是原封不動拿去給審計師看的。兩端的範圍亦不同：本圖由識別出需求開始，到支出納入報表為止；而按控制點寫的那一版，集中在財務報表認定所在的請購到付款那一段。審計卷宗用那一份，做流程用這一份。
應該用這一份，還是用單獨的採購訂單和發票流程圖？
問題跨越階段時用這一份，問題落在單一階段之內時用那幾份。本圖把每個階段壓縮到下一個階段真正依賴的那幾步，所以能在一頁之內展示整條周期——當收貨紀錄不齊、當發票沒有訂單就到、又或者當沒有人講得出請購到付款實際需要多久時，你需要的正是這個。它刻意比階段頁淺。如果你們要重新設計審批門檻和請購編碼，/yue/templates/請購流程 講得深入得多。訂單的開立與發出，看 /yue/templates/採購訂單流程。收貨區、差異處理與承運商索償，看 /yue/templates/收貨入倉流程。單張發票的路徑，包括重複檢查和記帳編碼，看 /yue/templates/發票審批流程。付款批次、供應商對帳單核對與期末應計，看 /yue/templates/應付帳款流程。大部分機構最後兩者都會有：政策裡放這一份，作業指引裡放各階段的圖。