起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識圖解支付賬務系統核心設計（進階版）
在金融科技領域，支付賬務系統的設計和實現是構建高效、安全支付平臺的關鍵。本文深入探討了支付賬務系統的核心設計，從賬戶管理、記賬處理到清結算與會計服務，為讀者揭示了支付賬務系統設計的復雜性和重要性。通過詳細的圖解和案例分析，文章為支付系統設計提供了寶貴的理論和實踐指導。
大家好，我是隱墨星辰，深耕境內/跨境支付架構設計十余年。
在前一篇的《圖解支付賬務系統入門》中，講解了賬務相關的一些基礎概念和關鍵模塊的設計要點。今天繼續深入講解支付賬務系統的設計，部分內容和入門篇有重復。
10個做支付的，9個不懂賬務，我也是入行很久后才開始懂賬務。
在入門篇中有說到，老板把賬務系統也劃到我這里管理，我只得被迫學習賬務知識。某日的下午，窗外驕陽如烈火，我端著一杯咖啡正襟危坐，正式開始學習賬務相關知識。首先映入眼簾的是賬戶、科目、會計分錄，翻了幾遍，還是云里霧里，于是去找做賬務的小弟。
問：“賬戶和科目有什么區別？”
答：“本質上沒有區別，都是一個東西?！?/p>
我不服氣，繼續問：“如果沒有區別，為什么又有賬戶，又有科目?！?/p>
答：“吧啦吧啦吧啦……（具體說什么忘記了，反正問完還是不求甚解）”
然后去查各種資料，查到的定義和描述仍然是晦澀而難以理解，硬著頭皮也難以記住。不過好在帶賬務團隊長達數年，天天耳聞目染，竟慢慢摸到了門道。
可謂近墨者黑，近朱者赤，近賬務時間久了就開始懂賬務。
學過之后能以自己的方式講出來，謂之“悟道”。今天繼續嘗試用我自己理解的方式聊聊賬務。
1. 前言
每個公司的賬務系統設計思路、實現方式必然是不一樣的，我個人經歷過好幾家支付公司，實現細節千差萬別，但是整體思路都差不太多，比如賬戶設計一定有客戶賬戶和內部賬戶，一定有中間戶（過渡戶），也一定使用復式記賬，也都有實時記賬和緩沖記賬等。
而不一樣的地方在于，有些是集團財務統一管理電商和支付平臺的資金，有些則是分開兩個團隊管理，這種業務上的差異（或部門職責差異）就會體現到賬務系統的實現細節。比如集團財務統管的話，就會要求會計科目的編制需要和集團財務系統保持一致，每天日切完成后要并賬到集團的財務系統，一些差異處理也要受集團財務的流程制約。而一些獨立運營的支付公司，會計科目的編制就沒有類似的問題。
本文嘗試拋開那些隨各公司業務部門定制的邏輯，回到賬務系統的本質，聊聊一個通用的賬務系統設計要點。當然不可避免會夾雜一些我個人不成熟的見解，各位讀者請以“取其精華，去其糟粕”的精神辯證地看待此文內容。
2. 賬務系統在支付平臺中的定位
賬務系統主要承擔賬戶管理、記賬、清結算及會計相關服務。
3. 一些基本的概念
賬務系統的一些基本概念，包括賬戶分類、復式記賬法、會計科目編制、會計分錄、記賬方向等說明，請參考前一篇：《圖解支付賬務系統入門》。
4. 信息流與資金流全生命周期
支付系統的本質，就是準確無誤地把錢從一個地方搬到另一個地方。就這涉及到所謂的信息流和資金流，資金流還可以細分虛擬資金流和實體資金流。
因為大家的錢一定要通過銀行才能變現，所以大家在支付平臺（比如支付寶或微信）賬戶看到的余額變動，就是虛擬資金流。真實的資金在銀行體系流轉，就是所謂實體資金流。不過大部分情況下，也不用刻意去區分虛擬資金流和實體資金流。
此外，像收單核心、支付引擎、渠道網關等處理的就是信息流，而賬務系統處理的就是資金流。所以要想理解賬務系統，一定要先理解資金流。
下面分別以最常見的支付來展開說明信息流和資金流。錢包賬戶余額充值和余額支付會有一些差別，但原理差不多，在此處略過。
4.1. 支付與結算交互圖極簡版
在支付流程中，就是商戶委托收單機構（支付平臺）把用戶的錢收回來，然后再把錢結算給商家。
下面以典型通過外部渠道的卡支付為例說明。
說明：
用戶的錢最終會走到商戶的收款銀行賬戶。真實情況下用戶的支付的錢會分成多份，包括通道收的費用，支付平臺收的手續費，稅費，營銷分潤，商戶結算款等。通道費用還可以繼續細分為發卡行手續費，收單行手續費，清算機構手續費等。
跨行一般都需要通過清算機構，這里為簡化也沒有畫出來。
支付平臺內部的資金流在詳細版中給出。
4.2. 支付記賬詳細版
說明：
圖中只畫了正常場景，像明細對賬出現差異（長短款）、賬單對不平（渠道少打款或多打款）等場景沒有畫出來。
4.3. 商戶結算記賬詳細版
說明：
上述是商戶結算到卡場景。
各公司的內部戶編制可能有所不同。
5. 賬務系統核心訴求
在第3節中提到，賬務系統負責支付平臺的資金流管理。根據上述圖繼續拆解，可以得出賬務系統的核心訴求如下：
賬戶管理：對私、對公賬戶的開戶、銷戶等。
余額管理：對私、對公賬戶的余額管理。
記賬處理：清楚知道每筆錢的來龍去脈。
清結算與對賬：把需要結算給商戶的錢算清楚，把渠道和支付平臺的賬算清楚。
銀行頭寸管理與流動性：支付平臺在各備付金銀行開立的頭寸，以及頭寸間流動性管理。
內部會計報表與外部監管報表：根據會計準則出具各種要求的報表。
6. 賬務系統產品架構圖
說明：
賬務主要負責賬戶的管理，以及記賬服務。比如開、銷戶，余額操作。
清結算主要負責對商戶的清分（算出應該給商戶多少錢），清償（實際打款給商戶），對賬以及差錯處理。
會計中心主要負責科目、分錄、日切、報表等。
補充：
各公司對賬務系統子模塊的拆分可能有差異，比如有些公司把賬戶和記賬服務單獨拆成兩個模塊，或者把對賬從清結算模塊中拆出成單獨的一個對賬核心。這些拆分不影響本質的東西。
何時拆何時合？公司業務規模小，就合起來，反正是一批人搞定代碼實現。公司交易量大，業務復雜，招的研發多，就拆，每個小團隊負責一個或幾個核心模塊。
7. 賬務系統系統架構圖
說明：
各能力基本與產品架構圖對應，但會多一些技術上的設計，比如實時記賬和緩沖記賬，業務上并不關心。
上面只畫出了核心模塊的核心能力，實際實現時需要做刪減。
上面的業務系統只畫了支付鏈路的示例，實際業務可能還有充、轉、提等資金產品服務。
記賬服務與會計中心簡要關系
為便于理解，這里做了極簡化處理。
記賬服務負責記賬，主要關注賬戶余額變動等；會計中心負責會計核算，主要關注點在于會計分錄、科目匯總、會計報表等。實際情況會比這個復雜。
8. 核心設計
8.1. 整體模型
說明：
科目有多級科目，所以有個自關聯。
賬戶分為客戶賬戶和內部賬戶，二者的結構有一些小的區別，比如內部賬戶一般不會被凍結，但是客戶賬戶可以被凍結。
這是大的關系圖。屬性在下面會講到。
沒有加入清結算和對賬的模型，不然畫出來比較亂。
8.2. 賬務核心
8.2.1. 賬務模型
說明：
因為客戶賬戶和內部戶賬戶有區別，所以拆成兩個模型更清晰。
只列出了最核心的幾個字段，其它字段根據業務訴求增加。
8.2.2. 賬戶分類
在賬務系統中，通常包含以下幾種賬戶類型：
客戶賬戶：對客可見。包括：對私的個人客戶賬戶，對公的商戶賬戶。
內部賬戶：對客不可見。包括：頭寸、手續費收入、過渡戶（也稱中間戶）等。
8.2.3. 記賬方向
說明：
賬戶類型與借貸方向，相同為加，相異為減，也就是所謂的：DD+，DC-，CC+，CD-。
示例：用戶提現100元，記賬如下：
DR：用戶余額（負債類賬戶）100
CR：提現過渡戶（負債類賬戶）100
8.2.4. 實時記賬與緩沖記賬
一般來說，客戶賬戶的記賬需要是實時的，比如用戶充值、提現，商家提現，用戶退款等。
這些賬戶如果不做實時記賬，一來有損用戶體驗，二來有資損風險。比如用戶充值100塊，如果延時不到賬，用戶可能會投訴。如果提現不實時記賬，用戶有可能重復提現成功。如果退款不實時記賬，有可能在退款場景下被透支。
假設記賬需要幾十毫秒（數據庫性能決定的），一個賬戶最高也就只支持30多TPS的記賬請求，對于一些高并發的賬戶（也稱為熱點賬戶）一定是性能不足的。這個時間可以使用緩沖記賬，以提高性能。開通緩沖記賬的，通常是內部賬戶或允許商戶透支的流出場景。
緩沖記賬通常就是先記錄流水，然后起定時任務去撈取流水，匯總后進行記賬。前提是一定要做好資損防控。
除了緩沖記賬外，還有拆分賬戶的方式來解決熱點賬戶問題。
8.3. 會計中心模型
說明：
只列出了最核心的幾個字段，其它字段根據業務訴求增加。
8.3.1. 會計科目與會計分錄
會計科目就是把會計要素進行分類，比如資產、負債等。通常都會有多級分類。
會計科目示例：
說明：
一般支付系統使用三級科目就已經足夠。部分特別復雜的系統，可能會用到五級科目。
為便于理解，上面的示例做了很大的精簡，各公司內部對科目的編制差異可能會比較大。
下面是一個典型的支付系統會計科目的示例。
8.3.2. 記賬方案
有了賬戶和會計科目，發生一筆交易時，如何讓系統自動去記賬？這個是記賬方案做的事。其中一個解決方案就是給不同的交易場景制定不同的交易碼，通過交易碼來驅動記賬。
下面是一個典型的支付系統的記賬方案示例。
8.3.3. 會計日與日切
會計日，也稱為會計結算日或賬務結算日，是支付平臺在會計周期中進行賬務處理和結算的特定日期。比如在分布式環境下，各機器可能存在時間差，一筆交易在零點時有可能跨天處理，如何判斷一筆交易歸屬于哪天，就依據會計日來計算。
所謂日切，簡單理解就是切換到下一個會計日。
主要做的工作：
借貸試算平衡。
父子科目試算平衡。
總賬試算平衡。
日、月、季度、年匯總。
會計日變更。
日切試算平衡核心邏輯：
借方發生額 = 貸方發生額
借方余額 = 貸方余額
期末余額 = 期初發生額 + 發生額
父科目累積額 = 子科目累積額
8.4. 清結算核心模型
8.4.1.?極簡商戶清結算流程
圖中各方關系畫得很清楚，不需要再做過多說明。
8.4.2. 渠道對賬模型
說明：
只列出了最核心的幾個字段，其它字段根據業務訴求增加。
我方流水和渠道流水單號、幣種、金額、狀態都對上，就是對平。雙方如果有缺少，就會有長短款。
流水對賬完成后，形成我方賬單，再和銀行賬單對賬，因為銀行可能多次打款，所以二者是多對多的關系。
8.4.3. 對賬差異處理
對賬一般有幾種結果：
對平：雙方交易類型、單號、狀態、幣種、金額都是一致的。
長款：我方多錢。支付長款：支付90塊，渠道清算100塊，或我方失敗，渠道成功。退款長款：退款100塊，渠道清算90塊。充值長款、提現長款類比。
短款：我方少錢。支付短款：支付00塊，渠道清算90塊。退款長款：退款90塊，渠道清算100塊。充值短款、提現短款類比。
因為我方和渠道之間有一定的時間差，所以長短款在T+1對賬對不上時，往往先進入存疑清單里面，第T+2對賬還是對不上，才會進入差異處理。
8.4.4. 渠道三層對賬體系
第一層是信息流對賬。我方流水和銀行清算文件的流水逐一核對?？赡軙嬖陂L短款情況。
第二層是賬單對賬。就是把我方流水匯總生成我方賬單，然后把銀行流水匯總生成銀行賬單，進行對賬?？赡軙嬖阢y行賬單和我方賬單不一致的情況，比如共支付100萬，渠道分2次打款，一筆98萬，一筆2萬。
第三層是賬實對賬。就是我方內部記錄的銀行頭寸和銀行真實的余額是否一致?？赡艽嬖谖曳接涗浀念^寸是220萬，但是銀行實際余額只有200萬的情況。
9. 內部系統實時與離線對賬
前面的對賬主要是和銀行渠道對賬，除了這個之外，一般的支付平臺還會有內部系統之間的兩兩核對，這種核對主要是信息流層面的核對，主要核對狀態、金額的一致性。
再細分，還可以拆成離線核對和實時核對。離線核對一般就是把生產數據庫的數據定時清洗到離線庫（一般還可以分為天表和小時表）。實時核對一般就是監聽數據庫的binlog，當數據有變動時，延時幾秒后請求雙方系統的查詢接口，查到數據后進行核對。
10. 拓展閱讀
賬務系統除了底層知識比較通用外，還有很多內容是和實際業務場景掛鉤的，推薦幾篇供大家拓展閱讀，互相補充。
看完后，就會發現，大家語言描述千差萬別，但本質就是會計原理、銀行核心那一套。場景復雜的，比如跨境，無外乎多幾個主體，加幾個主體之間的關系而已。（說得輕巧，實現還是相當有難度的）
《解密：站在資金的視角看支付（上）》、《站在資金的視角看支付（下）（跨境篇）》（來源公眾號：支付進階之路）
《一文搞懂“支付·清結算·賬務”全局》（來源公眾號：陳天宇宙）
《最后的黑盒，賬務核心》（來源公眾號：剛哥白話）
《跨境支付中的清結算體系解析》（來源公眾號：墨玉跨境學堂）
《賬務系統設計基礎》，《支付清結算之賬戶和賬務處理》（來源公眾號：鳳凰牌老熊，從2024年往回看，賬務系統的核心設計仍然沒有太大的變化）
11. 結束語
賬務系統負責為支付平臺處理資金流，是支付平臺最核心的子系統之一。相關會計報表是公司經營決策的依據，也是合規申報相關報表的基礎。
理解賬務系統的核心設計概念，才能讓我們構建出完整的支付系統設計與實現的理論基礎。
本文從研發工程師的視角，介紹了賬務系統核心的設計思路，希望能為大家在學習賬務系統相關知識時能提供一些有益的參考。如果還是看不懂，建議先去買本會計入門的書讀讀，基本就能懂了。
這是《圖解支付系統設計與實現》專欄系列文章中的第（36）篇。
深耕境內/跨境支付架構設計十余年，歡迎關注并星標公眾號“隱墨星辰”，和我一起深入解碼支付系統的方方面面。
本文由人人都是產品經理作者【隱墨星辰】，微信公眾號：【隱墨星辰】，原創/授權 發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于 CC0 協議。
在實際操作中，賬戶和科目往往是相互關聯的。一個賬戶可能對應一個或多個科目，而一個科目可能包含多個賬戶。