客戶信貸審批流程圖（額度與付款條件）
客戶信貸審批流程圖：申請與實體核實、徵信報告與同業推薦、評分、分層授權、擔保安排、在 ERP 建立額度，以及定期檢視。
甚麼是客戶信貸審批流程圖（額度與付款條件）流程
幾乎每一間公司都說自己有做信貸審查。追問下去，答案通常是：有人在開戶那一刻看過一次徵信評分，之後那個數字就再沒有動過，而客戶的訂單量已經翻了四倍。常見的失效都由此而來。風險承擔只按應收帳簿餘額計算，於是未交付的訂單、已交付但未開票的工作全部落在額度之外，真實數字往往是已批額度的兩倍。額度住在一封審批電郵裡，而不是客戶主檔上，所以實際上沒有東西攔得住那張訂單。付款條件在談判尾聲由銷售同事自行答應，信貸部之後才被叫去追認。而拒絕被當成一條死路，於是那個帳戶靠著一段關係，靜靜地照樣出貨。這些都不是評分方法的問題，而是流程的問題：由誰決定、依據甚麼證據、憑誰的授權，以及決定作出之後會怎麼樣。
本圖只涵蓋信貸決定本身，在額度生效並進入檢視循環的那一刻停下。訂定一個額度，和執行一個額度並不是同一回事：拿一張實際訂單去對照一個已經存在的額度，屬於由接單、履行、開票到收款銷帳的整條商業循環，即 /yue/templates/訂單到收款流程 上的訂單到收款流程——在那裡，信貸審批只是一個方格。本頁就是把那個方格打開。發票一旦存在之後發生的一切——開出發票、按付款條件跟進、追收、爭議、分期付款安排以至壞帳撇帳——屬於 /yue/templates/應收帳款流程 上的應收帳款流程。採購那一邊的鏡像問題不同，承擔的風險也不同，是交不到貨而不是收不到錢：一個供應商是否適合被使用，屬於 /yue/templates/供應商審批流程 上的供應商審批流程；而那個供應商要查到多深，則見 /yue/templates/供應商風險評估 上的供應商風險評估。至於在沒有額度、也沒有帳簿撐著的情況下簽署接受一項剩餘風險的通用做法，是 /yue/templates/風險接受決策 上的風險接受決策；在這裡，那份工作由授權層級承擔。本圖亦假定客戶紀錄已經存在——建立紀錄、簽約與開票設定屬於 /yue/templates/客戶導入流程 上的客戶導入流程，而本頁展開的正是該流程中的信貸與篩查分支。
本圖畫出了三個大部分書面信貸政策留作預設的決定。「是否在授權額度之內？」放在「信貸決定？」之前回答，而不是之後，於是個案送到的是有權簽署它的那個人，而不是碰巧在場的那個人；而拿去對照的數字，是總信貸風險承擔，不是眼前那一張訂單。「信貸決定？」刻意分成三路：按申請批准、附擔保批准、拒絕。中間那條分支正是邊緣個案的歸屬，而只有批或不批兩路的模型無處安放它們，於是靜靜地把分析員推去同意一些自己並不安心的額度。被拒絕的那條路亦不會就此停下：它通向「提供預付或先款後貨」，終止於「只以預付方式交易」——因為一個令銷售手上甚麼都沒得提的拒絕，正是兩星期後被推翻的那個拒絕。最後一個階段是一個循環，不是一條直線：「到檢視期或觸發條件成立？」在事情有變之前一直回到監察，而「調低、暫停還是撤銷？」把調低後的額度送回循環，而不是送出流程。
本流程圖涵蓋的內容
本範本包含
- 五條泳道——客戶、銷售、信貸分析員、信貸經理和財務總監——鋪在五個階段上：申請、核實、評估、決策與擔保，以及額度與檢視。
- 在有人花錢做查核之前的一道申請關卡：申請連同所要求的額度與付款條件一併記錄下來，隨後「申請文件是否齊備？」要麼放行，要麼送去「追取欠缺的資料」再重新提交。
- 先確認身分，後談信貸。「核實法人實體與股權」和「實體與篩查是否通過？」都排在徵信報告之前；而篩查一旦有命中，會終止於「因合規理由拒絕」，而不是被當成一個評分偏低的風險去處理。
- 信貸分析員泳道裡的取證動作——「取得商業徵信報告」、「審閱財務報表與同業推薦」，然後「評分並建議額度與付款條件」——令建議送到決策點時，計算過程是附著的。
- 授權層級與擔保這條支線：「是否在授權額度之內？」把超出授權的個案經「呈交上一級授權層級」再送回來；而三路的「信貸決定？」把中間那個答案送往「訂明所需的擔保」和「擔保是否到位並已核實？」——在那裡，一直沒有到位的擔保會匯入被拒絕那條路，而不是靜靜地照樣放行額度。
- 四個終點而不是一個：「因合規理由拒絕」；被拒絕或擔保未到位的客戶走向「只以預付方式交易」；重新評估過關之後是「額度維持至下次檢視」；而當「調低、暫停還是撤銷？」已經用盡較溫和的選項，終點是「信貸安排已撤銷」。
何時使用本範本
- 你們正在撰寫或更新一份信貸政策，需要用一張圖說清楚誰負責蒐集證據、誰有權批准哪一級的額度，以及額度批出之後會怎麼樣。
- 你們的信貸額度是每個帳戶開戶時定下的，之後從來沒有重新驗證過，即使有些客戶的訂單量已經翻倍。
- 銷售在談判過程中就答應了付款條件，信貸部之後才被叫去確認，於是審批變成一道沒有人拒絕得了的手續。
- 你們正在 ERP 裡設定信貸管理，希望在把授權層級、訂單封鎖行為和檢視觸發條件寫成系統規則之前，先把它們議定下來。
- 剛出現一筆壞帳，房間裡的問題是：額度是誰批的、依據甚麼證據，以及上一次有人看過它是甚麼時候。
運作方式
把泳道改成你們自己的角色
把客戶、銷售、信貸分析員、信貸經理和財務總監換成你們真實存在的角色。在小型財務團隊裡，分析員與經理是同一個人，那就把泳道合併，而不是留一條空的；在共享服務中心的做法裡，分析工作在境外做、決定留在本地，而那正正是最值得畫出來的交接。無論你們怎樣合併，都要令準備個案的人和批准個案的人分開，因為審計師或信用保險公司第一件要看的就是這道分工。
把授權層級寫成數字
「是否在授權額度之內？」在你附上數字之前是空的。每一級的額度要對應角色而不是對應某個人的名字，每一級都要指定一位代理人，令授權層級不會因為有人放假而卡住，並且要寫明幣別。最重要的是界定這個數字量度的是甚麼：總信貸風險承擔，即已入帳的應收餘額，加上未交付的訂單，加上已交付但未開票的工作，而不是眼前那一張訂單。另外加上不論金額都要向上呈交的情況，例如全新成立的公司、海外客戶，或者曾經被停止供貨的客戶。
界定甚麼才算一份完整的申請
決定「申請文件是否齊備？」背後那份文件必須包含甚麼，分析員才可以開工：註冊的法人名稱與公司註冊編號、集團母公司、送貨地點與開票實體、附有數字的信貸額度與付款條件要求、預計每月金額、兩份同業推薦，以及同意你們進行相關查核的授權。任何被設為選填的欄位都會是空白，而分析員會用一個假設去填補那個空缺。要寫明由誰去追、追多少次，以及一份停滯不前的申請在甚麼時候關閉，而不是一直開著。
寫明證據和它們如何加權
「評分並建議額度與付款條件」應該可以由另一位分析員憑同一份檔案重現出來。寫下你們用哪一家徵信機構、每一個評分區間對你們而言代表甚麼、額度如何由營業額、資產淨值或預計每月採購額推導出來，以及對於現有客戶，內部付款紀錄在甚麼情況下凌駕外部觀點。要寫明證據薄弱時分析員可以怎麼做——通常是一個較小的起步額度配一次提早檢視，而不是直接拒絕——並要求把推理過程與建議一併記錄下來。
界定擔保在實務上是甚麼
「訂明所需的擔保」需要一份有負責人的清單。列明你們接受的工具——母公司或董事擔保、按金或部分預付款、信用狀、信用保險、貨物所有權保留條款——並就每一項寫明由誰草擬、由誰核對簽署人是否有權簽署、正本存放在哪裡，以及由誰盯著到期日。同時記下每一項的局限：一份擔保的價值只等於擔保人的資產負債表，而保險公司可以在很短的通知期內削減承保額，那等於悄悄調低了你們自己的額度。
訂定檢視觸發條件，然後走一次並發佈
為「到檢視期或觸發條件成立？」的每一個風險級別附上一個節奏，並列出哪些事件會把檢視提前：一次逾期付款、一份分期付款安排違約、徵信評分下跌、一項法院判決、一項提高額度的申請、股權易手、財務報表遲交，以及一個突然不再落單的帳戶。然後帶著整張圖，與一位分析員、信貸經理和一位銷售同事一起走一次，用兩個真實客戶做例子（其中一個要是被拒絕過的），按他們實際的做法改正，再發佈該版本，令大家知道自己看的是哪一版。
常見問題
客戶信貸審批流程包含哪些步驟？
一個可行的次序是：客戶申請信貸條件，銷售記錄下所要求的額度與付款條件，申請文件被檢查是否齊備，有缺漏就去追。接著核實法人實體及其股權並做篩查；篩查一旦有命中，個案以合規理由停下，而不是被當成一個信貸問題來處理。然後由信貸分析員取得商業徵信報告，審閱已公佈的財務報表與同業推薦，並為客戶評分，以建議一個額度和一組付款條件。建議會對照分層授權去測試，超出本級授權就向上呈交一級，然後作出三選一的決定：按申請批准、附擔保批准（擔保、按金、信用狀或信用保險），或者拒絕並提供預付方案。已批准的額度要載入 ERP 的客戶主檔；之後帳戶進入監察，按節奏或按觸發條件檢視，一旦情況轉差就調低、暫停或撤銷。
客戶信貸額度應該怎樣訂？
常用的方法有四種，大部分信貸團隊會同時用其中兩種。第一種是按客戶的資產淨值或營運資金的某個比例，數字取自已公佈的財務報表，適用於經營穩定的公司。第二種由生意本身倒推：預計每月採購金額，乘以換算成月數的付款條件，再加一段客戶實際上會超出條件的日數作緩衝。第三種是徵信機構建議的額度，用來做合理性檢查很有用，但它是為一般債權人計算的，而不是針對你們自己的風險承擔。第四種適用於現有客戶：他們自己的付款紀錄和曾經清付的最高餘額，這比任何外部資料都可靠。無論用哪一種，額度都要套在總信貸風險承擔上，而不是只看應收帳簿餘額；並且新客戶要由低起步、配一次提早檢視，而不是在證據薄弱的情況下爭論一個大數字。
本頁與應收帳款流程有甚麼不同？
兩者在發票這一點相遇，其餘幾乎沒有交集。本頁的客戶信貸審批，決定的是一個客戶到底可不可以欠你錢、可以欠多少、以甚麼付款條件、附甚麼擔保，依據是身分核實、徵信報告、已公佈的財務報表與同業推薦，以及一套分層授權。它在額度於客戶主檔上生效並進入檢視之後結束。/yue/templates/應收帳款流程 上的應收帳款流程則由發票存在的那一刻開始：開出並送達發票、按付款條件跟進、追收階梯、爭議與貸項通知單、分期付款安排、轉交追收機構以及壞帳撇帳。如果你們的問題是逾期發票沒有被一致地追討，那一頁才是你要的。如果你們的問題是額度一開始就訂錯了，或者從來沒有真正執行過，那就是本頁。兩者都坐落在 /yue/templates/訂單到收款流程 上更大的訂單到收款流程之內，在那裡信貸審批只是一個方格，而本圖把它展開。
客戶信貸審查不過關時，可以要求哪些擔保？
審查不過關，很少就是對話的終點，這也是本圖設有「附擔保批准」這條分支的原因。常見的選項是母公司或董事擔保、按金或部分預付款、信用狀或銀行擔保、貿易信用保險，以及合約條款中的貨物所有權保留。每一種都有值得寫下來的局限。一份擔保的價值只等於擔保人自己的資產負債表，而且必須由有權作出該擔保的人簽署。按金最乾淨俐落，但也最難開口。信用狀很適合出口訂單，對客戶而言則相當昂貴。信用保險只賠付損失的一部分，並受保險公司對該買家所設的承保額限制；而保險公司看到情況轉差就會削減承保，有時比你更早。無論你們接受哪一種，都要在放行額度之前確認它真的已經到位，並持續盯著它的到期日。
客戶信貸額度應該多久檢視一次？
檢視節奏要按風險承擔的大小來定，而不是因為政策這樣寫，就一年把所有人檢視一次。常見的做法是：最大的額度和列入觀察名單的帳戶每季一次，中間一段每半年一次，長尾每年一次，其餘時間由一個輕量的徵信自動監察提示覆蓋全部客戶。不過真正保護你的並不是定期檢視，而是事件觸發條件。要把它們明確寫出來，並在它們出現的當天就行動——一次逾期付款或一份分期付款安排違約、徵信評分下跌、一項法院判決、保險公司削減承保額、一項提高額度的申請、股權易手、財務報表遲交甚至沒有提交，以及一個沒有解釋就停止落單的帳戶。在本圖中，這些觸發條件和日曆匯入同一個決策，所以一個額度不會僅僅因為過了某個日期就被檢視。有一件事檢視並不是：它不是取得更大額度的途徑——提高額度的申請要重新走一次分層授權，因為更大的風險承擔需要有權簽署它的那一級。
此流程所處的位置
在大多數機構中，此流程會交接給訂單履行流程圖範本——從下單到交付。
它是訂單到收款中的其中一個步驟。
第 1 步: 客戶信貸審批流程圖（額度與付款條件） 當前位置
客戶信貸審批流程圖：申請與實體核實、徵信報告與同業推薦、評分、分層授權、擔保安排、在 ERP 建立額度，以及定期檢視。
第 2 步: 訂單履行流程圖範本——從下單到交付
五泳道的訂單履行流程圖範本：訂單核對、信用審核、庫存分配與缺貨訂單、揀貨與包裝、發貨、交付，以及開票與訂單結案。
第 3 步: 簽收證明流程圖（ePOD 由交付到開票）
第 4 步: 發票到收款流程圖
第 5 步: 應收帳款流程圖（由開票到收款）
第 6 步: 銀行對帳流程圖