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

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

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

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

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

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

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

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

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

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

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

補(bǔ)充：

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

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

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

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

記賬服務(wù)負(fù)責(zé)記賬，主要關(guān)注賬戶余額變動(dòng)等；會(huì)計(jì)中心負(fù)責(zé)會(huì)計(jì)核算，主要關(guān)注點(diǎn)在于會(huì)計(jì)分錄、科目匯總、會(huì)計(jì)報(bào)表等。實(shí)際情況會(huì)比這個(gè)復(fù)雜。

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

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

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

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

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

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

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

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

7.2.4. 實(shí)時(shí)記賬與緩沖記賬

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

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

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

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

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

7.3. 會(huì)計(jì)中心模型

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

會(huì)計(jì)科目示例：

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

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

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

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

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

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

日切試算平衡核心邏輯：

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

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

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

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

因?yàn)槲曳胶颓乐g有一定的時(shí)間差，所以長短款在T+1對(duì)賬對(duì)不上時(shí)，往往先進(jìn)入存疑清單里面，第T+2對(duì)賬還是對(duì)不上，才會(huì)進(jìn)入差異處理。

7.4.4. 渠道三層對(duì)賬體系

第一層是信息流對(duì)賬。我方流水和銀行清算文件的流水逐一核對(duì)?？赡軙?huì)存在長短款情況。

第二層是賬單對(duì)賬。就是把我方流水匯總生成我方賬單，然后把銀行流水匯總生成銀行賬單，進(jìn)行對(duì)賬?？赡軙?huì)存在銀行賬單和我方賬單不一致的情況，比如共支付100萬，渠道分2次打款，一筆98萬，一筆2萬。

第三層是賬實(shí)對(duì)賬。就是我方內(nèi)部記錄的銀行頭寸和銀行真實(shí)的余額是否一致?？赡艽嬖谖曳接涗浀念^寸是220萬，但是銀行實(shí)際余額只有200萬的情況。

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

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

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

9. 結(jié)束語

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

【入群交流支付知識(shí)，加我個(gè)人微信入群】