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