想必大家對“對賬”這個詞都不陌生，單從字面意思就能略知一二；其實就是字面意思；“對”就是核對，“賬”就是賬目；“對賬”就是核對賬目；賬目核算是财務工作的必要部分，随着線上交易體量越來越大或者說對财務自動化線上化的效率提升需求越來越高；為了提升核對效率以及準确性，勢必要将核對業務系統化線上化自動化；那麼如何構建設計一套不同業務場景下的對賬系統呢？

希望在做對賬相關系統的産品同學可以參考借鑒以及交流溝通

• 生活中的對賬

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

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

• 什麼是對賬

1. 對賬概括來說就是“賬證實”核對，“賬”就是賬目，“證”就是憑證，“實”就是實際資金

2. 核對模式有三種：賬證核對，賬賬核對，賬實核對；确保賬證實兩兩的一緻性；比如吃了一碗面點菜單就是原始憑“證”，付了10元錢是“賬”，老闆電腦點菜記錄小票10元是“賬”，老闆看到賬戶中餘額增加了10元是“實”

3. 财務範疇來看，證就是會計憑證，比如發票，小票，出貨單，收據，交易系統的支付記錄等都是原始憑證；而賬呢就是财務的賬目，賬務系統的賬務記賬，金蝶的科目餘額等都是不同的賬目；而一筆交易會記錄在很多的環節，比如賬務系統，金蝶等

4. 另外脫離财務範疇來看，其實賬目本身抽象出來就是數據，商品數據，用戶數據，卡券數據等，那麼賬證實需要核對，很多時候很多非财務範疇數據也需要核對，比如今天應到10人實到8人，軍訓時的報數等其實也可以稱為對賬，我們暫且稱為“廣義的對賬”

5. 那麼我們來為對賬下一個定義：為了确保同一個事務的數據描述在不同場所下的記錄一緻而進行的相互之間的一緻性比對

• 為什麼要對賬

1. 首先在财務範疇，這是一個必要做的工作

2. 另外從業務範疇，現在交易鍊條越來越長，數據在衆多系統之間難免會出現丢失或者差錯，所以為了業務的正常運轉及時發現問題，需要确保系統間數據的一緻性

3. 從公司的角度，需要确保“不少收一分錢，不多付一分錢”，保證資金的安全，不然賣了多少貨，收了多少錢相互之間誰也不鳥誰，最後全是糊塗賬

4. 綜上所述，對賬是必不可少的；對于交易體量巨大的互聯網公司更是必不可少，而且系統化也是必須的，單靠人工難以滿足需要

• 幾個常見對賬場景

1. 三方支付公司：主要是核對自家的交易記錄和銀行清算數據之間的一緻性；銀行清算數據（應收應付）和銀行結算數據（實收實付）的一緻性；同樣也要核對與金蝶賬務數據的一緻性

2. 電商等服務平台：主要是核對自家的交易數據和三方支付公司或者微信支付寶的清算數據的一緻性；三方清算和結算的一緻性；三方結算到對公戶實際資金的一緻性

3. 另外還有紅包：比如用戶支付100元發10個紅包，有6個用戶領了6個一共8元，有4個超時沒領退回給了用戶；那麼對于平台的這個紅包中間賬戶的進出也要核對：

   { 用戶充值1筆100元

   中間戶入了1筆100元

   中間戶出了10筆100元

   中間戶被退回4筆2元

   中間戶退給用戶1筆2元

   這樣對于中間戶來說100-100 2-2=0 }

4. 還有一些其他的領域對賬，比如航司的機票，機票代理商的購票出票，中間券商的上下遊之間等等

• 常見的對賬模型

1. 交易對賬模型：數據之間的按照唯一标識進行一對一，一對多，多對多核對

2. 資金對賬模型：将交易數據按照款項類型進行彙總之後進行核對，比如收款，手續費

3. 餘額調節核對：對系統記賬餘額和實際資金賬戶餘額在經過在途調整後進行一緻性核對

   比如：系統記賬昨日日終餘額100元，截止昨日日終提現中100元；出款賬戶昨日日終200元；此時該賬戶：系統賬100元=出款賬戶200元-100元應付未付；這樣餘額是平的，說明資金沒有問題

4. 其他更複雜的核對模型：比如多鍊條之間進行關聯核對像三份數據進行一次性比對等，這裡不再過多闡述；本系列文章重點介紹的是1和2,至于3會在今後有機會講解，如果有朋友感興趣可以單獨交流

• 什麼是對賬系統

1. 對賬系統就是通過系統解決方案，對需要核對的數據按着設定好的規則進行核對校驗，并産出核對結果；并且可以對核對結果進行對應的差錯處理

2. 通俗來說就是傳統上用Excel來通過人工vlookup做的事情，完全交給系統去做，隻需要預先配置好規則就行了

3. 對于對賬系統來說最基本應具備以下幾個能力

   可以便捷的獲取需要核對的原始數據，如平台數據，三方數據

   可以對文件數據進行解析或者二次加工

   可以靈活配置核對規則

   可以查看核對的結果

   可以對差異進行追蹤管理和處理

   可以對外提供核對結果

   可以對外輸出數據

• 如何搭建一個對賬系統

1. 首先就是要先明确對應的業務模型

2. 其次需要抽象出業務的核對模型

3. 然後針對核對模型選擇合适的核對方案

4. 最後針對核對方案設計系統方案，然後進行研發和上線

01

标準業務架構

如果企業整體業務架構完整，系統建設完善的情況下建議對賬采用該架構

有完善的賬務核心和會計核心

對賬先完成交易數據和三方清算數據的核對

交易完成了賬務和會計層的資金賬記賬

彙總清算數據和銀行賬單數據

完成平台資金賬和銀行賬單的資金核對

對賬系統通知賬務核心銀行待清算資金的結轉，如下

02

簡化架構

如果企業沒有賬務和會計核心；可以通過對賬中心先時間交易數據和三方清算數據的核對；然後彙總清算數據與三方賬單數據核對；保證金業務記賬以及銀行清結算數據的一緻性

1. 按核對頻率獲取業務支付數據

2. T 1或其他頻率獲取三方清算文件和結算文件

3. 将清算和結算文件進行解析存儲

4. 根據對賬項目配置完成交易數據和清算的核對

5. 完成清算數據和結算數據的核對

6. 對交易的單邊數據和資金核對差異進行管理和處理

03

伽馬金融資金管理核對架構

資金管理框架的資金賬和銀行賬核對業務架構圖

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

核心幾個關鍵點

1. 統一收付平台收口收款、退款、調撥等資金業務

2. 對資金業務統一記賬形成統一資金賬務

3. 對集團的資金賬戶進行統一管理

4. 餘額調節對賬完成資金賬和銀行的核對勾兌

5. 賬戶的餘額調節表

04

伽馬支付核對業務架構

伽馬支付為公衆号案例中心虛拟的支付公司

05

通用對賬系統架構

第一篇文章介紹過，我們可以脫離财務範疇，抽象出數據核對的通用架構，對數據逐筆準确性校驗，實時監控；資金期初期末及發生額的資金校驗核對；在這個理念下我們形成如下一個應用範圍更廣的通用架構

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

01

對賬文件類型

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

excel（csv）

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

txt

微信，銀聯個别通道，一些銀行；這類文件很不便于查看

xml報文

網聯；這類文件人工很難查看和處理

其他類型

銀聯還有一些通道文件

02

對賬文件獲取方式

• 接口獲取

  通過機構提供的文件查詢和下載接口獲取對賬文件

  支付寶下載接口示例

• 人工下載

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

03

對賬文件管理

文件管理方式

文件一般存放在對賬系統指定的ftp内，并且對文件夾設定一定的命名規範，通過路徑查詢和下載文件

文件管理後台頁面

在後台頁面查看和下載文件，便于處理和排查對賬問題

04

對賬文件解析器配置設計

對賬文件解析是指将文件裡的數據解析到數據庫内，形成數據庫數據，因為文件數據不能直接被系統處理

• 原樣解析

  不改變文件的數據列數和内容，對文件數據保證不減少列數的前提下進行全量解析，可以根據需要增加列内容，比如賬号，對賬時間等

• 優點：不需要配置解析器，每一個文件研發好固定的解析器進行複用

• 缺點：每個文件類型需要建一套數據表，維護成本高

• 适用：通道少的平台，一般商戶都僅有微信支付寶，可以采用原樣解析

• 通用闆式解析

所有對賬文件數據按照映射關系解析到固定的數據表當中；例如以下的表結構

例如如下對賬文件

解析規則應該

• 解析器配置管理

  該部分不做過多介紹，記住一個原則公式：在X列滿足什麼條件時将Y列的數解析到數據表的W字段内；在第6第7篇中的對賬項目設計中會有類似的配置頁面設計

05

對賬數據查看

數據解析到數據庫裡了，為了便于運營排查問題，還需要做一個查看數據的運營頁面，頁面樣式如下

01

平台對賬需求獲取方式

拿到三方文件賬單數據以後需要與平台自己的相關數據做核對，比如平台交易數據與清算數據的核對；平台賬務數據與銀行賬單數據的核對；平台自有數據獲取方式常采用如下形式

• 文件獲取

  業務系統需要按照要求定期（如每日淩晨2:00）生成文件，按照約定規範進行命名後，将文件推送至對賬系統指定位置（ftp）；這種方式需要各業務系統有一定開發量，業務調整時也需要調整文件的生成策略，維護成本略高

• 接口接收

  對賬系統提供對賬數據接收接口，類似賬務記賬接口一樣，業務系統按照約定在相應業務節點發送業務數據到對賬中心

• MQ

  業務方按照要求在交易成功時發送約定格式的MQ消息，對賬系統訂閱該MQ，對MQ進行解析後獲得業務數據

• SQL

  通過SQL定期撈取業務數據，并将數據存儲到對賬系統數據庫中；該方式調整靈活，可以選擇在業務并發小的淩晨進行

• 人工上傳

  對于一些采購的外部應用，比如金蝶系統，數據無法通過以上方式獲取的情況下，就需要對賬人員定期下載應用内數據，然後上傳到對賬系統

02

數據分類管理

對賬系統數據會越來越多，類型也越老越多，支付數據，卡券數據，訂單數據，三方清算數據，三方結算數據等等；每類數據的數據字段有各有不同；如何對衆多類型數據進行管理呢？下面介紹一個方法：對數據進行分類管理，每類數據單獨設置表結構

數據分類設置

設置數據的大類，或者說是一級分類；就像商品類目一樣管理數據

設置數據類型

在數據分類下面設置數據的子類，并且數據子類關聯數據庫表名，便于存儲數據，查詢數據，對賬取數

03

取數規則配置

配置好了數據分類和類型以及關聯好了數據表之後，接下來就是配置獲取數據的規則了，我們以通過文件或者SQL兩個可選擇的形式獲取數據為例

為每個數據分類配置取數方式，如果是文件的話就配置文件路徑，如果是SQL的話就配置取數sql，這樣系統會按照任務配置基于取數規則定期獲取對賬的數據，并且插入到數據類型關聯的數據表當中

數據分類以及數據表在後面的對賬項目規則設置起到了非常重要的作用

對賬數據

通過前幾篇文章我們已經了解了什麼是對賬，對賬外部數據和内部數的獲取方式以及查看方式，除了這兩類對賬源數據，還有一類數據：對賬結果數據；對賬結果數據也需要存儲和管理，以及相應的用途

01

對賬結果數據

• 交易對賬結果

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

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

• 資金對賬結果

交易對賬結果是源數據本身在某個對賬項目裡的核對結果；而資金對賬結果是某資金賬号某交易日的資金收付的一緻性；比較平台的資金賬收付結果與銀行的收付結果是否一緻，或者說是銀行自己本身的清算與結算的款項及金額是否一緻；比如

從對賬結果我們可以看出來，微信在退款和退款手續費存在差異，而發現二者正好正負相抵，原因是微信退款和退款手續費是軋差出現在賬單裡的，所以實際上并沒有差異，但是既然已經對出差異，并且排查出原因，就需要對差異進行處理，資金對賬的差異是“長款，短款，應收未收，應付未付”；在确認對賬結果後，會生成差異表，在差異表中對差異進行核銷處理

02

對賬管理

上面我們介紹了交易對賬和資金對賬的核對結果，那麼如何存儲差異結果呢？

差異結果可以存儲在源對賬數據的表中，也可以單獨存儲

• 存儲在源對賬表

  該種方式适合與數據單一的對賬體系，且同一份數據不會在多個對賬項目中進行核對，比如支付數據隻與清算核對，這時候數據的核對結果就是默認與另一方的核對情況

  支付數據：1 對平 清算數據：1 對平

• 存儲在單獨的對賬表中

  該種方式适合複雜的核對場景，同一份數據會在多個對賬項目中與多組數據完成核對，産生多個對賬結果，比如支付數據與上遊的訂單進行核對得出一個對賬結果，支付數據又會與下遊的清算數據核對得出另一個對賬結果

  與訂單對：訂單數據：1 對平 支付數據：1 對平與清算對：支付數據：1 單邊 清算數據：無

• 我們發現支付數據的對賬結果有2個，一個是與訂單的核對的對平，另一個是與清算的核對的單邊，此種情況，我們的對賬結果就需要單獨存儲“某數據在每一個對賬項目組中的核對結果表”，對賬結果有2個，如下

支付數據對賬結果表

與訂單對：對平

與清算對：單邊

對賬配置化

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

01

交易對賬項目

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

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

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

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

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

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

對賬項目1：微信-收款

對賬項目2：微信-退款

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

02

對賬項目命名

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

要能從名字中看出具體核對的業務

基于這個原則我們為1中的幾個項目進行命名如下

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

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

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

03

對賬項目管理

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

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

04

對賬項目新增

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

05

對賬項目設置

對賬項目的設置主要設置對賬項目的執行時間，核對雙方的對應數據，核對的唯一标識，一些處理規則等；下面是一個基礎的設置頁面；實際工作中需要基于業務場景以及數據特點，對設置器進行一些調整；但是在這配置基礎之上一般難度不大；配置頁面如下

該配置器最終的實現是

我們從頁面可以看出來，該配置是設置卡系統的消耗數據與訂單中的消耗記錄進行核對

• 為數據兩方配置數據的選擇條件

• A方數據為卡數據

• 數據篩選條件是”交易類型=消耗購買”

• B方數據是訂單數據

• 對比設置兩方以訂單号進行核對，金額進行核對

• 訂單數據的金額如果存在多條則進行彙總

• 對賬差異的報警接受人，可以填郵件，辦公賬号等

這樣完成配置後，一個對賬項目就配置完成了；會照着配置的時間每天完成訂單數據和卡數據關于消耗明細的核對

·················END·················

不會彈吉他的算命先生不是個好産品-您好我是陳曉光，一個會彈吉他會算命的産品經理老司機，為您提供優質的産品内容和服務，(我的 陳曉光)

北京十幾年，曾經是一名創業者，開過三家公司，服務過美團，糯米，借貸寶；拿過千萬級融資；做了十年産品，大小廠都奮鬥過

未來5年将“前十年在産品領域的所見·所學·所做·所想”分享給讀者