圖解支付賬務系統核心設計

大家好，這次給大家分享一篇隱墨星辰關于賬務設計的經典文章。隱墨星辰的圖畫的比我還好，他通過極簡而有創意的構圖把復雜賬務和系統完美的融合起來，讓你輕松掌握賬務體系的精髓。

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

賬務系統主要承擔賬戶管理、記賬、清結算及會計相關服務。

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

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

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

3.3. 商戶結算記賬詳細版

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

前面提到，賬務系統負責支付平臺的資金流管理。根據上述圖繼續拆解，可以得出賬務系統的核心訴求如下：

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

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

補充：

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

1. 各能力基本與產品架構圖對應，但會多一些技術上的設計，比如實時記賬和緩沖記賬，業務上并不關心。
2. 上面只畫出了核心模塊的核心能力，實際實現時需要做刪減。
3. 上面的業務系統只畫了支付鏈路的示例，實際業務可能還有充、轉、提等資金產品服務。

記賬服務與會計中心簡要關系

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

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

7. 核心設計 7.1. 整體模型

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

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

在賬務系統中，通常包含以下幾種賬戶類型：

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

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

DR：用戶余額（負債類賬戶）100

CR：提現過渡戶（負債類賬戶）100

7.2.4. 實時記賬與緩沖記賬

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

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

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

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

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

7.3. 會計中心模型

1. 只列出了最核心的幾個字段，其它字段根據業務訴求增加。

會計科目示例：

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

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

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

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

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

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

日切試算平衡核心邏輯：

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

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

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

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

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

7.4.4. 渠道三層對賬體系

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

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

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

8. 內部系統實時與離線對賬

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

再細分，還可以拆成離線核對和實時核對。離線核對一般就是把生產數據庫的數據定時清洗到離線庫（一般還可以分為天表和小時表）。實時核對一般就是監聽數據庫的binlog，當數據有變動時，延時幾秒后請求雙方系統的查詢接口，查到數據后進行核對。

9. 結束語

賬務系統負責為支付平臺處理資金流，是支付平臺最核心的子系統之一。相關會計報表是公司經營決策的依據，也是合規申報相關報表的基礎。理解賬務系統的核心設計概念，才能讓我們構建出完整的支付系統設計與實現的理論基礎。本文從研發工程師的視角，介紹了賬務系統核心的設計思路，希望能為大家在學習賬務系統相關知識時能提供一些有益的參考。

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