圖解支付賬務(wù)系統(tǒng)核心設(shè)計

大家好，這次給大家分享一篇隱墨星辰關(guān)于賬務(wù)設(shè)計的經(jīng)典文章。隱墨星辰的圖畫的比我還好，他通過極簡而有創(chuàng)意的構(gòu)圖把復(fù)雜賬務(wù)和系統(tǒng)完美的融合起來，讓你輕松掌握賬務(wù)體系的精髓。

1. 前言每個公司的賬務(wù)系統(tǒng)設(shè)計思路、實現(xiàn)方式必然是不一樣的，我個人經(jīng)歷過好幾家支付公司，實現(xiàn)細(xì)節(jié)千差萬別，但是整體思路都差不太多，比如賬戶設(shè)計一定有客戶賬戶和內(nèi)部賬戶，一定有中間戶（過渡戶），也一定使用復(fù)式記賬，也都有實時記賬和緩沖記賬等。而不一樣的地方在于，有些是集團財務(wù)統(tǒng)一管理電商和支付平臺的資金，有些則是分開兩個團隊管理，這種業(yè)務(wù)上的差異（或部門職責(zé)差異）就會體現(xiàn)到賬務(wù)系統(tǒng)的實現(xiàn)細(xì)節(jié)。比如集團財務(wù)統(tǒng)管的話，就會要求會計科目的編制需要和集團財務(wù)系統(tǒng)保持一致，每天日切完成后要并賬到集團的財務(wù)系統(tǒng)，一些差異處理也要受集團財務(wù)的流程制約。本文嘗試拋開那些隨各公司業(yè)務(wù)部門定制的邏輯，回到賬務(wù)系統(tǒng)的本質(zhì)，聊聊一個通用的賬務(wù)系統(tǒng)設(shè)計要點。當(dāng)然不可避免會夾雜一些我個人不成熟的見解，各位讀者請以“取其精華，去其糟粕”的精神辨證地看待此文內(nèi)容。2. 賬務(wù)系統(tǒng)的定位

賬務(wù)系統(tǒng)主要承擔(dān)賬戶管理、記賬、清結(jié)算及會計相關(guān)服務(wù)。

3.信息流與資金流全生命周期支付系統(tǒng)的本質(zhì)，就是準(zhǔn)確無誤地把錢從一個地方搬到另一個地方。就這涉及到所謂的信息流和資金流，資金流還可以細(xì)分虛擬資金流和實體資金流。因為大家的錢一定要通過銀行才能變現(xiàn)，所以大家在支付平臺（比如支付寶或微信）賬戶看到的余額變動，就是虛擬資金流。真實的資金在銀行體系流轉(zhuǎn)，就是所謂實體資金流。不過大部分情況下，也不用刻意去區(qū)分虛擬資金流和實體資金流。此外，像收單核心、支付引擎、渠道網(wǎng)關(guān)等處理的就是信息流，而賬務(wù)系統(tǒng)處理的就是資金流。所以要想理解賬務(wù)系統(tǒng)，一定要先理解資金流。下面分別以最常見的支付來展開說明信息流和資金流。錢包賬戶余額充值和余額支付會有一些差別，但原理差不多，在此處略過。 3.1. 支付與結(jié)算交互圖極簡版 在支付流程中，就是商戶委托收單機構(gòu)（支付平臺）把用戶的錢收回來，然后再把錢結(jié)算給商家。 下面以典型通過外部渠道的卡支付為例說明。

1. 用戶的錢最終會走到商戶的收款銀行賬戶。真實情況下用戶的支付的錢會分成多份，包括通道收的費用，支付平臺收的手續(xù)費，稅費，營銷分潤，商戶結(jié)算款等。通道費用還可以繼續(xù)細(xì)分為發(fā)卡行手續(xù)費，收單行手續(xù)費，清算機構(gòu)手續(xù)費等。
2. 跨行一般都需要通過清算機構(gòu)，這里為簡化也沒有畫出來。
3. 支付平臺內(nèi)部的資金流在詳細(xì)版中給出。

說明：圖中只畫了正常場景，像明細(xì)對賬出現(xiàn)差異（長短款）、賬單對不平（渠道少打款或多打款）等場景沒有畫出來。

3.3. 商戶結(jié)算記賬詳細(xì)版

1. 上述是商戶結(jié)算到卡場景。
2. 各公司的內(nèi)部戶編制可能有所不同。

前面提到，賬務(wù)系統(tǒng)負(fù)責(zé)支付平臺的資金流管理。根據(jù)上述圖繼續(xù)拆解，可以得出賬務(wù)系統(tǒng)的核心訴求如下：

1. 賬戶管理：對私、對公賬戶的開戶、銷戶等。
2. 余額管理：對私、對公賬戶的余額管理。
3. 記賬處理：清楚知道每筆錢的來龍去脈。
4. 清結(jié)算與對賬：把需要結(jié)算給商戶的錢算清楚，把渠道和支付平臺的賬算清楚。
5. 銀行頭寸管理與流動性：支付平臺在各備付金銀行開立的頭寸，以及頭寸間流動性管理。
6. 內(nèi)部會計報表與外部監(jiān)管報表：根據(jù)會計準(zhǔn)則出具各種要求的報表。

1. 賬務(wù)主要負(fù)責(zé)賬戶的管理，以及記賬服務(wù)。比如開、銷戶，余額操作。
2. 清結(jié)算主要負(fù)責(zé)對商戶的清分（算出應(yīng)該給商戶多少錢），清償（實際打款給商戶），對賬以及差錯處理。
3. 會計中心主要負(fù)責(zé)科目、分錄、日切、報表等。

補充：

1. 各公司對賬務(wù)系統(tǒng)子模塊的拆分可能有差異，比如有些公司把賬戶和記賬服務(wù)單獨拆成兩個模塊，或者把對賬從清結(jié)算模塊中拆出成單獨的一個對賬核心。這些拆分不影響本質(zhì)的東西。
2. 何時拆何時合？公司業(yè)務(wù)規(guī)模小，就合起來，反正是一批人搞定代碼實現(xiàn)。公司交易量大，業(yè)務(wù)復(fù)雜，招的研發(fā)多，就拆，每個小團隊負(fù)責(zé)一個或幾個核心模塊。

1. 各能力基本與產(chǎn)品架構(gòu)圖對應(yīng)，但會多一些技術(shù)上的設(shè)計，比如實時記賬和緩沖記賬，業(yè)務(wù)上并不關(guān)心。
2. 上面只畫出了核心模塊的核心能力，實際實現(xiàn)時需要做刪減。
3. 上面的業(yè)務(wù)系統(tǒng)只畫了支付鏈路的示例，實際業(yè)務(wù)可能還有充、轉(zhuǎn)、提等資金產(chǎn)品服務(wù)。

記賬服務(wù)與會計中心簡要關(guān)系

為便于理解，這里做了極簡化處理。

記賬服務(wù)負(fù)責(zé)記賬，主要關(guān)注賬戶余額變動等；會計中心負(fù)責(zé)會計核算，主要關(guān)注點在于會計分錄、科目匯總、會計報表等。實際情況會比這個復(fù)雜。

7. 核心設(shè)計 7.1. 整體模型

1. 科目有多級科目，所以有個自關(guān)聯(lián)。
2. 賬戶分為客戶賬戶和內(nèi)部賬戶，二者的結(jié)構(gòu)有一些小的區(qū)別，比如內(nèi)部賬戶一般不會被凍結(jié)，但是客戶賬戶可以被凍結(jié)。
3. 這是大的關(guān)系圖。屬性在下面會講到。
4. 沒有加入清結(jié)算和對賬的模型，不然畫出來比較亂。

1. 因為客戶賬戶和內(nèi)部戶賬戶有區(qū)別，所以拆成兩個模型更清晰。
2. 只列出了最核心的幾個字段，其它字段根據(jù)業(yè)務(wù)訴求增加。

在賬務(wù)系統(tǒng)中，通常包含以下幾種賬戶類型：

1. 客戶賬戶：對客可見。包括：對私的個人客戶賬戶，對公的商戶賬戶。
2. 內(nèi)部賬戶：對客不可見。包括：頭寸、手續(xù)費收入、過渡戶（也稱中間戶）等。

1. 賬戶類型與借貸方向，相同為加，相異為減，也就是所謂的：DD+，DC-，CC+，CD-。
2. 示例：用戶提現(xiàn)100元，記賬如下：

DR：用戶余額（負(fù)債類賬戶）100

CR：提現(xiàn)過渡戶（負(fù)債類賬戶）100

7.2.4. 實時記賬與緩沖記賬

一般來說，客戶賬戶的記賬需要是實時的，比如用戶充值、提現(xiàn)，商家提現(xiàn)，用戶退款等。

這些賬戶如果不做實時記賬，一來有損用戶體驗，二來有資損風(fēng)險。比如用戶充值100塊，如果延時不到賬，用戶可能會投訴。如果提現(xiàn)不實時記賬，用戶有可能重復(fù)提現(xiàn)成功。如果退款不實時記賬，有可能在退款場景下被透支。

假設(shè)記賬需要幾十毫秒（數(shù)據(jù)庫性能決定的），一個賬戶最高也就只支持30多TPS的記賬請求，對于一些高并發(fā)的賬戶（也稱為熱點賬戶）一定是性能不足的。這個時間可以使用緩沖記賬，以提高性能。開通緩沖記賬的，通常是內(nèi)部賬戶或允許商戶透支的流出場景。

緩沖記賬通常就是先記錄流水，然后起定時任務(wù)去撈取流水，匯總后進行記賬。前提是一定要做好資損防控。

除了緩沖記賬外，還有拆分賬戶的方式來解決熱點賬戶問題。

7.3. 會計中心模型

1. 只列出了最核心的幾個字段，其它字段根據(jù)業(yè)務(wù)訴求增加。

會計科目示例：

1. 一般支付系統(tǒng)使用三級科目就已經(jīng)足夠。部分特別復(fù)雜的系統(tǒng)，可能會用到五級科目。
2. 為便于理解，上面的示例做了很大的精簡，各公司內(nèi)部對科目的編制差異可能會比較大。

下面是一個典型的支付系統(tǒng)會計科目的部分截圖示例。

7.3.2. 記賬方案 有了賬戶和會計科目，發(fā)生一筆交易時，如何讓系統(tǒng)自動去記賬？這個是記賬方案做的事。其中一個解決方案就是給不同的交易場景制定不同的交易碼，通過交易碼來驅(qū)動記賬。

下面是一個典型的支付系統(tǒng)的記賬方案示例（部分截圖）。

7.3.3. 會計日與日切 會計日，也稱為會計結(jié)算日或賬務(wù)結(jié)算日，是支付平臺在會計周期中進行賬務(wù)處理和結(jié)算的特定日期。比如在分布式環(huán)境下，各機器可能存在時間差，一筆交易在零點時有可能跨天處理，如何判斷一筆交易歸屬于哪天，就依據(jù)會計日來計算。 所謂日切，簡單理解就是切換到下一個會計日。主要做的工作：

1. 借貸試算平衡。
2. 父子科目試算平衡。
3. 總賬試算平衡。
4. 日、月、季度、年匯總。
5. 會計日變更。

日切試算平衡核心邏輯：

1. 借方發(fā)生額 = 貸方發(fā)生額
2. 借方余額 = 貸方余額
3. 期末余額 = 期初發(fā)生額 + 發(fā)生額
4. 父科目累積額 = 子科目累積額

1. 所謂主動清算和被動清算，都是站在支付平臺的角度。主動清算，就是以支付平臺為準(zhǔn)，被動清算，就是以外部機構(gòu)為準(zhǔn)。
2. 一般來說，強勢的一方是主動清算角色，弱勢的一方是被動清算角色。大部分情況下，與商戶對接時，支付平臺是主動清算方，如果是特別大的商戶，支付平臺就是被動清算方。與外部渠道對接時，外部渠道一般是主動清算方。

1. 只列出了最核心的幾個字段，其它字段根據(jù)業(yè)務(wù)訴求增加。
2. 我方流水和渠道流水單號、幣種、金額、狀態(tài)都對上，就是對平。雙方如果有缺少，就會有長短款。
3. 流水對賬完成后，形成我方賬單，再和銀行賬單對賬，因為銀行可能多次打款，所以二者是多對多的關(guān)系。

1. 對平：雙方交易類型、單號、狀態(tài)、幣種、金額都是一致的。
2. 長款：我方多錢。支付長款：支付90塊，渠道清算100塊，或我方失敗，渠道成功。退款長款：退款100塊，渠道清算90塊。充值長款、提現(xiàn)長款類比。
3. 短款：我方少錢。支付短款：支付00塊，渠道清算90塊。退款長款：退款90塊，渠道清算100塊。充值短款、提現(xiàn)短款類比。

因為我方和渠道之間有一定的時間差，所以長短款在T+1對賬對不上時，往往先進入存疑清單里面，第T+2對賬還是對不上，才會進入差異處理。

7.4.4. 渠道三層對賬體系

第一層是信息流對賬。我方流水和銀行清算文件的流水逐一核對。可能會存在長短款情況。

第二層是賬單對賬。就是把我方流水匯總生成我方賬單，然后把銀行流水匯總生成銀行賬單，進行對賬。可能會存在銀行賬單和我方賬單不一致的情況，比如共支付100萬，渠道分2次打款，一筆98萬，一筆2萬。

第三層是賬實對賬。就是我方內(nèi)部記錄的銀行頭寸和銀行真實的余額是否一致。可能存在我方記錄的頭寸是220萬，但是銀行實際余額只有200萬的情況。

8. 內(nèi)部系統(tǒng)實時與離線對賬

前面的對賬主要是和銀行渠道對賬，除了這個之外，一般的支付平臺還會有內(nèi)部系統(tǒng)之間的兩兩核對，這種核對主要是信息流層面的核對，主要核對狀態(tài)、金額的一致性。

再細(xì)分，還可以拆成離線核對和實時核對。離線核對一般就是把生產(chǎn)數(shù)據(jù)庫的數(shù)據(jù)定時清洗到離線庫（一般還可以分為天表和小時表）。實時核對一般就是監(jiān)聽數(shù)據(jù)庫的binlog，當(dāng)數(shù)據(jù)有變動時，延時幾秒后請求雙方系統(tǒng)的查詢接口，查到數(shù)據(jù)后進行核對。

9. 結(jié)束語

賬務(wù)系統(tǒng)負(fù)責(zé)為支付平臺處理資金流，是支付平臺最核心的子系統(tǒng)之一。相關(guān)會計報表是公司經(jīng)營決策的依據(jù)，也是合規(guī)申報相關(guān)報表的基礎(chǔ)。理解賬務(wù)系統(tǒng)的核心設(shè)計概念，才能讓我們構(gòu)建出完整的支付系統(tǒng)設(shè)計與實現(xiàn)的理論基礎(chǔ)。本文從研發(fā)工程師的視角，介紹了賬務(wù)系統(tǒng)核心的設(shè)計思路，希望能為大家在學(xué)習(xí)賬務(wù)系統(tǒng)相關(guān)知識時能提供一些有益的參考。

【入群交流支付知識，加我個人微信入群】