圖解支付賬務系統核心設計（進階版）

在前一篇的《圖解支付賬務系統入門》中，講解了賬務相關的一些基礎概念和關鍵模塊的設計要點。今天繼續深入講解支付賬務系統的設計，部分內容和入門篇有重複。

進入正題前，先講個小故事。

在入門篇中有說到，老闆把賬務系統也劃到我這裏管理，我只得被迫學習賬務知識。某日的下午，窗外驕陽如烈火，我端着一杯咖啡正襟危坐，正式開始學習賬務相關知識。首先映入眼簾的是賬戶、科目、會計分錄，翻了幾遍，還是雲裏霧裏，於是去找做賬務的小弟。

問：“賬戶和科目有什麼區別？”

答：“本質上是沒有區別，都是一個東西。”

我不服氣，繼續問：“如果沒有區別，爲什麼又有賬戶，又有科目。”

答：“吧啦吧啦吧啦......（具體說什麼忘記了，反正問完還是不求甚解）”

然後去查各種資料，查到的定義和描述仍然是晦澀而難以理解，硬着頭皮也難以記住。從那以後，我就喜歡閱讀別人的文章，然後以自己的方式理解並講解支付相關的概念。

學過之後能以自己的方式講出來，說明真的會了，謂之 “悟道”。

1. 前言

每個公司的賬務系統設計思路、實現方式必然是不一樣的，我個人經歷過好幾家支付公司，實現細節千差萬別，但是整體思路都差不太多，比如賬戶設計一定有客戶賬戶和內部賬戶，一定有中間戶（過渡戶），也一定使用複式記賬，也都有實時記賬和緩衝記賬等。

而不一樣的地方在於，有些是集團財務統一管理電商和支付平臺的資金，有些則是分開兩個團隊管理，這種業務上的差異（或部門職責差異）就會體現到賬務系統的實現細節。比如集團財務統管的話，就會要求會計科目的編制需要和集團財務系統保持一致，每天日切完成後要並賬到集團的財務系統，一些差異處理也要受集團財務的流程制約。

本文嘗試拋開那些隨各公司業務部門定製的邏輯，回到賬務系統的本質，聊聊一個通用的賬務系統設計要點。當然不可避免會夾雜一些我個人不成熟的見解，各位讀者請以 “取其精華，去其糟粕” 的精神辯證地看待此文內容。

2. 賬務系統在支付平臺中的定位

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

3. 一些基本的概念

賬務系統的一些基本概念，包括賬戶分類、複式記賬法、會計科目編制、會計分錄、記賬方向等說明，請參考前一篇：《圖解支付賬務系統入門》。

4. 信息流與資金流全生命週期

支付系統的本質，就是準確無誤地把錢從一個地方搬到另一個地方。就這涉及到所謂的信息流和資金流，資金流還可以細分虛擬資金流和實體資金流。

因爲大家的錢一定要通過銀行才能變現，所以大家在支付平臺（比如支付寶或微信）賬戶看到的餘額變動，就是虛擬資金流。真實的資金在銀行體系流轉，就是所謂實體資金流。不過大部分情況下，也不用刻意去區分虛擬資金流和實體資金流。

此外，像收單核心、支付引擎、渠道網關等處理的就是信息流，而賬務系統處理的就是資金流。所以要想理解賬務系統，一定要先理解資金流。

下面分別以最常見的支付來展開說明信息流和資金流。錢包賬戶餘額充值和餘額支付會有一些差別，但原理差不多，在此處略過。

4.1. 支付與結算交互圖極簡版

在支付流程中，就是商戶委託收單機構（支付平臺）把用戶的錢收回來，然後再把錢結算給商家。

下面以典型通過外部渠道的卡支付爲例說明。

說明：

1. 用戶的錢最終會走到商戶的收款銀行賬戶。真實情況下用戶的支付的錢會分成多份，包括通道收的費用，支付平臺收的手續費，稅費，營銷分潤，商戶結算款等。通道費用還可以繼續細分爲髮卡行手續費，收單行手續費，清算機構手續費等。

2. 跨行一般都需要通過清算機構，這裏爲簡化也沒有畫出來。

3. 支付平臺內部的資金流在詳細版中給出。

4.2. 支付記賬詳細版

說明：

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

4.3. 商戶結算記賬詳細版

說明：

1. 上述是商戶結算到卡場景。

2. 各公司的內部戶編制可能有所不同。

5. 賬務系統核心訴求

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

1. 賬戶管理：對私、對公賬戶的開戶、銷戶等。

2. 餘額管理：對私、對公賬戶的餘額管理。

3. 記賬處理：清楚知道每筆錢的來龍去脈。

4. 清結算與對賬：把需要結算給商戶的錢算清楚，把渠道和支付平臺的賬算清楚。

5. 銀行頭寸管理與流動性：支付平臺在各備付金銀行開立的頭寸，以及頭寸間流動性管理。

6. 內部會計報表與外部監管報表：根據會計準則出具各種要求的報表。

6. 賬務系統產品架構圖

說明：

1. 賬務主要負責賬戶的管理，以及記賬服務。比如開、銷戶，餘額操作。

2. 清結算主要負責對商戶的清分（算出應該給商戶多少錢），清償（實際打款給商戶），對賬以及差錯處理。

3. 會計中心主要負責科目、分錄、日切、報表等。

補充：

1. 各公司對賬務系統子模塊的拆分可能有差異，比如有些公司把賬戶和記賬服務單獨拆成兩個模塊，或者把對賬從清結算模塊中拆出成單獨的一個對賬核心。這些拆分不影響本質的東西。

2. 何時拆何時合？公司業務規模小，就合起來，反正是一批人搞定代碼實現。公司交易量大，業務複雜，招的研發多，就拆，每個小團隊負責一個或幾個核心模塊。

7. 賬務系統系統架構圖

說明：

1. 各能力基本與產品架構圖對應，但會多一些技術上的設計，比如實時記賬和緩衝記賬，業務上並不關心。

2. 上面只畫出了核心模塊的核心能力，實際實現時需要做刪減。

3. 上面的業務系統只畫了支付鏈路的示例，實際業務可能還有充、轉、提等資金產品服務。

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

爲便於理解，這裏做了極簡化處理。

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

8. 核心設計

8.1. 整體模型

說明：

1. 科目有多級科目，所以有個自關聯。

2. 賬戶分爲客戶賬戶和內部賬戶，二者的結構有一些小的區別，比如內部賬戶一般不會被凍結，但是客戶賬戶可以被凍結。

3. 這是大的關係圖。屬性在下面會講到。

4. 沒有加入清結算和對賬的模型，不然畫出來比較亂。

8.2. 賬務核心

8.2.1. 賬務模型

說明：

1. 因爲客戶賬戶和內部戶賬戶有區別，所以拆成兩個模型更清晰。

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

8.2.2. 賬戶分類

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

1. 客戶賬戶：對客可見。包括：對私的個人客戶賬戶，對公的商戶賬戶。

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

8.2.3. 記賬方向

說明：

1. 賬戶類型與借貸方向，相同爲加，相異爲減，也就是所謂的：DD+，DC-，CC+，CD-。

2. 示例：用戶提現 100 元，記賬如下：

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

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

8.2.4. 實時記賬與緩衝記賬

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

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

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

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

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

8.3. 會計中心模型

說明：

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

8.3.1. 會計科目與會計分錄

會計科目就是把會計要素進行分類，比如資產、負債等。通常都會有多級分類。

會計科目示例：

說明：

1. 一般支付系統使用三級科目就已經足夠。部分特別複雜的系統，可能會用到五級科目。

2. 爲便於理解，上面的示例做了很大的精簡，各公司內部對科目的編制差異可能會比較大。

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

8.3.2. 記賬方案

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

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

8.3.3. 會計日與日切

會計日，也稱爲會計結算日或賬務結算日，是支付平臺在會計週期中進行賬務處理和結算的特定日期。比如在分佈式環境下，各機器可能存在時間差，一筆交易在零點時有可能跨天處理，如何判斷一筆交易歸屬於哪天，就依據會計日來計算。

所謂日切，簡單理解就是切換到下一個會計日。主要做的工作：

1. 借貸試算平衡。

2. 父子科目試算平衡。

3. 總賬試算平衡。

4. 日、月、季度、年彙總。

5. 會計日變更。

日切試算平衡核心邏輯：

1. 借方發生額 = 貸方發生額

2. 借方餘額 = 貸方餘額

3. 期末餘額 = 期初發生額 + 發生額

4. 父科目累積額 = 子科目累積額

8.4. 清結算核心模型

8.4.1. 主動清算

說明：

1. 所謂主動清算和被動清算，都是站在支付平臺的角度。主動清算，就是以支付平臺爲準，被動清算，就是以外部機構爲準。

2. 一般來說，強勢的一方是主動清算角色，弱勢的一方是被動清算角色。大部分情況下，與商戶對接時，支付平臺是主動清算方，如果是特別大的商戶，支付平臺就是被動清算方。與外部渠道對接時，外部渠道一般是主動清算方。

8.4.2. 渠道對賬模型

說明：

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

2. 我方流水和渠道流水單號、幣種、金額、狀態都對上，就是對平。雙方如果有缺少，就會有長短款。

3. 流水對賬完成後，形成我方賬單，再和銀行賬單對賬，因爲銀行可能多次打款，所以二者是多對多的關係。

8.4.3. 對賬差異處理

對賬一般有幾種結果：

1. 對平：雙方交易類型、單號、狀態、幣種、金額都是一致的。

2. 長款：我方多錢。支付長款：支付 90 塊，渠道清算 100 塊，或我方失敗，渠道成功。退款長款：退款 100 塊，渠道清算 90 塊。充值長款、提現長款類比。

3. 短款：我方少錢。支付短款：支付 00 塊，渠道清算 90 塊。退款長款：退款 90 塊，渠道清算 100 塊。充值短款、提現短款類比。

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

8.4.4. 渠道三層對賬體系

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

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

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

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

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

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

10. 拓展閱讀

賬務系統除了底層知識比較通用外，還有很多內容是和實際業務場景掛鉤的，推薦幾篇供大家拓展閱讀，互相補充：

《一文搞懂 “支付 · 清結算 · 賬務” 全局》（來源：陳天宇宙）

《最後的黑盒，賬務核心》（來源：剛哥白話）

《跨境支付中的清結算體系解析》（來源：墨玉跨境學堂）

《賬務系統設計基礎》，《支付清結算之賬戶和賬務處理》（來源：鳳凰牌老熊，從 2024 年往回看，賬務系統的核心設計仍然沒有太大的變化）

《支付寶整體架構 ppt 課件（前螞蟻 CTO 魯肅所寫）》（預覽版，手機可直接打開）（完整版，下載需要電腦瀏覽器打開，手機無法打開：http://m.pptbz.com/down/1606760735499003.html）（來源：網絡。裏面也有賬務會計的內容，雖然內容有點老，但作爲第三方支付的鼻祖還是很有參考價值）

《圖解支付系統的渠道路由設計》（和賬務無關，但寫得還不錯）

11. 結束語

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Y_pwfsvlkvIf46er2ZPCCQ