訂單到收款流程圖（由接單到收款銷帳）
六條泳道的訂單到收款流程圖：訂單與主檔資料檢查、信貸凍結與解除、出貨、簽收證明、開票、收款銷帳、短付扣款、追收與壞帳撇帳。
甚麼是訂單到收款流程圖（由接單到收款銷帳）流程
訂單到收款是公司裡唯一真正令錢進來的流程，而它幾乎從來不屬於某一個人。銷售管訂單，信貸管理管額度，倉庫管貨，開票管發票，應收管追收——而每一方被考核的又是不同的數字：接單金額、風險承擔額、準時出貨率、開出的發票張數、應收帳款週轉天數（DSO）。結果就是一條在每個部門自己的儀表板上都很健康、由頭到尾卻要走七十天的循環。損失很少發生在某條泳道的中間，而是發生在接縫上：一張擱在信貸凍結上、卻從來沒有人告訴過客戶的訂單；一次沒有簽名收貨單的交付，於是開票不肯放行；一張因欠缺採購訂單編號而被客戶的應付帳款入口網站退回的發票，付款時鐘從未開始計算；一筆被記成逾期餘額、被一個根本不知道有爭議存在的人追了三個月的短付。上述每一件事，從造成它的那個部門內部都看不見——這也正是為甚麼把整條循環畫在一頁上，通常是弄清楚自己的錢究竟卡在哪裡最便宜的辦法。
本圖畫的是完整循環，因此它在兩個地方是刻意畫得淺的，而那兩處各有一張姊妹圖深入展開。倉庫那一半——庫存分配、缺貨待交訂單、分批出貨、揀貨、包裝與向承運商交接——在這裡被壓縮成一個步驟，完整版在 /yue/templates/訂單履行流程 上的訂單履行流程圖，作業層面的細節則在 /yue/templates/揀貨與包裝流程。追收那一半——逐級催款、分期還款方案、貸項通知單的審批權限與壞帳準備——在這裡被簡化為一個追收步驟、一次轉交追收機構和一次撇帳審批，完整版在 /yue/templates/應收帳款流程 上的應收帳款流程圖。客戶當初是怎樣拿到信貸額度的，與一張訂單如何對照額度接受檢查是兩回事，那是 /yue/templates/客戶信貸審批流程 上另一條獨立的審批流程。訂單存在之前的一切——銷售線索、報價、折扣與條款審批，以及已簽署的訂單——屬於報價到收款循環的前半段，見 /yue/templates/報價到收款流程 上的報價到收款流程圖；那張圖跨越的弧線與本頁相同，但把深度放在定價工作上，而不是履行與追收上。而這條循環在採購一側的鏡像——你們是客戶、錢是出去而不是進來——見 /yue/templates/採購到付款流程。當問題橫跨多個部門時，用本頁；當問題落在某一個部門裡面時，用那幾張的其中一張。
有三處接縫被明確畫了出來，因為多數書面程序把它們留給了習慣。信貸凍結是一個循環，而不是一道關卡：「信貸凍結是否解除？」分成三路——已解除、先行預付、不予解除——而預付這條路會回來重新檢查，而不是離開流程，所以一張靠付款解除凍結的訂單，仍然是一張必須有人確認並放行的訂單。「是否已取得簽收證明？」被放在出貨與開票之間，而不是開票之後，這令發票取決於貨已送達的證據，而不是取決於貨已發出這個事實。而「是否在到期日前全額付款？」分成三路而不是兩路：短付走向「為扣款編碼並開立爭議個案」，由能夠了結它的人對照訂單與簽收證明去查證，沉默則走向追收階梯。把短付和不付分開，是最能減少無用追收工作量的一項改動，因為兩者的成因、負責人和解法都不一樣。
本流程圖涵蓋的內容
本範本包含
- 六條泳道——客戶、銷售與客戶服務、信貸管理、倉庫與物流、應收與收款銷帳、財務主管——橫跨五個階段：接單、信貸與確認、履行與交付、發票與收款，以及追收與結案。
- 帶真實修正循環的接單：「訂單與主檔資料是否齊全？」會把不完整的訂單退回客戶去「補齊欠缺的訂單資料」，而不是讓它繼續流進倉庫的待辦隊列；圖中還註明了哪些主檔欄位應當攔下訂單、哪些只應給出提示。
- 信貸凍結的解除循環。「信貸風險承擔額是否在額度之內？」把超出額度的訂單送去「將訂單置於信貸凍結」，隨後「信貸凍結是否解除？」分成三路：已解除、先行預付——這條路會繞回去重新檢查——或不予解除，終止於「因信貸不予批准而取消訂單」。
- 一道取決於證據、而不是取決於出貨的開票關卡。履行被壓縮成一個步驟，隨後「是否已取得簽收證明？」要麼放行開票，要麼把訂單送去「向承運商追討簽收證明」，再繞回同一道檢驗。
- 三路分支的「是否在到期日前全額付款？」決策，把付款、短付和沉默分開，於是一筆扣款絕不會被當成逾期餘額去處理，一筆真正逾期的餘額也絕不會被當成爭議擱在那裡。隨後的「客戶的回應？」會把追收開始之後才提出爭議的客戶送回同一場查證，而不是另開一場。
- 扣款分支與三個終點。短付走向「為扣款編碼並開立爭議個案」，隨後「對照訂單與簽收證明查證」，再由「扣款是否成立？」這道檢驗要麼開出貸項通知單，要麼併入追收階梯；整條循環終止於「發票已結清，訂單結案」、經財務主管批准後的「餘額已撇帳」，或那張被取消的訂單。
何時使用本範本
- 你們想縮短現金轉換周期，需要在有人啟動專案之前，先看清楚延誤究竟卡在信貸解除、出貨、把發票開出去，還是未了結的扣款上。
- 你們要在 ERP 中導入或重新設定訂單到收款，希望信貸凍結規則、開票觸發條件和扣款原因代碼先由業務方達成共識，再落成系統設定。
- 銷售和信貸管理正在為被凍結的訂單爭執，你們需要把解除權限、回應時限和預付路徑畫出來，而不是一張訂單一張訂單地去談。
- 你們的應收帳齡報表裡全是沒有人說得清的零星餘額，需要把短付路徑與逾期路徑分開，好讓扣款送到能夠了結它的人手上。
- 你們要為收入循環的內部或外部審計撰寫流程說明，需要一張受控的圖，說明信貸、交付證據、開票和撇帳這幾道管控分別位於哪裡。
運作方式
把泳道改成你們自己的組織
把客戶、銷售與客戶服務、信貸管理、倉庫與物流、應收與收款銷帳、財務主管換成你們真實擁有的部門。小型財務團隊把信貸管理併進應收，不會損失甚麼；共享服務中心通常需要把開票和追收拆開，因為它們是不同地方的不同團隊。如果由第三方物流（3PL）替你們發貨，就給 3PL 單獨一條泳道，好讓你們自身管控的邊界清晰可見。批准撇帳的人，要和追討這筆款的人待在不同的泳道裡。
把你們的信貸政策寫進風險承擔額檢查
「信貸風險承擔額是否在額度之內？」在你說清楚風險承擔額指甚麼之前是空的。寫明它是否包括未結訂單、已交付但尚未開票的貨物、尚未收回的發票以及爭議中的金額，然後去核對 ERP 實際計算的是甚麼，因為這兩者往往不同。記下額度的來源——內部評分卡、徵信機構評級、集團內跨法人實體共用的額度——以及一個毫無往績的全新客戶會怎樣處理，通常是預付款或一個小額起步額度，而不是一個空白欄位。
給信貸凍結定一個服務時限和一位負責人
沒有時鐘的凍結等於丟掉的訂單。訂明誰可以解除、金額上限是多少，把回應時間按工作小時而不是按日來定，並決定由誰告訴客戶訂單被凍結了、可以說到甚麼程度。為超出權限的解除加上升級路徑——通常是財務主管或商務總監——並要求每一次解除都填寫理由。沒有記下理由的被凍結訂單，事後無從檢視；而這些理由裡的規律，正是你們的額度需要調整的地方。
決定一張訂單憑甚麼可以開票
本圖把發票攔在「是否已取得簽收證明？」被回答之前。想清楚這對你們是否合適：有的企業按發貨過帳開票，有的按交付確認，有的按客戶驗收，服務類則按里程碑或按已記錄的工時開票。無論選哪一種，都要寫下證據存放在哪裡，以及在把欠缺的證明當成交付失敗之前你們會追討多久。搶在證據之前開票，買回來的是幾天的應收帳款週轉天數，代價是一季之後的扣款。
在需要之前先把扣款原因代碼建好
「為扣款編碼並開立爭議個案」只有在代碼存在而且有含義時才成立：價格、數量、短交、破損、促銷或折讓、運費、退貨、重複付款。給每個代碼指定一位預設負責人，因為查證要送去哪裡靠的就是它——價格爭議給銷售，短交給倉庫，折讓索償給簽下那份協議的人。設定一個金額門檻，低於它的零星餘額不作查證直接清掉；並議定爭議未了結期間追收是否暫停、暫停多久。
和真正做這件事的人走一遍，然後發佈一個版本
把圖拿到銷售接單組、一位信貸管理專員、出貨部和一位收款銷帳同事面前，跟著三張真實訂單走一遍：一張順利的、一張曾經擱在信貸凍結上的、一張被短付並產生爭議的。把圖改成大家實際在做的事，而不是程序上寫的事，並為每個步驟補上所用的系統與單據。然後發佈該版本並保留此前的版本，令日後打開這張圖的人知道自己看的是哪一版、又改了甚麼。
常見問題
訂單到收款流程包含哪些步驟？
收到客戶訂單，對照訂單與主檔資料做檢查；把客戶的信貸風險承擔額與其額度比對，超出額度的訂單被置於信貸凍結，然後被解除、改為預付或不予解除；訂單帶著承諾日期得到確認並放行至履行；貨物被揀貨、包裝並出貨；取得簽收證明；發票依據交付產生並發送；在到期日對付款作匹配；收款銷帳、發票結清。在這條主幹之外，還有兩條決定這條循環是否真的走得通的分支：短付被編碼為扣款，對照訂單與簽收證明查證，最終或是開出一張貸項通知單，或是繼續追討；而未付的發票進入追收階梯，隨後轉交追收機構，最後由一位獨立於追收工作的人批准壞帳撇帳。
訂單到收款和應收帳款有甚麼分別？
應收帳款是訂單到收款的收款那一半：發票、付款條件、催款通知、爭議和款項。訂單到收款是整條循環，由客戶訂單開始，經過信貸檢查、訂單確認、出貨與交付證據，發票在這之後才存在。這個分別之所以重要，是因為大多數訂單到收款的問題都產生在應收的上游，卻落到應收頭上：一個錯誤的送貨地址會變成交付爭議，一個欠缺的採購訂單編號會變成被客戶入口網站退回的發票，一次沒有記錄的分批出貨會變成一筆扣款。如果你們要的是追收那一側的細節——催款時間表、分期還款方案、貸項通知單的審批權限和壞帳撇帳——請用 /yue/templates/應收帳款流程 上的應收帳款流程圖。如果你們想弄清楚應收為甚麼總是收到有問題的發票，請用本頁，它展示的正是產生這些發票的那些步驟。
甚麼是信貸凍結？誰應當有權解除？
信貸凍結是當客戶的風險承擔額突破其信貸額度、或其帳戶逾期超過某個設定點時，自動加在訂單上的一道攔截。它會令訂單停在原地不再走向履行，直到有人作出決定。解除權限應當按金額分級，並歸屬信貸管理而不是銷售，正正因為希望這批貨發出去的人，不應該是判斷客戶付不付得起的人。令它成為一道管控而不是一處瓶頸，靠的是三件事：以工作小時計的回應時限、為超出信貸管理專員權限的解除所定義的升級路徑，以及每一次解除都記下理由。理由的分量比看上去大得多——把一季的理由拿來檢視，通常會看出兩件事之一：某個好客戶的額度定得太低，或者某個本來不應該有額度的客戶，額度正在被例行突破。
短付和扣款應該怎樣處理？
與逾期發票分開處理，而且要立即處理。短付是客戶在告訴你有甚麼地方不對，所以有用的反應是查證，而不是再寄一封催款通知。在銷帳匯款的當下就把原因編好代碼——價格、數量、短交、破損、促銷或折讓、運費、退貨、重複付款——並把個案送給能夠了結這一類問題的人：定價給銷售，短交給倉庫，促銷索償給簽下那份折讓協議的人。設一個小額門檻，低於它的零星餘額不作查證直接清掉，因為追一筆一百元的差額，成本比這筆差額本身還高。然後按原因代碼長期追蹤扣款。這些代碼作為你們自己訂單到收款流程的缺陷報告，價值遠高於作為一條追收清單：短交代碼在上升，是倉庫的問題；價格代碼在上升，是定價或合約的問題，不修好就會一直付出代價。
怎樣衡量訂單到收款循環運作得好不好？
應收帳款週轉天數（DSO）是那個頭條數字，但它單獨看會掩蓋時間究竟花在哪裡，而且它隨銷售量變動的程度不亞於隨績效變動。把循環拆成這張圖令人看得見的幾段間隔：下單到確認、擱在信貸凍結上的時間、確認到出貨、出貨到取得簽收證明、交付到發票發出、發票到收款銷帳。再在旁邊加上三個品質指標——發票一次準確率、無需人手比對即自動銷帳的收款佔比，以及扣款佔已開票金額的比重並按原因代碼拆分。這樣衡量之後，最大的那一段延誤往往根本不在客戶身上，而是交付到開票、或者一張擱在凍結上的訂單、或者帳上尚未銷帳的收款——這些全都在你們自己的管控範圍之內，而且單看一個 DSO 數字，一個也看不出來。
此流程所處的位置
在大多數機構中，此流程緊接由銷售線索到訂單流程圖：由收集到訂單登記之後。
前置流程
- 由銷售線索到訂單流程圖：由收集到訂單登記 — 由銷售線索到訂單流程圖範本：收集與去重複、線索評分與 MQL 關卡、SDR 接觸與銷售接納、CPQ 設定、折扣審批、報價接納、信貸審核與銷售訂單登記。