大家好，我是隱墨星辰，深耕境內/跨境支付架構設計十余年。今天和大家聊聊賬務系統的一些入門知識。

這篇文章主要從研發的視角講清楚：賬務相關的一些基礎概念，賬務系統核心的職責，以及一些關鍵模塊的設計要點。

主要內容：

1）復式記賬理論簡要介紹。

2）賬務系統產品架構圖。

3）從最基本的支付說起。

4）記賬全流程。

5）其它重要知識點。

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

幾年前一個狂風暴雨電閃雷鳴的下午，老板把負責賬務系統的技術經理炒了魷魚，并把賬務系統及對應的研發小組劃到我這里，于是除了風控系統仍然在大數據團隊（彼時還沒有算法團隊一說），整個支付系統包括收單結算、收銀支付、渠道、賬務等全部劃歸到我這里。

那時距離我進入第三方支付行業已經過去5個春秋，但我對賬務的理解仍處在只知道“有借必有貸，借貸必相等”的程度。為不辜負老板的信任，也為了不讓小弟們看不起，我決定認真學習賬務。過了一個月，恰好重構的新支付核心上線灰度切流，發生日切不過，為校驗學習成果，我身先士卒深入進去查原因，查了2天，終于......很不幸，木有查出原因，仍是依靠小弟們解決了問題。

這是我和賬務系統之間的一個小插曲。

1. 前言

我在支付行業呆了十年有余，一直從事研發相關工作，從個人以及身邊同事的經驗看，除了從事賬務系統研發的工程師外，大部分支付研發工程師對賬務都了解甚少，主要原因仍然是賬務系統的業務門檻往往大于技術門檻，比如很多支付研發工程師甚至不了解復式記賬。所以有必要從研發工程師的角度來介紹一些賬務系統入門的知識。

需要說明的是，不同支付公司內部設計的賬務系統必然存在差異，但有些基本原則大家都會遵守，比如復式記賬、賬戶管理、記賬、對賬、會計中心、日切等。本次只談這些公共的內容，大家可以結合各自公司的系統實現或內部文檔辯證地看。

需要說明的是，純概念或術語不好理解，所以我會把相關的概念融合到示例中去講，但里面夾雜了很多我個人的理解，可能和專業的教科書存在部分描述不一致的情況。

2. 復式記賬理論簡要介紹

賬務系統的理論基礎是復式記賬法。如果對于復式記賬沒有任何了解，建議先找網上一些公開的優秀資料先做初步的學習。

如果能看懂下面的場景描述，說明已經掌握了復式記賬的初步知識。

以用戶通過支付平臺使用招商銀行CMB支付500塊為例做個簡要說明。

假設：支付平臺同樣使用CMB做為收單行，在CMB開設有備付金賬戶。

涉及的支付平臺內部賬戶：

圖片

記賬步驟（只以支付成功并結算到商戶余額做示例，渠道清算相關記賬后面講）：

圖片

說明：

1）支付系統的記賬一定是復式記賬法。內部開設了很多賬戶和科目。

【借記類】賬戶：資產，應收款等；

【貸記類】賬戶：負債，所有者權益，應付款等；

2）借貸方向簡要公式（不太嚴謹，但是夠用）：

【借記類】賬戶（如資產，應收款），【增加】為【借】，【減少】為【貸】；

【貸記類】賬戶（如負債和所有者權益，應付款），【增加】為【貸】，【減少】為【借】；

3）復式記賬的專業術語很多，這里只摘錄幾個重要的說明：

復式記賬法定義：對每項經濟業務按相等的金額在兩個或兩個以上有關賬戶中同時進行登記的方法。

記賬原則：有借必有貸，借貸必相等。

記賬依據：會計恒等式：1. 資產 = 負債 + 所有者權益；2. 利潤 = 收入 - 費用。

賬戶：具有一定格式和結構，能夠用來連續、系統、全面的記錄反映某種經濟業務的增減變化及其結果。

科目：同類財務交易的分類，比如資產、負債、所有者權限、收入或費用等都屬于科目。一般科目會分為多級。

賬戶和科目的區別：科目只有名字，賬戶包括結構和格式，每個賬戶對應一個特定的科目。

3. 賬務系統產品架構圖

拆解記賬之前，我們先看一個典型的賬務系統具備哪些產品能力。

賬務系統一般說來需要負責管理賬戶、余額、記賬、對賬、清結算、會計核算、報表等能力。大致如下：

圖片

后面單獨再開文章詳細介紹設計思路。

4. 從最基本的支付說起

我們以最典型的電商購物舉個例子（只是舉例）：小明使用PayPal在拼多多電商（海外）通過多多錢包（海外）支付了50美金。

經過簡化后的交互圖如下：

圖片

說明：

• 持牌的第三方支付機構和電商是獨立的法律主體，所以多多錢包和多多電商是互相獨立的，需要走獨立的結算。
• 為突出重點，中間省略了很多中間機構，比如花旗通過清算網絡才能轉賬到匯豐，清算網絡先略過。
• 為簡化描述，還有幾個假設：

假設拼多多電商選擇結算到銀行卡。還有一個場景是電商選擇結算到余額，然后自己手動提現。

假設單幣種場景，跨幣種場景還涉及到外匯兌換。

下面我們針對這個典型場景做進一步的細化來講解賬務相關的概念。

5. 記賬全流程

5.1. 支付記賬完整順序圖

圖片

說明：

• 圖中只畫了正常場景，像明細對賬出現差異（長短款）、賬單對不平（渠道少打款或多打款）等場景沒有畫出來。
• 日切相關的在后面單獨說明。
• 給商戶結算也在后面單獨說明。
• 記賬方案也會在后面單獨說明。

上面只寫了順序，為更清楚描述各系統的參與，下面單獨再拆解幾個核心步驟，并加渠道網關、支付引擎等子系統的交互。

5.2. 渠道扣款成功

圖片

說明：

• 對賬中心監聽渠道網關的消息，注冊我方流水，用于后續和渠道的對賬。
• 賬務中心記賬：DR：應收-渠道待清算，CR：應付-網關過渡戶。因為現在有可能收單域的訂單已經被關閉，所以這里還不能直接【CR：應付-商戶待結算】。
• 每條記賬明細都會對應記錄一條會計分錄。

5.3. 收單訂單推進成功

圖片

說明：

• 收單成功后，需要把手續費扣出來。

5.4. 明細對賬

圖片

說明：

• 渠道本身也會收手續費，還可能幫政府代收稅費，實際應清算金額=支付金額-渠道手續費-稅費。

5.5. 賬單對賬

圖片

說明：

• 賬單對賬和明細對賬不一樣的地方在于，明細對賬是支付渠道PayPal給的清算文件，賬單對賬是備付金銀行收到支付渠道打款后給出的賬單文件。
• 在記賬模塊先是記銀行頭寸的賬（收到銀行賬單，說明錢已經到賬），再記應清算的賬。
• 有些場景沒有窮舉說明，比如渠道應清算49.50USD，實際只到賬40USD，這時仍有9.50USD屬于應清算。

5.6. 結算打款

圖片

說明：

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

6. 其它重要知識點

6.1. 賬戶

圖片

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

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

6.2. 實時記賬與緩沖記賬

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

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

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

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

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

6.3. 記賬方向

圖片

說明：

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

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

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

6.4. 會計科目與會計分錄

會計科目與賬戶、會計分錄的關系如下：

圖片

說明：

• 科目有多級科目，所以有個自關聯。
• 賬戶分為客戶賬戶和內部賬戶，二者的結構有一些小的區別，比如內部賬戶一般不會被凍結，但是客戶賬戶可以被凍結。

會計科目示例：

圖片

說明：

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

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

圖片

6.5. 記賬方案

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

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

圖片

6.6. 會計日與日切

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

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

• 借貸試算平衡。
• 父子科目試算平衡。
• 總賬試算平衡。
• 日、月、季度、年匯總。
• 會計日變更。

圖片

日切試算平衡核心邏輯：

• 借方發生額 = 貸方發生額
• 借方余額 = 貸方余額
• 期末余額 = 期初發生額 + 發生額
• 父科目累積額 = 子科目累積額

6.7. 三層對賬體系

圖片

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

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

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

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

圖片

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

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

7. 結束語

賬務子系統負責為支付平臺管理所有資金，是支付平臺最核心的子系統之一。相關會計報表是公司經營決策的依據，也是合規申報相關報表的基礎。理解賬務子系統的核心概念，能幫助我們構建一個完整的支付系統設計與實現的理論基礎。

本文從研發工程師的視角，介紹了賬務子系統一些最核心的概念，希望能為大家在學習賬務系統相關知識時能提供一些有益的參考。