起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識對賬系統從入門到精通
編輯導讀：使用電子支付的時候，我們會對老板說“錢已經付過了”，老板聽到語音播報就能確認，這就是簡單的一個對賬過程。但是一個對賬系統的搭建遠不止這么簡單，本文作者將從十個維度，分析如何構建設計一套不同業務場景下的對賬系統，與你分享。
想必大家對“對賬”這個詞都不陌生，單從字面意思就能略知一二。其實就是字面意思，“對”就是核對，“賬”就是賬目；“對賬”就是核對賬目。
賬目核算是財務工作的必要部分，隨著線上交易體量越來越大或者說對財務自動化線上化的效率提升需求越來越高。為了提升核對效率以及準確性，勢必要將核對業務系統化線上化自動化。那么如何構建設計一套不同業務場景下的對賬系統呢？接下來的“對賬系統設計”十個章節將帶領大家學習如何設計一個對賬系統。
全文分十個部分，共13596字，預計閱讀時間20分鐘
第一部分：對賬概述
1.1 生活中的對賬
日常生活中我們每天都在對賬，比如去餐館吃飯付款，會對老板說一聲“老板，錢付過去了”；老板檢查過收款或者聽到語音播報后回復一聲“好嘞，下次再來”；這就是最簡單的一次對賬。
再比如你在淘寶開了一個店鋪，每個月幾千單的交易，發貨；每次月末都拿著所有的訂單明細和支付寶收款賬戶收款記錄逐筆的做一次核對，保證發過貨的訂單都收到款了，這就是一次更復雜的核對了。
1.2 什么是對賬
- 對賬概括來說就是“賬證實”核對，“賬”就是賬目，“證”就是憑證，“實”就是實際資金
- 核對模式有三種：賬證核對，賬賬核對，賬實核對；確保賬證實兩兩的一致性；比如吃了一碗面點菜單就是原始憑“證”，付了10元錢是“賬”，老板電腦點菜記錄小票10元是“賬”，老板看到賬戶中余額增加了10元是“實”
- 財務范疇來看，證就是會計憑證，比如發票，小票，出貨單，收據，交易系統的支付記錄等都是原始憑證；而賬呢就是財務的賬目，賬務系統的賬務記賬，金蝶的科目余額等都是不同的賬目；而一筆交易會記錄在很多的環節，比如賬務系統，金蝶等
- 另外脫離財務范疇來看，其實賬目本身抽象出來就是數據，商品數據，用戶數據，卡券數據等，那么賬證實需要核對，很多時候很多非財務范疇數據也需要核對，比如今天應到10人實到8人，軍訓時的報數等其實也可以稱為對賬，我們暫且稱為“廣義的對賬”
- 那么我們來為對賬下一個定義：為了確保同一個事務的數據描述在不同場所下的記錄一致而進行的相互之間的一致性比對
1.3 為什么要對賬
- 首先在財務范疇，這是一個必要做的工作
- 另外從業務范疇，現在交易鏈條越來越長，數據在眾多系統之間難免會出現丟失或者差錯，所以為了業務的正常運轉及時發現問題，需要確保系統間數據的一致性
- 從公司的角度，需要確保“不少收一分錢，不多付一分錢”，保證資金的安全，不然賣了多少貨，收了多少錢相互之間誰也不鳥誰，最后全是糊涂賬
- 綜上所述，對賬是必不可少的；對于交易體量巨大的互聯網公司更是必不可少，而且系統化也是必須的，單靠人工難以滿足需要
1.4 幾個常見對賬場景
- 三方支付公司：主要是核對自家的交易記錄和銀行清算數據之間的一致性；銀行清算數據（應收應付）和銀行結算數據（實收實付）的一致性；同樣也要核對與金蝶賬務數據的一致性
- 電商等服務平臺：主要是核對自家的交易數據和三方支付公司或者微信支付寶的清算數據的一致性；三方清算和結算的一致性；三方結算到對公戶實際資金的一致性
- 另外還有紅包：比如用戶支付100元發10個紅包，有6個用戶領了6個一共8元，有4個超時沒領退回給了用戶；那么對于平臺的這個紅包中間賬戶的進出也要核對：{ 用戶充值1筆100元中間戶入了1筆100元中間戶出了10筆100元中間戶被退回4筆2元中間戶退給用戶1筆2元這樣對于中間戶來說100-100+2-2=0 }
- 還有一些其他的領域對賬，比如航司的機票，機票代理商的購票出票，中間券商的上下游之間等等
1.5 常見的對賬模型
- 交易對賬模型：數據之間的按照唯一標識進行一對一，一對多，多對多核對
- 資金對賬模型：將交易數據按照款項類型進行匯總之后進行核對，比如收款，手續費
- 余額調節核對：對系統記賬余額和實際資金賬戶余額在經過在途調整后進行一致性核對比如：系統記賬昨日日終余額100元，截止昨日日終提現中100元；出款賬戶昨日日終200元；此時該賬戶：系統賬100元=出款賬戶200元-100元應付未付；這樣余額是平的，說明資金沒有問題
- 其他更復雜的核對模型：比如多鏈條之間進行關聯核對像三份數據進行一次性比對等，這里不再過多闡述；本系列文章重點介紹的是1和2,至于3會在今后有機會講解，如果有朋友感興趣可以單獨交流
1.6 什么是對賬系統
- 對賬系統就是通過系統解決方案，對需要核對的數據按著設定好的規則進行核對校驗，并產出核對結果；并且可以對核對結果進行對應的差錯處理
- 通俗來說就是傳統上用Excel來通過人工vlookup做的事情，完全交給系統去做，只需要預先配置好規則就行了
- 對于對賬系統來說，最基本應具備以下幾個能力可以便捷的獲取需要核對的原始數據，如平臺數據，三方數據可以對文件數據進行解析或者二次加工，可以靈活配置核對規則，可以查看核對的結果，可以對差異進行追蹤管理和處理，可以對外提供核對結果，可以對外輸出數據
1.7 如何搭建一個對賬系統
- 首先就是要先明確對應的業務模型
- 其次需要抽象出業務的核對模型
- 然后針對核對模型選擇合適的核對方案
- 最后針對核對方案設計系統方案，然后進行研發和上線
第二部分：對賬架構圖
2.1 標準架構
如果企業整體業務架構完整，系統建設完善的情況下建議對賬采用該架構
-
- 有完善的賬務核心和會計核心
- 對賬先完成交易數據和三方清算數據的核對
- 交易完成了賬務和會計層的資金賬記賬
- 匯總清算數據和銀行賬單數據
- 完成平臺資金賬和銀行賬單的資金核對
- 對賬系統通知賬務核心銀行待清算資金的結轉，如下
2.2 簡化架構
如果企業沒有賬務和會計核心；可以通過對賬中心先時間交易數據和三方清算數據的核對；然后匯總清算數據與三方賬單數據核對；保證金業務記賬以及銀行清結算數據的一致性
- 按核對頻率獲取業務支付數據
- T+1或其他頻率獲取三方清算文件和結算文件
- 將清算和結算文件進行解析存儲
- 根據對賬項目配置完成交易數據和清算的核對
- 完成清算數據和結算數據的核對
- 對交易的單邊數據和資金核對差異進行管理和處理
2.3 伽馬金融管理核對架構
資金管理框架的資金賬和銀行賬核對業務架構圖
該圖略，課程里會介紹該體系
核心幾個關鍵點：
- 統一收付平臺收口收款、退款、調撥等資金業務
- 對資金業務統一記賬形成統一資金賬務
- 對集團的資金賬戶進行統一管理
- 余額調節對賬完成資金賬和銀行的核對勾兌
- 賬戶的余額調節表
2.4 伽馬支付核對業務架構
伽馬支付為公眾號案例中心虛擬的支付公司
2.5 通用對賬系統架構
第一篇文章介紹過，我們可以脫離財務范疇，抽象出數據核對的通用架構，對數據逐筆準確性校驗，實時監控；資金期初期末及發生額的資金校驗核對；在這個理念下我們形成如下一個應用范圍更廣的通用架構
第三部分：對賬文件獲取和解析
支付交易的通道提供方，例如微信、支付寶、網聯、銀聯等，都是按照約定頻率和時間提供交易的記錄文件，一般都是2份，一個清算文件“記錄支付明細”；另一個是“結算文件”記錄資金賬戶的實際的資金變動；對于文件的獲取大部分在提供通道時會提供下載接口，另外如果沒有接入下載接口，可以采用人工下載的方式獲得文件，將文件傳到對賬系統獲得對賬數據；本文主要介紹渠道方的對賬文件獲取以及解析和管理。
3.1 對賬文件類型
主流類型還是Excel和txt，本文主要介紹的也是這2種
excel（csv）支付寶,常見支付公司；這類文件最方便查看
txt微信，銀聯個別通道，一些銀行；這類文件很不便于查看
xml報文網聯；這類文件人工很難查看和處理
其他類型銀聯還有一些通道文件
3.2 對賬文件獲取方式
接口獲取通過機構提供的文件查詢和下載接口獲取對賬文件支付寶下載接口。
示例：
人工下載如果技術能力資源不足，或者暫時沒有接入接口，可以采用人工下載的方式，然后在對賬中心上傳對賬文件進行解析
3.3 對賬文件管理
-
- 文件管理方式文件一般存放在對賬系統指定的ftp內，并且對文件夾設定一定的命名規范，通過路徑查詢和下載文件
- 文件管理后臺頁面在后臺頁面查看和下載文件，便于處理和排查對賬問題
3.4 對賬文件解析器配置
對賬文件解析是指將文件里的數據解析到數據庫內，形成數據庫數據，因為文件數據不能直接被系統處理。
原樣解析不改變文件的數據列數和內容，對文件數據保證不減少列數的前提下進行全量解析，可以根據需要增加列內容，比如賬號，對賬時間等。
- 優點：不需要配置解析器，每一個文件研發好固定的解析器進行復用
- 缺點：每個文件類型需要建一套數據表，維護成本高
- 適用：通道少的平臺，一般商戶都僅有微信支付寶，可以采用原樣解析
- 通用板式解析
所有對賬文件數據按照映射關系解析到固定的數據表當中；例如以下的表結構：
例如如下對賬文件：
解析規則應該：
解析器配置管理該部分不做過多介紹，記住一個原則公式：在X列滿足什么條件時將Y列的數解析到數據表的W字段內；在第6第7篇中的對賬項目設計中會有類似的配置頁面設計。
3.5 對賬數據查看
數據解析到數據庫里了，為了便于運營排查問題，還需要做一個查看數據的運營頁面，頁面樣式如下：
第四部分：平臺自有數據的獲取
4.1 平臺對賬數據獲取方式
拿到三方文件賬單數據以后需要與平臺自己的相關數據做核對，比如平臺交易數據與清算數據的核對；平臺賬務數據與銀行賬單數據的核對；平臺自有數據獲取方式常采用如下形式：
- 文件獲取業務系統需要按照要求定期（如每日凌晨2:00）生成文件，按照約定規范進行命名后，將文件推送至對賬系統指定位置（ftp）；這種方式需要各業務系統有一定開發量，業務調整時也需要調整文件的生成策略，維護成本略高
- 接口接收對賬系統提供對賬數據接收接口，類似賬務記賬接口一樣，業務系統按照約定在相應業務節點發送業務數據到對賬中心
- MQ業務方按照要求在交易成功時發送約定格式的MQ消息，對賬系統訂閱該MQ，對MQ進行解析后獲得業務數據
- SQL通過SQL定期撈取業務數據，并將數據存儲到對賬系統數據庫中；該方式調整靈活，可以選擇在業務并發小的凌晨進行
- 人工上傳對于一些采購的外部應用，比如金蝶系統，數據無法通過以上方式獲取的情況下，就需要對賬人員定期下載應用內數據，然后上傳到對賬系統
4.2 數據分類管理
對賬系統數據會越來越多，類型也越老越多，支付數據，卡券數據，訂單數據，三方清算數據，三方結算數據等等；每類數據的數據字段有各有不同；如何對眾多類型數據進行管理呢？下面介紹一個方法：對數據進行分類管理，每類數據單獨設置表結構。
數據分類設置設置數據的大類，或者說是一級分類；就像商品類目一樣管理數據。
設置數據類型在數據分類下面設置數據的子類，并且數據子類關聯數據庫表名，便于存儲數據，查詢數據，對賬取數。
4.3 取數規則配置
配置好了數據分類和類型以及關聯好了數據表之后，接下來就是配置獲取數據的規則了，我們以通過文件或者SQL兩個可選擇的形式獲取數據為例。
為每個數據分類配置取數方式，如果是文件的話就配置文件路徑，如果是SQL的話就配置取數sql，這樣系統會按照任務配置基于取數規則定期獲取對賬的數據，并且插入到數據類型關聯的數據表當中。
第五部分：對賬數據管理
5.1 對賬結果數據
5.1.1 交易對賬結果
支付數據與三方清算的核對，或者其他數據的兩兩核對，會得出核對結果；并且每一組核對都會有一個組別的名字，這個下一節會詳細介紹，比如“會員支付VS微信清算”，核對結果如下表：
我們可以看出來“1,5,6”三條記錄是有問題的，2條是一方有一方沒有，另外一條是都有但金額不一致；這就是交易對賬結果，“對平，單邊，錯賬”，對于對賬有問題的數據需要進行排查找出原因，并進行差錯處理（后面會詳細介紹）。
5.1.2 資金對賬結果
交易對賬結果是源數據本身在某個對賬項目里的核對結果；而資金對賬結果是某資金賬號某交易日的資金收付的一致性；比較平臺的資金賬收付結果與銀行的收付結果是否一致，或者說是銀行自己本身的清算與結算的款項及金額是否一致；
比如：
從對賬結果我們可以看出來，微信在退款和退款手續費存在差異，而發現二者正好正負相抵，原因是微信退款和退款手續費是軋差出現在賬單里的，所以實際上并沒有差異，但是既然已經對出差異，并且排查出原因，就需要對差異進行處理，資金對賬的差異是“長款，短款，應收未收，應付未付”；在確認對賬結果后，會生成差異表，在差異表中對差異進行核銷處理。
5.2 對賬管理
上面我們介紹了交易對賬和資金對賬的核對結果，那么如何存儲差異結果呢？差異結果可以存儲在源對賬數據的表中，也可以單獨存儲
存儲在源對賬表該種方式適合與數據單一的對賬體系，且同一份數據不會在多個對賬項目中進行核對，比如支付數據只與清算核對，這時候數據的核對結果就是默認與另一方的核對情況。
支付數據：1 對平 清算數據：1 對平
存儲在單獨的對賬表中該種方式適合復雜的核對場景，同一份數據會在多個對賬項目中與多組數據完成核對，產生多個對賬結果，比如支付數據與上游的訂單進行核對得出一個對賬結果，支付數據又會與下游的清算數據核對得出另一個對賬結果。
與訂單對：訂單數據：1 對平 支付數據：1 對平與清算對：支付數據：1 單邊 清算數據：無
我們發現支付數據的對賬結果有2個，一個是與訂單的核對的對平，另一個是與清算的核對的單邊，此種情況，我們的對賬結果就需要單獨存儲“某數據在每一個對賬項目組中的核對結果表”，對賬結果有2個，如下：
支付數據對賬結果表
與訂單對：對平
與清算對：單邊
第六部分：交易對賬項目設計
企業業務在不斷變化，新的業務也在不斷出現，對賬數據因為業務的變化也在發生變化；如果接入了新的支付渠道對賬設置也需要新增；如果每次都通過開發實現，那么成本會很高；本篇文章我們將介紹如何實現交易對賬項目的配置化設計，極大的提升對賬項目的管理效率。
6.1 交易對賬項目
做對賬并不是簡單的一方與另一方比對；實際會基于業務情況，存在很多組進行核對；比如與微信的核對，與支付寶的核對等；每一組又可能分成更細的組，比如與微信核對，可以分成微信收款核對，微信退款核對；又可能微信收款有很多賬號，我們又可能會按照微信賬戶進行分組進行核對；例如微信收款一共有兩個微信賬號：微信1，微信2；那么我們可以設置4個對賬的組，如下：
對賬項目1：微信1-收款
對賬項目2：微信1-退款
對賬項目3：微信2-收款
對賬項目4：微信2-退款
對賬項目就是我們設定的核對組；當然以上的對賬項目我們可以簡化成2個
對賬項目1：微信-收款
對賬項目2：微信-退款
具體如何設置核對組，這個因公司而已，因喜好而已，核心目的只要能完成全量的核對即可；對賬項目越少越容易管理，對賬項目越多越清晰，各有利弊。
6.2 對賬項目命名
為了便于管理我們還需要為每個對賬項目命個名字，如何起名這個也看自己喜好；原來在易寶支付，因為對賬組的同學基本都是女生，都是吃貨，所以所有對賬項目都命名稱跟吃相關的“如：工商9876-鹵煮火燒”；命名的一個關鍵原則。
要能從名字中看出具體核對的業務，基于這個原則我們為1中的幾個項目進行命名如下：
對賬項目1：會員購買微信支付-收款
對賬項目2：會員購買微信支付-退款
這樣我們可以清晰的知道對賬項目1是用戶使用微信支付購買會員的收款核對項目。
6.3 對賬項目管理
一個企業可能會存在很多個對賬項目，像原來在某支付，高達幾百個核對項目；為了便于管理，我們就需要一個菜單專門管理對賬項目；示例如下：
該頁面可以查看所有的對賬項目；點擊設置可以進行該對賬項目的配置設置；右上角的新增可以新增新的項目。
6.4 對賬項目新增
在對賬項目列表點擊新增會有一個彈窗可以添加一個對賬項目；新增時需要先填寫基本信息即可，比如對賬項目的名稱，對賬啟用時間，對賬的頻次，對賬的類型等；確定后在對賬項目列表就會有一個新增的項目，點擊設置即可以進入設置頁面，具體看5。
6.5 對賬項目設置
對賬項目的設置主要設置對賬項目的執行時間，核對雙方的對應數據，核對的唯一標識，一些處理規則等；下面是一個基礎的設置頁面；實際工作中需要基于業務場景以及數據特點，對設置器進行一些調整；但是在這配置基礎之上一般難度不大；配置頁面如下：
該配置器最終的實現是：
我們從頁面可以看出來，該配置是設置卡系統的消耗數據與訂單中的消耗記錄進行核對。
- 為數據兩方配置數據的選擇條件
- A方數據為卡數據
- 數據篩選條件是”交易類型=消耗購買”
- B方數據是訂單數據
- 對比設置兩方以訂單號進行核對，金額進行核對
- 訂單數據的金額如果存在多條則進行匯總
- 對賬差異的報警接受人，可以填郵件，辦公賬號等
這樣完成配置后，一個對賬項目就配置完成了；會照著配置的時間每天完成訂單數據和卡數據關于消耗明細的核對。
第七部分：資金對賬項目設計
完成線上支付交易以后，雖然通道方告知支付成功，但是錢是不是真的能給，還需要打一個問號？資金對賬就是應收應付和實收實付之間的核對；什么是應收應付，什么是實收實付呢？哪些數據與之對應呢，這邊文章會詳細介紹。
7.1 資金對賬項目
通過上一篇6我們已經明白對賬項目的概念；今天我們要介紹的資金對賬項目可能更容易理解：一個實體的銀行或者三方資金賬戶為一個資金對賬項目。
所以說資金對賬，我們按照銀行賬戶的維度進行核對；因為在會計科目中銀行賬戶已經是葉子科目了，雖然一個資金賬戶可能有很多業務類型的收款，但是我們這里不再細分了；如果因為公司需要想細分也是可以實現，只需要按著業務類型區分賬戶的資金變動項即可。
這里我們按照一個實體的資金賬戶設置為一個資金對賬項目，比如平臺有微信平臺2個收款賬戶1和2，支付寶平臺兩個收款賬戶3和4，招商對公5，一共5個資金賬戶，那么我們就可以設置5個資金對賬項目，如下：
資金對賬項目1：微信賬戶1
資金對賬項目2：微信賬戶2
資金對賬項目3：支付寶賬戶3
資金對賬項目4：支付寶賬戶4
資金對賬項目5：招商對公戶5
7.2 對賬項目命名
為了便于管理我們還需要為每個對賬項目命個名字，如何起名這個也看自己喜好；命名的一個關鍵原則。
要能從名字中看出具體核對的那個賬戶。
基于這個原則我們為1中的幾個項目進行命名如下：
規則：通道方+通道類型+賬戶號
資金對賬項目1：微信-收款-賬戶1
資金對賬項目2：微信-收款-賬戶2
資金對賬項目3：支付寶-收款-賬戶3
資金對賬項目4：支付寶-收款-賬戶4
資金對賬項目5：招商對公-收款-公戶5
這樣我們可以清晰的知道對賬項目1是微信開的的賬戶號為1的收款賬戶。
對賬文件管理前面已經講過了，每個賬戶次日都會提供相應的清算文件和結算文件；那么文件要跟資金資金對賬項目對應上，最后為對賬文件命名上可以知道對應的所屬賬戶，比如：
規則：通道方+賬號+文件類型+交易日期
資金對賬項目1：wx-1-pay-20210204
7.3 對賬項目管理
一個企業可能會存在很多個資金賬戶；為了便于管理，我們就需要一個菜單專門管理資金對賬項目；示例如下：
該頁面可以查看所有的資金對賬項目，每個項目就是一個實體資金賬戶；點擊設置可以進行該對賬項目的配置設置；右上角的新增可以新增新的項目。
7.4 資金對賬模式選擇
資金對賬我們知道是核對應收應付和實收實付，實收實付我們知道就是銀行實際資金的變動，使用銀行結算賬單即可；那么應收應付的選擇其實有2種方法一個是使用通道的清算文件作為應收應付，另一個是使用平臺的資金賬務作為應收應付。
使用銀行清算文件就是銀行記錄應收應付與實收實付進行核對，但是有個缺陷就是平臺的支付記錄需要跟銀行的清算文件進行核對，所以核對模型如下：
看3中的新增對賬項目中有一個關聯交易對賬，就是看一下平臺的支付記錄和清算文件核對有沒有差異，如果沒有且資金對賬沒差異，那么就沒有問題。
使用平臺資金賬務核對就是如果公司有賬務中心的話，可以直接拿資金變動賬務與實際銀行的資金結算賬單核對，這個不做具體介紹了。
7.5 對賬維度
交易對賬是按照逐筆核對的，資金對賬我們不按照逐筆核對，因為存在軋差以及線下匯入等情況，我們按照費用維度進行核對，就是將應收應付和實收實付解析成款項，對相同款項進行核對，比如收款，收款手續費，退款，退款手續費，打款等。
7.6 對賬項目設置
我們以核對清算數據和結算數據為例，資金對賬項目解析就是將文件里的數據解析匯總到對應的款項上去，知道一個賬戶今天每一個款項上的金額。
該配置器最終的實現是：
我們從頁面可以看出來，該配置是將文件里的數據先通過“條件組”的篩選，然后取目標數據的金額，并且對金額進行運算匯總；比如例子中的第一條就是：取交易狀態=success的數據，取訂單金額作為結算金額
如文件數據
通過原型中的配置條件
條件組：交易狀態=success，
金額：正直匯總訂單金額
我們得到了：收款=100+90=190
其他費用邏輯類似
一定要枚舉一個資金賬戶里的每一類型費用，不能遺漏，不然會出現資金差異。
這樣完成配置后，一個對賬項目就配置完成了；會照著配置的時間每天完成賬單數據的匯總，得到該賬戶每一方數據的每個款項的金額。
第八部分：對賬引擎及對賬結果查看
在對賬執行前還有最后幾個重要的問題沒有解決，那就是對賬的核心處理邏輯是什么；對賬有幾個關鍵的處理引擎。
8.1 對賬連續性控制
對賬不能跨日，比如2號對完才能對3號，如果今天是10號，2號還沒對賬，那么3-9號的賬都不會核對；因為前一天的單邊會循環進入下一天的核對。
8.2 對賬時間控制
如上表，我們需要管理對賬的時間；這里有3個時間概念需要知道：
- 對賬日期：就是對的那一天的賬，也是交易成功時間或者資金變動日期
- 對賬啟用日期：一個對賬項目的第一個對賬日期
- 最后對賬日期：一個對賬項目的最后一個對賬日期
8.3 對賬狀態控制
需要管理可查每一個對賬項目在每一天的對賬狀態。
8.4 對賬任務流程控制引擎和報警
主流程控制對賬項目的任務執行，并在流程成變更更新其他控制環節參數；如果主流程某一個處理失敗那么進行任務報警，人工干預重啟流程。
8.5 對賬核心處理引擎
對賬最核心的引擎就是數據間逐筆核對的過程：
比如經過上面的邏輯，對賬項目1在x日的對賬結果如下：
8.6 對賬結果查看
通過上面的對賬執行，我們就得到了對賬的結果，每個對賬項目的對賬總筆數，總差異。
交易對賬結果該結果是每個對賬項目按筆數核對的結果。
-
- 資金對賬結果該結果是每個資金賬戶對賬項目，按照費用款項核對的結果
好了，得到了對賬結果之后，下一步就是針對不同的差異進行排查和差錯處理了。
第九部分：差錯處理和差錯配置設計
對賬有兩個核心目的，一個是發現錯誤，另一個是改正錯誤；今天我們說一下對賬差異的處理
對賬結果如果有差異，就需要有排查差異的原因，差異原因千奇百怪，但存在必是有原因的，如果登時查不到就先掛著，至少我們知道了有一個差異待處理；（下文提到的差異我們代表交易對賬對出的單邊或者錯賬以及資金對賬對出的資金長短款）
9.1 關于差錯處理
差錯處理其實就是消除差異的過程：
- 發現差異：對賬結果對出了差異
- 排查差異原因：排查差異原因，是掉單了，bug，時間差等具體的原因
- 按照實際處理差異：找到原因后對差錯進行處理，掉單的補單，bug就修復，時間差的話就不用處理，等待第二天對平
- 消除差異：這一步是在對賬系統對差異進行標記處理，說明差異已經排除了
9.2 交易差錯處理
交易對賬是數據的逐筆核對，會出現三類結果：
- 對平：無需處理
- 單邊：需要處理
- 錯賬：需要處理
差錯列表：
對賬的差異會單獨出現在差異列表等待處理。
點擊處理，彈窗選擇處理類型，提交之后可以走一個流程，也可以直接處理完成。
差錯處理類型：
就是我們用什么樣的方式消除了差異，比如如果是銀行成功，我方平臺掉單了，那么就進行補單，補完后就對平了，這樣也是保證用戶的權益；這時因為是我方掉單了，所以對賬結果是銀行單邊；等我方補完單后，銀行的這筆單邊就出錯了“平臺補單”。
我們可以預設一些差錯處理類型，形成每個類型的處理流程，便于在處理的時候直接選擇使用。
差錯處理接口：
有些差錯處理是可以讓相關系統包裝接口直接進行處理的；比如平臺掉單補單，可以讓訂單系統包裝一個補單接口，對賬系統調用進行補單。
9.3 資金差錯處理
資金對賬的差異是費用的差異，收款，退款，手續費；在賬戶對完結果后，如果確認不是解析等技術層面的差異，可以對結果進行一個確認，確認之后差異會生成長短款數據，后面對資金進行長短款處理時就對長短款進行核銷。
資金對賬結果確認：
長短款管理：
比如微信的一個資金賬戶，資金同事直接在微信商戶后臺操作了一筆轉賬，或者用戶直接用微信轉給給了這個賬戶，這時候都會出現微信收款比平臺收款多的情況。
微信賬單收款1000———-平臺記賬收款900
此時資金對賬就會有100元的長款，就是微信多收了。
確認結果以后，長短款模塊就會生成一筆該賬戶的 100元長款記錄；長款款記錄要有賬戶信息，對賬日期信息，費用信息等。
長短款核銷：
對于生成的長短款差異，同時也會生成賬務憑證，算是一個掛賬憑證，為了讓賬務是平衡的；后續針對每筆資金差異進行排查核銷；比如如果確認是人工微信做了轉賬，那么可以直接核銷“資金人工轉出確認”，直到長短款沒有待核銷長短款，我們的資金就是準確的了。
9.4 其他對賬場景案例
除了常見的三方支付，電商等的普通的在線交易的對賬，還有一些其他領域的核對，雖然行業不同，交易數據特點不同，但是對賬的本質是相通的；唯一不同的就是交易數據的結構千奇百怪，導致數據的解析，核對邏輯會有變化，下面我們舉幾個場景。
紅包中間賬戶對賬：
我們都知道，紅包場景算是比較復雜的，因為發紅包的支付一筆紅包款，會發出幾十個紅包，最后有些紅包沒被領取又退回了，這個核對場景最復雜的是一對多，我們站在紅包的中間賬戶角度看這個交易場景，對中間賬戶的進出進行核對。
案例：用戶A用招商銀行卡通過紅包發了10個紅包共100元，3天后一共領了7個80元，退回20元到招商銀行卡。
- 紅包發放充值流入：+100元
- 紅包流出付款流出：一共8筆共80元
- 超時未領取退回流出：一筆20元
你覺得該如何做核對呢？
機票代理對賬：
我們都知道去哪網，攜程，飛豬，這些賣機票的平臺；可能不太清楚這些平臺上的眾多機票代理商，他們的交易體量也是非常巨大了，每個月賣出幾萬賬票的很多；我幫助很多機票代理商實現了自動化對賬的系統建設；他們的對賬相對來說是非常復雜的，在鶴壁有一家代理商是從深圳搬過來的，他們一共有5個財務每天進行對賬，5個財務的年薪資支出有二三十萬之多，可想而知如果實現系統化對賬，能節省多少費用。
機票代理商的交易模型：
從模型中我們可以看出來，主要是有三個環節：
- 售票平臺代理商入住后，就像淘寶已經，會有個結算賬戶，記錄賣票記錄和結算款記錄，賣出去10張票，平臺抽取傭金剩余部分結算給代理商結算賬戶；平臺會提供2分文件：機票銷售明細文件，結算明細文件；這兩份數據要做核對
- 機票代理商機票代理商有一個機票管理系統，購買的第三方服務公司的，可以記錄在每個平臺的賣票情況以及付款出票情況
- 付款通道機票代理商要賣機票需要向航司去買，賣票付款的話航司簽約了一些三方支付公司，比如支付寶，易寶支付，代理商選擇這些付款通道進行簽約向航司付款，先把錢充值到指定付款賬戶中，易寶支付是航旅行業覺得的第一名，付款通道會給機票代理付款文件
機票代理的對賬模型所以對賬我們要對這幾個維度售票平臺的售票明細與結算明細核對售票平臺的售票明細與代理商系統的售票明細核對代理商系統的付款明細與通道的付款賬單核對。
機票行業數據特點這個行業的文件是很復雜的，特別是幾家ota平臺，文件形式各不相同，一個用戶買7張票，一個訂單對應7個人，對應7張票；有的平臺的一個訂單一票記錄，票號塞在一個單元格里，有的平臺是一張票一條數據….大家可以思考一下，一下對賬怎么對呢：按照訂單號對？還是按照票號對？
還有一個行業是券商對賬：
什么是券商呢，我們在招商信用卡，中移動積分商城里兌換的商家優惠券其實不是直接由商家提供的，而是中間券商；就像電子支付一樣，中間券商匯集采購商家的優惠券，然后通過接口提供售賣給信用卡平臺或者中移動等平臺；用戶在中移動或者信用卡商城兌換后到商家去消費，然后進行層層的核銷和結算。
招商銀行和中移動與券商結算，券商再把結算款結算給商家。
這個對賬模式我就不再細說了，大家可以思考一下如何建設券商的對賬系統。
第十部分：銀行存款余額調節對賬
你有賬戶里有多少錢，有多少錢可用？這個問題是不是很莫名其妙，錢都是我的，當然都能用啊！那再換個說法，如果你10號會發2萬工資，4號要支付1萬房貸，現在銀行卡里還剩1.1萬，如果你對象說有急事3號要先用你2000塊錢，你怎么辦，在每次要花錢的時候，是不是有一個經典問題困擾著你，我是誰，我在那？當然不是，“我還有多少錢能用？” ！這就是我們今天要解決的問題，銀行賬戶還有多少錢，還有多少錢能用 ！
10.1 什么是余額調節表
銀行存款余額調節表，就是將企業的賬面余額和銀行的賬單余額，經過未達款項調整后，核對調整余額是否一致的核對工具；驗證調節后的存款余額是否相等的核對方法；如果想等則表明企業和銀行的賬目都沒有問題；反之，則說明記賬有錯誤，或者有未達賬沒找到；需要進一步查明原因，進行修正；余額調節表調整后的余額是銀行存款當日可以動用的最大值。
日期：xxxxxx ，賬戶：銀行存款-工行1122
未達是怎么產生的呢，比如打款一般企業先扣賬，然后走審批；如果在對賬時還沒完成審批，這時就會有銀行還沒到達，但企業已操作賬務；另一個場景就是用戶直接線下匯入賬戶的資金，企業賬務還沒進行記賬，對企業賬來說就形成未達；
特別提醒要區分資金對賬的應收應付和實收實付概念；未達這里是個余額對賬的概念；應收付是資金清算的概念。
10.2 如何編制余額調節表
就如第一部分介紹的概念，編制余額調節表就是在兩方余額之上進行未達賬的加減，獲得調整余額。
第一步：
獲得兩邊的余額作為基礎余額以及賬務明細作為未達素材；企業賬從賬務系統獲得資金賬明細，銀行賬從銀行獲得對賬單并解析入庫；待勾兌。
第二步：
通過可勾兌唯一表示，勾兌雙方賬務明細；未匹配上的明細即是對方未達。
第三步：
按照調整公式計算出調整余額。
銀行調整余額=銀行對賬單存款余額+企收銀未收－企付銀未付
企業調整余額=企業賬面銀行存款余額+銀收企未－銀付企未付
調節后，如果雙方余額相等，一般可以認為雙方記賬沒有差錯。調節后雙方余額仍然不相等時，原因還是兩個，要么是未達賬項未全部查出，要么是一方或雙方賬簿記錄還有差錯。無論是什么原因，都要進一步查清楚并加以更正，一定要到調節表中雙方余額相等為止。
調節后的余額既不是企業銀行存款日記賬的余額，也不是銀行對賬單的余額，它是企業銀行存款的真實數字，也是企業當日可以動用的銀行存款的極大值。
10.3 如何余額調節表系統
余額調節表系統就是通過系統實現賬戶的日末賬戶余額調節核對；要想實現系統化要解決一下問題。
資金賬：
平臺要對支付交易和打款進行規范的資金賬記錄，企業通過oa走的其他費用，例如報銷，補貼等也要進行資金賬記錄；資金調撥也要進行資金賬記錄；所以綜合來講需要有平臺所有賬戶的所有資金賬務的系統記賬處理；那么就是需要一個賬務系統，這個后面會講，這里就不在贅述。
賬戶管理：
對平臺所有銀行存款或者其他類賬戶，如微信支付寶賬戶進行通過管理，可以通過財務主數據也可以在對賬系統維護；并且最好可以關聯會計科目；最后就是要設定賬戶的余額調節啟用日期。
賬戶的期初余額：
在賬戶管理里設定賬戶的期初余額，系統會基于該期初余額加減資金賬的明細獲得任何一個時間區間的期初，發生，期末；所以該期初余額一定要正確。
獲取銀行賬單：
通過人工上傳或者銀企直聯以及三方接口，每日獲取上一期的對賬單，并解析入庫，用于進行資金勾兌。
企業資金賬單：
從資金賬獲取本次核對日期要核對的資金賬明細，備用，用戶與銀行賬進行勾兌。
核對：
執行企業賬單和銀行賬單的勾兌，為勾兌上的認為是對方未達，進入余額調節表。
獲取余額：
從賬戶余額表獲取企業賬該賬戶的余額，用銀行對賬單或者接口查詢獲得銀行對應賬戶的日終余額。
余額調節表結果：
結果是基于賬戶維度，得到每個賬戶的日終調整余額兩邊的核對結果以及調整明細。
詳情：
好的，對賬系列我們就完結了，對賬系統大家會設計了么。
工作當中，每個行業，每家公司的業務場景和業務模型都會有差異，對賬模式以及系統設計也需要相應的針對性設計，在通用對賬的基礎上進行調整，比如因為數據結構特點設計解析器，因為業務流程不同設計對賬流程和差錯處理流程。
雖然文章盡可能詳盡，但難免有疏漏，文章完結了，對賬系統設計的征途還在繼續，可以加入學習群，繼續交流探討更多設計問題 ！卡! 對賬系統殺青。
作者：陳曉光，一個會彈吉他會算命的產品經理老司機，微信公眾號：陳天宇宙
本文由 @陳天宇宙 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
專欄作家
陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
1111