起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識長文干貨丨從0到1搭建結算平臺
結算系統根據平臺的業務模式不同，大致有2個設計方向，重點是要保證結算效率與時效，同時保證資金安全，不要出現重復結算及資金結算倒掛的問題。本文從親身工作實踐中，總結了O2O電商結算平臺建設的實操與設計思路。
一、概述
我們最開始分享了O2O電商支付清結算體系，接著分享了如何從0-1搭建計費體系，接下來我們分享：各方的錢算完之后怎么付出去，也即結算平臺建設的實操與設計思路。
1.什么是結算？
說結算平臺之前，先說一下業務上的結算概念，結算顧名思義就是平臺把系統計算好的資金結算給對應的供應商、分銷員、勞動者等交易參與方，資金結算主要有2種結算方式：
第一種也是看起來最簡單的：平臺線下轉賬給被結算對象，業務前期階段，業務量不大的時候這樣運轉還行，后續隨著業務的起量，極大概率會出現結賬周期時全員變財務/核算、打款出錯、下游結算對象催打款等一系列問題。
第二種也就是本次要分享的：通過系統手段，線上自動打款給下游結算對象，根據實際業務的需要，線上又可以打款至微信、支付寶、銀行卡（對公/對私）、平臺賬戶，線上結算搭建完之后，可以把結算能力放給所有的業務線復用。
2.結算平臺的落地形態
上文解釋了業務上結算的概念，技術上結算系統就是根據業務實際需要而搭建的實體化系統設施，通過系統化手段在線完成資金的打款發放。
結算平臺與計費系統作為清結算體系中重要的組成部分，計費平臺把訂單的業務信息流轉變成轉化為資金信息流，結算平臺把資金信息流轉化成實實在在的結算資金流。
在多業務線、多種結算類型的平臺中，結算平臺可以做成通用的中臺系統，單純作為資金出款的統一出口，至于結算到平臺賬戶還是微信/支付寶零錢，又或者是銀行卡賬戶，都依賴于業務側計費系統的通知，結算平臺只是執行結算指令（如上圖所示），同時做好資金風控兜底，防止資金結算倒掛。
搭建結算平臺的優點是結算平臺可以制定統一的接入規范，各業務系統統一對接結算平臺即可，無需再對接底層通道或賬戶中心，大大降低系統重復對接開發量。
注：可能會有人會說這種系統架構，平臺涉及到“二清”問題，確實會涉及到，但大公司有牌照不會有這個問題，其他公司如果不是大額融資或者上市大概率也不會涉及到這個問題，個人覺得在公司體量沒有到達一定級別前，不要太糾結這個點。
后續也會分享平臺“二清”的解決產品方案，可以期待下。
二、結算平臺系統架構
不同公司根據業務模式與技術組織架構的不同，所適合的結算系統間架構也不同，在這分享自己參與過的也是比較常見的2個系統架構，詳見下圖：
系統架構1（O2O自營B2C電商）
說明：上圖是我們當前正在用的結算系統架構，因為公司存在多條業務線，且不同業務線在完成訂單清算后流程不同，有的需要平臺進行結算單調整/審核，有的業務線則不需要，所以結算調整/審核相關的模塊，統一放到了業務側，結算系統最終只負責結算打款的職能，作為一個資金出款的前置通用系統，放在中臺體系內，各業務系統統一對接結算平臺。
系統架構2（類自營B2B電商）
說明：上圖是我之前公司經歷過另一種系統架構，與圖1的區別除了需要發票相關的模塊（灰色）之外，最大的區別就是把結算單調整/審核相關的功能，統一放到了結算模塊中，因為所有的業務線關于清算之后的流程是相同的，可以抽象為一個統一的模塊，計費模塊單純完成費用計算即可。
當然以上2個系統架構也不是萬能架構，算是比較通用的2種設計思路，但如果公司業務比較簡單，可能都不需要分成2個系統，直接計費與結算放在一個系統就OK，每天念三遍：系統不重要，業務最重要。
系統交互流程說明：
以上2種系統架構，系統間整體交互流程很相近，第一步各業務系統的計費模塊完成各種資金類型的清算計費，根據清算結果生成結算單，完成結算單調整確認后，請求結算平臺統一結算接口，結算系統根據業務側所需結算方式，請求底層支付平臺或帳戶中心接口，完成賬戶中心入賬或通道打款，下文也會詳細說明。
小結：結算模塊的整體系統架構大同小異，具體采用什么樣的系統架構一定要根據平臺自身的業務需要，整體原則是：以滿足業務為前提，追求系統通用，防止重復造輪子。
三、結算平臺系統搭建
上文我們分享了結算平臺的系統架構，接下來分享怎么從0到1真正落地搭建起1個結算平臺，我接下來會把上文中的2種系統架構，都展開說下，2者可以互相結合著看。
下文主要從4方面展開：業務流程、系統交互流程、頁面原型及核心規則、關鍵接口說明。
系統架構1（O2O自營B2C電商）
1.業務流程
上圖為O2O自營B2C電商勞動者薪資報酬結算業務流程，首先說下這個流程不是通用的，各平臺可根據自身提供服務的標準化程度及履約復雜度靈活調整，例如滴滴與外賣配送是非常標準的O2O服務，結算環節不需要審核，直接結算即可，但比較復雜的家政服務與互聯網裝修服務，肯定會加上比較多審核確認環節。
2.系統間交互流程
上圖是各業務系統與結算系統間的交互流程，這里的業務系統包括不限于各業務線計費系統、勞動者獎懲系統、分銷平臺等等。
此架構下，各業務系統與結算系統的交互相對比較簡單，業務系統只需要傳輸對應金額、結算渠道等核心參數，結算系統請求下游系統即可。
3.頁面原型及核心規則
以O2O自營B2C電商的系統架構為基礎的結算系統，頁面原型相對不會太多，因為主要系統模塊都已經被上游業務計費系統承擔，忘記的可以去看下計費系統搭建的內容回顧下，原型主要分為2部分：
平臺側：費用類型管理、結算規則配置、結算記錄如下圖：
（1）費用類型管理
因為后續分享賬戶中心的時候也會用到費用類型，這次先重點說下:
費用類型的含義及作用：費用類型表象上就是結算資金的名稱，簡單來說這就是是一筆什么錢，再往上抽象一層，1個費用類型代表了業務的1個計費場景，對應了一個具體的計費規則（前提是費用類型顆粒度要足夠細化）。
他們之間的關系如下圖簡單舉例：
- 業務場景：費用類型=1：1或1：N
- 費用類型：計費場景/規則=1：1
費用類型的命名原則：簡短同時要能反映費用的業務屬性，賬戶中心記賬的時候，賬務流水就會很清楚，勞動者可以很直觀地就知道這筆錢的因為什么進來，這筆錢為什么被扣掉，如下圖所示：
費用類型在系統間流轉過程：當上游業務側新增一個計費場景時，結算系統會新增1個費用類型，具體新增費用類型的運營流程，看自己公司要求，結算系統配置完成后，將費用類型編碼同步至業務側，業務系統需要將此編碼維護在系統中。
當此費用類型的資金進行結算時，需要傳費用類型編碼ID，同時如果需要結算到賬戶中心，則賬戶中心也需要同步添加費用類型編碼，因為賬戶中心需要根據費用類型編碼確定入到哪個賬戶中，流程如下圖：
（2）結算規則管理
結算規則說明：費用類型新增之后，需要為費用類型配置結算規則，結算規則的主要作用是確定此費用類型的結算渠道，即結算到勞動者的微信零錢還是銀行卡，亦或是平臺賬戶中，如果要結算到平臺賬戶，還需要在賬戶中心配置此費用類型的入賬規則及凍結規則，確定費用類型入到哪個賬戶及要不要凍結，流程見下圖：
從上圖可以看到，一個費用類型可以配置多條結算規則，但業務系統請求結算系統接口時，會根據業務線匹配唯一結算規則，防止重復結算，若結算時未匹配到結算規則，系統會直接報錯。
有一個點需要注意的是，如果平臺內資金結算渠道只有一種，所有的費用類型都只結算到銀行卡或者平臺賬戶，則不需要配置結算規則，直接系統寫死即可，甚至可以不要單獨做結算系統，沒有意義，因為此系統架構下結算單生成/審核/調整都已經與計費模塊融合，由計費系統（不僅僅是計費）直接請求底層通道或者賬戶中心即可。
歸根結底一句話：視自己平臺真實業務需要，做對應系統建設，忌自嗨、忌華而不實。
（3）結算記錄
O2O電商結算有一個特點，都是按訂單逐筆結算，即勞動者完成服務，工資報酬即結算至平臺賬戶，然后各平臺根據各自業務需要，設置提現窗口期或設置凍結時間。
上述原型圖中有兩個字段特殊說明下：
- 一是【訂單號】，逐筆結算的結算記錄一定要加上訂單號，運營有問題找過來的時候，大多數只發個訂單號過來，同理賬戶中心也要加訂單號（有的話）。
- 二是【結算狀態】，要以最底層出款通道或賬戶中心的最終入賬結果為準，不能業務系統請求結算系統接口成功了就返回上游系統結算成功，可以異步通知慢點兒，不然可能會造成上游業務系統顯示的結算結果有誤。
4.關鍵接口設計
結算系統最核心的就是結算的接口，各業務系統請求此接口，完成資金的打款結算，下圖是接口入參必填參數，根據結算渠道的不同，業務系統需要傳對應參數進來，例如結算到微信要傳openid、結算到銀行卡要傳銀行卡號、開戶行等等，這個直接看底層通道需要什么參數即可，不再贅述。
系統架構2（類自營B2B電商）
1.結算業務流程（類自營電商B2B）
這個系統架構與系統架構一（O2O自營B2C）業務流程比較大的區別在于，因為業務模式與結算金額（多筆合并結算、大額）的原因，結算單審核/調整成為了一個必要流程，并且部分平臺還會涉及到開票流程。
開票流程又分為2種：
第1種：先開票后結算（上圖），即商戶側根據平臺推送的結算單開具發票并上傳，平臺發票審核通過后，方可進行實際資金結算流程，這個方案的好處是優先保證平臺的利益，同時也降低了結算單與發票金額數據不一致的概率（結算單金額與發票金額），降低后續運營與商戶的人力負擔。
第2種：開票與結算相互獨立，無明確先后流程，好處是可以保證結算時效，商戶側的資金回款效率與結算體驗更好，壞處就是上個流程中的好處，大家可以根據自身平臺需要選擇合適的方案。
2.結算系統間交互流程（類自營電商B2B）
上圖是類自營B2B電商結算系統交互流程，我用的是計費模塊和結算模塊，而不是系統，因為他倆可以放在一個系統，特別是業務線不多，計費模式與結算類型都比較單一的平臺，完全沒有必要做2個系統。
單獨說一下結算單生成的時間點，比較常見的方案是：根據約定的賬期，在賬單日通過凌晨定時任務生成本賬期結算單。
還有另一個方案：進入到下一賬期即生成結算單，舉例：T月賬期過去，進入到T+1月1號即生成T+1月的結算單，數據清算完成即填充數據至結算單，只是這個結算單不會推到商戶后臺，只在平臺側展示，但是賬單的總額數據可以展示給商戶側，以便讓商戶知道自己T+1月的數據概覽情況。
3.頁面原型及核心規則
此系統架構下，平臺側頁面原型主要分為計費管理、結算單管理、發票管理，計費管理主要是完成訂單資金計費，生成清算明細數據，上一篇計費系統從0到1搭建已經詳細介紹過，不再贅述。
商戶側后臺主要有結算記錄與發票管理2個功能模塊，模塊展示的信息和平臺側基本一致，大家可以直接看平臺側相關原型內容，也不再贅述。
（1）結算單管理
關于原型圖和規則主要說幾個點：
上圖中三個狀態字段的關系：結算單狀態、發票狀態、結算狀態，3個狀態依賴與先后關系如下圖所示：
結算單導出內容：因為對公結算多是匯總軋差結算，所以結算單導出后是一條條計費明細，包括正向與逆向數據，最常見的結算單就是三方支付機構給的結算對賬文件，結算單導出后如下圖所示，可以根據自身需要增刪字段：
結算單生成規則：以商戶為緯度，以賬期為時間范圍，把發生在此賬期范圍的所有費用類型的計費明細數據寫入商家對應結算單中。
結算風控：一是結算系統要防止資金倒掛，即結算單中各訂單累計金額要大于等于結算金額，做兜底，二是防止訂單逆流程帶來的資金損失風險，例如平臺承諾7天無理由退貨，如果賬期是5天，會存在資金已經結算至商家，即便扣除商家保證金，退款資金仍然不夠的風險。
解決方案有幾個方向：限制結算賬期、限制結算金額（有風險的結算金額不能超過保證金兜底的金額）、入駐合同中約定好商戶資金不足，平臺墊資的資金怎么處理，可以根據平臺實際情況選擇對應方案。
（2）發票管理
說明：結算單審核通過后，商家在后臺上傳發票圖片，財務在平臺側【發票管理】完成發票審核/核銷，沒問題后結算模塊請求底層賬戶中心或支付平臺完成資金結算，同時商家側快遞紙質發票至平臺，如果做的再完善些，平臺還可以對接快遞的接口，可以在后臺查看快遞進度。
4.關鍵接口說明
接口部分與上文的O2O自營B2C電商的系統架構很相似，直接看上文即可，不再贅述。
四、總結
結算系統根據平臺的業務模式不同，大致有我上文中的2個設計方向，整體復雜度可控，重點要保證結算效率與時效，同時保證資金安全，不要出現重復結算及資金結算倒掛的問題。
未完待續，下一篇分享《從0到1搭建賬戶中心》。
本文由 @鯨爺陸 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
請教一下，如果交易已經結算后用戶又進行了退款，這種結算后退款在結算處理過程中怎么處理啊
紅沖
學習了
我們也在做一個分賬功能，現在遇到最大問題是接入的微信分賬只能分賬30%給用戶，線下打款要承擔6%的稅點，很頭疼
找一個三方支付公司，接代付產品就沒這個限制了
很詳細 學到了