編輯導(dǎo)讀：使用電子支付的時候，我們會對老板說“錢已經(jīng)付過了”，老板聽到語音播報就能確認，這就是簡單的一個對賬過程。但是一個對賬系統(tǒng)的搭建遠不止這么簡單，本文作者將從十個維度，分析如何構(gòu)建設(shè)計一套不同業(yè)務(wù)場景下的對賬系統(tǒng)，與你分享。

想必大家對“對賬”這個詞都不陌生，單從字面意思就能略知一二。其實就是字面意思，“對”就是核對，“賬”就是賬目；“對賬”就是核對賬目。

賬目核算是財務(wù)工作的必要部分，隨著線上交易體量越來越大或者說對財務(wù)自動化線上化的效率提升需求越來越高。為了提升核對效率以及準確性，勢必要將核對業(yè)務(wù)系統(tǒng)化線上化自動化。那么如何構(gòu)建設(shè)計一套不同業(yè)務(wù)場景下的對賬系統(tǒng)呢？接下來的“對賬系統(tǒng)設(shè)計”十個章節(jié)將帶領(lǐng)大家學(xué)習(xí)如何設(shè)計一個對賬系統(tǒng)。

全文分十個部分，共13596字，預(yù)計閱讀時間20分鐘

第一部分：對賬概述

1.1 生活中的對賬

日常生活中我們每天都在對賬，比如去餐館吃飯付款，會對老板說一聲“老板，錢付過去了”；老板檢查過收款或者聽到語音播報后回復(fù)一聲“好嘞，下次再來”；這就是最簡單的一次對賬。

再比如你在淘寶開了一個店鋪，每個月幾千單的交易，發(fā)貨；每次月末都拿著所有的訂單明細和支付寶收款賬戶收款記錄逐筆的做一次核對，保證發(fā)過貨的訂單都收到款了，這就是一次更復(fù)雜的核對了。

1.2 什么是對賬

1. 對賬概括來說就是“賬證實”核對，“賬”就是賬目，“證”就是憑證，“實”就是實際資金
2. 核對模式有三種：賬證核對，賬賬核對，賬實核對；確保賬證實兩兩的一致性；比如吃了一碗面點菜單就是原始憑“證”，付了10元錢是“賬”，老板電腦點菜記錄小票10元是“賬”，老板看到賬戶中余額增加了10元是“實”
3. 財務(wù)范疇來看，證就是會計憑證，比如發(fā)票，小票，出貨單，收據(jù)，交易系統(tǒng)的支付記錄等都是原始憑證；而賬呢就是財務(wù)的賬目，賬務(wù)系統(tǒng)的賬務(wù)記賬，金蝶的科目余額等都是不同的賬目；而一筆交易會記錄在很多的環(huán)節(jié)，比如賬務(wù)系統(tǒng)，金蝶等
4. 另外脫離財務(wù)范疇來看，其實賬目本身抽象出來就是數(shù)據(jù)，商品數(shù)據(jù)，用戶數(shù)據(jù)，卡券數(shù)據(jù)等，那么賬證實需要核對，很多時候很多非財務(wù)范疇數(shù)據(jù)也需要核對，比如今天應(yīng)到10人實到8人，軍訓(xùn)時的報數(shù)等其實也可以稱為對賬，我們暫且稱為“廣義的對賬”
5. 那么我們來為對賬下一個定義：為了確保同一個事務(wù)的數(shù)據(jù)描述在不同場所下的記錄一致而進行的相互之間的一致性比對

1.3 為什么要對賬

1. 首先在財務(wù)范疇，這是一個必要做的工作
2. 另外從業(yè)務(wù)范疇，現(xiàn)在交易鏈條越來越長，數(shù)據(jù)在眾多系統(tǒng)之間難免會出現(xiàn)丟失或者差錯，所以為了業(yè)務(wù)的正常運轉(zhuǎn)及時發(fā)現(xiàn)問題，需要確保系統(tǒng)間數(shù)據(jù)的一致性
3. 從公司的角度，需要確?！安簧偈找环皱X，不多付一分錢”，保證資金的安全，不然賣了多少貨，收了多少錢相互之間誰也不鳥誰，最后全是糊涂賬
4. 綜上所述，對賬是必不可少的；對于交易體量巨大的互聯(lián)網(wǎng)公司更是必不可少，而且系統(tǒng)化也是必須的，單靠人工難以滿足需要

1.4 幾個常見對賬場景

1. 三方支付公司：主要是核對自家的交易記錄和銀行清算數(shù)據(jù)之間的一致性；銀行清算數(shù)據(jù)（應(yīng)收應(yīng)付）和銀行結(jié)算數(shù)據(jù)（實收實付）的一致性；同樣也要核對與金蝶賬務(wù)數(shù)據(jù)的一致性
2. 電商等服務(wù)平臺：主要是核對自家的交易數(shù)據(jù)和三方支付公司或者微信支付寶的清算數(shù)據(jù)的一致性；三方清算和結(jié)算的一致性；三方結(jié)算到對公戶實際資金的一致性
3. 另外還有紅包：比如用戶支付100元發(fā)10個紅包，有6個用戶領(lǐng)了6個一共8元，有4個超時沒領(lǐng)退回給了用戶；那么對于平臺的這個紅包中間賬戶的進出也要核對：{ 用戶充值1筆100元中間戶入了1筆100元中間戶出了10筆100元中間戶被退回4筆2元中間戶退給用戶1筆2元這樣對于中間戶來說100-100+2-2=0 }
4. 還有一些其他的領(lǐng)域?qū)~，比如航司的機票，機票代理商的購票出票，中間券商的上下游之間等等

1.5 常見的對賬模型

1. 交易對賬模型：數(shù)據(jù)之間的按照唯一標識進行一對一，一對多，多對多核對
2. 資金對賬模型：將交易數(shù)據(jù)按照款項類型進行匯總之后進行核對，比如收款，手續(xù)費
3. 余額調(diào)節(jié)核對：對系統(tǒng)記賬余額和實際資金賬戶余額在經(jīng)過在途調(diào)整后進行一致性核對比如：系統(tǒng)記賬昨日日終余額100元，截止昨日日終提現(xiàn)中100元；出款賬戶昨日日終200元；此時該賬戶：系統(tǒng)賬100元=出款賬戶200元-100元應(yīng)付未付；這樣余額是平的，說明資金沒有問題
4. 其他更復(fù)雜的核對模型：比如多鏈條之間進行關(guān)聯(lián)核對像三份數(shù)據(jù)進行一次性比對等，這里不再過多闡述；本系列文章重點介紹的是1和2,至于3會在今后有機會講解，如果有朋友感興趣可以單獨交流

1.6 什么是對賬系統(tǒng)

1. 對賬系統(tǒng)就是通過系統(tǒng)解決方案，對需要核對的數(shù)據(jù)按著設(shè)定好的規(guī)則進行核對校驗，并產(chǎn)出核對結(jié)果；并且可以對核對結(jié)果進行對應(yīng)的差錯處理
2. 通俗來說就是傳統(tǒng)上用Excel來通過人工vlookup做的事情，完全交給系統(tǒng)去做，只需要預(yù)先配置好規(guī)則就行了
3. 對于對賬系統(tǒng)來說，最基本應(yīng)具備以下幾個能力可以便捷的獲取需要核對的原始數(shù)據(jù)，如平臺數(shù)據(jù)，三方數(shù)據(jù)可以對文件數(shù)據(jù)進行解析或者二次加工，可以靈活配置核對規(guī)則，可以查看核對的結(jié)果，可以對差異進行追蹤管理和處理，可以對外提供核對結(jié)果，可以對外輸出數(shù)據(jù)

1.7 如何搭建一個對賬系統(tǒng)

1. 首先就是要先明確對應(yīng)的業(yè)務(wù)模型
2. 其次需要抽象出業(yè)務(wù)的核對模型
3. 然后針對核對模型選擇合適的核對方案
4. 最后針對核對方案設(shè)計系統(tǒng)方案，然后進行研發(fā)和上線

第二部分：對賬架構(gòu)圖

2.1 標準架構(gòu)

如果企業(yè)整體業(yè)務(wù)架構(gòu)完整，系統(tǒng)建設(shè)完善的情況下建議對賬采用該架構(gòu)

1. 1. 有完善的賬務(wù)核心和會計核心
   2. 對賬先完成交易數(shù)據(jù)和三方清算數(shù)據(jù)的核對
   3. 交易完成了賬務(wù)和會計層的資金賬記賬
   4. 匯總清算數(shù)據(jù)和銀行賬單數(shù)據(jù)
   5. 完成平臺資金賬和銀行賬單的資金核對
   6. 對賬系統(tǒng)通知賬務(wù)核心銀行待清算資金的結(jié)轉(zhuǎn)，如下

2.2 簡化架構(gòu)

如果企業(yè)沒有賬務(wù)和會計核心；可以通過對賬中心先時間交易數(shù)據(jù)和三方清算數(shù)據(jù)的核對；然后匯總清算數(shù)據(jù)與三方賬單數(shù)據(jù)核對；保證金業(yè)務(wù)記賬以及銀行清結(jié)算數(shù)據(jù)的一致性

1. 按核對頻率獲取業(yè)務(wù)支付數(shù)據(jù)
2. T+1或其他頻率獲取三方清算文件和結(jié)算文件
3. 將清算和結(jié)算文件進行解析存儲
4. 根據(jù)對賬項目配置完成交易數(shù)據(jù)和清算的核對
5. 完成清算數(shù)據(jù)和結(jié)算數(shù)據(jù)的核對
6. 對交易的單邊數(shù)據(jù)和資金核對差異進行管理和處理

2.3 伽馬金融管理核對架構(gòu)

資金管理框架的資金賬和銀行賬核對業(yè)務(wù)架構(gòu)圖

該圖略，課程里會介紹該體系

核心幾個關(guān)鍵點：

1. 統(tǒng)一收付平臺收口收款、退款、調(diào)撥等資金業(yè)務(wù)
2. 對資金業(yè)務(wù)統(tǒng)一記賬形成統(tǒng)一資金賬務(wù)
3. 對集團的資金賬戶進行統(tǒng)一管理
4. 余額調(diào)節(jié)對賬完成資金賬和銀行的核對勾兌
5. 賬戶的余額調(diào)節(jié)表

2.4 伽馬支付核對業(yè)務(wù)架構(gòu)

伽馬支付為公眾號案例中心虛擬的支付公司

2.5 通用對賬系統(tǒng)架構(gòu)

第一篇文章介紹過，我們可以脫離財務(wù)范疇，抽象出數(shù)據(jù)核對的通用架構(gòu)，對數(shù)據(jù)逐筆準確性校驗，實時監(jiān)控；資金期初期末及發(fā)生額的資金校驗核對；在這個理念下我們形成如下一個應(yīng)用范圍更廣的通用架構(gòu)

第三部分：對賬文件獲取和解析

支付交易的通道提供方，例如微信、支付寶、網(wǎng)聯(lián)、銀聯(lián)等，都是按照約定頻率和時間提供交易的記錄文件，一般都是2份，一個清算文件“記錄支付明細”；另一個是“結(jié)算文件”記錄資金賬戶的實際的資金變動；對于文件的獲取大部分在提供通道時會提供下載接口，另外如果沒有接入下載接口，可以采用人工下載的方式獲得文件，將文件傳到對賬系統(tǒng)獲得對賬數(shù)據(jù)；本文主要介紹渠道方的對賬文件獲取以及解析和管理。

3.1 對賬文件類型

主流類型還是Excel和txt，本文主要介紹的也是這2種

excel（csv）支付寶,常見支付公司；這類文件最方便查看

txt微信，銀聯(lián)個別通道，一些銀行；這類文件很不便于查看

xml報文網(wǎng)聯(lián)；這類文件人工很難查看和處理

其他類型銀聯(lián)還有一些通道文件

3.2 對賬文件獲取方式

接口獲取通過機構(gòu)提供的文件查詢和下載接口獲取對賬文件支付寶下載接口。

示例：

人工下載如果技術(shù)能力資源不足，或者暫時沒有接入接口，可以采用人工下載的方式，然后在對賬中心上傳對賬文件進行解析

3.3 對賬文件管理

• • 文件管理方式文件一般存放在對賬系統(tǒng)指定的ftp內(nèi)，并且對文件夾設(shè)定一定的命名規(guī)范，通過路徑查詢和下載文件
  • 文件管理后臺頁面在后臺頁面查看和下載文件，便于處理和排查對賬問題

3.4 對賬文件解析器配置

對賬文件解析是指將文件里的數(shù)據(jù)解析到數(shù)據(jù)庫內(nèi)，形成數(shù)據(jù)庫數(shù)據(jù)，因為文件數(shù)據(jù)不能直接被系統(tǒng)處理。

原樣解析不改變文件的數(shù)據(jù)列數(shù)和內(nèi)容，對文件數(shù)據(jù)保證不減少列數(shù)的前提下進行全量解析，可以根據(jù)需要增加列內(nèi)容，比如賬號，對賬時間等。

• 優(yōu)點：不需要配置解析器，每一個文件研發(fā)好固定的解析器進行復(fù)用
• 缺點：每個文件類型需要建一套數(shù)據(jù)表，維護成本高
• 適用：通道少的平臺，一般商戶都僅有微信支付寶，可以采用原樣解析
• 通用板式解析

所有對賬文件數(shù)據(jù)按照映射關(guān)系解析到固定的數(shù)據(jù)表當中；例如以下的表結(jié)構(gòu)：

例如如下對賬文件：

解析規(guī)則應(yīng)該：

解析器配置管理該部分不做過多介紹，記住一個原則公式：在X列滿足什么條件時將Y列的數(shù)解析到數(shù)據(jù)表的W字段內(nèi)；在第6第7篇中的對賬項目設(shè)計中會有類似的配置頁面設(shè)計。

3.5 對賬數(shù)據(jù)查看

數(shù)據(jù)解析到數(shù)據(jù)庫里了，為了便于運營排查問題，還需要做一個查看數(shù)據(jù)的運營頁面，頁面樣式如下：

第四部分：平臺自有數(shù)據(jù)的獲取

4.1 平臺對賬數(shù)據(jù)獲取方式

拿到三方文件賬單數(shù)據(jù)以后需要與平臺自己的相關(guān)數(shù)據(jù)做核對，比如平臺交易數(shù)據(jù)與清算數(shù)據(jù)的核對；平臺賬務(wù)數(shù)據(jù)與銀行賬單數(shù)據(jù)的核對；平臺自有數(shù)據(jù)獲取方式常采用如下形式：

• 文件獲取業(yè)務(wù)系統(tǒng)需要按照要求定期（如每日凌晨2:00）生成文件，按照約定規(guī)范進行命名后，將文件推送至對賬系統(tǒng)指定位置（ftp）；這種方式需要各業(yè)務(wù)系統(tǒng)有一定開發(fā)量，業(yè)務(wù)調(diào)整時也需要調(diào)整文件的生成策略，維護成本略高
• 接口接收對賬系統(tǒng)提供對賬數(shù)據(jù)接收接口，類似賬務(wù)記賬接口一樣，業(yè)務(wù)系統(tǒng)按照約定在相應(yīng)業(yè)務(wù)節(jié)點發(fā)送業(yè)務(wù)數(shù)據(jù)到對賬中心
• MQ業(yè)務(wù)方按照要求在交易成功時發(fā)送約定格式的MQ消息，對賬系統(tǒng)訂閱該MQ，對MQ進行解析后獲得業(yè)務(wù)數(shù)據(jù)
• SQL通過SQL定期撈取業(yè)務(wù)數(shù)據(jù)，并將數(shù)據(jù)存儲到對賬系統(tǒng)數(shù)據(jù)庫中；該方式調(diào)整靈活，可以選擇在業(yè)務(wù)并發(fā)小的凌晨進行
• 人工上傳對于一些采購的外部應(yīng)用，比如金蝶系統(tǒng)，數(shù)據(jù)無法通過以上方式獲取的情況下，就需要對賬人員定期下載應(yīng)用內(nèi)數(shù)據(jù)，然后上傳到對賬系統(tǒng)

4.2 數(shù)據(jù)分類管理

對賬系統(tǒng)數(shù)據(jù)會越來越多，類型也越老越多，支付數(shù)據(jù)，卡券數(shù)據(jù)，訂單數(shù)據(jù)，三方清算數(shù)據(jù)，三方結(jié)算數(shù)據(jù)等等；每類數(shù)據(jù)的數(shù)據(jù)字段有各有不同；如何對眾多類型數(shù)據(jù)進行管理呢？下面介紹一個方法：對數(shù)據(jù)進行分類管理，每類數(shù)據(jù)單獨設(shè)置表結(jié)構(gòu)。

數(shù)據(jù)分類設(shè)置設(shè)置數(shù)據(jù)的大類，或者說是一級分類；就像商品類目一樣管理數(shù)據(jù)。

設(shè)置數(shù)據(jù)類型在數(shù)據(jù)分類下面設(shè)置數(shù)據(jù)的子類，并且數(shù)據(jù)子類關(guān)聯(lián)數(shù)據(jù)庫表名，便于存儲數(shù)據(jù)，查詢數(shù)據(jù)，對賬取數(shù)。

4.3 取數(shù)規(guī)則配置

配置好了數(shù)據(jù)分類和類型以及關(guān)聯(lián)好了數(shù)據(jù)表之后，接下來就是配置獲取數(shù)據(jù)的規(guī)則了，我們以通過文件或者SQL兩個可選擇的形式獲取數(shù)據(jù)為例。

為每個數(shù)據(jù)分類配置取數(shù)方式，如果是文件的話就配置文件路徑，如果是SQL的話就配置取數(shù)sql，這樣系統(tǒng)會按照任務(wù)配置基于取數(shù)規(guī)則定期獲取對賬的數(shù)據(jù)，并且插入到數(shù)據(jù)類型關(guān)聯(lián)的數(shù)據(jù)表當中。

第五部分：對賬數(shù)據(jù)管理

5.1 對賬結(jié)果數(shù)據(jù)

5.1.1 交易對賬結(jié)果

支付數(shù)據(jù)與三方清算的核對，或者其他數(shù)據(jù)的兩兩核對，會得出核對結(jié)果；并且每一組核對都會有一個組別的名字，這個下一節(jié)會詳細介紹，比如“會員支付VS微信清算”，核對結(jié)果如下表：

我們可以看出來“1,5,6”三條記錄是有問題的，2條是一方有一方?jīng)]有，另外一條是都有但金額不一致；這就是交易對賬結(jié)果，“對平，單邊，錯賬”，對于對賬有問題的數(shù)據(jù)需要進行排查找出原因，并進行差錯處理（后面會詳細介紹）。

5.1.2 資金對賬結(jié)果

交易對賬結(jié)果是源數(shù)據(jù)本身在某個對賬項目里的核對結(jié)果；而資金對賬結(jié)果是某資金賬號某交易日的資金收付的一致性；比較平臺的資金賬收付結(jié)果與銀行的收付結(jié)果是否一致，或者說是銀行自己本身的清算與結(jié)算的款項及金額是否一致；

比如：

從對賬結(jié)果我們可以看出來，微信在退款和退款手續(xù)費存在差異，而發(fā)現(xiàn)二者正好正負相抵，原因是微信退款和退款手續(xù)費是軋差出現(xiàn)在賬單里的，所以實際上并沒有差異，但是既然已經(jīng)對出差異，并且排查出原因，就需要對差異進行處理，資金對賬的差異是“長款，短款，應(yīng)收未收，應(yīng)付未付”；在確認對賬結(jié)果后，會生成差異表，在差異表中對差異進行核銷處理。

5.2 對賬管理

上面我們介紹了交易對賬和資金對賬的核對結(jié)果，那么如何存儲差異結(jié)果呢？差異結(jié)果可以存儲在源對賬數(shù)據(jù)的表中，也可以單獨存儲

存儲在源對賬表該種方式適合與數(shù)據(jù)單一的對賬體系，且同一份數(shù)據(jù)不會在多個對賬項目中進行核對，比如支付數(shù)據(jù)只與清算核對，這時候數(shù)據(jù)的核對結(jié)果就是默認與另一方的核對情況。

支付數(shù)據(jù)：1 對平 清算數(shù)據(jù)：1 對平

存儲在單獨的對賬表中該種方式適合復(fù)雜的核對場景，同一份數(shù)據(jù)會在多個對賬項目中與多組數(shù)據(jù)完成核對，產(chǎn)生多個對賬結(jié)果，比如支付數(shù)據(jù)與上游的訂單進行核對得出一個對賬結(jié)果，支付數(shù)據(jù)又會與下游的清算數(shù)據(jù)核對得出另一個對賬結(jié)果。

與訂單對：訂單數(shù)據(jù)：1 對平 支付數(shù)據(jù)：1 對平與清算對：支付數(shù)據(jù)：1 單邊 清算數(shù)據(jù)：無

我們發(fā)現(xiàn)支付數(shù)據(jù)的對賬結(jié)果有2個，一個是與訂單的核對的對平，另一個是與清算的核對的單邊，此種情況，我們的對賬結(jié)果就需要單獨存儲“某數(shù)據(jù)在每一個對賬項目組中的核對結(jié)果表”，對賬結(jié)果有2個，如下：

支付數(shù)據(jù)對賬結(jié)果表

與訂單對：對平

與清算對：單邊

第六部分：交易對賬項目設(shè)計

企業(yè)業(yè)務(wù)在不斷變化，新的業(yè)務(wù)也在不斷出現(xiàn)，對賬數(shù)據(jù)因為業(yè)務(wù)的變化也在發(fā)生變化；如果接入了新的支付渠道對賬設(shè)置也需要新增；如果每次都通過開發(fā)實現(xiàn)，那么成本會很高；本篇文章我們將介紹如何實現(xiàn)交易對賬項目的配置化設(shè)計，極大的提升對賬項目的管理效率。

6.1 交易對賬項目

做對賬并不是簡單的一方與另一方比對；實際會基于業(yè)務(wù)情況，存在很多組進行核對；比如與微信的核對，與支付寶的核對等；每一組又可能分成更細的組，比如與微信核對，可以分成微信收款核對，微信退款核對；又可能微信收款有很多賬號，我們又可能會按照微信賬戶進行分組進行核對；例如微信收款一共有兩個微信賬號：微信1，微信2；那么我們可以設(shè)置4個對賬的組，如下：

對賬項目1：微信1-收款

對賬項目2：微信1-退款

對賬項目3：微信2-收款

對賬項目4：微信2-退款

對賬項目就是我們設(shè)定的核對組；當然以上的對賬項目我們可以簡化成2個

對賬項目1：微信-收款

對賬項目2：微信-退款

具體如何設(shè)置核對組，這個因公司而已，因喜好而已，核心目的只要能完成全量的核對即可；對賬項目越少越容易管理，對賬項目越多越清晰，各有利弊。

6.2 對賬項目命名

為了便于管理我們還需要為每個對賬項目命個名字，如何起名這個也看自己喜好；原來在易寶支付，因為對賬組的同學(xué)基本都是女生，都是吃貨，所以所有對賬項目都命名稱跟吃相關(guān)的“如：工商9876-鹵煮火燒”；命名的一個關(guān)鍵原則。

要能從名字中看出具體核對的業(yè)務(wù)，基于這個原則我們?yōu)?中的幾個項目進行命名如下：

對賬項目1：會員購買微信支付-收款

對賬項目2：會員購買微信支付-退款

這樣我們可以清晰的知道對賬項目1是用戶使用微信支付購買會員的收款核對項目。

6.3 對賬項目管理

一個企業(yè)可能會存在很多個對賬項目，像原來在某支付，高達幾百個核對項目；為了便于管理，我們就需要一個菜單專門管理對賬項目；示例如下：

該頁面可以查看所有的對賬項目；點擊設(shè)置可以進行該對賬項目的配置設(shè)置；右上角的新增可以新增新的項目。

6.4 對賬項目新增

在對賬項目列表點擊新增會有一個彈窗可以添加一個對賬項目；新增時需要先填寫基本信息即可，比如對賬項目的名稱，對賬啟用時間，對賬的頻次，對賬的類型等；確定后在對賬項目列表就會有一個新增的項目，點擊設(shè)置即可以進入設(shè)置頁面，具體看5。

6.5 對賬項目設(shè)置

對賬項目的設(shè)置主要設(shè)置對賬項目的執(zhí)行時間，核對雙方的對應(yīng)數(shù)據(jù)，核對的唯一標識，一些處理規(guī)則等；下面是一個基礎(chǔ)的設(shè)置頁面；實際工作中需要基于業(yè)務(wù)場景以及數(shù)據(jù)特點，對設(shè)置器進行一些調(diào)整；但是在這配置基礎(chǔ)之上一般難度不大；配置頁面如下：

該配置器最終的實現(xiàn)是：

我們從頁面可以看出來，該配置是設(shè)置卡系統(tǒng)的消耗數(shù)據(jù)與訂單中的消耗記錄進行核對。

• 為數(shù)據(jù)兩方配置數(shù)據(jù)的選擇條件
• A方數(shù)據(jù)為卡數(shù)據(jù)
• 數(shù)據(jù)篩選條件是”交易類型=消耗購買”
• B方數(shù)據(jù)是訂單數(shù)據(jù)
• 對比設(shè)置兩方以訂單號進行核對，金額進行核對
• 訂單數(shù)據(jù)的金額如果存在多條則進行匯總
• 對賬差異的報警接受人，可以填郵件，辦公賬號等

這樣完成配置后，一個對賬項目就配置完成了；會照著配置的時間每天完成訂單數(shù)據(jù)和卡數(shù)據(jù)關(guān)于消耗明細的核對。

第七部分：資金對賬項目設(shè)計

完成線上支付交易以后，雖然通道方告知支付成功，但是錢是不是真的能給，還需要打一個問號？資金對賬就是應(yīng)收應(yīng)付和實收實付之間的核對；什么是應(yīng)收應(yīng)付，什么是實收實付呢？哪些數(shù)據(jù)與之對應(yīng)呢，這邊文章會詳細介紹。

7.1 資金對賬項目

通過上一篇6我們已經(jīng)明白對賬項目的概念；今天我們要介紹的資金對賬項目可能更容易理解：一個實體的銀行或者三方資金賬戶為一個資金對賬項目。

所以說資金對賬，我們按照銀行賬戶的維度進行核對；因為在會計科目中銀行賬戶已經(jīng)是葉子科目了，雖然一個資金賬戶可能有很多業(yè)務(wù)類型的收款，但是我們這里不再細分了；如果因為公司需要想細分也是可以實現(xiàn)，只需要按著業(yè)務(wù)類型區(qū)分賬戶的資金變動項即可。

這里我們按照一個實體的資金賬戶設(shè)置為一個資金對賬項目，比如平臺有微信平臺2個收款賬戶1和2，支付寶平臺兩個收款賬戶3和4，招商對公5，一共5個資金賬戶，那么我們就可以設(shè)置5個資金對賬項目，如下：

資金對賬項目1：微信賬戶1

資金對賬項目2：微信賬戶2

資金對賬項目3：支付寶賬戶3

資金對賬項目4：支付寶賬戶4

資金對賬項目5：招商對公戶5

7.2 對賬項目命名

為了便于管理我們還需要為每個對賬項目命個名字，如何起名這個也看自己喜好；命名的一個關(guān)鍵原則。

要能從名字中看出具體核對的那個賬戶。

基于這個原則我們?yōu)?中的幾個項目進行命名如下：

規(guī)則：通道方+通道類型+賬戶號

資金對賬項目1：微信-收款-賬戶1

資金對賬項目2：微信-收款-賬戶2

資金對賬項目3：支付寶-收款-賬戶3

資金對賬項目4：支付寶-收款-賬戶4

資金對賬項目5：招商對公-收款-公戶5

這樣我們可以清晰的知道對賬項目1是微信開的的賬戶號為1的收款賬戶。

對賬文件管理前面已經(jīng)講過了，每個賬戶次日都會提供相應(yīng)的清算文件和結(jié)算文件；那么文件要跟資金資金對賬項目對應(yīng)上，最后為對賬文件命名上可以知道對應(yīng)的所屬賬戶，比如：

規(guī)則：通道方+賬號+文件類型+交易日期

資金對賬項目1：wx-1-pay-20210204

7.3 對賬項目管理

一個企業(yè)可能會存在很多個資金賬戶；為了便于管理，我們就需要一個菜單專門管理資金對賬項目；示例如下：

該頁面可以查看所有的資金對賬項目，每個項目就是一個實體資金賬戶；點擊設(shè)置可以進行該對賬項目的配置設(shè)置；右上角的新增可以新增新的項目。

7.4 資金對賬模式選擇

資金對賬我們知道是核對應(yīng)收應(yīng)付和實收實付，實收實付我們知道就是銀行實際資金的變動，使用銀行結(jié)算賬單即可；那么應(yīng)收應(yīng)付的選擇其實有2種方法一個是使用通道的清算文件作為應(yīng)收應(yīng)付，另一個是使用平臺的資金賬務(wù)作為應(yīng)收應(yīng)付。

使用銀行清算文件就是銀行記錄應(yīng)收應(yīng)付與實收實付進行核對，但是有個缺陷就是平臺的支付記錄需要跟銀行的清算文件進行核對，所以核對模型如下：

看3中的新增對賬項目中有一個關(guān)聯(lián)交易對賬，就是看一下平臺的支付記錄和清算文件核對有沒有差異，如果沒有且資金對賬沒差異，那么就沒有問題。

使用平臺資金賬務(wù)核對就是如果公司有賬務(wù)中心的話，可以直接拿資金變動賬務(wù)與實際銀行的資金結(jié)算賬單核對，這個不做具體介紹了。

7.5 對賬維度

交易對賬是按照逐筆核對的，資金對賬我們不按照逐筆核對，因為存在軋差以及線下匯入等情況，我們按照費用維度進行核對，就是將應(yīng)收應(yīng)付和實收實付解析成款項，對相同款項進行核對，比如收款，收款手續(xù)費，退款，退款手續(xù)費，打款等。

7.6 對賬項目設(shè)置

我們以核對清算數(shù)據(jù)和結(jié)算數(shù)據(jù)為例，資金對賬項目解析就是將文件里的數(shù)據(jù)解析匯總到對應(yīng)的款項上去，知道一個賬戶今天每一個款項上的金額。

該配置器最終的實現(xiàn)是：

我們從頁面可以看出來，該配置是將文件里的數(shù)據(jù)先通過“條件組”的篩選，然后取目標數(shù)據(jù)的金額，并且對金額進行運算匯總；比如例子中的第一條就是：取交易狀態(tài)=success的數(shù)據(jù)，取訂單金額作為結(jié)算金額

如文件數(shù)據(jù)

通過原型中的配置條件

條件組：交易狀態(tài)=success，

金額：正直匯總訂單金額

我們得到了：收款=100+90=190

其他費用邏輯類似

一定要枚舉一個資金賬戶里的每一類型費用，不能遺漏，不然會出現(xiàn)資金差異。

這樣完成配置后，一個對賬項目就配置完成了；會照著配置的時間每天完成賬單數(shù)據(jù)的匯總，得到該賬戶每一方數(shù)據(jù)的每個款項的金額。

第八部分：對賬引擎及對賬結(jié)果查看

在對賬執(zhí)行前還有最后幾個重要的問題沒有解決，那就是對賬的核心處理邏輯是什么；對賬有幾個關(guān)鍵的處理引擎。

8.1 對賬連續(xù)性控制

對賬不能跨日，比如2號對完才能對3號，如果今天是10號，2號還沒對賬，那么3-9號的賬都不會核對；因為前一天的單邊會循環(huán)進入下一天的核對。

8.2 對賬時間控制

如上表，我們需要管理對賬的時間；這里有3個時間概念需要知道：

• 對賬日期：就是對的那一天的賬，也是交易成功時間或者資金變動日期
• 對賬啟用日期：一個對賬項目的第一個對賬日期
• 最后對賬日期：一個對賬項目的最后一個對賬日期

8.3 對賬狀態(tài)控制

需要管理可查每一個對賬項目在每一天的對賬狀態(tài)。

8.4 對賬任務(wù)流程控制引擎和報警

主流程控制對賬項目的任務(wù)執(zhí)行，并在流程成變更更新其他控制環(huán)節(jié)參數(shù)；如果主流程某一個處理失敗那么進行任務(wù)報警，人工干預(yù)重啟流程。

8.5 對賬核心處理引擎

對賬最核心的引擎就是數(shù)據(jù)間逐筆核對的過程：

比如經(jīng)過上面的邏輯，對賬項目1在x日的對賬結(jié)果如下：

8.6 對賬結(jié)果查看

通過上面的對賬執(zhí)行，我們就得到了對賬的結(jié)果，每個對賬項目的對賬總筆數(shù)，總差異。

交易對賬結(jié)果該結(jié)果是每個對賬項目按筆數(shù)核對的結(jié)果。

• • 資金對賬結(jié)果該結(jié)果是每個資金賬戶對賬項目，按照費用款項核對的結(jié)果

好了，得到了對賬結(jié)果之后，下一步就是針對不同的差異進行排查和差錯處理了。

第九部分：差錯處理和差錯配置設(shè)計

對賬有兩個核心目的，一個是發(fā)現(xiàn)錯誤，另一個是改正錯誤；今天我們說一下對賬差異的處理

對賬結(jié)果如果有差異，就需要有排查差異的原因，差異原因千奇百怪，但存在必是有原因的，如果登時查不到就先掛著，至少我們知道了有一個差異待處理；（下文提到的差異我們代表交易對賬對出的單邊或者錯賬以及資金對賬對出的資金長短款）

9.1 關(guān)于差錯處理

差錯處理其實就是消除差異的過程：

• 發(fā)現(xiàn)差異：對賬結(jié)果對出了差異
• 排查差異原因：排查差異原因，是掉單了，bug，時間差等具體的原因
• 按照實際處理差異：找到原因后對差錯進行處理，掉單的補單，bug就修復(fù)，時間差的話就不用處理，等待第二天對平
• 消除差異：這一步是在對賬系統(tǒng)對差異進行標記處理，說明差異已經(jīng)排除了

9.2 交易差錯處理

交易對賬是數(shù)據(jù)的逐筆核對，會出現(xiàn)三類結(jié)果：

• 對平：無需處理
• 單邊：需要處理
• 錯賬：需要處理

差錯列表：

對賬的差異會單獨出現(xiàn)在差異列表等待處理。

點擊處理，彈窗選擇處理類型，提交之后可以走一個流程，也可以直接處理完成。

差錯處理類型：

就是我們用什么樣的方式消除了差異，比如如果是銀行成功，我方平臺掉單了，那么就進行補單，補完后就對平了，這樣也是保證用戶的權(quán)益；這時因為是我方掉單了，所以對賬結(jié)果是銀行單邊；等我方補完單后，銀行的這筆單邊就出錯了“平臺補單”。

我們可以預(yù)設(shè)一些差錯處理類型，形成每個類型的處理流程，便于在處理的時候直接選擇使用。

差錯處理接口：

有些差錯處理是可以讓相關(guān)系統(tǒng)包裝接口直接進行處理的；比如平臺掉單補單，可以讓訂單系統(tǒng)包裝一個補單接口，對賬系統(tǒng)調(diào)用進行補單。

9.3 資金差錯處理

資金對賬的差異是費用的差異，收款，退款，手續(xù)費；在賬戶對完結(jié)果后，如果確認不是解析等技術(shù)層面的差異，可以對結(jié)果進行一個確認，確認之后差異會生成長短款數(shù)據(jù)，后面對資金進行長短款處理時就對長短款進行核銷。

資金對賬結(jié)果確認：

長短款管理：

比如微信的一個資金賬戶，資金同事直接在微信商戶后臺操作了一筆轉(zhuǎn)賬，或者用戶直接用微信轉(zhuǎn)給給了這個賬戶，這時候都會出現(xiàn)微信收款比平臺收款多的情況。

微信賬單收款1000———-平臺記賬收款900

此時資金對賬就會有100元的長款，就是微信多收了。

確認結(jié)果以后，長短款模塊就會生成一筆該賬戶的 100元長款記錄；長款款記錄要有賬戶信息，對賬日期信息，費用信息等。

長短款核銷：

對于生成的長短款差異，同時也會生成賬務(wù)憑證，算是一個掛賬憑證，為了讓賬務(wù)是平衡的；后續(xù)針對每筆資金差異進行排查核銷；比如如果確認是人工微信做了轉(zhuǎn)賬，那么可以直接核銷“資金人工轉(zhuǎn)出確認”，直到長短款沒有待核銷長短款，我們的資金就是準確的了。

9.4 其他對賬場景案例

除了常見的三方支付，電商等的普通的在線交易的對賬，還有一些其他領(lǐng)域的核對，雖然行業(yè)不同，交易數(shù)據(jù)特點不同，但是對賬的本質(zhì)是相通的；唯一不同的就是交易數(shù)據(jù)的結(jié)構(gòu)千奇百怪，導(dǎo)致數(shù)據(jù)的解析，核對邏輯會有變化，下面我們舉幾個場景。

紅包中間賬戶對賬：

我們都知道，紅包場景算是比較復(fù)雜的，因為發(fā)紅包的支付一筆紅包款，會發(fā)出幾十個紅包，最后有些紅包沒被領(lǐng)取又退回了，這個核對場景最復(fù)雜的是一對多，我們站在紅包的中間賬戶角度看這個交易場景，對中間賬戶的進出進行核對。

案例：用戶A用招商銀行卡通過紅包發(fā)了10個紅包共100元，3天后一共領(lǐng)了7個80元，退回20元到招商銀行卡。

• 紅包發(fā)放充值流入：+100元
• 紅包流出付款流出：一共8筆共80元
• 超時未領(lǐng)取退回流出：一筆20元

你覺得該如何做核對呢？

機票代理對賬：

我們都知道去哪網(wǎng)，攜程，飛豬，這些賣機票的平臺；可能不太清楚這些平臺上的眾多機票代理商，他們的交易體量也是非常巨大了，每個月賣出幾萬賬票的很多；我?guī)椭芏鄼C票代理商實現(xiàn)了自動化對賬的系統(tǒng)建設(shè)；他們的對賬相對來說是非常復(fù)雜的，在鶴壁有一家代理商是從深圳搬過來的，他們一共有5個財務(wù)每天進行對賬，5個財務(wù)的年薪資支出有二三十萬之多，可想而知如果實現(xiàn)系統(tǒng)化對賬，能節(jié)省多少費用。

機票代理商的交易模型：

從模型中我們可以看出來，主要是有三個環(huán)節(jié)：

• 售票平臺代理商入住后，就像淘寶已經(jīng)，會有個結(jié)算賬戶，記錄賣票記錄和結(jié)算款記錄，賣出去10張票，平臺抽取傭金剩余部分結(jié)算給代理商結(jié)算賬戶；平臺會提供2分文件：機票銷售明細文件，結(jié)算明細文件；這兩份數(shù)據(jù)要做核對
• 機票代理商機票代理商有一個機票管理系統(tǒng)，購買的第三方服務(wù)公司的，可以記錄在每個平臺的賣票情況以及付款出票情況
• 付款通道機票代理商要賣機票需要向航司去買，賣票付款的話航司簽約了一些三方支付公司，比如支付寶，易寶支付，代理商選擇這些付款通道進行簽約向航司付款，先把錢充值到指定付款賬戶中，易寶支付是航旅行業(yè)覺得的第一名，付款通道會給機票代理付款文件

機票代理的對賬模型所以對賬我們要對這幾個維度售票平臺的售票明細與結(jié)算明細核對售票平臺的售票明細與代理商系統(tǒng)的售票明細核對代理商系統(tǒng)的付款明細與通道的付款賬單核對。

機票行業(yè)數(shù)據(jù)特點這個行業(yè)的文件是很復(fù)雜的，特別是幾家ota平臺，文件形式各不相同，一個用戶買7張票，一個訂單對應(yīng)7個人，對應(yīng)7張票；有的平臺的一個訂單一票記錄，票號塞在一個單元格里，有的平臺是一張票一條數(shù)據(jù)….大家可以思考一下，一下對賬怎么對呢：按照訂單號對？還是按照票號對？

還有一個行業(yè)是券商對賬：

什么是券商呢，我們在招商信用卡，中移動積分商城里兌換的商家優(yōu)惠券其實不是直接由商家提供的，而是中間券商；就像電子支付一樣，中間券商匯集采購商家的優(yōu)惠券，然后通過接口提供售賣給信用卡平臺或者中移動等平臺；用戶在中移動或者信用卡商城兌換后到商家去消費，然后進行層層的核銷和結(jié)算。

招商銀行和中移動與券商結(jié)算，券商再把結(jié)算款結(jié)算給商家。

這個對賬模式我就不再細說了，大家可以思考一下如何建設(shè)券商的對賬系統(tǒng)。

第十部分：銀行存款余額調(diào)節(jié)對賬

你有賬戶里有多少錢，有多少錢可用？這個問題是不是很莫名其妙，錢都是我的，當然都能用??！那再換個說法，如果你10號會發(fā)2萬工資，4號要支付1萬房貸，現(xiàn)在銀行卡里還剩1.1萬，如果你對象說有急事3號要先用你2000塊錢，你怎么辦，在每次要花錢的時候，是不是有一個經(jīng)典問題困擾著你，我是誰，我在那？當然不是，“我還有多少錢能用？” ！這就是我們今天要解決的問題，銀行賬戶還有多少錢，還有多少錢能用 ！

10.1 什么是余額調(diào)節(jié)表

銀行存款余額調(diào)節(jié)表，就是將企業(yè)的賬面余額和銀行的賬單余額，經(jīng)過未達款項調(diào)整后，核對調(diào)整余額是否一致的核對工具；驗證調(diào)節(jié)后的存款余額是否相等的核對方法；如果想等則表明企業(yè)和銀行的賬目都沒有問題；反之，則說明記賬有錯誤，或者有未達賬沒找到；需要進一步查明原因，進行修正；余額調(diào)節(jié)表調(diào)整后的余額是銀行存款當日可以動用的最大值。

日期：xxxxxx ，賬戶：銀行存款-工行1122

未達是怎么產(chǎn)生的呢，比如打款一般企業(yè)先扣賬，然后走審批；如果在對賬時還沒完成審批，這時就會有銀行還沒到達，但企業(yè)已操作賬務(wù)；另一個場景就是用戶直接線下匯入賬戶的資金，企業(yè)賬務(wù)還沒進行記賬，對企業(yè)賬來說就形成未達；

特別提醒要區(qū)分資金對賬的應(yīng)收應(yīng)付和實收實付概念；未達這里是個余額對賬的概念；應(yīng)收付是資金清算的概念。

10.2 如何編制余額調(diào)節(jié)表

就如第一部分介紹的概念，編制余額調(diào)節(jié)表就是在兩方余額之上進行未達賬的加減，獲得調(diào)整余額。

第一步：

獲得兩邊的余額作為基礎(chǔ)余額以及賬務(wù)明細作為未達素材；企業(yè)賬從賬務(wù)系統(tǒng)獲得資金賬明細，銀行賬從銀行獲得對賬單并解析入庫；待勾兌。

第二步：

通過可勾兌唯一表示，勾兌雙方賬務(wù)明細；未匹配上的明細即是對方未達。

第三步：

按照調(diào)整公式計算出調(diào)整余額。

銀行調(diào)整余額=銀行對賬單存款余額+企收銀未收－企付銀未付

企業(yè)調(diào)整余額=企業(yè)賬面銀行存款余額+銀收企未－銀付企未付

調(diào)節(jié)后，如果雙方余額相等，一般可以認為雙方記賬沒有差錯。調(diào)節(jié)后雙方余額仍然不相等時，原因還是兩個，要么是未達賬項未全部查出，要么是一方或雙方賬簿記錄還有差錯。無論是什么原因，都要進一步查清楚并加以更正，一定要到調(diào)節(jié)表中雙方余額相等為止。

調(diào)節(jié)后的余額既不是企業(yè)銀行存款日記賬的余額，也不是銀行對賬單的余額，它是企業(yè)銀行存款的真實數(shù)字，也是企業(yè)當日可以動用的銀行存款的極大值。

10.3 如何余額調(diào)節(jié)表系統(tǒng)

余額調(diào)節(jié)表系統(tǒng)就是通過系統(tǒng)實現(xiàn)賬戶的日末賬戶余額調(diào)節(jié)核對；要想實現(xiàn)系統(tǒng)化要解決一下問題。

資金賬：

平臺要對支付交易和打款進行規(guī)范的資金賬記錄，企業(yè)通過oa走的其他費用，例如報銷，補貼等也要進行資金賬記錄；資金調(diào)撥也要進行資金賬記錄；所以綜合來講需要有平臺所有賬戶的所有資金賬務(wù)的系統(tǒng)記賬處理；那么就是需要一個賬務(wù)系統(tǒng)，這個后面會講，這里就不在贅述。

賬戶管理：

對平臺所有銀行存款或者其他類賬戶，如微信支付寶賬戶進行通過管理，可以通過財務(wù)主數(shù)據(jù)也可以在對賬系統(tǒng)維護；并且最好可以關(guān)聯(lián)會計科目；最后就是要設(shè)定賬戶的余額調(diào)節(jié)啟用日期。

賬戶的期初余額：

在賬戶管理里設(shè)定賬戶的期初余額，系統(tǒng)會基于該期初余額加減資金賬的明細獲得任何一個時間區(qū)間的期初，發(fā)生，期末；所以該期初余額一定要正確。

獲取銀行賬單：

通過人工上傳或者銀企直聯(lián)以及三方接口，每日獲取上一期的對賬單，并解析入庫，用于進行資金勾兌。

企業(yè)資金賬單：

從資金賬獲取本次核對日期要核對的資金賬明細，備用，用戶與銀行賬進行勾兌。

核對：

執(zhí)行企業(yè)賬單和銀行賬單的勾兌，為勾兌上的認為是對方未達，進入余額調(diào)節(jié)表。

獲取余額：

從賬戶余額表獲取企業(yè)賬該賬戶的余額，用銀行對賬單或者接口查詢獲得銀行對應(yīng)賬戶的日終余額。

余額調(diào)節(jié)表結(jié)果：

結(jié)果是基于賬戶維度，得到每個賬戶的日終調(diào)整余額兩邊的核對結(jié)果以及調(diào)整明細。

詳情：

好的，對賬系列我們就完結(jié)了，對賬系統(tǒng)大家會設(shè)計了么。

工作當中，每個行業(yè)，每家公司的業(yè)務(wù)場景和業(yè)務(wù)模型都會有差異，對賬模式以及系統(tǒng)設(shè)計也需要相應(yīng)的針對性設(shè)計，在通用對賬的基礎(chǔ)上進行調(diào)整，比如因為數(shù)據(jù)結(jié)構(gòu)特點設(shè)計解析器，因為業(yè)務(wù)流程不同設(shè)計對賬流程和差錯處理流程。

雖然文章盡可能詳盡，但難免有疏漏，文章完結(jié)了，對賬系統(tǒng)設(shè)計的征途還在繼續(xù)，可以加入學(xué)習(xí)群，繼續(xù)交流探討更多設(shè)計問題 ！卡! 對賬系統(tǒng)殺青。

作者：陳曉光，一個會彈吉他會算命的產(chǎn)品經(jīng)理老司機，微信公眾號：陳天宇宙

本文由 @陳天宇宙 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議