起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識FMS財務管理系統：付款管理
前一篇介紹了財務應付管理中的結算明細報表、結算單以及稅票管理幾個部分，本篇將分享下財務付款相關的內容。
付款最終是要匯款或現金支付給供貨商或合作商家，公司的現金流就會減少，所以是不是所有的付款申請都要付？什么時間付出才能保障公司現金流的充沛合理？這都需要財務部根據實際情況制定出合理的流程。
財務部以外的同事在報銷、請款等流程提報時都會覺得財務部是公司做事最嚴格最不請情面的部門，沒辦法，職責所在，互相理解！
結算單編輯補充
在《FMS財務管理系統：應付結算》中關漏掉了結算單編輯部分，這里先補充一下。
在前面講述結算單生成完以后，審核通過即可進行供應商或商家對賬、稅票方面的后續流程，這種場景是完全依賴系統的數據，即便在結算單對賬過程中有問題后，財務同事會返饋給技術或產品同事進行數據處理，然后可以通過后臺重新生成結算單。
財務業務同事的主要工作就是核對，如果結算單無誤則嚴格按系統數據執行。
在實際的結賬過程中，如果前面業務系統的數據錯了，無法修改怎么辦呢？
這對技術和財務同事都是一個不小的工作量，解決辦法這里可以加強核對及提供手動勾單的方式。
１. 加強數據的核對勾稽（這里已經強調過幾次核對平臺的重要性）
這主要是系統研發與財務同事共同要做的工作，這部分也是結賬流程應該有的，共有三部分如下圖。
預結算可以提前模擬走一遍結賬數據核對，提前發現問題，及時處理更正；
預警與日常數據監控，可以實時發郵件或短信等給研發同學跟蹤異常，這部分不應該局限于財務自己的數據，對于前端業務系統的數據也應該與負責的相關同事溝通，進行監控，保證源頭的數據正確。
2. 結算單編輯
在審核前財務同事可以編輯結算單數據，這里的編輯不是隨意修改已生成的數據而且可以通過勾單的方式去除掉錯誤的業務單據，保證財務順利結賬（財務每月初結賬時間非常緊張）；
借誤的業務單據可以待處理正確后在下一個結算周期體現，如下圖：
付款關聯模塊
下面開始正式介紹付款方面的內容，按慣例還是上一個圖，我們先來看看付款涉及到的相關內容有什么，因為合同一直慣穿于財務系統，所以圖中沒有體現。
1. 供應商管理
應付主要是針對供應商的（平臺商家是代收貨款有些項有所區別），在供應鏈SCM中如何管理好供應商是非常非常重要的。
舉個例子華為芯片美國斷供事件，安卓系統版權問題還沒有結束，去年發生的中興事件也是鬧的沸沸揚揚。在這兩起事件中華為還是比較牛的，已經在國內培養了一批供應商，保證生產的正常運轉（我親友公司是給華為供貨的美國企業，現在比較尷尬正在極力想挽回華為這個大客戶）。
在生產型企業中對供應商管控尤為重要，對于電商中我們的供應商也要嚴格管控，資質的審核、商品質量的把控、到貨率的監控等，可以根據ABC法則來給供應商分類。
供應商分類與付款有什么關聯：通過供應商分類后不同的級別付款額度不同，可以有效培養各級別的供應商，增加后續采購過程中談判籌碼。
供應商權重指標：
- 到貨率
- 商品不良品占比
- 信用天數：合同賬期－庫存周轉天數
供應商財務付款狀態：
- 凍結狀態：財務可以根據此供應商應付余額信息與采購溝通，凍結此供應商，凍結后供應商暫停付款，同時需要輸入凍結金額與原因；
- 清戶狀態：如果供應商不合作，則需要清戶，此時開始清戶核算階段，不能進貨，可以退貨。
對于供應商管理，可以查看之前的《電商系統之供應商管理》總結。
2. 應付資金預算
財務資金預算是公司管理中的一個重要部分，先簡單看下完整的財務預算是什么樣的過程：
如果在FMS財務管理系統中做成這樣，需要買本預算管理的財務書先補習一下了；所以在我們的財務進銷存體系統中可以略去以上復雜的過程，簡單的做一個應付資金預算的模塊，可以包括以下幾個模塊：
- 財務組織與業務部門的映射關系表：每個業務部門可以確定其所屬的成本中心；
- 采購計劃表：根據歷史的銷售預測與采購數據來制定本期的采購計劃（計劃也是供應鏈中的重要部分，計劃不一定準確，但是有計劃比沒有計劃好），根據采購計劃表即可以得出預計的采購金額，從而推算出每期的應付計劃金額。；
- 應付資金預算：根據上面計劃得出的應付計劃金額，業務部門進行調整考慮促銷等因素，確定最終的資金預算，然后上傳到系統中由部門及財務審核。
3. 應付賬齡表與預警
- 賬齡報表：賬齡表可以統計出我們各期的應付金額，此部分在財務上屬于負債，最終會體現在的資產負債表中；報表中主要體現30天、60天、90天、180天的應付金額及占比；補充一句應收款也要有對應的賬齡報表。
- 預警報表：通過生成的結算單可以根據合同賬期提前預警應付的金額，可以以系統站內信方式休現出來。
4. 付款流程
在審批過程中設置各個節點，以確保付款單的正常及時流轉與付款金額的準確性，下面可以看付款審批流程圖。
（1） 結算單
結算單在上一篇中已經介紹，經過審核、對賬、稅票維護后便進入到待付款申請狀態中，這里就不多說了。
（2）付款申請
1）付款申請單生成：
已經進入到待付款申請狀態的結算單，可以生成付款申請單，多個結算單可以在一張付款申請單中，為了方便審核建議一個供應商的多個結算單在一個付款申請單中。
由于在與供應商合作過程中，可能涉及一種場景即和同一個供應商有多種合作模式，但是如果簽定多個合同，在前端業務系統處理計算會非常復雜，所以建議一個供應商編碼有效合同只有一個，如果有多個合作模式則建立多個供應商。
這便產生另外一個問題，即當多個供應商實質上是同一家公司時，財務如何控制風險？
解決方案：在供應商編碼上級增加一個父供應商，用父供應商的匯總數據來有效的控制應付款，降低我們的資金風險。
2）付款申請單審核：
根據審核規則：父供應商總應付金額為負數，或前面在供應管理中供應商為凍結狀態的，有凍結金額的需要進行判斷；供應商在清戶結算狀態要注意庫存金額等數據。
審核粒度：申請單是由結算單匯集的，所以我們審核的是結算單，結算單的狀態應該為通過或不通過的終結狀態后才可以生成付款申請單；這里可以自行設計原型與操作。
（3）付款單
當付款申請單生成后，需要再次確認生成付款單，對于付款單的數據來原有三種：
- 預付款：當需要預付款時，SCM中產生預付款申請單，審批后生成付款單；
- 質保金返還：錄入質保金返還單，審批后生成付款單；
- 付款申請單：審核通過生成付款單。
（4）對接銀企直聯
付款單應該與第三方銀企直聯對接，實現審批通過后自動付款，這樣能極大減少財務同事的工作量；但系統自動化則要求數據的準確性及審批流程的嚴格性。
總結
至此,財務應付部分涉及的幾個模塊（結算明細報表、結算單、稅票、付款流程）都介紹完了，每一部分的流程和關鍵環節做了說明，希望您讀后有所收獲，獨學而無友，則孤陋而寡聞，期待您留言，共同探討，感謝您的閱讀！
作者：倔強的大蘿卜；公眾號：倔強的大蘿卜
本文由 @倔強的大蘿卜 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
流程圖里的順序是：結算單審核通過收票后自動生成付款申請單。一定要把結算作為付款的前置條件嗎？
我以前公司是裝修行業的，付款申請單和結算單是獨立流程，未結算情況下也能發起付款，但會受合同約定的付款比例影響，如果結算了，那么按照結算金額計算總應付。
舉例：材料采購合同，預付款比例10%，進度款比例70%，結算比例95%，完工比例5%。
合同簽訂后即可發起付款申請，比例不超過10%；
有材料入庫后，付款申請單的應付金額是合同的成本價*數量的70%；
一旦結算單審核通過，應付金額就要按結算的金額計算。
正好在梳理我們公司的財會系統模塊，大蘿卜寫的很全面，給了我很多參考，這里發出來純粹是探討
付款申請單和付款單可以合并成一個單據嗎？
可以的，一個供應商或商家一個付款申請單，審核通過后直接付款。
上文提到付款單有3個來源，分別是：預付款申請、退款申請、付款申請單。
如果把付款申請單和付款單合并成1個，意味著以上3個來源的申請都要對接銀企直連。
其次，申請單的信息數量大，付款單的信息量少，只保留收款方、付款方和付款原因等少數字段。
我理解申請單給業務人員使用，審批過后生成給出納用的付款單。
付款流程中如果是線下付款線上記錄，當線下付款失敗時應如何處理呢？
線下付款線上記錄，這種情況一般是線下付款成功后手動操作系統更改付款狀態，失敗了可以重新發起（如果線下支付時與線上單據強綁定，這種場景可以重新生成一個付款單號）。
所有的付款流程都應該統一，這樣更容易控制風險
是的，非常贊同！標準化是軟件開發的一項重要原則。
關于付款這部分，有個問題想請教大神，訂單退款也算是支付里的一種么？
是的，這個屬于逆向流程，可以通一歸結到付款，但財務憑證掛的科目不同，要通過類型區分