詳解賬務系統，從入門到精通

交易過程中或者完結以後，記賬工作就開始了，賬務作爲支付交易的基礎設施非常重要，其關鍵並不是設計本身，而是賬務的設計理念、規範和原則。本文將詳細介紹賬務相關係統的設計方法，並從賬務原理、賬戶子系統、熱點賬戶、賬戶合併、會計日切原理、營銷類賬務處理、清結算的賬務實現模型等 10 方面瞭解賬務及賬戶的相關內容。

1. 賬務實現原理

現代支付的底層就是賬務，無賬務不支付，無賬戶不資金。既然賬務這麼重要，那麼搭建一套適合自己的賬務核心是非常重要的

1.1 從場景中抽象能力

從場景中的需求出發理解賬務的本質，搞懂客戶、客戶的場景、客戶在場景中的訴求，懂用戶才能做出好產品，一切系統設計來源於需求

首先是基於外部客戶的賬務訴求看賬務服務，賬務是要服務的不同客戶面對的業務和訴求，爲他們提供針對性的支付等各類解決方案；搞清楚這一點，可以更懂自己的客戶，提供更符合市場餘額的 “賬務和賬戶產品”

然後是基於內部客戶的賬務訴求看賬務服務，主要就是清結算業務、內部運營訴求和財務覈算訴求，內部業務依賴的賬務和賬戶類型與客戶支付和資金處理訴求存在差異；瞭解內部業務及訴求，可以爲內部業務運轉提供高效的 “賬務和賬戶服務”

所以說，基於客戶訴求抽象和構建賬務核心的服務矩陣

1.2 賬務總架構解析

任何設計都要先俯視全局，一切從總架構出發，在總架構的指引下完成局部建設，賬務全局架構非常關鍵的一點就是與外圍系統所建立的往來關係。

所有相關的外圍系統，例如交易系統、支付系統、清結算系統等本書前面章節均做了詳細的解析，將 “各業務系統，業務系統產生的記賬種類，賬務核心” 等內容整理到一張架構圖中來闡明這種渾然一體的全局關係。

1.2.1 記賬離不開外圍驅動

如圖中各個系統都產生相應的記賬業務，然後調用賬務核心的記賬服務，根據各類記賬接口協議提交業務流水明細，例如：

1.2.2 賬務服務爲記賬提供接口

賬務系統採用統一記賬接口也可以，所有業務的記賬請求都請求這個接口。但是，因爲未來要給商戶出具賬單，各類記賬所需要的參數信息存在差別，所以可以爲不同記賬種類設定差異化的記賬接口，例如收單類記賬、打款類記賬、結算類記賬、鑑權類記賬等等，並在記賬接口模塊維護這些記賬協議，可以方便新增和調整這些記賬協議。

業務記賬數據通過指定接口提交至賬務系統以後，賬務系統需要先生成業務流水進行存儲。因爲不能業務數據不落地直接生成記賬憑證，需要原樣保留原始憑證；更不能讓業務用記賬憑證的格式提交數據，那不是業務系統該做的事情。以收款記賬爲例（下同）來串聯這個流程，下表是收款業務流水，信息做了簡化，一共 2 筆訂單，數據編碼都是 2001 類型，另外還有商戶編號、交易金額、時間、支付金額、手續費、業務產品等維度的信息。

1.2.3 記賬需要憑證規則

業務流水生成以後，賬務事務控制基於記賬規則，生成相應的記賬憑證，我們先看 2001 收款類流水的記賬憑證規則，包含 2 張憑證規則，一張時本金的入賬憑證 “借記清算往來，貸記商戶待結算”，另一張是手續費的轉賬憑證 “借記商戶手續費，貸記平臺手續費收入”。

1.2.4 憑證生成

通過規則可以看出來，會生成 2 張憑證，並且其中 002 號憑證的 03 行需要進行單邊的資金處理，實時更新商戶手續費賬戶，生成的 2 張憑證如下表所示。

1.2.5 實時資金處理

002 號憑證的 03 憑證行需要進行資金處理，請求賬戶子系統進行資金處理生成賬戶明細，以支出的形式入賬到商戶的手續費賬戶中，並登記入賬前後的賬戶餘額。

1.2.6 定時憑證彙總

因爲電商類企業收款業務數量巨大，因此往往需要對明細憑證行進行彙總，以便向會計提交數據時不至於數據量過大，而會計分錄數據可以向原明細憑證進行關聯追溯；對收款憑證進行彙總得到彙總憑證

1.2.7 單據關係

外圍系統驅動賬務登記，整個鏈條上會產生一系列的單據，業務系統有業務單據，提交至賬務核心以後賬務系統也會生成一些單據，這些單據之間的關係如下圖所示

2. 賬戶子系統  

賬戶是根據會計科目設置的，具有一定格式和結構，用於反映會計要素的增減變動情況及其結果的載體，而賬戶體系是支付交易的基礎，就像電池對於手機，油罐對於加油站，心臟對於人體，是管理賬戶的信息化系統。

2.1 賬戶生態及原理

現代電子支付離不開各類賬戶的參與，又因爲支付體系中存在衆多機構參與者，因此也必將存在種類繁多的資金賬戶，要想悟透支付，參透賬戶體系非常重要。從不同的視角看，賬戶有不同的分法，例如從財務視角，賬戶可分爲資產類、負債類、所有者權益類、損益類、共同類等；因爲要研究支付，所以我們更關注跟支付相關的賬戶，也就是跟貨幣 - 銀行存款相關的賬戶，這類賬戶又可以從賬戶用途或者機構歸屬去劃分。從賬戶用途的角度去劃分，在整個清結算鏈路上可以將賬戶劃分爲 “存款賬戶、中間過渡戶（清算往來、已清算、待結算）、客戶虛擬賬戶等”。

從機構歸屬的角度去劃分，又可以分爲央行清算賬戶、銀行結算賬戶、支付機構支付賬戶、普通企業虛擬賬戶等。而每個機構的賬戶又可以進行二次多級分類，例如銀行賬戶又可以分爲個人結算賬戶、企業結算賬戶；支付機構的賬戶可以分爲個人支付賬戶、企業支付賬戶；而銀行個人結算賬戶又可以分爲一二三類戶。金融監管的本質實際上是對不同機構的不同類型的賬戶進行個性化監管，例如銀行的個人結算賬戶和單位結算賬戶分別適用於不同的監管條例；而個人結算戶的一類二類三類戶又擁有不同的賬戶交易權限。如此富有層次的賬戶體系，支撐起了如此龐大的支付清算體系，使得各類資金在不同機構、不同賬戶之間進行流轉，也正因爲有這麼龐大的賬戶體系，現代支付的實現才成爲可能。

2.1.1 清結算 5 類賬戶原理

根據賬戶用途的不同，可以將賬戶分爲如下 5 類：客戶賬戶、結算過渡戶、清算往來戶、已清算應收付賬戶、XX 存款戶；各類機構會基於實際情況選擇設定這 5 類賬戶中的一種或者多種用於自己的清結算業務，其中客戶的賬戶就是我管別人的錢，而 XX 存款就是我的錢被管在 XX 那。

在不同的機構，這 5 類賬戶的性質會有所不同，例如對於銀行來說客戶賬戶就是個人或企業結算賬戶，屬於資金賬戶，而存款多指在央行的存款或者在其他金融機構開立的存款賬戶。對於支付機構來說，客戶賬戶就是支付賬戶，而存款多指存放在央行的備付金存款賬戶的資金。同樣清算往來賬戶登記的也有差別，支付機構的清算往來是指與網聯銀聯的往來；而交易平臺的清算往來指的是交易平臺與支付機構的支付往來。有了對於賬戶的這個基本原理的認知，再理解各類機構的賬戶設定就容易多了。

2.1.2 支付機構支付賬戶

支付賬戶可以分爲個人支付賬戶和企業支付賬戶；該賬戶實際上是一種虛擬記賬賬戶，真實的資金存放在央行。企業支付賬戶多是用於登記其商戶的代收預付的款項，最終會結算至企業綁定的同名銀行單位結算賬戶中。個人支付賬戶主要是用於零售消費使用，可以通過綁定的個人銀行結算戶進行資金充值，同樣也是一個虛擬記賬賬戶，真實的資金也存放支付機構在央行的備付金賬戶中。

2.1.3 銀行結算賬戶

銀行結算賬戶也就是我們所熟悉的銀行卡的底層賬戶，可以分爲個人結算賬戶和單位結算賬戶，這類賬戶是整個社會的金融基礎，個人存款、消費等的資金存放處。

2.1.4 央行三方備付金賬戶及清算賬戶

央行的賬戶與支付比較密切的就是三方備付金賬戶以及銀行和網銀聯的清算賬戶，跨機構支付清算在這些賬戶之間完成最終的資金清算。

2.1.5 清算機構清算虛擬賬戶

斷直連以後，網銀聯爲支付機構在其前置系統內開設清算用途的虛擬賬戶，用於央行備付金的映射管理、機構間清算往來登記、可用額度管理。這裏的所有餘額都只是虛擬記賬，是機構間交易的清算結果，真實的資金存放在各機構在央行的備付金賬戶中，只有在結算場次將各機構的清算淨額提交央行完成最終清算以後，央行備付金餘額纔會發生變動。

2.2 賬戶系統概述  

在開始學習賬戶系統之前，先看賬戶的基本結構，標準的賬戶應包含以下內容:

從業務視角來看賬戶，賬戶可以理解爲是用於記錄某個主體、某類型資金的餘額、以及餘額變動明細的數據載體，所以賬戶應該包含 3 個最基本的信息。

抓住了上面的 3 個關鍵點，也就抓住了賬戶設計的核心了。基於這 3 個點去構建賬戶的輔助內容，比如賬戶主體、賬戶種類、賬戶餘額結構、賬戶流水的字段、賬戶的功能權限、賬戶的出入賬、賬戶其他服務（賬戶開通、註銷、凍結、解凍、餘額流水查詢）等。

2.2.1 賬戶種類

與科目分類相同，賬戶可以分資產類賬戶、負債類賬戶、損益類賬戶、共同類賬戶。從業務的視角看，可以基於業務場景對賬戶進行分類和命名，比如商戶的結算款會結算到商戶結算賬戶，支付公司在銀行開的賬戶叫備付金賬戶，斷直連之前備付金賬戶又分存管戶、收付戶、匯繳戶；按主體類型可以分個人賬戶、企業賬戶；按賬戶的功能又可以分爲會員子賬戶、商戶子賬戶、中間擔保戶等，下圖某監管類賬戶的子賬戶種類設置。

通過賬戶的命名基本就知道了這個賬戶是幹什麼用的。就像某人有 10 張卡，其中一張是存放工資的卡叫工資卡。基於業務命名，目的是爲了更容易識別賬戶的用途。

賬戶無論叫什麼名字，都要包括賬戶餘額、賬戶流水、賬戶交易這幾項；無論銀行卡叫什麼名字，其本質都是銀行卡。所以賬戶的本質屬性並不會隨着賬戶名稱的改變而改變，設計方法也基本相同。不同的是附屬內容存在區別，例如支出賬戶只能打款不能收款，中間擔保賬戶餘額不能爲負等，賬戶權限可能不同、主體歸屬不同、交易特點不同等

2.2.2 賬戶系統功能結構

先從整體上了解賬戶系統的基本功能，一個基礎的賬戶系統應該至少包含賬戶配置、賬戶管理、賬戶信息管理、賬戶權限、賬戶交易等模塊。

2.2.3 基於賬戶的解決方案

賬戶是一個底層服務，基於賬戶提供的服務可以構建很多資金解決方案提供給不同場景、不同人員或者上層產品使用，整個解決方案藍圖如下圖。

最底層是賬戶的基礎能力，包括主體管理、賬戶管理、餘額管理、交易管理等，是賬戶封裝各類服務的能力基礎。

基礎賬戶基礎服務可以向外提供一個 API 矩陣，將賬戶能力包裝成服務接口提供給上游各方，例如主體變更、賬戶開通、信息查詢、交易服務、凍結解凍等。

然後就是基於賬戶服務而封裝出來的各類資金解決方案，如結算業務、對公結算業務、其他種類的結算業務、財務處理等。

在業務層就可以產出如錢包、收銀臺、對公結算平臺等用戶產品，提供給用戶和商戶、內部財務人員或運營人員使用的產品工具。

2.3 賬戶主體

賬戶需要歸屬於一個主體，也就是誰的錢、誰的債。主體可以是個人人，可以是公司，可以是一個組織，主體是一個具有基本特徵的可定義的對象。

2.3.1 主體的定義

廣義的主體，基於對象出發，可以認爲主體就是自然界存在的實體物質或者虛擬的對象，如一個人是一個主體，一個公司是一個主體陳天宇宙，一個組織是一個主體，公司的一條業務線是一個主體，公司的一個部門也是一個主體，一個城市也是一個主體，一座房子也可以是一個主體。賬戶的主體可以是廣義的，比如一個城市的 GDP 因爲可以通過一個統計報表得到，所以也可以爲每個城市設置一個 GDP 賬戶，那麼這個賬戶的主體就是一座城市。因此，只要是一個可以被定義的對象，我們就可以將它作爲賬戶的主體來管理，就可以爲之開通某種意義上的賬戶，賬戶也可以是廣義的，不只是金錢餘額，也可以是水量餘額，電量餘額，好感度餘額等等。從而廣義賬戶就可以認爲是一個可以記錄數量和數量變化歷史的工具。

狹義的主體，迴歸賬戶主體本身，就是賬戶的歸屬對象；最常見的主體分類就是個人和企業；如銀行卡的主體有個人主體和法人主體。一個公司爲了經營分析或者管理的需要，又會虛擬出更多的主體類型，比如營銷賬戶的主體可以是業務線、部門或者一個小組，來記錄部門和小組的預算以及預算的消耗情況。從央行的角度看，清算賬戶的主體就是網聯、銀聯、各商業銀行、各城市處理中心、各特批處理機構；站在銀行角度看銀行賬戶的主體就是個人、企業、支付機構等；站在一個普通企業看賬戶主體就是個人用戶、企業用戶、內部業務線、子公司等。

2.3.2 主體的生成和管理

對於一個平臺而言，其賬戶系統的主體無非有以下幾種：

在創建主體的同時就需要定義每一類主體的唯一識別 ID。在開戶的時候，需要使用這個唯一識別 ID 作爲賬戶主體的唯一識標識。個人的唯一 ID 可以是身份證，在開銀行卡的時候就是用的身份證 ID 作爲個人的唯一識別 ID，在辦理社保的時候也是用身份證 ID 作爲身份的唯一識別 ID；唯一 ID 的條件就是能夠唯一識別這個主體，其中：個人的唯一 ID 可以是身份證、手機號、社保號、一個平臺的 userID，其他的在這個平臺的唯一 ID；企業的唯一 ID 可以是統一社會信用編號，也可以是對公戶的卡號等；如果企業入駐了一個平臺，那麼這個平臺爲這個企業生成的企業編碼也可以唯一識別這個企業。唯一 ID 的用途是唯一識別這個主體，但有時候可能這個主體的唯一身份 ID 不夠用，比如這個人在淘寶即是個人用戶又是商家用戶，那麼他在開戶時可能就不能只用身份證了，而是用個人身份的 userID  和商戶身份的 bussid。

爲了安全起見，平臺需要覈查主體的身份，像去銀行開戶需要本人到場 + 身份證覈驗；二類戶的開通需要多要素鑑權識別主體身份的合法性。對於企業來說可以通過企業的營業執照、法人簽字、蓋章或者對公戶小額打款來驗證企業的真實身份

怎麼管理這些主體呢？一個平臺的各主體信息一般是放在用戶中心，用戶中心去調用賬戶中心爲主體開通相應的賬戶。用戶中心存儲着主體的基本信息，比如 ID 信息、屬性信息、權限信息、關係信息等。要新增信息就增加字段即可，也可以將信息進行分類，每一類記錄到不同的表中，比如身份信息、認證信息、賬戶開通信息等，如下表所示。

2.3.3 爲主體開通戶

生成了主體信息以後，就可以通過人工方式開戶，也可以通過上游系統調用開戶接口爲主體開通相關賬戶，例如通過接口開通賬戶傳入了以下信息：

開戶成功後賬戶系統首先會在賬戶主體表中插入主體的基本信息。

根據主體 ID 可以去賬戶表查詢開通的所有賬戶，基於開戶請求我們在賬戶中心表爲主體創建對應的賬戶，賬戶中心表中要有主體的唯一 ID。

在賬戶餘額表中爲賬戶創建賬戶餘額。

在賬戶的權限表中設置賬戶權限。

賬戶中心經過上述一系列的處理後，賬戶就開通成功了，然後將開戶結果返回給開戶請求方。

從上面的開戶過程可以看出來，賬戶和主體之間有複雜的對應關係，主體和賬戶以及與賬戶主表與各類子表之間有複雜的對應關係，主體與賬戶是一對多的關係，一個主體可以開通多個賬戶，每一個賬戶又會關聯餘額表、權限表、流水錶等多張表，主體的開戶 ID 去關聯賬戶的賬戶 ID，賬戶 ID 去關聯賬戶的餘額表中的餘額、權限表中的權限。

2.4 賬戶結構與關係

設計賬戶前需要了解賬戶的基礎結構，所面對的業務不同，就意味着需要的賬戶結構就會存在差異，可以從賬戶的複雜程度將賬戶結構分成簡單結構和複雜結構。

2.4.1 賬戶結構

賬戶結構一方面是賬戶本身的結構有什麼組成，另方面就是賬戶與賬戶之間的構成關係。簡單的賬戶結構可以分爲單類型賬戶和多類型賬戶，單類型賬戶是隻有一個類型的賬戶，整個賬戶系統只有一類賬戶，或者有多個類型的賬戶，但賬戶層級只有一級，本質上依然很簡單，很容易管理。

隨着業務的複雜度增加，各類功能性需求以及業務需求增加，簡單的賬戶結構變得不夠用了，難以支撐更復雜的業務模型，例如每個業務線都要推出一種紅包營銷形態，有保險業務線的紅包，也有遊戲業務線的紅包，而紅包又被拆分成了現金紅包、虛擬幣紅包，這種情形下紅包賬戶結構就成了多層級的複雜賬戶結構。

某些監管類賬戶的結構更加複雜，不僅存在多層級的賬戶關係，還從業務層面對賬戶進行了分組，如下圖所示，是具有衆多子賬戶的賬戶結構，協同完成資金的監管和分賬職能。

2.4.2 餘額結構

餘額結構就是賬戶的餘額如何劃分，就像火鍋可以分一個鍋、鴛鴦鍋、九宮格；同樣，賬戶作爲一個 “資金容器”，其內部依然可以劃分成多個存儲空間，按照賬戶餘額的種類可以將賬戶分成簡單餘額結構和複雜餘額結構。

只有一個餘額的餘額結構是簡單餘額結構，比如微信錢包的餘額只有一個，陳天宇宙。

複雜餘額結構是指賬戶的餘額被拆分成了多個餘額。因爲資金清算週期或者業務流轉節點多，亦或者其他風控要求，需要對賬戶餘額進行復雜的處理操作，比如有的能提現，有的不能提現。常見的複雜餘額結構如表所示的具有三個餘額屬性的賬戶餘額結構。

這種結構存在一個核算恆等式：總餘額 = 凍結餘額 + 可用餘額，基於這樣的結構，可以對賬戶餘額進行一些複雜的處理，比如發的紅包 7 天后才能提現，那麼紅包入賬戶時就可以先入凍結餘額，7 日後解凍到可用餘額。

2.4.3 賬戶結構關係

賬戶可以分多級，餘額可以分多塊，那麼他們之間有什麼關係呢？可以用下面的公式表達。

瞭解了賬戶主體、賬戶結構、賬戶餘額結構以後，就可以設計出賬戶表的基本字段了，大體上應包含這幾部分信息：賬戶主體信息、賬戶結構信息、餘額信息、賬戶狀態信息；除了核心字段以外，其他想展示的字段可以去相關表中查詢，比如主體信息，可以用主體 ID 去主體表中查詢。

2.5 費用項和入賬配置

開通了賬戶以後，賬戶裏就會有存入和存出、充值和提現、轉賬和消費；此時賬戶就會流動起來，就有了生命力；那麼在不同的交易場景裏就需要關注 “費用”，一筆收支有多少錢，是什麼費用，賬戶的記賬才清晰。

2.5.1 交易場景

任何一筆收支的發生都依託於一個或多個場景，例如用戶出行在某打車平臺叫了一輛快車，張師傅接了單子，路程從立水橋南到奧森公園；這就是一個交易場景，可以稱爲” 快車打車場景 “，在這個場景裏我們可以知道用戶是誰、在哪兒打的車、什麼車型、起步價多少、每公里單價多少、司機是誰等信息。

如果車到了超過了 4 分鐘，用戶不用車取消了訂單，用戶就需要支付一個取消費用，這又是一個新的場景，可以稱爲 “超時取消場景”。將平臺的所有交易場景進行枚舉，如果要新增場景，那麼要預先在場景中心申請場景編號，才能開展上線業務。

2.5.2 費用項

在上述的場景中，就會發生交易，因此會產生一系列的費用，例如打車單的相關費用費用包括下面這些，完單後要給司機做結算就有了訂單結算費用，平臺要抽取一定服務費就有了平臺服務費用，如果是在高峯期，要給司機發一些補貼，就有了高峯補貼費等等。

費用就是站在業務角度定義資金的業務屬性，基於業務側的費用我們可以關聯到後續的財務科目，費用是從業務發生那一刻就產生，而且最後可以關聯到會計科目的核算內容。

2.5.3 計算

計算業務場景中產生的費用需要一個強大的計費系統，例如上一小節中的場景，在下單前需要進行費用的預計算，用戶選擇起點和終點後預先計算可能需要的訂單費用；在訂單進行中需要實時計算費用，訂單結束後需要計算出本單實際產生的費用。

從圖中可以看出來訂單總費用包含三部分：起步價 + 里程費 + 時長費；你可能會問，一個訂單爲什麼要拆成這麼多費用呢？簡單想一下，這三個費用的特點，而且這三個費用在不同的城市，不同的時段，不同的用戶，不同的車型都會發生變化，所以可以理解爲，費用的細化是精細化運營的必然結果，另外用戶也需要知道爲什麼收這麼多錢。

訂單完結後就需要給司機做結算，就需要再進行一次計算，計算出這一單應該給司機多少錢，平臺抽多少錢，要不要實時扣稅，有沒有其他費用，比如保險費等，即可以得出如下的清算結果。

2.5.4 費用管理設計

前面講了交易場景和費用的定義，現在進行費用設計的分析，設計費用有三個關鍵點：費用編碼、費用名稱、費用結構。當然，圍繞費用可以展開非常深的研究，如與科目的關聯、費用的資金方向、用途等，本部分僅從簡單的原理進行設計，不做過於複雜的分析。設計辦法常見的有 2 種：一級枚舉型，就是費用之間沒有關係，對所有費用進行枚舉，如下表；另一種是多級結構，可以對費用進行分組，在不同的使用場景下展示不同級別的名稱。以上兩種方式可能第二種更好一些，特別是在覈算和統計時，可以進行總分分別進行統計分析和核算。

         

2.5.5 入賬規則管理

在交易的每一個節點都會產生費用，或者計算出相關的費用，例如司機收入。計費之後就需要計入相關的賬戶，如司機收入要計入司機的結算賬戶；有時候一個費用要計入多個賬戶，又比如司機獎金可能要同時計入平臺的運營賬戶和司機的結算賬戶。

入賬規則的設計有兩個關鍵點，一個是匹配條件，要以入賬請求的傳參爲條件匹配到相關的入賬規則條目，需要定義每類記賬請求需要什麼條件，比如司機收入入賬，一個 “費用類型” 作爲條件就夠了；另一個是入賬規則，就是這個條目指定入什麼賬戶，比如司機收入匹配到的規則是要記入司機結算賬戶，則入賬規則如下：

這樣就得到了一條入賬規則，如表所示。

基於上面的規則，上游系統在申請入賬時必須傳幾個參數：費用類型、主體類型、主體 id。基於司機收入這個費用，就可以匹配出一條規則，應該入司機的結算賬戶，利用司機 ID 找到相關的結算賬戶 ID 然後計入賬戶，這個流程如下圖所示。

2.6 凍結配置與賬戶流水    

業務系統請求入賬以後，基於費用類型以及入賬規則就可以知道應該入哪個賬戶；那麼問題就來了，因爲賬戶餘額也是分結構的，有凍結餘額和可用餘額，要是想將入賬金額先凍結起來怎麼辦呢？這就需要凍結規則去實現。

2.6.1 凍結規則

凍結就是一個費用請求入賬時暫時凍結起來，計入凍結餘額。凍結規則是基於入賬規則設置的，也就是這筆入賬需不需要凍結，如何凍結，是全部凍結還是部分凍結，所以一個入賬規則要關聯一個凍結規則，入賬的時候就需要同時獲取凍結規則；入賬規則和凍結規則是一對一的關係，費用類型和入賬規則是一對多的關係，因此，費用類型、入賬規則、凍結規則三者之間的關係如圖所示，陳天宇宙。

凍結規則有 2 部分組成，一個是關聯的入賬規則；另一個是凍結規則。也就是說在配置入賬規則的同時就需要關聯性的去配置一條凍結規則，如下表所示。

配置規則的新增規則原型如圖所示，凍結模式爲固定時間和固定時長的規則配置內容不同，具體看圖例，凍結規則的配置有以下幾個關鍵點：

2.6.2 賬戶流水

賬戶有 2 個核心部分組成，一個是賬戶餘額，另一個就是賬戶流水。賬戶流水是賬戶的歷史變動明細。爲了記錄資金的變動明細，賬戶流水需要記錄最基本的明細信息，一般必須包含以下內容：

2.6.3 更新賬戶餘額

這裏有一個賬務處理任務流，每筆入賬都需要從頭執行到尾，不能遺漏，任何一個處理失敗了這筆入賬就宣佈失敗，進行入賬失敗的處理流程，入賬任務流如下：

總餘額 = 總餘額 + 本次發生額

凍結餘額 = 凍結餘額 + 本次發生額（凍結時）

可用餘額 = 可用餘額 + 本次發生額（不凍結時）

自洽校驗：總餘額 = 凍結餘額 + 可用餘額；

經過上述的處理流程，成功的完成了入賬，並通知請求方，本次入賬結束。

2.6.4 餘額解凍

因爲入賬的時候有的流水處於凍結狀態，所以需要按照凍結的規則進行解凍。此時，需要一個解凍處理的任務對流水進行掃描，至於掃描的模式要基於凍結模式去設計，我們以凍結固定時長最小單位爲天爲例，那麼任務就需要每日凌晨去掃描遍歷所有處於凍結狀態的賬戶流水，滿足解凍條件的流水就變更凍結狀態爲未凍結，然後對餘額進行處理，即減少凍結餘額並增加可用餘額，賬戶總餘額不變。   

3. 賬務層解決問題  

特別是企業的清結算業務，賬務是其核心部分；另外現在支付體系的基礎也可以說是站在賬務核心之上，不同機構的賬務管理着不同資金屬性的 “賬戶”，管理着不同的信用貨幣。

市面上的賬戶種類主要有三方支付機構的支付賬戶、銀行的結算賬戶、央行的清算賬戶、合規監管賬戶體系、數字貨幣錢包體系、跨主體清算的往來賬戶、區塊鏈的分佈式賬務等。不難看出發現，支付的創新和變革，支付產品的設計很多都是建立在一套新賬務模式之上；如果你想做一個支付業務，那麼先把賬務想清楚，基本事情就成功了一半。

3.1 賬務作爲突破口  

作爲一名支付產品經理，工作中經常會遇到新的業務形式或者業務變化，任何新的業務和變化基本上都會觸碰到資金的問題，任何資金的問題又會涉及到財務和法務以及公司主體的資金問題，這些問題更多的是 “規矩”，交給法務、財務去解決。

另一個問題是技術問題，這個事情如何去落地，很多場景我們都會有很多的選擇；而最後總會有一個耀眼的明星脫穎而出 “從賬務上去解決問題”，其實也可以說是“從信息層去解決問題”，換而言之就是“先把賬捋清楚，把賬務處理搞明白” 事情可能就解決了。

怎麼把賬搞清楚呢，無外乎，這是誰的賬，要記到什麼賬戶，使用什麼樣的費用去記錄，什麼時候去記錄，誰來請求記錄等。所以說，精通財務會讓產品設計容易很多，因爲無論是技術還是產品還是運營，大家的擋箭牌都是 “我不太懂財務”, 爲什麼財務這麼重要，因爲它基本是支付的終點，任何支付問題，最後都會從業務問題收斂到財務問題，系統上收斂到 “賬務核心”。大家可以回想一下，自己工作中遇到的各種支付問題，哪些跟賬務相關。

我們去理解很多支付產品，或者接入不同的支付解決方案，最關注的還是對方的賬戶體系怎麼建設的，就會涉及到支付的兩個核心問題，一個是信息流的問題，另一個是資金流的問題。

很多時候，通過 “玩轉賬務” 會讓工作如魚得水；從信息層解決問題，可以凸顯自己不可替代的專業性，會讓事情脈絡非常清晰，也會讓項目成本極大的降低，簡單的說會讓事情做的很漂亮。

當一個新業務像毛線球一樣一團糟時，可以考慮從賬務模型上把事情抽象出來，事情會清晰很多；賬務就像心臟一樣將血液有條不紊的輸送出去，業務就像各個臟器一樣，他們賴以生存的血液又會有條不紊的迴流迴心髒。

如果做線下結算體系的線上化，那麼請先把 “賬” 想明白；那些結算對象，他們都要結算什麼款項，由哪些主體給他們結算，分別使用什麼資金；結算後財務又需要什麼樣的報表去記賬；如何爲結算對象設計“賬戶體系”。

3.2 從 “賬” 上解決業務問題  

很多企業的某些業務會需要繳納保證金，比如在淘寶開店，需要繳納店鋪保證金，騎共享單車需要繳納保證金，在抖音開店需要繳納保證金；在支付機構接入支付產品同樣也需要繳納保證金。保證金的用途其實就是擔保，就是增加對象在平臺的信用兜底；在淘寶經營出了問題，那麼保證金就可以作爲最後的兜底手段，如果因爲退款出現了欠款，就可以用保證金償還。

但是，很多企業的保證金是單獨存在的，跟某些業務或者說業務賬戶並不能互通；比如淘寶，你的經營結算賬戶出現了欠款，不能直接從保證金轉入進行抵償；這個過程會涉及到很多問題；一個是兩個賬戶的業務屬性不同，資金屬性也不同，法律問題也不同，同樣在公司的財務層面上科目也不同，在資金層面上也在不同的銀行賬戶中，或者在不同的監管賬戶中。

這種情況下，要想將保證金扣一部分用於抵扣結算賬戶欠款，會面臨很多問題，那麼這時候，可以換個思路，先從 “賬務” 上去把問題解決，從 “賬務” 上去梳理對應的其他事物；因爲賬務跟公司主體，所屬對象，財務科目，背後管理的銀行資金相互關聯，賬務理清楚了這個事就清楚了；賬務動了，每一個關聯的環節都會順勢而動。

例如：某 B2B 電商給商家提供商家貸，給個人用戶提供消費貸，其 C2C 電商業務中商家或者個人有用於經營結算的賬戶；所以大家有沒有發現這個體系裏存在着資金的閉環，同樣也存在着風控的閉環。

用戶在其消費端申請消費貸款，然後在其電商平臺購買商品，錢最終結算給了商家；同樣商家又可以在平臺申請商家貸，然後到 B2B 採購平臺去採購商品。

如果商家在 B2B 的貸款還不上了，就可以用商家在電商平臺的經營結算款去強制償還。如此就降低了商家貸的壞賬；陳天宇宙總之，這套供應鏈金融體系，讓資金極大的在內部形成閉環，流動性在內部進行控制，支付效率可以說極高，風控能力可以說極強。

這個閉環效率，其實就可以從賬務層完成，相關的合規問題，法務問題，以及其他更多問題不在這裏探討，比如不同主體間債權債務關係轉移的協議等，實際工作中請嚴格遵循財務和法務意見以及當地的相關法律和監管制度。

在工作中遇到問題，嘗試着從賬務層尋找突破口，很多時候會事半功倍。

4. 熱點賬戶  

經常聽到 “熱點賬戶” 的概念，很多人對什麼是熱點賬戶並不陌生，但是對如何解決熱點賬戶問題並沒有系統性的完整的思路；事物總是發展的，事物所處的場景也是在不斷變化的，基於有限的經驗去解決無限的可能性是很好的技能，本小節將從認識熱點賬戶開始，解析幾個常見的解決熱點賬戶問題的思路，徹底掌握熱點賬戶的內容。

4.1 認識熱點賬戶  

認識熱點賬戶之前先簡單回顧一下賬戶，瞭解賬戶的結構是 “入賬請求、賬戶流水、賬戶餘額”，入賬請求產生了賬戶流水，賬戶流水更新賬戶餘額，其中我們要關注賬戶流水的創建以及賬戶餘額的更新，要重點關注賬戶餘額更新，這是造成熱點賬戶問題的主要環節

賬戶的賬務處理主要分三類：收錢、付錢、賬戶之間轉賬；收錢針是增加餘額，付款是餘額減少，轉賬是兩個賬戶之間一個增加一個減少。

4.1.1 熱點賬戶定義

賬戶處理存在最大併發量，超過這個併發量時賬務處理就會出問題。賬務處理過程中需要進行線程控制，無論是收錢、付錢還是轉賬，爲了保證賬務的準確性，每次賬務處理都是一個單獨的事務，就算是多個請求同時發生，對賬戶的操作也需要一個一個的進行處理，當一筆入賬請求開始處理時賬戶資源會被加鎖，等該筆請求處理完以後會釋放鎖。這就意味着每一筆賬務處理都會佔用一定的時間，在這個時間內其他入賬是不能操作的，這就出現了資源的瓶頸，即賬戶入賬必然存在一個併發的最大閾值，一旦超過這個閾值，就會出現賬戶的性能問題。

在交易併發過程中，有些字段的使用頻率很高，比如流水號、餘額、發生額等字段，這些使用頻率很高的字段稱爲熱點字段；導致熱點字段的事件稱爲熱點事件，比如商家結算日，需要給商家結算付款，這時候造成付款專戶的付款併發，這就是一個熱點事件。

業務發生以後會產生業務事件，如下單進行支付時，而業務事件發生後需要申請入賬；當在短時間內產生了大量的業務事件，或者有大量的交易產生時，就會造成高併發的入賬請求，此時高併發的賬務處理將會引起賬戶系統的性能瓶頸從而產生性能問題，進而造成入賬延遲、失敗、賬務準確性等各種賬務問題，這個過程中涉及到的賬戶我們就稱爲熱點賬戶。

因此，熱點賬戶是由於高併發交易發生時，賬戶系統頻繁更新賬戶產生性能問題而造成的，一個關鍵的前提是 “高併發”，一些文獻裏提到形成熱點賬戶需要滿足兩個標準：賬戶每秒有 10 次以上更新需求，串行化時賬戶處理延遲高於 1 秒以上。

4.1.2 常見熱點賬戶發生場景

既然熱點賬戶是由於高併發頻繁更新賬戶造成的，所以探索熱點賬戶的發生場景就轉換成了探索交易高併發的場景，這些高併發場景都有可能造成熱點賬戶，很容易想到 “雙 11 購物節”“微信發紅包”“某自營電商平臺的秒殺搶購”“小米官網新品的預售” 等等。

高併發場景有的是因爲高併發收款造成的，有些是高併發付款造成的；而且收款和付款的熱點賬戶解決方案往往會存在差異，不同場景的收款和付款解決方案也會有差異。就像淘寶雙 11 收款，淘寶中間賬戶因爲不外漏給用戶，後續商家履約週期也長，所以時效性要求並不高，可以考慮批量定時入賬、異步入賬、緩存入賬等模式，不採用實時入賬。因此，可以將業務場景分爲高頻入賬場景和高頻扣款場景；像淘寶雙 11 的中間擔保賬戶就是高頻入賬造成的熱點賬戶。

在淘寶購物時，錢並不會直接給到商家，而是先收到中間擔保賬戶，等商家履約完成以後纔會由擔保賬戶結算給商家。擔保賬戶有兩個過程，一個是用戶購買商品時的收款，另一個是服務履約結束後的結算付款。雙 11 期間用戶付款是一個熱點事件，從而中間擔保賬戶的收款就使得擔保戶成了熱點賬戶。

擔保賬戶是內部賬戶，並不外漏給用戶或者商家，這樣的話，只需要實時告訴用戶和商家已經付款成功即可，至於擔保賬戶的入賬可以慢慢的處理；從這裏可以得到一個思路，就是解決熱點賬戶應該關注兩個問題：

一個是對交易參與者的反饋策略：參與者需不需要實時知道賬戶的處理情況，是隻需要知道結果即可還是需要實時看到賬戶餘額的變化，顯然對於淘寶中間賬戶來說，賬戶參與者是不需要知道其賬戶餘額更新情況的，只需要知道支付成功的反饋結果即可，而這個結果可以依賴渠道的反饋通知，而內部記賬可以不反饋給用戶，這樣的話擔保賬戶就有了足夠的時間來規避併發問題。

另一個是賬務要求：賬務更新時效性要求高不高，賬務的準確性要求高不高，對於中間擔保戶來說對時效性要求不高，而所有賬戶對準確性要求都高。如此一來，可以採用批量處理，延遲更新中間擔保賬戶的方式來規避雙 11 高併發交易的入賬請求，從而規避熱點賬戶的發生。

數據庫插入數據的併發支持是非常大的，一般不會造成數據庫性能問題，批量插入即可，只是更新賬戶餘額需要進行鎖處理，會造成性能問題，所以解決淘寶中間賬戶的關鍵是解決賬戶餘額更新問題。

先將高併發入賬請求插入到入賬流水錶，這時並不着急去更新中間擔保賬戶餘額，此時這些流水我們標記一個入賬狀態 “未入賬”；定時的去掃描這個流水錶，將掃描到的數據進行加鎖，確保不會被後續入賬或其他處理影響，然後彙總求和，用這個求和的總值去更新中間擔保賬戶的餘額，將這一批“未入賬” 流水更新爲已入賬，最後釋放鎖，這樣就以很小的併發完成了對中間賬戶的更新。

接下來介紹幾種常見的熱點賬戶解決方案，並且針對每個方案列舉一個實際的案例爲補充；對於熱點賬戶的方案設計，需要重點關注幾個問題：

4.2 熱點賬戶解決方案  

不難發現，熱點賬戶產生的根本機理跟城市交通高峯時段的擁堵地段是相同的，怎麼解決高峯問題，錯峯出行、限號限流、分流等等方法都可以緩解擁堵；解決熱點賬戶的思路類似，既然是高併發造成的擁堵，就可以以降低賬戶的併發爲解決熱點問題的抓手，也就是降低熱點賬戶的操作併發以降低賬戶熱度。如可以採用緩存記賬、批量彙總記賬、將賬戶拆分分攤併發、進行記賬排隊等等手段來降低對賬戶的高併發操作，從而降低賬戶熱度。

4.2.1 限號限流直接控制併發

不想太多，陳天宇宙直接解決產生問題的問題本身；既然熱點賬戶是有高併發造成的，那麼反向思考，這個併發閾值是多少，在賬戶之前設一道屏障控制這個閾值，就像很多城市的限號限流一樣，最終的結果肯定是損害一部分車主的體驗；雖然是立竿見影的效果，但是這也是自損 800 的方案；這裏我們不妨稱之爲 “熱點閥”。

所以給賬戶安裝 “熱點閥” 可以解決熱點賬戶問題，但問題比較明顯的，除非賬戶系統很強勢，比如交通控制，否則以 “客戶優先” 爲宗旨的企業這種方式一般不會採用。

4.2.2 變多爲少明細彙總入賬

數據庫插入數據是可以支持非常高併發，所以插入流水不是熱點賬戶瓶頸所在，而是餘額更新。因此可以將 “降低賬戶的單位併發” 設計思路縮小到了 “降低餘額更新併發” 的範圍，餘額更新就是基於流水去增加或者減少餘額，即“balance=balance + 發生額”。 

新餘額等於當前餘額加上或減去該流水的發生額，要想降低餘額的更新頻率，可以從降低發生額的更新頻率入手，也就是你們這個多流水來更新我，我實在是忙不過來了，都堵在門口了，不如你們派一個代表 10 分鐘進來一次，彙總大家的要求，我一次性解決。這樣就是我們說的 “彙總明細記賬” 的方法，這樣的話這個函數就變成了：balance=balance+sum（一段時間內全部明細的發生額）。

該方案適用於不需要實時更新餘額的場景，且主要是增加賬戶餘額的場景，如果是扣款類場景，可能彙總入賬會造成賬戶餘額透支，不過如果允許賬戶透支，出款類場景也是可以考慮，只不過資金管理的時效就會變差，你無法通過賬戶餘額直接看到剩餘可用餘額。

4.2.3 排隊處理緩衝記賬

現在大家經常做核酸，因爲併發人數較大，檢測人員有限，所以大家需要排一個很長的隊伍。同時因爲一個人一個人的檢測成本也高，效率也低，因此將 10 個人分成一組進行混採，混採就像我們上面說的指派代表的彙總記賬一樣。所以說可以爲賬戶設置一個排隊機制，當出現高併發賬戶更新不過來時大家進行排隊辦理。

就算排隊可以解決賬戶的併發問題，但是同樣是存在瓶頸的。就像 10 個人採樣，100 萬人排隊，那要做到什麼時候，也可能發生抱怨和投訴。所以怎麼辦呢？增加檢測點是一個很好的辦法，1000 個人採樣，就可以分攤這麼多的檢測樣本；這就是下面要介紹的 “子賬戶拆分” 分攤壓力。

4.2.4 增加點位子賬戶拆分

當即要解決高併發的熱點賬戶問題又要保證實時性時，上面的方案因爲會影響賬戶的更新時效，自然就不是首選了，就需要一個能夠支持實時餘額更新的方案。

既然一個賬戶的更新出現了瓶頸，那是不是可以考慮爲他找更多的幫手分攤壓力呢？答案是肯定的。我們可以將賬戶進行按需拆分，拆分成多個子賬戶，將高併發請求分配給各個子賬戶，從而單個賬戶的併發就降下來了。這裏要明確一個問題，子賬戶是不能讓用戶感知的，只是內部的處理方案，對用戶來說還是一個賬戶，所以反映給用戶的流水和賬戶餘額還是一個，這就意味着賬戶作爲一個整體被用戶感知。

該方案勢必增加賬戶設計的複雜程度，如入賬的時候入哪個子賬戶？是平均入賬還是按序入賬？出賬的時候怎麼出？有個別子賬戶餘額不足但是總賬戶餘額充足時怎麼處理？所以說這裏會有一個複雜的賬務處理模型；不管這個模型怎麼設計，要保證金業務上順利完成賬務記錄要求，以及保證用戶的使用體驗，從而確保業務的正常進行。

之前設計的賬戶系統，每個商家可能會有七八個子賬戶，出款的時候是按照順序出款，就是先扣完一個賬戶扣下一個賬戶。

4.2.5 臨時存放緩存記賬

高併發請求可以先進行緩存，然後定時將緩存更新到數據庫。這個看起來跟緩衝記賬異曲同工，但這裏有個區別，緩衝記賬時賬務請求還在排隊入賬，而緩存記賬實際上賬務請求已經實時在緩存中完成了記賬。緩存記賬具備緩衝記賬和彙總明細記賬的雙重優點。

需要注意，因爲緩存需要具備賬戶餘額部分的管理，所以賬戶系統的餘額要賦予緩存模塊，緩存模塊在此餘額基礎上進行出金和入金的記賬操作；定期將緩存同步到賬戶系統完成最終的記賬，記賬完成的緩存部分可以進行清空，然後獲得最新的賬戶餘額，以此循環。

4.2.6 小弟先上前置緩衝

爲解決備付金集中存管所形成的熱點賬戶問題，實現對已映射額度管理，網聯構建了 “備付金熱點賬戶前置系統” 即“RCMP”，用於支付機構通過網聯平臺（EPCC）的業務辦理。

前置系統分爲額度管理模塊及賬戶管理模塊，網聯將爲各支付機構在前置系統中建立賬戶，用於可用額度的監控、已映射額度的管理。因爲網聯是 “實時清算，定時結算”，在一個清算週期內淨額軋差了支付機構的支付指令，最後提交給人行的結算請求筆數一個週期從每個機構的上千萬筆到一筆，這個看起來有點像彙總明細記賬，而這個彙總處理的操作是網聯代人行支付系統完成的。

如此看來，我們工作當中也可以設置這樣一個前置系統，來幫助賬戶系統完成壓力的分擔，比如要求業務方建設前置模塊，按照要求進行處理加工後請求入賬；特別是賬戶中臺，面對衆多業務線時，是不是可以考慮每個業務線在某些場景下都做賬戶前置，完成初步加工後再請求中臺賬戶系統，這樣就可以分擔中臺的壓力，又不損害中臺的賬戶核心能力，業務線也不用完整的建設賬戶系統；這裏的思路就是中臺不能一攬子打包，一些能力要分攤給業務線，比如業務線的個性化部分，需要業務線做前置層。

4.2.7 技術性能升級

技術層面就不過多討論了，作爲非專業人士，或者說從產品視角提些建議 “能多增加幾臺服務器麼，可以擴充下硬盤麼，你這個 cpu 可不可以換成頂尖的......”。

事物總是變化的，場景也會不斷地更新，面對新的場景，新的問題，歷史的經驗只能作爲解決新問題的參考；不妨在遇到虛擬問題時多思考一下真實的世界，也許會有意料之外的答案。

5. 賬戶合併  

這是事物的發展規律，只要公司業務在發展，人員在流動，運營者的理念總會發生變化，變化的過程中就會有人提出合併一些賬戶；同樣也會有運營人員提出拆分一些虛擬賬戶。那麼合併和拆分賬戶就要考驗產品經理的綜合把控能力和全面的知識儲備，需要知道合併和拆分會涉及到哪些方面的改造，如何改造，通過本小節的案例，可以清楚的掌握虛擬賬務、會計賬務、實際資金、業務等之間的關聯和協同關係，對虛擬記賬有一個更立體的認識。

5.1 合併場景分析  

保證金是一個很常見的平臺用於控制風險或者制衡外部參與者的資金手段，比如共享單車的保證金就是爲了保證車的安全，外賣員繳納的保證金就是爲了制約其服務質量，代理商的保證金同樣也是這樣的目的。

對於一個多業務線的平臺來說，每個業務線都可能需要繳納不同種類的保證金，比如用戶在 A 業務線需要繳納 A 保證金，在 B 業務線需要繳納 B 保證金，這種情況下，用戶就需要在錢包裏分別充值 A、B 兩類保證金。同樣，在平臺的賬戶中心也會有 A、B 兩個虛擬賬戶，每個保證金賬戶獨立存在，單獨管理。

保證金的賬務不只是在賬戶中心，在多處都有記錄，而且相互對應，互爲覈算關係。首先就是支付系統的充值和提現記錄；其次是賬戶系統的保證金開戶、保證金餘額、保證金流水的相關記錄；然後是會計系統對應的保證金科目以及會計記錄，和保證金資金管理賬戶的銀行存款科目；最後就是保證金的資金存儲的銀行結算賬戶的資金賬務記錄。

如果一個用戶或者商家在一個平臺繳納多種保證金的話，其實就意味着平臺是以業務爲顆粒度來管理保證金，這樣對於用戶來說勢必要繳納更多的保證金；一方面會造成用戶不滿，另一方面也會造成招商的難度，影響業務的發展。

其實，可以以個人或者商家主體爲維度來管理保證金，就是一個用戶在平臺只需要繳納一份保證金，實現 “一金多用，事後覈算” 的模式，也就是繳納的保證金屬於平臺總部統一管理，當各業務線發生保證金扣款時再計入各業務線名下，而不是在賬戶維度就計入業務線名下。這樣就可以很大程度的降低保證金賬戶數量以及提升用戶滿意度，同樣也降低了資金賬戶數量以及會計的管理成本。

合併賬戶需要關注什麼，做保證金賬戶合併不是簡單的將賬戶中心的虛擬賬戶合併到一起，而是要將保證金相關的多層賬務完成合並，首先是賬戶中心的多個保證金賬戶餘額合併到一個賬戶中去，另一個就是會計系統的多個保證金明細科目結轉到一個科目中去，然後就是將存儲在多個專用銀行賬戶中的資金調撥到對應的一個銀行賬戶當中，這樣操作完成以後，才真正實現保證金的合併。

5.2 賬戶合併方案  

在合併虛擬賬戶時，有很多種選擇，一種是將原來的一個保證金賬戶作爲合併後的總賬戶，另一種是新開通一個統一保證金賬戶，將原來的所有賬戶裏的餘額轉入。我比較推薦用後者，賬務更加清晰，不必揹負歷史的衆多賬務問題，以新賬戶爲起點重新出發。

同理會計系統也要新建相應的保證金科目，將原來的 A 類保證金科目餘額和 B 類保證金科目餘額全部結轉到新的統一保證金科目當中，至於結轉多少，這個要依據賬戶中心提供的 “餘額轉出” 的系統賬務統計進行結轉。

這樣的動作也會間接的進行一次系統賬務和會計賬戶的核算，比如系統賬務的 “A 類保證金餘額轉出 = X”，假如會計系統的 A 類保證金科目餘額不等於 X，說明這個科目的餘額沒辦法結轉爲 0，即系統賬務跟會計賬務覈算不一致，這就需要一定的策略進行差錯處理，以使得會計科目餘額最終結轉爲 0。假如結轉完 X 以後，B 類科目餘額還有△X，則可以再結轉一次△X，可以定義爲保證金調整。

前期不同業務線的保證金可能存放在不同的銀行賬戶中，既然業務系統以及會計系統都完成了賬務合併和餘額的轉移，那麼對應的銀行賬戶的資金也應該做相應的調撥合併。假如又開了一個新的銀行賬戶 T，這就需要根據系統記錄轉移的餘額 X 進行資金的調撥，如果資金不足或者調撥後有結餘，就需要進行歷史資金賬務的核算，以找到賬務出現差錯的原因，進行對應的差錯處理，比如資金剩餘了，可以確認資金爲營業外收入 - 保證金未知結餘；這就屬於天上掉餡餅了，如圖所示。

最後陳天宇宙要處理另一個事情，就是不同業務線成員對系統的操作，因爲保證金已經合併了，那麼如果用戶因爲在不同業務線出現了違規要扣除一部分保證金，那麼這時候就需要知道這筆保證金扣除應該歸屬那個業務線。實現方法有很多，我們可以在扣除流水上標記業務線，怎麼識別業務線呢？可以在操作扣除時要求選擇什麼業務線要扣除。

6.“倒扣” 的博弈  

某些情況下在還沒有獲得任何收益時，讓用戶去預支付一筆資金是非常困難的，就算這筆錢在滿足條件後可以退還。特別是用工市場，如家政阿姨、外賣員、出行司機等。什麼還沒幹呢，上來就交一筆保證金，或者購買一些工具包，大家會有一些牴觸。如果是比較大的平臺可能還好一點，如果是一些小的機構或者組織就很難收上來這筆錢了。

這種情況下就出現了一個這樣的模式：你先幹着，這筆錢先不用自己交，從後面的收入裏慢慢扣除，直到扣足了爲止。暫且稱這個模式爲 “倒扣” 模式。

倒扣模式從一定程度上可以降低招募服務人員的難度，但同時也會增加資金風險，特別是在需要服務人員領取工具的情況下。如果勞動者領取了工具，但是沒有掙得足夠的收入，那麼這個工具費用是有可能成爲損失的，所以這裏面就是二者的博弈，用風險博取商業上的利益。

如何實現倒扣模式的系統設計呢？系統需要實現 “清楚每個用戶應該倒扣多少錢，然後在後續的收入中進行扣除，多餘的部分結算給商家”。

6.1 兩個記賬模式  

首先解決規則和記賬的問題，需要制定一套規則從而知道每一類用戶應該交多少錢；其次需要知道每一個用戶本次結算應該倒扣多少錢，因此從期初的規則值開始，後面逐漸倒扣了一部分，每次應扣的金額就變了，成了：規則值 - 累計已扣。所以這裏要解決 2 個問題，一個是規則配置問題，另一個是剩餘代扣金額問題，因此這一部分需要建立規則的管理，即設定好不同類型的用戶應該交多少錢。

知道了哪些商家總共應該扣到少的規則以後，還需要記錄已經扣了多少，還需要再要扣多少。有 2 種實現方式，第一種用結算單進行記錄，另一種是用賬戶實現。

6.1.1 結算單模式

結算單的模式是爲每個商家每個結算週期生成一個結算單，記錄關鍵信息，這些關鍵信息相當於他的賬務信息。

表所示內容有一個自洽關係：剩餘待繳 = 規則 - 累計已繳。在商家結算之前，先查看信息表裏商家是否還有 “剩餘待繳”，如果有的話要先清分出一部分進行扣減計入累計已繳，剩餘部分結算給商家，如下表所示，示例中，張三的收入需要全部扣掉，而李四的收入足夠倒扣，剩餘 700 打款給商家。

6.1.2 賬戶模式

另一種模式是賬戶的模式，認證以後平臺爲每個商家開通一個待繳賬戶，這個賬戶的期初餘額爲 0，記錄後續繳納的金額。同樣商家的貨款結算也採用賬戶模式，這樣商家就有了 2 個賬戶。

如表中數據，收入已經結算了結算賬戶中；接下來要將一部分結算款扣減到保證金賬戶中。查詢到李四的保證金規則是 1500，所以現在賬戶還需要再轉入 1000。因此，要做一個賬務處理操作，將其結算賬戶中的 1000 轉入其保證金賬戶，會計分錄如下所示：

借 結算賬戶 - 李四 1000

    貸  保證金賬戶 - 李四  1000

6.2 返還和優化  

保證金滿足一定條件以後需要返還給商家，因此要有一個返還的操作，就需要一個事件來觸發這個返還，比如合同結束且沒有其他待辦事情後，可以通知賬務系統進行返還，做如下的賬務處理：

借 保證金賬戶 - 李四 1000

    貸  結算賬戶 - 李四  1000

這裏的風險並不是錢沒有交齊，而是發生了違規事項，扣除保證金造成的負餘額，這個負餘額就有資損的風險，後續需要商家繳納更多來填補。當平臺有數百萬商家時，這個模式就暴露出了很大的風險，如果很多賬戶都出現了欠款的情況，就需要想辦法杜絕這種情況發生。

這裏提供兩種思路：一種方法是從根本上解決問題，取締這種倒扣模式，採用先充值，這樣就可以解決這個模式的問題；另一種辦法就是設定可透支閾值，當被透支到一定金額以後封禁商家，需要充值償還欠款以後纔可以繼續經營，所以需要增加對該賬戶進行充值的能力。

7. 子賬戶之道  

一個企業在經營過程中，或者一個平臺在運營過程中，所有的業務都需要記賬。

從支付寶的擔保賬戶體系變革了線上零售以後，建立一套虛擬賬戶體系去解決交易流、支付流、資金流的匹配問題成爲了很多平臺都在遵從的 “賬戶之道”。

好的賬戶模型，往往是解決複雜交易，實現模式創新的突破點，而好的賬戶模型，往往從 “分割子賬開始”。

7.1 交易多樣性與賬戶拆分  

賬戶的本質是電子貨幣的載體，存儲着賬戶貨幣的數量以及流動變化信息，而這種流動的源動力來自交易的驅動，所以不同的交易流必然造成不同的賬戶貨幣的流動性。這就是賬戶的本質，建立交易流與資金流的匹配；而這種匹配關係的清晰性，決定了賬戶體系的效率和靈活性。

以上是在做賬戶設計時要關注的賬戶最核心的部分，可以通過一個賬戶解決基礎問題，通過交易分類解決賬戶流動性的清晰問題。

當交易模型複雜，交易流繁多時，可能會造成資金屬性的不同，比如存款、信用額度、理財資金往往是無法混合，這時就可以用多個賬戶來管理。同樣，當資金的來龍去脈不同，不同的用途時，爲了交易的效率，也可以用多個賬戶來管理。

不同的行業有各自不同的交易特點，如航旅、教育、保險、基金、遊戲等，他們的參與者不同，交易流不同，支付流不同，資金流不同，而且在時間、空間、政策很多維度都存在不同。這種不同的特點，衍生出不同的行業痛點和難點；如果想去攻克這些難點，拆分子賬戶，提升行業資金管理效率和交易效率是重要的突破口，通過賬戶方案建立線上交易基礎，通過賬戶拆分提高資金效率。

7.2 拆分案例  

賬戶最終要解決行業問題，那麼必然要基於行業的交易模型特點，分割出子賬戶，讓賬戶體系能夠清晰反映出行業的交易脈絡。

以航旅爲例：代理商從航司購買機票，分銷給二級代理商，再通過三方平臺或者線下代理點到達消費者。

以支付爲切入點，通過支付的變革實現行業的變革，改變行業的交易成本和效率；將交易電子化、資金電子化、並實現交易信息流和支付資金流線上高度統一；交易電子化可以將機票電子化，用戶可以線上選票、購票、出票。

實現資金電子化可以基於交易模型爲各參與者建立與交易相匹配的賬戶體系；以代理商角色爲例，分析在上述交易模型的資金行爲。

我們發現在整個交易模型裏有三處存在明顯邊界的資金往來：代理商與航司的資金往來，代理商與二級代理商的資金往來，代理商與資金開戶行的資金往來。

所以將代理商的虛擬業務賬戶進行拆分，通過子賬戶體現出這層關係，並將賬戶內資金的流動性通過子賬戶之間的業務關係完成。

  

環境是變化的，行業也是變化的，痛點也是變化的，在變化的商業環境裏必然產生新的變化的交易特徵，新的模式，新的方案。

一個子賬戶解決一個問題，那麼更多的問題就可以用更多的子賬戶去解決；比如代理商資金流動性不足，就有了信貸的場景，就可以爲其提供信貸；有的代理商資金充足，可能就有了理財的場景，可以爲其提供理財，子賬戶又可以進行拆分；付款賬戶拆分出信用賬戶，資金賬戶拆分出理財賬戶。

未來還有更多場景，未來還有更多可能，無論遇到何種問題，通過子賬戶拆分，再拆分，合併再合併，切換再切換，用這種可伸縮的靈活性，變通性，將交易流，支付流，資金流的脈絡結構完美的反映和契合，從資金結構中反映出業務結構，讓資金管理效率更高，覈算更便捷，讓支付解決方案更具魔力。

8. 日切原理

對日切這個概念，我想很多人都不陌生，但日切究竟是如何實現的，日切前後及過程中都發生了什麼，需要做哪些事情，不同的年代，不同的機構情形下，日切的實現模式會有一些差異，本小節將講清楚日切的實現原理。

所謂日切就是切換到下一個記賬日期，這裏要先搞清楚一個事情，日切就意味上一個交易日結束，下一個交易日開始，也就是日切總是伴隨着日終，二者形影不離。那麼介紹日切就必須聊日終處理，我們把它當成一件事來看。爲了深刻理解日切模式，先看一下日切的發展史。

8.1 日切簡史

有些人覺得，我現在就在做賬務系統，但是對日切的感知並不明顯，如果是這樣，那是因爲：時代變了，日切的方式也變了，要想深度理解一個事物，就要站在歷史發展的視角看它，當前感知不到，只是因爲，它變得更加簡潔和高效了，不像早些時候那樣繁重。

8.1.1 從重到輕

支付發展程度越高，效率越高，成本越低，其中就包括日切的處理，日切隨着支付的發展，也在變得簡單。

早期的錢莊，貨幣是金屬實物性質的，做賬是手工實現的，加上沒有現代會計方法作爲記賬依據，那麼賬務登記和管理效率也相對較低，造成兩個交易日之間的日終處理工作相對繁瑣，可以理解爲非常重的 “日切 / 日終處理” 的時期。

同樣，銀行也經歷了多個時期，例如最早期的手工賬時期，用算盤算賬，紙質賬簿做賬務登記，那麼日切過程勢必要處理的事務也相對較多，而且人力成本較高，用時較長。

1979 年，國務院批准銀行業可以引進外國計算機進行試點，1987 年開始，工行、中行、建行開始引入 IBM 的大型機和業務應用系統，結束了手工記賬的時代，開啓了信息化進程‌。很多工作交給了計算機去做，這時候的日終處理效率相比手工賬時代就高多了，但是日切和日終的事務依然耦合在一起，需要停止聯機交易進行日切和日終處理。

這個階段，每年的 12 月 31 號，一年最後一天的日切 / 年終也就是銀行年終決算是最忙的一天，需要進行全年損益結轉利潤。因爲銀行的賬目很多，例如現金賬、日記賬、櫃員賬、網點的賬等等都需要實現平衡，一分錢都不能錯，這就導致每次年終決算就像打仗一樣，全行聯動，爲確保數據無缺失、準確，需要進行大量的檢查。聽說每圓滿完成一次年終決算，是要慶祝甚至放鞭炮的。而現在的年終決算，相比之前要輕鬆容易多了，陳天宇宙。

現代銀行一般都可以提供 724 交易服務，那麼銀行系統是如何實現即可以 724 小時不間斷聯機交易，又可以同時進行日切、日終處理的呢？這是這個時期需要重點解決的問題，這個時期的日切可以認爲是極輕的日切時代，即然輕，那對它的感知就弱了。

這裏要掰扯清楚一點，就是雖然現在大部分銀行都實現了 724 小時聯機交易，但銀行依然需要進行日終維護，二者之間並不是衝突的關係，不是說，交易可以 7 24 進行，就不休息了，不維護了，只不過是 “系統維護” 和“7* 24 小時不間斷交易”可以實現並行。

8.1.2 從繁到簡

上面講到了 “7*24 小時不間斷交易” 處理是當下的流行，那麼系統怎麼兼顧實時交易不間斷，而日終處理又可以順利進行呢？就成了這個階段最重要的課題。

二者重點產生耦合的地方是在日切點附近的 “實時交易和日終處理”，二者存在依賴關係，例如日終處理需要用到 “上日終的靜態日末餘額”，而實時交易的餘額是動態實時更新不停息的。那麼，切斷二者的耦合而形成輕聯繫，建立讓彼此單獨運行的模式，就是突破口。而上一日的日末餘額和上一日數據的完整性是日終處理依賴的關鍵，所以，實時交易要確保能夠提供這兩個數據的保證即可。常見的模式是雙餘額模式和雙表模式。

可以這麼理解，將實時交易和日終處理進行隔離，7*24 小時實時交易獨立運行，而日終處理在另一個區域單獨進行，不阻礙也不干擾實時交易的進行，實時交易只需要保證提供日終處理需要的內容即可，也就是所謂的：“實時聯機交易 + 日終批量處理” 雙模式。

這時候，日切和日終的強耦合日切模式，演變到了二者實現隔離的簡日切模式，也就意味着，如果交易不需要關注日終，那麼日切將變得極其簡單。

當然對於支付機構、交易平臺，這是很容易實現，因爲屬於弱賬戶模式，哪怕沒有日切和日終的概念，也可以實現數據的自然切割，按照自然日進行處理即可。而對於銀行要實現這一點相對複雜，因爲存在客戶存款計息、貸款計息的管理，對靜態餘額強依賴，所以即需要維持動態餘額的更新，又需要確保靜態餘額的生成和不變。

8.2 日切概述

日切簡單的說就是記賬日期的切換，變更系統的記賬時間；也就是人爲的將時間軸根據設定的 “日切時間點” 切割成一個一個的區間，從前一個區間到下一個區間的過程就是切換的過程；這裏的切換時間點就是“日切點”。

所以，通過日切點將連續的時間進行了切割，同時也對數據進行了切割，形成了一個個的數據集，例如 23:00 作爲日切點，那麼 [T：23:00，T+1:23:00) 就構成了一個記賬日。

1）爲什麼要有 “日切”

雖然自然時間是連續的，但是很多事務的處理需要按週期進行或者以週期爲單位進行管理，例如飯館到了晚上 21:00 要打烊，然後盤點當天的賬目，打掃衛生，爲下一個營業日準備，這裏的 21:00 就是日切點，日切後進行日終處理。

同樣銀行也要上下班，下班後櫃面業務收取的現金等線下業務需要進行盤點，入庫。而核心系統的線上業務等也要進行一系列的日終處理，例如生成日末餘額、生成總賬、賬目覈算、計息等等，那麼需要 “日切點” 作爲兩個週期的分割點。特別在手工賬年代，日切及日終處理的工作量尤其龐大，只不過隨着科技的發展、隨着電子化的普及，這個過程大部分都交給電腦來做了。

這裏要清楚一點，日切完成不一定會着立刻進入了下一個交易日，例如日切完成了，但是下一個週期的交易要等待次日 9:00 纔開始，那時間上，日切點 23:00 到次日 9:00 這個區間算是 “日終處理 + 休息時間 + 營業準備” 時間，不營業，但有事做。

雖然現在的交易大部分都是 7*24 小時不間斷進行，但是日切後還是會涉及一些日終的處理，例如清算文件的生成、結算數據的生成與下發等，日終與與日間的實時交易處理明顯不同，存在明顯的週期性和集中性，需要以 “日切點” 作爲日終事務處理開始的信號。

這裏也涉及到數據的切割問題，例如一個交易日的數據做爲一個信息單元，我們的利息按日計算，衆多系統之間、各個機構之間的數據都需要按照相同的切割規則完成，這樣才能實現按週期的核算，例如渠道的清算文件以日爲週期進行提供，那麼這個區間的起始點，就是兩個連續的 “日切點”。所以，需要“日切” 這樣一個動作，執行日期的切換，實現數據分割，作爲日終處理的標誌，起到調度的作用。

2）日切時間選擇

日切時間在時間點選擇上，往往選擇在夜間交易低估時段進行，因爲日切前後需要進行一系列的事務處理，避免影響正常業務，例如有些銀行選擇 23:00 作爲日切點，那麼 23:00 以後的交易將劃歸到下一個交易日。

3）日切要幹嘛

從系統實現上，日切只是將記賬日期進行變更，但是日切前後及日切過程中需要執行一系列的事務，還要協調衆多系統之間的配合。例如全部系統切換記賬時間，全部採用最新的記賬時間；進行多系統間數據的核對，保證每個系統都完成數據的登記，進行賬務的入賬、生成總賬等。

4）不同場景做的事不同

普通交易平臺、支付機構、銀行業務、清算、央行等在日切點關注重點和實現上存在差異。

銀行因爲涉及到大量的賬戶，所以銀行日切要重點關注賬務處理的完整性和準確性以及日終處理。另外就是按日計息等工作，又需要重點關注日終餘額或者日均餘額，那麼每日的日終靜態餘額顯得很重要。同時銀行又因爲涉及到櫃面、ATM 等線下業務，監管申報和合規性檢查等等，所以，銀行的日切處理相對複雜，要做的工作較多。

清算機構因爲主要做信息轉接，所以清算機構日切的重點在交易數據的清分、彙總與清算處理上，沒有那麼重的賬戶處理業務，甚至清算機構會存在場切，每小時一個場次，場次之間也存在固定時間點的切換。

央行的日切或者日終要確保清算場次內所有機構都可以完成清算，例如頭寸不足的交易要排隊撮合、銀行可以拆解或者貸款，那麼央行各系統的日切要保證清算完成避免出現系統性金融風險，當然清算文件的生成和下發也是日切工作之一。

而支付機構或者交易平臺相比金融機構，對於日切就沒有那麼明確的訴求了，他們日切的核心目的就是確保完成對商戶的記賬和按週期準確的結算，這也就意味着數據切割是重點。不同機構的日切和聯繫。

除了不同類型機構之間的日切實現模式存在差異，即使是同一類機構，不同的企業之間也會存在差異，一個純線上交易的平臺和一個涉及線下門店業務的交易平臺在日終處理上會有很多不同。所以，雖然日切在原理實現上有通用性，但是不同的場景、不同的企業，需要根據實際的業務特點，選擇適合自己的日切和日終模式。

8.3 日切的挑戰 

如果日切執行過程中交易系統停止工作，那事情就好辦了，在這個期間沒有交易，把所有要做的日終處理都做完，再開啓下一個工作日的交易，那麼日切其實就是一個日切的切換。

但是，實際上的日切業務不止是時間的切換，還存在一連串的挑戰。

1）7*24 小時不間斷交易的挑戰

業務和系統是 7*24 小時不間斷運行的，採用什麼樣的模式處理實時不間斷交易和日終批處理之間的協同，是一大挑戰。

2）多系統作業的協同挑戰

一個交易體系所涉及系統數量衆多，其中包括交易系統、支付系統、清結算系統、賬務系統、會計系統、財務系統等。而日切不只是賬務系統記賬日切的切換，還需要各個系統執行相應的日切任務。

這裏最大的挑戰就是調度問題，因爲系統之間的日切和日終處理存在順序和依賴關係，誰先誰後，什麼時候開始，什麼時候結束，大家怎麼知道上游已經結束了輪到自己了。例如，當交易系統沒有完成日切，沒有確保所有上日交易都推送至賬務核心，這時候，賬務核心執行日切就會出問題，如記賬數據不全，日終餘額不準確，與上游覈對存在差異等問題。

3）數據切割的一致性

衆多系統的存在，意味着同一份數據會登記在很多系統中，就會存在多個時間屬性，例如交易時間、清算時間、記賬時間等。那麼在進行上下游覈對時，就需要確保彼此數據切割一致，否則會存在數據集合不同的問題，與外部渠道間也存在這個問題，例如銀行日切點是 23:00，而機構日切實 00:00，那麼二者同一個交易日期的數據集不同。

除了數據切割時間不一致造成的差異之外，不同系統之間，即使日切點一致，也可能會存在差異，這裏要了解一個現象：記賬漂移——就是系統之間傳遞數據的時間差造成的時間整體向後推移，系統間在日切時間點附近造成了同一筆交易，交易日期和記賬日期不同的現象。如下圖所示，從圖中可以看出來，即使實時記賬，因爲系統延遲等原因，會造成交易時間和記賬時間存在△t 的時間差異，這個差異就是記賬漂移。

如果交易的時間遠離日切點，這種差異並不明顯，因爲很少會覈對數據間的具體時間的一致性。但是在日切點附近的交易就可能飄逸到下一個記賬日期，也就是 T 日的交易，記賬日期飄逸到了 T+1，那麼整個數據集合就形成了錯配。當以日爲單位進行數據覈算時，發現，交易和賬務層的數據並不一致，即所謂的時間差差異。

所以需要通過一個模式來解決這個問題，如何確保全局數據切割的一致，按那個時間切割，交易按交易時間切割，賬務按記賬時間切割，如果這樣，這裏就會天然存在時間差。這裏的切割一致性涉及到交易、賬務、會計、提供給客戶的交易文件等，他們之間的一致性。

8.4 日切總架構設計

開始前先理解 2 個概念：動態實時賬戶餘額、靜態的賬戶日終餘額。

所謂動態即會隨着交易的產生而不斷變化，例如賬戶餘額，這個是隨着收入、支出的產生而動態變化的，用戶需要實時看到這個餘額，而且需要足夠準確。

所謂靜態數據即數據一旦產生便不再變化，例如日終餘額，一旦完成日切，日終餘額生成，那麼這個餘額就不能再變了，像計息、總賬覈對等需要用到這個靜態餘額。

接下來我們從日切架構、雙餘額法、雙表法等方面詳細介紹日切的系統實現。

8.4.1 日切處理架構

數據在系統之間的傳遞存在順序性，交易不會繞過賬務系統直接將數據提交給會計系統；其次，系統之間的 “日切處理” 也存在順序性以及依賴關係；而且，每個系統的日切任務不同，如圖所示，是日切子系統的業務架構。

1）統一調度模型

爲了不讓各個系統的日切處理各自爲政，採用統一調度的模式，由日切子系統進行全局管理，通知各個系統執行日切，並監控日切進程和結果，按照預先設定的日切順序和任務監管各個系統的日切業務。

2）日切點與記賬日期維護

日切子系統需要統一管理各類日切點，以及當前記賬日期，作爲公共參數，提供給各系統查詢使用。同樣，這裏的日切點和記賬日期可以按照業務線、產品、商戶等多維度進行配置，以便實現更加靈活的日切業務和數據切割模式，陳天宇宙。

例如，即使全業務都是 0:00 日切，但是像酒吧、ktv 等夜場業務，可以選擇在交易量最小的 12:00 進行日切，因爲這類場所，夜間是交易量最大的時候。

3）系統時段切割與運行狀態管控

爲了更好的日切任務，控制日終處理的進程，可以將全局時段進行切割，切割成時區段，在不同的時段執行對應的任務。例如銀行系統日終處理經常被分割成三段: 日切 (Cut-Off)、日終批量 (End-Of-Day)、 日初準備 (Begin-Of-Day)。

因此，可以將整個時間軸切割成如下階段：正常交易、日切、日終處理、交易準備等。並將各階段規劃出系統狀態，維護在日切子系統中進行統一控制。

在整個 7X24 小時不間斷交易週期中，可以劃分爲日間聯機交易和日終處理期間的交易，其中，將日終處理期間的交易時段成爲特殊時期，因爲這個階段要兼顧日終批處理和實時交易處理，而日切設計的重點就是該時段。

8.4.2 動靜拆分和隔離

前面介紹了在 24 小時交易中，日切點的實時和批處理會存在衝突，那麼，能不能實現 724 小時連續交易的前提，是在日切期間和日終處理階段能不能進行交易。可以考慮將實時交易的動態處理和日終批處理的靜態處理進行隔離。中間依靠隔離區通過 “日切處理” 建立起聯繫，這樣就可以確保面向客戶的 724 小時聯機交易不間斷，同時對內的日終處理又可以並行進行。

那麼，在日切階段，如何處理此時的交易所產生的賬務處理就成了關鍵，而這個階段主要是賬戶餘額的更新處理。

8.4.3 日切賬務特徵

日切過程會產生兩個餘額數據，一個是動態賬戶餘額數據，一個是靜態日終餘額數據。而動態餘額和靜態餘額都是賬戶的屬性，動態賬戶餘額受交易驅動實時變化，而靜態日終餘額受日終批處理生成。所以二者之間都依賴 “賬戶”，同時日終餘額又依賴動態的賬戶餘額。

8.5 日終處理的賬務模型

對同一個賬戶在日切期間會同時受到實時交易和日終處理的影響，可能會被兩個事務同時更新，那麼要確保這種併發更新不會造成問題，需要一個處理機制，例如賬戶雙餘額法、影子賬戶並行法、應入賬日期標記法等。

8.5.1 賬務雙餘額法

這裏要重點理解 4 個時間：交易時間、記賬時間、最後動賬日期、當前記賬日期；2 餘額：賬戶當前餘額、賬戶上日終餘額。

將每個賬戶設置 3 個參數：最後動賬日期、上日終餘額、當前餘額。tx 是交易登記時間、ty` 是賬務記賬時間，Balance 代表賬戶餘額。如圖可以看出來最後一筆記賬的時間就是最後動賬日期，一天最後一筆記賬的賬戶餘額就是上日終餘額，而最後一筆記賬的餘額就是賬戶當前餘額。在日期子系統維護着 “當前記賬日期”。

這裏要做一個模式的選擇，就是上日終餘額如何更新，因爲當前餘額的更新是動賬才更新，而日終餘額的更新方式有多種，可以動賬時更新，也可以選擇在日終處理時更新。

1）動賬時更新上日終餘額

即當賬務有新的入賬時，根據 “最後動賬日期和當前記賬日期” 來判斷上日終餘額更新。

如果 “最後動賬日 = 當前記賬日”，即當前入賬是當天的入賬，只需要更新當前賬戶餘額即可：Balance7=Balance6 + 本筆發生額，如下圖所示，記錄 7 入賬時當前記賬日期與最後動賬日相同，那麼說明還沒進行日切，則無需更新上日終餘額，只需更新賬戶餘額。

如果 “最後動賬日≠當前記賬日”，說明已經發生了日切，本筆入賬時日切後的第一筆入賬，則需要更新上日終餘額和當前賬戶餘額：上日終餘額更新爲當前的賬戶餘額 Balance6；並再將當前餘額更新爲：Balance7=Balance6 + 本筆發生額；並將最後動賬日更新爲新的記賬日期。

這種更新模式下，因爲沒有動賬的情況下上日終餘額是不會更新的，所以日終餘額的查詢也要根據最後動賬日和當前記賬日期的關係進行邏輯查詢。

如果 “最後動賬日 = 當前記賬日”：則直接取上日終餘額字段的值即可。

如果 “最後動賬日≠當前記賬日”：說明已經完成日切了，但是新的記賬日還沒有入賬，那麼賬戶登記的上日終餘額已經不是昨日了，而是更久之前的，此時應該取當前的賬戶餘額作爲 “上日終餘額”。

2）日切時更新上日終餘額

動賬時更新上日終餘額會造成 “上日終餘額” 的更新不及時，所以可以執行日切時更新上日終賬戶餘額，不管有沒有動賬發生，每次發生日切都進行上日終餘額的更新，而且同時更新最後動賬日期，這樣每次直接取上日終餘額字段即可，無需進行邏輯判斷。

因爲在日終處理過程中，聯機交易也在進行，且日終處理需要一定的時間，所以，爲了確保聯機交易正常對賬務的更新，那麼依然保持 “動賬更新餘額的模式”。

這就意味着，在日切期間有可能出現聯機交易和日終處理同時更新賬戶餘額的情形，那麼爲了解決這一問題，就需要進行賬戶餘額的加鎖，誰先發起更新，誰執行，另一方等待，直到鎖解除了，等待的一方再執行餘額更新。

 

日終處理和聯機交易同時更新賬戶餘額時就是衝突期，通過加鎖和解鎖確保每次只有一方操作賬戶餘額的更新。

雙餘額方法看起來邏輯簡單，但是表結構比較複雜，而且按日更新餘額模式下，可能存在日終處理和實時處理的賬戶餘額更新衝突，會形成一個排隊期，這樣就會在日切點造成一定的賬務延遲，那麼爲了確保聯機交易和批量處理完全並行處理，而且不衝突，可以採用雙賬戶法。

8.5.2 影子賬戶並行法

即爲每個分戶設置一個影子臨時賬戶，來處理日切和日終處理的衝突期的聯機交易記賬。當系統運行狀態進入日切和日終階段時，臨時影子賬戶開始運行，聯機交易實時記賬不再更新主賬戶，而是登記在這個臨時賬戶中。

在這種模式下，整個賬務處理可以分成 3 個階段：正常記賬期，雙賬戶記賬期，調賬期。確保在雙賬戶記賬期主賬戶處於靜止狀態，臨時賬戶爲動態更新狀態。

正常記賬期：主賬戶正常記賬；

雙賬戶記賬期：日終操作主賬戶，更新上日終餘額，當前賬戶餘額保持靜止，此時期 “當前賬戶餘額 = 上日終賬戶餘額”。該階段需要注意一點，就是對外的賬務服務，例如用戶看到的 “當前賬戶餘額 = 主賬戶當前賬戶餘額 + 臨時賬戶發生額”。

調賬期：在這個時期，日間交易開始更新主賬戶，同時臨時賬戶的臨時登記交易也要調賬到主賬戶，其實臨時賬戶的調賬跟聯機交易更新主賬戶沒有區別，調賬完成以後，清空臨時賬戶，開啓下一個正常記賬期。

8.5.3 應入賬日期標記法

前面介紹了一個記賬漂移的現象，會造成系統間數據切割的不一致。可以通過要求上游系統標記該筆交易的 “應入賬日期”，來規避記賬的漂移。例如在日切運行狀態期間的記賬，交易系統先執行了日切，那麼最後 5 分鐘的交易標記上 “應入賬時間”，這樣，賬務系統對於打上了應入賬時間的交易執行記賬時間修復機制，將其記賬時間特殊處理標記爲上一個記賬日，來規避時間差問題，如下圖，T 日的交易記錄 7，在 T+1 日請求賬務登記，被記賬修復登記爲 T 日的交易。

8.5.4 自然日切，不做特殊處理

對於一些支付機構、交易平臺，因爲不涉及到計息、罰息、貸款預期等的業務處理，對日終餘額沒有過多依賴，甚至有的機構本身就不存在上日終餘額這個數據，那麼可以選擇不設置日切機制，按照自然日自然日切即可。

9. 營銷類賬務處理原理

如果用戶下單時用了券應該怎麼記賬？平臺發的券和商家發的券記賬有啥區別？如果券需要平臺和商家共同分攤呢，怎麼記賬？假如這張券又是用戶用錢買的呢？

這麼一假設是不是賬務處理難度瞬間升高了幾個維度，彆着急，把邏輯理清楚了，就容易了。

9.1 券的交易本質

這裏要建立一個非常明確的認知，交易層記得是平臺應該收用戶的賬以及應該結給商家的賬，而支付層記得是平臺跟渠道之間應清算的賬，理解這一點非常重要。

券的本質是補貼給用戶的，因此補貼了券，就意味着用戶會少支付一些，那麼跟渠道之間就會少清算這部分券的金額，但是交易的總額沒變，那麼券的錢找誰清算呢？——誰發的券，找誰清算，所以，券 + 渠道支付 = 交易總額。

 

因此，當用戶在交易時使用了券、卡、積分等非渠道支付方式時，清算部分就多了這些 “渠道”，而清算對象就是誰提供的營銷補貼找誰清算，也就是這筆賬記到誰的賬上，而券本質上是營銷成本。

有了上面的原理，我們還應該知道下面這些營銷的 “賬務” 性質，才能知道該如何編排 “借 · 貸” 符號。

如果是平臺發的券，那麼對平臺來說這是一筆 “銷售費用”，所以平臺的券是平臺的費用。如果是商家發的券，那麼這個券走商家的營銷款，而商家營銷款，是平臺的負債。看一個公式：資產 + 費用 = 負債 + 所有者權益 + 收入。

這就意味着，用戶用了平臺發的券，因爲是平臺的費用，費用增加了，所以記借方，就記 “借 平臺營銷費用”。如果用了商家發的券，爲了更好地理解，我們走商家營銷預充值款，這筆商家營銷資金，是平臺的負債，用戶用了商家的券，那麼商家營銷賬戶要出錢，所以負債減少記借方 “借 商家營銷費用”，這就是券的最基本記賬方法。

你可能會覺得奇怪，怎麼上面全是 “借”，不是應該“有借必有貸，借貸必相等” 麼？因爲這是收款側，也就是錢從哪來，還有結算側，錢要到哪去，收上來的錢要結給商家，平臺還要抽傭，這就是貸方。貸應結商戶，貸平臺佣金收入，貸合夥人分成等，陳天宇宙。

9.2 券的賬務處理案例

有了上面的基礎認知，再看交易用了券以後怎麼記賬，就容易理解了，下面從 5 個場景來解析交易使用了優惠券的賬務處理方法。

9.2.1 從簡單到複雜，先從沒用券開始

如果一筆訂單 100 元，用戶支付成功了 100 元，那記賬就很簡單了，交易 = 支付，用戶支付的錢也就是後面要清結算的總量，最後結算給商家 80 以及平臺抽一部分佣金 20，這也是最基礎的賬務處理，如圖圖一所示。會計分錄如下圖二所示。

9.2.2 用了一張平臺優惠券

如果一筆訂單 100 元，用戶用了一張 20 元平臺券，渠道實際支付 80 元，賬務處理如下圖一所示。會計分錄如圖二所示。

9.2.3 用了一張平臺優惠券，且需要分攤

如果一筆訂單 100 元，用戶用了一張 20 元平臺券，渠道實際支付 80 元，但是因爲聯合營銷，商家承擔 20% 的券成本，也就是承擔了 4 元，賬務處理如下圖所示。

9.2.4 用了一張商家優惠券

如果一筆訂單 100 元，用戶用了一張 20 元商家券，渠道實際支付 80 元，賬務處理如下圖所示。

9.2.5 當然還有更復雜的場景

如果這張優惠券不是平臺免費發放給用戶的，而是用戶自己花錢買的，例如用戶花 5 元買了一張 20 元的平臺優惠券，交易邏輯如圖所示。

用戶下了一個 100 元的訂單，用了這張買的 20 元的優惠券，實際支付 80 元，這個賬怎麼記呢？如圖所示。

這裏有兩個問題需要思考，問題 1：這張券究竟應該記 20 呢？還是 15 元呢？畢竟平臺實際上並沒有補貼 20 元，而是淨補貼了 15 元；問題 2：再複雜一點，如果這張券使用時，商家又分攤了 20% 成本，那商家究竟是分攤了 15 的 20% 呢？還是分攤了 20 的 20% 呢？

假如，考慮 “券淨額” 去記賬，怎麼記能夠滿足呢？很明顯這張 20 元的券，可以認爲是平臺和用戶共同承擔了成本，即平臺承擔了 15 元，用戶承擔了 5 元，這麼看的話其實也能記，平臺直接記淨額。

但是，這裏有個問題，原來的 5 元怎麼記，從財務視角來看，賣券是平臺獲得了收入了，應該記一筆收入纔對，那收入什麼時候記呢？...... 到這裏其實就開始糊塗了。

這裏要明確一個知識點，券的費用記賬是在覈銷的時候纔會記，而發給用戶的時候一般是不記賬的。

因此，平臺在賣券的那一刻銀行賬戶中已經收到錢了，所以，銀行存款已經增加了，那另外一方記什麼呢？其實就是券的銷售收入。按照權責發生制，銀行的錢增加了，不能不記賬，不能等用戶用券的時候再記收入，這樣的話如果用戶一直不用券，那這筆收款就一直都無法確認收入。

所以，一般我們在賣券完成權益交割以後就記賬了，可以看出來，這個時候就登記了收入，只不過，用戶還沒用券，要不要確認收入呢？這個其實可以確認的，只不過後續如果券能退的話，收入被券退款沖銷即可，用戶買券記賬邏輯如圖所示。

這樣的話，用戶在用這張券的時候就不用關注這張券是不是花錢買的了，當用戶用了這張券平臺自然會記 20 元的補貼成本，如圖所示。

可能你會問，明明是隻補貼了 15 元，記 20 元不就虛增成本了麼，其實不用擔心，還有一個環節呢，就是會計週期末的結賬，所有損益類賬務全部結轉到利潤中，神奇的事情就發生了，如下圖所示。賣券收入和用戶用券補貼成本在利潤中核算出補貼 15 元的淨額。

10. 清結算的賬務實現原理

將以支付機構場景爲例，解析通過賬務體系的清結算全局實現，以及各環節數據的產生，各類賬戶的設置，以及各類場景的賬務處理方法。

支付機構的主業務是幫助交易平臺代收代付交易款，那麼就需要先從消費者髮卡行把錢拿過來，然後再結算給交易平臺；對於交易平臺側來說也是一樣的道理，要幫店家賣東西，需要通過支付機構代商戶收款，從支付機構拿到錢以後再結算給自己的商家。這是典型的 2 個不同的清結算場景，一個是支付機構的清結算，一個是交易平臺的 “清結算”，雖然交易平臺沒有清結算資質，但其需要在信息層完成清結算業務，上述業務模式如圖所示。

瞭解一個公司的清結算所涉及的全量業務環節，才能徹底明白，如何下手搭建清結算體系，涉及哪些系統，這些系統之間都有什麼關係，將上圖濃縮抽象以後，清結算涉及的資金處理業務如圖所示。

所謂清結算，就是從渠道那拿到全部的錢、給商戶正確的完成了全部結算，從上圖可以看出來，清結算全局主要涉及到以下幾個部分：

10.1 全局數據

無論是交易還是支付，或者是對賬、渠道清算、結算，都離不開各類數據，可以將全鏈路的最原始數據分成四類，分別是：賬務數據、支付數據、清算數據、結算數據。並分別定義爲 1 段數據、2 段數據、3 段數據、4 段數據，如表所示。

數據分段以後，從數據編號既可以看出該數據的全量信息，來自那個系統，是什麼支付業務產生的數據，在後續憑證規則中就可以基於數據段設置憑證規則，那個數據段的數據生成什麼憑證，操作哪些賬戶，例如 2001 的支付數據要操作清算收款往來賬戶和商戶待結算賬戶

將所有數據段以及覈對差異產生的差錯處理數據的賬務處理關係繪製出來，就得到了如下圖所示的，各段數據源與賬務核心的賬務處理關係。

這麼多數據，是如何從業務系統流向賬務系統的，系統之間的數據流轉關係，數據從各業務系統產生以後經過對賬系統、轉換中心、計費中心、財務處理中心到最後的會計核心。

對賬中心從渠道獲取清算文件解析出清算數據，並從交易平臺獲取到交易數據用於交易對賬；交易中心推送賬務核心進行記賬，對賬中心的清算數據也會推送至賬務系統進行過渡清算類賬戶的賬務處理。交易對賬數據和賬務數據會按照各段數據的格式要求轉換成文件數據，然後推送至成本計費中心，完成通道成本的計算，並在清算數據上綁定結算賬戶、結算日期等信息，然後推送至財務處理中心準備資金對賬。資金對賬產生的長短款數據以及長短款覈銷數據也是新的數據段，會推送至會計核心生成長短款等掛賬數據。最後備付金賬套的手續費收入和通道成本會結轉給財務賬套，進行內部資金的核算。至此，整個數據就從業務產生到覈算完成，實現了全鏈條的流轉。

10.2 科目與賬戶設置

清結算業務離不開賬務和賬戶，爲此，需要設置一套賬戶，爲支付交易和清結算等業務提供賬務支持。設置的賬戶及用途如表所示。

整個賬戶體系包含 5 套賬戶，分別是商戶結算戶、結商戶賬戶、清算往來戶、已核銀行收付、銀行存款，其中共同類賬戶又分成了收款類和付款類，這樣的賬戶設置共同完成了基於支付交易的向內結算和向外清算的支付業務框架

有了上述科目以後，要想搞清楚賬務處理，需要搞明白賬務處理的要素和基礎原理。

賬務處理要素：賬務處理的要素就是要做賬務處理，需要關注那幾個維度的信息，主要是 5 個維度：什麼業務、什麼時候記、用什麼數據記、記賬規則是什麼。

什麼業務：常見的業務種類有收款 / 退款、打款 / 打款退回、差錯即差錯處理、長短款及覈銷、客戶賬務調整、結算結轉財務等等；

什麼時候記：即記賬的時機，如支付成功、打款成功、退款成功、渠道清算對賬成功、資金對賬成功、賬務記賬成功等等；

用什麼數據記：用於記賬的數據有支付數據、賬務數據、清算數據、結算數據、差錯數據、長短款覈銷數據等；

記賬規則是什麼：有了記賬數據，如何記賬就需要記賬規則，記賬規則內容主要包括借貸方向以及涉及到的賬戶。

賬務處理的基礎原理就是通過借貸記賬法利用業務數據操作相應的賬戶，如上圖中所示的那樣，主要的記賬數據是支付交易記錄、賬務記錄、渠道清算記錄、渠道結算記錄，他們相應的借貸符號也如圖中所示，例如收款的支付記錄要借記清算往來收款、貸記待結商戶賬戶，以此類推。同樣也要特別關注差錯類的記賬，包括交易類差錯、資金處理類差錯、客戶調賬了差錯等。

10.3 三大在途

因爲過渡賬戶的借方和貸方使用的是 2 份相關的數據源，因此其餘額反映了這 2 份數據源之間的差異，因此當過渡戶存在餘額時，則意味着存在在途，主要有三大在途：客戶在途、支付在途、資金在途，在途可以理解爲各類掛賬，各類差錯處理的記賬就是抹平掛賬。

10.3.1 支付在途

渠道待清算往來賬戶餘額反映的是支付在途，清算完成以後餘額應該爲 0，否則平臺與渠道清算數據之間存在差異。

從原理上看，該賬戶的餘額上是平臺支付記錄和渠道清算記錄的差額，即該賬戶的期末餘額就是 “支付在途”，那麼一個清算週期內，該賬戶的餘額會存在 3 中情況：

當餘額不爲零時，則意味着存在平臺單邊或者銀行單邊，單邊數據在交易對賬中心，可以通過相應的差錯處理抹平差異。例如銀行單邊，則要不進行平臺補單，要不進行銀行退款，或者平臺確認收入，這部分差錯處理也會操作該賬戶，進而抹平賬戶的餘額，完成最終覈算。

10.3.2 資金在途

已核應收銀行的賬戶餘額爲長短款數據，資金對賬完成後，該科目餘額應該爲 0，如果不爲 0 則存在長短款，餘額在借方則存在短款，銀行少結錢了，如果餘額在貸方，則存在長款，銀行多結錢了，陳天宇宙。

10.3.3 客戶在途

待結算商戶賬戶餘額意味着沒有完全結算，如果餘額在借方則說明多結給商戶了，如果餘額在貸方說明少結給商戶了，少結的情況下，可以通過調增客戶賬戶餘額進行補入賬，多結的情況下可以調減客戶賬戶餘額進行平賬。

10.4 賬務處理規則及示例

先看整個全局覈算是如何做賬務處理的，我們以收款業務爲例，整個收款業務的賬務處理涉及到 4 個環節、3 類差錯：支付交易環節、渠道清算覈算環節、商戶結算環節、渠道結算覈算環節、客戶差錯、交易差錯、資金差錯環節，每個環節都有相應的記賬源數據，以相應的記賬規則操作相關賬戶，具體環節說明和記賬規則如表所示。

我們根據一個實際收款例子加深對上述各環節賬務處理的理解。

案例：平臺收了 2 筆錢，都是 10 元，渠道 T+1 結算，給商戶也是 T+1 結算，然後各環節數據情況及賬務處理如下：

10.4.1 支付交易記賬

用戶支付了 2 筆，各 10 元，成功了 1 筆，另一筆支付處理中，支付核心生成了相應的支付數據

交易驅動賬務進行記賬，以支付數據爲記賬數據，借記渠道清算往來，貸記待結算商戶

10.4.2 渠道清算環節

對賬中心獲取到渠道清算文件以後，與平臺記錄進行覈對，渠道清算成功了 2 筆，因此覈對結果如下表所示，出現了一筆渠道單邊。

其中清算文件數據做爲渠道清算記賬數據，借記 “已覈對應收銀行”，貸記 “渠道清算往來”，記賬情況如下

可以看出，清算完成以後，渠道清算往來 - 收款存在貸方餘額，也就是交易對賬的渠道單邊造成的。

10.4.3 交易差錯處理

經排查，是平臺的支付系統狀態更新異常，在對賬中心進行了 “平臺補單” 的差錯處理，原來的處理中的支付狀態，更新成了成功

補單成功的支付記錄將驅動賬務再次記賬，因爲平臺補單的數據屬於平臺支付記錄，因此，其賬務處理規則與平臺支付記錄的賬務處理規則相同

到此爲止，全部賬戶的記賬情況如下圖所示

從圖中可以看出來，此時待結算商戶 20 元，與渠道清算成功，應收渠道 20 元，商戶結算戶和銀行存款戶還沒有餘額。

10.4.4 商戶結算環節

假設，開始支付成功的一筆交易是沒有完成賬務記賬的，而次日對賬補單成功的交易完成了客戶記賬，那麼也只有補單成功的完成了向商戶的結算

基於補單成功的交易，推動賬務完成了記賬，在 T+1 執行結算以後，完成了向商戶的結算

可以看到待結算商戶 - 收款，存在貸方餘額，即應結商戶的在途資金，這是因爲存在交易未入賬的情況。

10.4.5 客戶賬調賬、交易補入賬

觸發交易發起補入賬操作，補入未入賬的交易記錄，如表，狀態是未結算

未結算的賬務明細重新執行結算，完成商戶結算入賬，至此待結商戶餘額爲 0，完成商戶在途資金的處理。也完成了向商戶的結算，如圖 8-28 所示。

10.4.6 渠道結算環節

資金對賬模塊獲取到銀行結算賬單以後，進行資金對賬，假設渠道結算文件記錄只有一筆，因此在資金對賬時出現了短款

資金對賬結果產生了 10 元的短款，系統會自動生成長短款記錄  

基於渠道結算單進行記賬，實收 10 元，記賬如下

可以看出來，渠道資金對賬以後，已核應收銀行存在借方餘額，即有短款掛賬，這個與短款記錄是一致的，因此過渡戶科目餘額的反映與對賬結果的反映含義是一樣的。

10.4.7 長短款覈銷

經人工排查，收單賬戶已經完成了資金入賬，是結算文件數據丟失，因此對短款進行 “銀行補入賬” 的核銷，數據如表 

該短款覈銷，執行覈銷憑證的入賬，記賬如圖所示。

至此，就完成了收款清結算的全部環節的賬務處理了，涉及到的全部賬戶的記賬情況如圖所示。

可以看出通過這 5 組賬戶的借貸賬務處理，完成了從交易到內外清結算的全鏈路覈算以及最後的記賬，中間過渡戶的最終餘額爲 0，代表着完成了渠道的清算往來覈算以及商戶的結算覈算。通過該賬戶體系可以非常高效和準確的實戰清結算業務的全局處理。

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

猜你喜歡