支付完成以后需要進行履約結算，那么如何設計一個結算系統？結算的流程是什么樣的？不同場景的結算系統設計有什么區別？本文結合7個真實的案例，與大家探討結算系統的設計方法，希望對你有所啟發。

支付完成以后進行履約，履約完成以后就需要清算各方利益并最終進行結算；清結算體系與支付體系并行是支付范疇另一個非常龐大的體系。

其中的結算就是根據債權債務關系，進行最終資金交付的過程，可以將需要收客戶的錢收進來，也可以將企業的錢支付給客戶，結算系統就是對這個過程進行管理的系統。

就比如，每個月公司要給員工結算工資；陳老師在京東開了一個店鋪，定期京東需要給我結算貨款；你請了一個保姆，每個月要給阿姨結算服務費，企業采購了一批設備要給供貨商結算貨款等等，這些結算場景我們并不陌生。

但是怎么設計一個結算系統？結算的流程是什么樣的？不同場景的結算系統設計有什么區別？在整個結算系統的設計過程中我們還要去要思考下面這些問題：

（1）結算依賴的源數據是什么

結算所依賴的數據的來源，就是結算系統以什么數據為依據生成結算單據，比如可以以訂單數據為依據，可以以賬務數據為依據，可以以人工提交的結算數據為依據，來做為應收應付的來源數據。

（2）結算信息數據從哪里獲取

結算給誰，結算對象的基本信息以及結算收款卡信息等等，往往并不會存儲在結算系統，而是存儲在其他系統中，所以需要建立結算系統與其他信息系統的聯系，以獲得結算需要的基本信息。

（3）結算單該如何設計

有了結算數據以后，那么結算系統的核心單據“結算單”如何設計，有哪些結算單的類型，每種結算單的具體內容有哪些，每種結算類型的結算流程是什么。

（4）結算模式的有哪些

• 就是結算系統支持的將款項結算到對象的什么對方，是卡還是內部虛擬賬戶
• 結算到銀行卡：直接將結算款項直接付款到商家簽約的結算銀行卡賬戶中
• 結算到虛擬戶：將虛擬結算款結算入賬到商家在平臺開通的結算戶中，后續可以商家自主提現

（5）結算周期該如何約定

整個結算業務所支持的結算周期管理有哪些模式。

• T1結算：工作日結算，當天的服務款，在下一個工作日結算
• D1結算：日然日結算，當天的服務款，在下一個自然日結算
• D0結算：日然日結算，當天的服務款，在當天結算
• S0結算：交易完成后即可結算，按照訂單號逐筆進行結算，像借貸的還款，一般逐筆
• 還有按周結算、按月結算等等

（6）結算有誰來發起

用戶可以選擇系統自動結算，也可以選自主發起結算。

• 自動：系統按照結算協議，在約定時間自動將服務款支付給結算卡
• 自助：商家需要自主的在服務平臺完成可結算周期內的款項的結算申請

（7）稅、票、內部單據是否需要關聯

結算過程還需要考慮是否需要基于結算單做稅務的處理、發票的匹配、以及與內部出入庫驗收單等等進行核銷或者匹配校驗。

（8）付款模塊如何接入

結算單最終要發起付款處理，結算單跟付款單之間的關系要規劃好，另外就是結算單到付款單整個正逆向流程的設計。

（9）賬單怎么提供

結算了多少錢，什么時候結算的，結算到哪里了，結算了哪些債務或者債權，需要提供結算相關的賬單給到客戶，賬單里要列明商家關。同樣還需要考慮賬單如何提供給客戶，是否郵件、系統內自主下載還是接口接入下載。

下面我們將通過過幾個真實案例給大家展示結算系統的設計方法，從這些不同場景下的結算系統設計案例，我相信大家可以深刻的體會到——哦，原來如此！

01 企業福利平臺結算系統

我想大家在公司都收到過一些消費券或者購物卡，有時候還指定消費場所或者平臺，這就是企業的員工福利了，而企業發放福利的成本是可以用以抵扣所得稅。

國稅總局《企業所得稅法》相關條例，企業福利員工薪酬的14%，工會福利員工薪酬的2%，教育經費員工薪酬的8%，可以免征企業所得稅。

但是，企業的福利管理如果單單企業自己從采購商品、制定各種卡或者券，管理和監控員工的使用等事務是相當繁瑣的，這樣，針對這樣的企業需求場景，企業福利平臺就營運而生了。

企業福利平臺以合規稅籌為基本，在經營范圍允許的基礎上，以多賬戶支付體系為核心，為企業提供企業福利和稅優解決方案，實現B2B2C業務從預算到核算的管理閉環。

福利平臺的業務模式是這樣的，企業購買平臺福利產品（簽采購合同），以虛擬戶的方式充值到企業賬戶，企業以積分或額度或者卡的方式發放給員工，平臺根據企業購買的福利產品給員工配置消費通路，員工在c端進行消費，平臺從中賺取平臺服務費或商品利潤。

1.1 結算業務流程架構

根據以上場景描述，企業福利結算中心分為企業（客戶）結算和商家結算，來闡述企業結算系統（以企業集采為例）。

企業集采說明：企業購買一批兌換券，由員工自主兌換，平臺提供后續服務。

B端業務，多為銷售和企業簽訂銷售合同然后在銷售系統下單，銷售系統把相關信息傳給結算中心，結算中心為銷售系統提供收款、開票和財務入賬服務。

企業結算根據企業的實際的預算和合規性需求，業務結構如下：

商家結算-應付，員工消費/兌換商品后，產生交易單，交易單匹配費用規則請求清算至商家賬戶，商家根據具體結算周期在商家系統發起結算，具體結算流程如下：

1.2 企業結算單管理

企業結算單由銷售單發起生成，結算單產生后發起后續的收款、開票流程；

單據及相關簡述：

結算單查詢頁面：

1.3 收款管理

依托待付款的結算單發起付款流程（乙方向甲方付款）收款流程。

收款管理，提供收款單查詢，記錄外部收款流水，記錄收款核銷詳情，是后續與外部資金系統對賬、與開票數據進行對賬的依據。

單據及相關簡述：

收款單查詢頁面：

1.4 發票管理

依托待開票的結算單發起開票流程：

收款發票核銷：由于收款和發票都是關聯在結算單上，一個結算單會對應多個收款記錄，也可能會對應多個發票記錄，固發票和收款會是多對多的關系，為了方便財務入賬（此流程可根據公司具體財務需求），建立了發票和收款核銷流程。

單據及相關簡述：

外部對接發票系統，提供自主開票申請功能。

1.5 應收對賬

提供針對結算中心的業務實績，根據業務場景實際需要，定期與相關業務系統對賬，同時可提供查詢或下載相關業務交易明細，供相關方對賬核對。

02 政務服務平臺結算系統

在政務服務領域中，終端機作為政務服務的重要承載體之一，被廣泛運用在各個服務大廳。作為政務服務服務企業，會隨項目而起定期向供應商采購終端機。

終端機的采購流程，先由項目經理在經營管理系統中填寫采購合同，經過審批、采購、驗收，最后入庫，便可以批準供應商的發票支付款項。

有了終端機，運維那是必不可少的。對于終端機較多的區域，部分運維工作是直接外包給其他公司。但有部分地區的終端機較少或者分布較散，這種情況會將運維工作外包給個人。

運維工單的發起一般分3種場景：固定的定期檢查工單；市民掃碼填寫提交的報障工單；以及終端機的運維監控系統推送的終端機異常工單。

2.1 結算業務流程架構

當終端機采購入庫并驗收之后，采購訂單則會更新訂單狀態已完成。由于這類項目的周期較長，回款較慢，因此一般以采購結束后3個月為周期對供應商款項進行結算，所以系統會根據采購訂單的狀態自動記錄結算時間，生成結算賬單。

維修工單由區域項目經理在工單系統審核通過后創建維修單，派單給該外包公司或者個人前去維修，驗收通過后則生成結算單。

結算單生成由供應商開發票，在系統中發起結算生成結算單（結算單必須包括合同、發票、驗收單、入庫單），再推送到財務系統通過財務打款。如果是個人外包，則通過代付通道一月一結給服務方。

2.2 結算系統產品架構

結算配置：對不同的結算對象進行不同結算規則的配置，如供應商結算、運維外包個人結算、運維外包企業結算等，以供結算單模塊根據需要生成賬單。

結算單：根據不同的結算對象匹配相應的結算規則生成結算單，審核通過后推送到財務進行結算。

賬單模塊：供財務進行篩選查詢各類型已完成結算單情況。

2.3 主要單據和原型

計算系統的主要單據是結算單，財務中心根據審核通過的結算單進行款項結算，結算完成的賬單將流入賬單模塊。

結算單來自兩個方面，一方面是終端機的采購合同，一方面是外包運維人員的維修單和合同。

對于終端機采購合同，當合同進入采購流程之日起計算，往后推三個月的日期為“原定付款日”，一般情況下，“原定付款日”與“實付日期”是一致的。當特殊情況下，如終端機審核不通過需重新驗收或者在運輸過程中出現延誤等情況需要修改付款日期則“最新付款日”與“實收付款日”一致。

對于運維外包，會定期對個人或企業已通過驗收的工單做周期結算，生成結算單。若外包企業或外包個人需提前作結算，可在系統中發起結算單申請，由相關人員審批通過生成結算單。同樣，針對這類情況，“原定付款日”為合同中的日期，“最新付款日”與“實付款日”一致。當結算單審核成功扭轉到賬單模塊且打款成功，接口返回“實付款日”并結算單狀態變為“已完成”。

結算規則配置：

結算規則包括ID、結算單類型、結算對象、結算周期、結算方式、創建時間。個人與企業的結算方式不同，結算給個人一般不用發票，走代付通道。而企業則需要上傳發票到系統進行審核，最后銀行打款。

結算單與結算規則：通過結算單類型來進行匹配，再確定結算對象是個人還是企業，最后通過不同的結算方式來生成不同的結算單。

新增結算規則：

03 推廣平臺結算系統

別字君

分銷推廣行業，大家聽起來可能比較陌生，但或多或少都有接觸過?；ヂ摼W剛興起時大學校園里和大街小巷的APP拉新見過不少吧，經久不衰的地推模式，以及現在網上五花八門各種形式的網推，這就是分銷推廣行業的線上線下營銷組合拳。

別看這個行業好像挺少見，專業分銷推廣玩家賺的真不少，現在市面上就有許多聚合推廣平臺，左手引項目，右手拉代理，年收入百萬不成問題。

假設我方是一個叫“推光光”的聚合推廣平臺，對接引入了高速ETC、POS機、信用卡、養老金賬戶4個項目可供推廣，平臺有3位拓展專員負責發展、培訓種子代理，再由種子代理去幫平臺推廣項目或者發展下級讓下級去推廣。

3.1 結算類型

該行業涉及到要結算的錢有兩大類，傭金類和設備押金類。

（1）傭金獎勵結算

不同角色，結算傭金獎勵的模式不同。

對拓展專員結算：拋開工資，我們跟拓展專員要結算的主要是績效，而績效的多少則與他所服務的種子代理質量掛鉤。

種子代理的質量如何評估，單純地按業績粗暴地計算太過簡單了，不利于平臺的可持續發展。為了激勵拓展專員更好地培養和扶持種子代理，除了看代理的業績總數外，可以從這幾個維度去評判，如新增團隊人員數量、團隊出單總數、團隊人均出單數、團隊有效代理數等。

對種子代理結算：種子代理的合作模式主要有2種，一種是直接拿一個底價假設100元，然后放給下級更低的價格90元，中間吃差價10元。此外就是跟平臺對賭，100元直接平放給下級，然后達到某個條件平臺給額外獎勵，反之懲罰，具體看商務合作模式。

由此延伸出種子代理的結算款項也分2種，一種是下級們做單出業績種子代理的差價分潤，另一種則是基于某個條件平臺給予的獎勵。

對普通下級代理結算：對于普通下級代理，最主要結算的錢就是出單的傭金，而且結算到賬要快，讓他們“有實感有快感”。

如平臺有任務體系的話，也會有對應完成任務的獎勵結算。

（2）設備押金退款結算

像ETC和POS機這一類項目的推廣，是離不開硬件設備的，因此有些代理為了現場推廣，或是對庫存和發貨有一套標注要求，往往會從平臺交押金“拿貨”。

后續不合作的時候，就需要根據設備的實際消耗和損耗情況進行設備押金結算。

3.2 結算業務流程架構

業務起始于拓展專員發展出種子代理，并為其配置對應的產品權限之后，種子代理即可去發展下級和進行營銷推廣。

代理營銷推廣之前如要拿硬件設備，則先交納對應的押金，獲取拿貨額度，然后提交拿貨申請，則扣減拿貨額度。

拿到貨之后正式開始展業，根據產品不同，每成交一單，則會給傭金賬戶結算入賬一單的錢，對應上級也會收到差價分潤。代理所屬的拓展專員也相應新增一單業績記錄。但是這里有一個特殊場景，既有時候這個結算是會增加某些限制條件，比如你需要保證高速ETC推廣的車輛的真實性，因此對訂單可能有一個審核機制，審核通過才會結算入賬。

結算的時效也有不同，有的代理走個人結算，因此秒結算到傭金賬戶，隨時可以提現到個人銀行卡，走代付通道。而有的代理是走企業開票結算，就不能自主提現了。

3.3 產品架構

結算模塊本身不是很復雜，主要是約束好結算的規則和生成對應的結算賬單。但是他依賴的上游系統比較多，數據也比較雜。

3.4 主要單據

根據不同的角色要結算的內容不同，結算單據的設計也有所不同，但還是能抽離出部分公共字段，如結算單號，結算對象、結算時間、結算類型和結算金額。

再根據不同的結算類型，定義所需的不同結算內容，最終根據結算對象和內容結算., 到虛擬戶后自行提現或者是進行打款。

3.5 主要頁面原型

由于代理數量眾多，實際運營不可能每新增一個代理就多一條結算規則，幾千上萬個代理會讓運營人員崩潰，因此結算規則的設計最好把”結算對象”轉移至渠道代理系統，由代理系統的每一個代理來關聯結算規則。

這樣做的好處是我只需要配置一條通用的規則，代理注冊進來的時候默認關聯該規則。此后如有特殊代理，再由市場端提申請給運營端進行修改配置即可。

04 銀行收單業務結算系統

銀行收單業務大家都不陌生，就是待商戶收款，并結算給商戶。那么這個過程中有一個非常重要的環節，就是商戶結算。

結算，顧名思義是指收單系統對前一個結算周期內商戶產生的交易的軋差匯總，進而產生一筆結算單，最終通過銀行核心系統或者人行二代支付系統等渠道將款項打款給商家。

結算是收單過程中最后一環，也是最重要的一環。結算的金額不準確或到賬時間不及時，輕者會給商家帶來不必要的麻煩，重者可能會引起客戶投訴，影響到銀行聲譽。

結算業務需要一系列的賬戶來實現，我們先看下幾個賬戶。

商戶基本戶：該賬戶是虛擬賬戶，在銀行核心系統中不存在，僅僅是收單系統的登記簿，在商戶入網成功后自動生成的。收單系統除了商戶基本戶外，還有商戶待清算、待結算、已結算賬戶，這類賬戶從屬于收單系統，用于支付、退款等場景的清分記賬。

商戶結算賬戶：商戶攜帶個人或者企業相關證件去銀行柜面開立的銀行賬戶。當商戶類型是個體工商戶時，結算賬戶一般是指個人的銀行卡，當商戶類型是企業時，結算賬戶是指企業的對公賬戶。

4.1 結算模式和流程

（1）結算模式

打款至商戶結算賬戶。

商戶入網時一般要求開立本行結算賬戶。如果商戶選擇打款至結算賬戶，收單系統會調用本行核心系統進行打款。當結算單比較多的情況下，一般會調用核心批量打款接口，待核心系統處理完畢后再根據核心處理結果更新收單系統結算單狀態。

打款至商戶基本戶，再通過提現方式提款。

由于某些場景需要會選擇打款至商戶基本戶，再通過提現方式提款。一般對接外部平臺時，銀行為了資金沉淀，獲取低成本的存款，同時平臺為了獲取協議存款利率，要選擇該種結算方式。

根據結算單通過調用核心系統將結算金額打款至銀行監管賬戶（銀行內部戶），此時每個商戶可以看到自己的基本戶有相應的余額，所有商戶的余額總和與銀行監管賬戶余額一致。最后系統通過自動提現或者商戶手動提現的方式將余額里的錢從監管賬戶提出。

（2）結算流程

銀行開展收單業務，為了獲取低成本的存款，一般要求商戶使用本行的銀行賬戶進行入網。為了滿足不同的場景需求，收單系統一般支持兩種結算方式，一種是直接結算到商戶的銀行賬戶，另外一種是結算至商戶的基本戶，再通過自動提現或者商戶手動提現的方式將基本戶余額提現至綁定的銀行賬戶。無論哪種結算方式，都需要先生成結算單。

4.2 結算規則

收單系統中的結算設置主要是提供給運營人員配置商戶結算規則的。結算規則包括商戶收款開戶行的相關信息、結算周期信息、結算類型信息、結算打款方式、最小/最大結算金額、留存金額等內容。

結算周期設置，系統支持T+0、T+1、T+N、D+0、D+1，支持節假日結算。每種結算周期對應不同的應用場景，為了留住優質商戶一般會采取T+0或者D+0，為了平臺型商戶的資金留存，一般采用T+N的結算周期。

結算類型信息，支持實收（軋差結算，實扣手續費后結算）。

結算打款方式設置，支持打款至商戶結算賬戶或打款至商戶基本戶，后再通過提現方式將基本戶里的余額再提現至商戶結算賬戶。

最小/最大結算金額設置，當商戶當日的結算金額小于設定的最小結算金額時，當日系統不自動生成結算單，金額累計至下一日，當某日累計金額達到最小結算金額時才參與結算。當商戶當日的結算金額大于設定的最大結算金額時，當日系統生成的結算單會標記為紅色對結算人員進行提醒。

留存金額是指應結算金額與實際結算金額之間的差額。留存金額的結算將通過單獨的任務執行。

4.3 結算單生成

在到達設定的商戶結算周期時，系統會自動生成商戶的匯總結算單，運營人員可根據商戶、單號、時間等信息進行結算單查詢，可查看匯總結算單中的結算明細數據，如果發現結算的明細數據中存在有疑問的訂單，可將訂單設置為存疑狀態，存疑狀態的訂單將不參與本期結算。

對于生成的結算單如果不存在其他問題，則由運營人員進行審核，結算單審核后系統根據商戶結算規則設置中的結算方式打款。

05 積分電商平臺結算系統

項目為平臺型的積分電商系統，商家可入駐到平臺進行線上線下同步商品銷售，用戶可以通過到店自取、第三方本地配送和物流配送等方式完成商品購買。

商家在平臺填寫入網信息審核成功后，將會在第三方支付平臺和自有系統內開通結算賬戶，訂單支付成功賬戶將記錄凍結金額，當訂單確認收貨時，訂單履約系統將會請求清算系統將本筆訂單的實際支付金額和積分抵扣部分扣除退款金額分攤計算，并生成清算賬單，賬單內將會記錄商家現金結算賬戶金額、營銷補貼賬戶金額和平臺抽傭金額。

在出賬單后商家可以選擇賬單發起提現或等待系統自動推送至結算系統，結算系統內會進行一次對賬，核對賬單金額是否有誤；審核成功后系統將賬單所對應的訂單號分別請求第三方平臺分賬和代付接口，扣除傭金后金額分別結算商家，在T+1日最終金額結算至商家銀行卡/對公賬戶。

5.1 結算業務流程

系統生成賬單后即可發起結算，第三方每日下午15:00推送央行結算，系統需要在每日下午14:00前分批推送訂單至第三方，金額將在T+1日到達商家銀行卡/對公賬戶，第三方返回結算成功后，平臺將結算單和賬單執行變更狀態為已結算。

5.2 主要頁面原型

結算單根據商家主動發起賬單提現或系統自動執行賬單提現而生成，結算單內包含結算方式（實付->分賬，積分抵扣->代付），實付部分的傭金結算至平臺賬戶，積分抵扣部分為平臺營銷補差，傭金平臺記錄為虛擬金額，扣除該部分剩余為需要補貼商家金額，通過代付結算至商家賬戶。

06 高速ETC平臺結算系統

自1996年首都機場高速公路進行ETC試驗以來，高速ETC在我國已有27年歷史了。早期推廣的時候ETC卡還是先充值后通行的儲值卡，就像地鐵卡公交卡一樣，不夠錢無法通行ETC?，F在比較常見的大部分都是先通行后扣款的記賬卡了，除了歷史遺留的儲值卡和廣東還有少部分針對港澳車輛辦理的儲值卡。

那么對于主推記賬卡的發行企業來說，主要結算的大款項就是ETC通行費用，結算的規則也因合作而異。

結算周期不同：有的要求D0結算，當天的通行文件當天結算并打款，有的D1甚至可以T1結算，當天的通行文件可以第二天甚至第二個工作日結算并打款。

墊資模式不同：常規的合作方都要求全量通行賬單結算回款，無論發行企業是否能正?？鄣接脩舻目?，少部分合作方愿意按實際扣款成功后再結算通行費用，但是也有一定的時間限制以及需要有兜底方案。

結算方式不同：因為ETC通行費用是存在“ETC退費”情況（ETC退費，指的是由于各種原因如優惠政策，需要給用戶退錢），因此除了通行賬單，還有退費賬單。這種情況一般都是進行凈額結算，即通行費用和退費費用軋差之后再結算給合作方。但也有的合作方追求“收支分離”，因此需要全額結算，退費部分再單獨結算。

結算業務不同：有的合作方需要不同的項目組（如客車、貨車；停車、高速、輪渡等）分開結算，有些則一筆結算即可。

6.1 結算業務流程架構

用戶ETC通行之后，每日通行賬單模塊會定時去合作方的FTP獲取ETC賬單，獲取到賬單后解析關聯匹配對應的車輛，創建賬單向用戶發起路費扣款，扣款失敗或有特殊費用，則請求清算計費入賬到對應賬戶。

接著高速ETC結算系統會根據不同合作方配置的結算規則，統計生成對應的通行結算賬單，并把結算賬單推送給打款中心，由打款中心負責完成最終的出款。由于通行費賬單金額比較高，不建議采用高自動化打款，采用人為發起打款申請，再復核審批后打款為宜。

6.2 結算系統產品架構

高速ETC結算系統包含如下子模塊。

ETC結算配置：提供針對不同合作方，進行不同結算規則的配置的能力，如結算周期、是否區分業務線、凈額結算還是全額結算等，以供結算賬單模塊根據需要生成通行對賬單。

ETC結算賬單：有了不同的結算規則之后，定時任務按照配置的規則進行統計，生成ETC通行應付賬單和退費應收賬單。退費應收賬單是針對于全額結算的合作方當發生ETC退費的時候，由對方來付款給我方。

打款模塊：打款模塊根據應付賬單發起打款申請，并進行審核之后根據打款配置進行出金。

賬單對賬：按月匯算ETC賬單的總筆數和總金額，以供財務每月進行對賬。

6.3 結算系統主要單據

高速ETC結算系統主要單據為“通行賬單結算單”，以該單據為核心每日推送給打款中心進行打款。

上文我們提及到該結算單的原始數據是來源于“通行賬單模塊去合作方取的ETC賬單數據”，然后根據結算規則生成結算單。

基于上述情況，賬單數據來源各種原因（如網絡波動我方漏取、他方漏發、解析故障）有那么一點兒不穩定，而通行賬單有一個“賬單日期的概念，也叫請款日期”，打比方1月1號0點-23點59分合作方原定會發100筆ETC賬單給我們，那么這100筆ETC賬單的賬單日期舊是1月1號。

但是由于某種原因我方取到賬單的時間推遲了2天，那么這100筆賬單的“賬單日期”并不會由此變為1月3號，他依然屬于1月1日的，只不過我們的結算日期會相應推遲而已。

因為這種情況往往不能被第一時間被發現，為了應對這種特殊情況，我們將“通行賬單”和“通行賬單結算單”進行了解耦，正常的流程正常發起，而當發現有過往日期 “漏賬單”的情況，則啟動補償機制，將漏掉的賬單重新生成結算單，并再次補付款。

雖不想面對，但是有少付就可能有多付，那如何處理這種情況呢，請看下圖，在合作方不愿意手動配合退款的情況下，我們在結算單模塊新增一個類型“多付應收賬單”，由系統與“通行應付賬單”進行軋差。

為了兼顧財務有時進行線下付款/補付的場景，可針對結算賬單設計了關聯線下付款的功能。

6.4 主要頁面原型

6.4.1 結算規則配置

結算規則配置，無非就是定義好幾個W。WHAT結算什么；WHO，對誰結算；WHEN，按什么時間或者周期；HOW，怎么結算。

沿著這個思路，看以下規則，就包含了要結算哪條業務線什么類型的賬單，向哪個合作方，結算周期D0還是D1， 怎么結算，墊資還是不用墊資，凈額還是全額。

新增結算規則不用拘泥于一定要有什么配置項，可根據業務來定義有什么類型的賬單需要結算，然后再抽象出類似結算周期，結算對象這種公共參數出來后，根據實際業務的不同結算需求去規劃額外的的、特有的配置參數，以撐起我們規則的靈活性。

6.4.2 結算賬單付款記錄

每一筆結算賬單對應的付款狀態和記錄需要展示出來，讓財務人員有跡可循，不至于想核查的時候都沒記錄看。

付款記錄需要明確展示出對應哪筆結算賬單，金額是多少，以及從哪個賬戶付，付到哪個收款賬戶，還有通過什么方式（通道）付款的。

如果付款失敗，最好把失敗原因展示出來，以便快速定位和排除問題。

07 消費金融平臺結算系統

消費金融大家可能比較陌生，但是在購物付款時一定接觸過是否選擇分期付款，或使用花唄或京東白條，其實這些都屬于消費金融的一種展業場景。

消費金融業務是向廣大消費者發放的以消費（不包括購買房屋、汽車以及投資股市等）為目的的貸款。

一般指機構或企業為個人提供以日常消費為主要目的的小額貸款產品和金融服務，單筆授信額度小、服務方式靈活、貸款期限短（一般在1-12個月）等特點，流程簡便、申請材料要求簡單、到款迅速。本質是為了提前滿足有消費需求，但短期無法全額付款的消費者的物質需求。用一句很流行的話來形容，就是：花明天的錢，圓今天的夢。

其中消費金融平臺業務模式是利用自有資金或與銀行、信托聯合出資、同業拆借等形式獲取資金，通過自營渠道（APP、公眾號、小程序等）、B端合作渠道（借唄、金條等）、其他引流渠道（微信系、抖音系）等獲得客戶，為信貸用戶和資金方搭建平臺并引入增信方促成交易。

7.1 消費金融下的結算場景

消費金融公司結算業務主要為信貸業務中參與的資金方、增信方、渠道方、服務機構、其他方通過賬務記賬分賬和計費系統進行收益分配后資金結算，覆蓋放還款、保費、理賠、追償款、傭金、服務費等業務場景。

名詞解釋：

資金方：貸款出資人，根據不同的模式一筆貸款的資金方有可能是單獨消費金融、銀行、信托，或者消費金融+信托、消費金融+銀行組合模式放款。主要涉及結算承貸資金，用戶還款分配，逾期后觸發理賠款和追償款，以及項目利潤的服務費等。

增信方：為客戶貸款行為進行增信的機構，如保險公司、擔保公司。主要涉及結算保費、服務費、理賠款、追償款、保證金等。

渠道方：為消費金融平臺提供客戶的機構，如各大互聯網提供消費分期和現金分期業務的平臺。主要涉及結算放款、還款、傭金、貼息、營銷費用等。

服務機構：為信貸業務整體過程中提供營銷、投放流量和征信查詢等服務的機構。主要涉及結算營銷推廣費、征信查詢費等

其他方：為保險公司銷售保險產品提供保險經紀服務或者為擔保公司提供保證金拆借服務的機構。主要涉及結算保險經紀費、拆借利息和拆借資金還回等。

7.2 結算核心業務流程

如下圖消金業務，客戶向渠道申請借款，渠道會將客戶信息上送消費金融平臺，平臺會聯合資金方進行放款，增信方進行承保，用戶還款會拆分成各方賬進行分配結算。

用戶逾期時增信方會將理賠款支付資金方，債權轉移，催收追償款付給增信方，同時還會涉及到各方利潤的分配。

所以，結算系統的核心業務就是根據結算規則將上游推送的計費數據嚴格按照協議合規前提下進行收款和付款結算，實現資金轉移。

7.3 結算系統產品架構

基于計費系統的結算單對商戶收支結算，支持提現、扣款、收款、軋差、匯總等操作。

既然要進行結算就需要知道向誰付款或收款，通過什么路徑和形式，收付款時間、周期規則以及協議依據。

對接商戶系統獲取收付款賬號信息等進行開戶，對接計費系統獲取核心分賬數據，對接客戶系統獲取客戶身份信息等進行清分中注冊、登賬、清分等功能

對接內部戶在商戶下開設虛擬戶和實戶映射關系實現資金管控，對接支付查詢收付流水實現付款和收款自動核銷匹配。

由此結算系統的核心功能主要包含賬戶管理、路徑管理、收付規則管理、項目協議管理、交易管理等。7.4.結算流程和模式

整個結算過程如下圖所示：

7.4.1 開戶

結算系統需為結算商戶進行開戶管理，維護合作方收款戶、付款戶、過渡戶等信息，并關聯結算項目，標記業務權限和用途。

7.4.2 配置結算規則

配置結算費項的收付規則和路徑信息，提現、扣款、上下帳、收款時讀取規則進行自動觸發。詳情參考頁面原型5.2路徑管理和5.3收付規則管理部分。

7.4.3 結算數據獲取

結算需要的基礎單據主要來源于計費系統，計費系統將關聯商戶的結算數據按照資金類型維度推送至結算系統。如下圖是計費系統推送的計費數據。

7.4.4 結算單生成

根據結算規則處理數據進行匯總、軋差等結算操作，生成結算單。

7.4.5 提現、扣款、收款

結算系統的核心處理流程，主要涉及交易模式和收款匹配模式：

7.4.5.1 結算模式

結算周期：全天實時結算、工作日實時結算、按日結算、按周結算、按月結算、按結算單逐步結算。

扣款模式：目前支持逐筆扣款，扣款軋差，按小時或按日匯總扣款。

充值模式：手動充值、自動充值、識別碼收款充值。其中手動充值時，結算單和銀行流水金額必須完全相等，按照下圖流程進行充值

付款模式：多單合并付款和逐單付款。

7.4.5.2 收款匹配模式

可以進行手工匹配和自動匹配。

（1）手工匹配

通常結算系統收到收款訂單后，出納拉取銀行收款流水，通過打款賬戶、備注、摘要和收款金額等進行人工識別，匹配收款結算單，進行核銷。

（2）自動匹配

步驟一：生成帳號

01從計費系統獲取結算收款基礎數據；

02驗證所有結算單為同商戶下，且都處于代收款未支付的狀態；

03生成識別碼：10位數，從0開始生成，每次請求生成不同號碼；

04關系保存：識別碼與結算單進行關系保存；

05產出完整卡號：系統參數中基礎卡號位+識別碼位=25位完整卡號；

步驟二：匹配處理

01獲取銀行流水：使用頭寸帳號到調撥系統獲取銀行流水，會返回對應識別碼及打款金額等信息；

02匹配結算單：使用識別碼到關系表中獲取對應結算單，確認收款金額是否正確；

03處理：對應結算單/銀行流水設置為已支付，進行相關帳號下賬處理（軋差及下賬）。7.5系統頁面及原型

7.5.1 賬戶管理

與合作方結算，發生收付款交易，在項目各場景下維護對應的合作方收付款賬戶信息、結算方式生成對應的結算賬號信息。

7.5.2 路徑管理

在路徑管理中進行維護項目中每一個結算場景的收付路徑，有幾個付款步驟，每個步驟付款賬戶是什么，收款賬戶是什么，哪些需要代為操作，哪些由合作方自己操作，權限配置，路徑生效期有無特殊限制，滿足財務多步驟付款的訴求。

7.5.3 收付規則管理

在實際業務中，需要給合作方付款也會收款，合作方會提出形形色色的收付款要求。例如有的要求按日付，有的要求按周付，有的要求收款費項和付款費項軋差后按凈額付，有的擔保公司對接不同資金方項目產生的費用分別支付，有的要求所有項目匯總支付，基于上述業務場景收付規則管理統一進行維護。

主要維護：收付款頻率、軋差模式、匯總收付維度、特定摘要、付款額度規則（保費池額度）、規則有效期、是否走清分、截留模式等。

（1）收付款頻率

全天實時結算：收到結算單，立即提現。

工作日實時結算：收到結算單，在工作日10：00-17：00立即提現。

按日結算：帳戶打開自動提現時，每日10：00-16：00，每小時提現一次。（需要打開自動提現、支付開關）多個結算單

按周結算：在帳號配置提現周幾。打開自動提現后，每日觸發檢查，滿足即進行提現。

按月結算：在帳號配置每月幾號，打開自動提現后，每日觸發檢查，滿足即進行提現。

每日：帳戶打開自動提現時，每日10：00-16：00，每小時提現一次。（需要打開自動提現、支付開關）按結算單逐步結算。

（2）軋差模式

軋差是指利用抵銷、最終取得一方對另一方的一個數額的凈債權或凈債務，如市場交易者之間，可能互有內容相同，方向相反的多筆交易，在結算或結束交易時，可以將各方債權在相等數額內抵銷。

收款軋差，通常指應收款-應付款=凈應收款。

付款軋差，通常指應付款-應收款=凈應付款。

（3）提現軋差類型說明

默認軋差：即表示同商戶編號下帳號進行軋差。

指定軋差：可以在結算帳號配置指定的軋差帳號，如貨款指定軋差退貨款。

全賬號軋差：指多貸多借軋差，并進行提現。

（4）匯總收付維度

針對不同結算費項之間或同一債權方不同項目之間有匯總結算的業務進行配置

7.5.4 項目協議管理

所有結算依據都是用印協議，運營對賬核算、財務審批都需要嚴格按照協議內容規定進行審核。當協議內容進行變更時，系統中維護的對應內容應及時更新，避免結算和付款錯誤，造成資金風險。因此此功能主要將協議標記項目信息關聯資金方、增信方、資金類型等信息，并根據協議內容復核系統配置參數，確保收付信息正確。

7.5.5交易管理

主要提供查詢結算交易相關信息：包含支付流水、收款流水、收款認賬、賬戶交易和余額等查詢。支持線下充值和收款匹配等操作，實現資金上下帳操作。

交易類型：結算、調增、調減、退貨、調減、提現、自動扣款

交易方向：上賬、反向交易、下賬