第一章：對賬系統概覽
一、什麼是對賬？
1.生活中的對賬場景 - 煎餅攤老闆的故事
對賬在我們的生活中非常常見。
舉個例子：下班回家路上，你有點餓，看到路邊有個煎餅。於是過去買了個煎餅，老闆把煎餅遞給你，然後指著牆上的二維碼貼紙說「8 塊」。
你拿出手機，掃碼支付 8 元后，和老闆說「8 塊 ，過去啦」。緊接著老闆聽到自己手機播報說「微信收款：8元。」老闆心裡確認了這筆錢到賬了。你宣稱「已付8元」，老闆收款賬戶確認「已收8元」，這就是一次最簡單的對賬。
2.互聯網公司中常見的對賬場景 - 支付對賬系統
在互聯網公司中，只要帶交易，就需要對賬。不論是售賣實體物品的淘寶店、虛擬物品的在線課程，還是銷售各種會員服務的視頻網站，都需要對賬，對賬是整個交易流程中最後一道安全防線。
我們來舉個淘寶店的例子，為了方便理解，這家淘寶店，只賣一種杯子，一個杯子20元，一個月只有 1 單生意，1 單賣1個杯子。
當用戶下單購時，打印機自動打印出一份發貨訂單，老闆根據這份紙質訂單到庫房揀貨，然後交給快遞公司發貨。用戶收到杯子，確認收貨。20元轉入老闆的賬戶。
（1）發貨次日，老闆盤點庫房，發現少了一個杯子。於此同時，發現自己的賬戶裡多了20元，正好是1個杯子的售價。這個對賬過程叫賬實核對。
（2）老闆根據打印的訂單對賬，手裡有一張紙質訂單，訂單總額20元，再看自己賬戶金額，多了20元。這個對賬過程叫賬證對賬。
（3）月底對賬時，發現賬戶只多了10元，於是老闆翻出全部賬本，發現訂單賬多了20元，快遞發貨賬因發貨減少10元（快遞費）。一計算，收入20元（增加），快遞費10元（減少），即賬戶賬應增加10元。這個對賬叫賬賬對賬。
3.對賬方式 - 杯子店出現的三種對賬方式
（1）賬實對賬：是指我們記錄的賬與實物資產的實際數量進行對賬。
（2）賬證對賬：是指將自己的賬本與記賬憑證進行核對。一般記賬憑證由與你業務合作的第三方公司提供，在上面的杯子店的例子裡，記賬憑證由淘寶提供（訂單）。
（3）賬賬對賬：是指在上下游相互關聯的賬本之間進行對賬。在整個交易過程中，一般會涉及上下游多套賬，上游比如外部進貨賬、內部採購賬，下游比如快遞發貨賬、第三方服務費等。這些賬和總賬之間有非常多的關聯性，所以一般賬賬核對，通常用於修正內部賬的數據不一致。
「賬證實」是對賬的基礎，後面我們會結合實例來講解在對賬系統搭建的過程中，如何把「賬證實」融入進對賬系統中。
二、為什麼要對賬
1.對賬是整個支付系統中，最後一道安全防線。是交易流程中重要的糾錯機制。
2.避免意外和人為錯誤發生
（1）意外錯誤：網絡穩定性、內部系統（訂單、支付、風控）的健壯性。
（2）人為錯誤：人為操作失誤、上游、內部惡意修改等行為。
3.對賬是財務流程中重要的一環，特別是當交易量上萬/天，人工手動對賬毫無可能時，為了避免訂單差錯越積越多，變成糊塗賬，我們需要日日結清，對賬也是保證公司財務健康的必要環節。
第二章：對賬系統的架構
無論多麼複雜、多麼宏大的對賬系統，都是由一個個「賬與賬」之間最簡單的對比核查構成。我們只要搞清楚每一組賬怎麼核對，然後再將此邏輯應用至多組賬即可，萬變不離其宗。
為了縮減案例複雜度，方便大家理解，本案使用大多數電商都會接入的「支付寶」、「微信」兩個支付渠道來舉例。
其實不論是接入互聯網風格的「支付寶」，還是接國企風格的「銀行」，又或者是海外支付渠道「paypal」都是類似的。他們除了接口、文件格式、鑑權等細節上的差異外，在抽象層面，對賬邏輯是一致的，一通百通。
一、如何搭建一套對賬系統
1.設置對賬的目標賬
對賬的核心是在不同系統中找到記錄相同事件的賬本，用這些關聯賬進行對比，發現其中的差錯。
比如
（1）我方後臺訂單系統中的日結算金額與第三方支付系統中的日結算金額進行對比。
（2）我方庫存系統中的庫存量與我方訂單系統中訂單中發出的貨品數量進行對比
2.獲得賬單數據（賬單獲取模塊）
（1）出賬時間：各渠道日結算賬單生成時間不同，有凌晨生成的，也有上午9點生成的。搞清楚出賬時間，設定好抓取/下載時間，讓系統自動下載（或手動下載後再上傳至對賬系統）。
（2）賬單文件格式：各渠道賬單格式並不統一，有 csv、xml、txt、json 等，針對不同渠道，設定好對應的格式解析程序。
3.賬單格式標準化（數據標準化模塊）
各渠道賬單針對同一個數據有不同的字段和命名方式。比如同一個「訂單號」，支付寶叫「商戶訂單號」，我方系統中同樣的數據叫「商城訂單號」。再比如，同一個訂單的支付金額，支付寶中叫「商家實收」，我方系統中叫「結算金額」。他們雖然命名不同，實際上是同一個數據在兩套系統的反映。
所以我們首相要將來自支付寶、微信、銀行系統、銀聯、paypal等三方機構的賬單數據統一口徑，使數據可讀，可對比。這個過程我們叫賬單數據標準化。
4.賬單核對（賬單核對模塊）
這一步大家一定要結合自己公司的業務邏輯來設計，不同的業務邏輯、財務管理方式會有不同的設計方法。但最基本的宗旨不會變，找出兩套系統中對同一個訂單的數據，對比這兩個數據是否一致，找出差異，標記差異，在下一個模塊處理。賬單核對的細節，我們在第六章展開講。
5.對賬單差錯處理（差異處理模塊）
如果差錯是可預見和可自動修復的，我們可使用機器自動處理，比如經典的「跨日支付」問題，訂單創建在當日23:59分，支付時間在次日00:01。這時，第三方支付渠道對應我方系統中訂單的支付信息，會在T+1日出現。這種情況，等待拿到次日賬單後，再對一次即可解決。
如果差錯不可以自動處理，那麼進入人工處理流程。人工處理首先要對比兩組數據，找到問題所在，再手動執行解決方案，使兩邊對平。如果當下無法對平，可選擇「掛起」，暫時存檔差錯，未來合適的時間再解決。關於差錯處理，我們會在第七章詳解。
第三章：對賬文件獲取
對賬文件獲取是整個對賬系統的起點，我們首先要將支付寶、微信、銀行、銀聯、第三方支付等支付渠道的對賬單下載到本地，解析入庫後，才能進行後續對賬動作。每個支付渠道都有自己的結算週期和結算文件生成時間，以及文件格式，我們首先要查看支付渠道文檔，把這些問題搞清楚。
一、對賬文件下載
目前常見的渠道對賬單下載方式主要有這幾種
- 調用 API 下載賬單：這種方式簡單幹淨，設定好接口鑑權及每日下載時間即可。非常友好，支付寶、微信均為此種方式。
- SFTP/FTP 下載賬單：也是比較簡單直接的獲取方式，設定好本地目錄及命名邏輯後，直接下載即可。
- 手動下載：少數渠道仍然需要手動下載，雖然也可以寫前端自動代碼去拿，但總歸不太直接。
二、對賬文件獲取時間
每一家支付渠道，會根據自己的情況，約定日對賬單生成時間，我們要搞清楚每一家支付渠道生成賬單的時間，然後在這個時間之後一段時間再去拉賬單，才能高效的讓對賬系統運轉起來。
比如：微信支付，一般在次日上午9點左右出賬單，我們10點以後拉取微信支付的對賬單會比較合適。
更多信息還請前往渠道支付對應的官網文檔中確認。總會有些特殊情況，比如銀聯的清分時間就跟大家不同，所以一定要看清文檔。各支付渠道文檔，見本文最後擴展資料部分。
三、對賬文件的格式
不同渠道對賬文件的格式也不同，總體來說分為 CSV、json、txt、xml等格式。下面列舉兩類常見文件格式，供大家參考。
1.微信對賬單： txt 文件
2.支付寶對賬單：csv 格式
四、對賬文檔 API 獲取
通過 API 獲取支付機構對賬文件，本文文末附支付渠道文檔
微信支付下載交易賬單的API 文檔
第四章：對賬文件標準化入庫
每天從各第三方支付渠道獲取的對賬文件均為原始對賬數據，一定要保存好這些原始文件，方便在未來整個支付或對賬系統出錯時，可以追根溯源。
一、原始對賬文件標準化命名
我們需要將各個渠道的原始對賬文件根據自身屬性來重新統一命名，方便未來查找與使用。
例：「業務類型_支付渠道_清算日期_序列號.文件格式：alipay_20210721_03.csv」
當然，我們要根據自己公司接入的所有支付渠道的情況，更宏觀的找到一套合適的命名方法。
二、對賬文件數據統一標準化
由於各支付渠道有自己一套字段體系，我們需要將各渠道對賬單中字段統一起來，標準化後再入庫存儲。
我們可以根據自己內部系統使用的字段為原點，來設計轉化後的字段。對於多餘和暫時用不到的字段可直接丟棄，減少冗餘。未來需要時，我們可以從對賬文件存儲管理器中找到源數據。
通用對賬單字段參考
注：上圖字段引用無敵碼農的總結，感謝前輩分享。文字版點這裡下載
如果公司未來業務需要接入更多支付渠道，可以提前考慮對賬系統的擴展性問題，設計一套解析流程，財務人員在後臺即可設置新增對賬賬單的字段與公司內部訂單系統字段是如何對應關聯。
三、對賬數據入庫查看
各渠道對賬數據清洗冗餘信息，統一格式，解析入庫後。我們可以在後臺方便的查看每一天，各渠道對賬數據，清晰明瞭。當在對賬的任何環節出現問題，財務人員都可以在這裡查詢到對賬系統，在對賬時使用的數據，便於定位問題。
第五章：賬單核對邏輯理解
本地對賬數據與第三方支付對賬數據就緒後，接下來我們可以將兩邊數據進行核對了。對賬一般只有四種狀態，兩邊一致（對平）、支付渠道多收了一筆（長款）、支付渠道少收一筆（短款）、本地和支付渠道兩邊都有，但數字不同（金額不一致）。其他錯誤都是這幾種狀態的擴展。
一、核對模塊幾種錯誤狀態及處理方法
1.收款類交易對賬
- 短款差錯：我們的訂單中有記錄，但支付渠道對賬單中沒有記錄。簡單講就是少收錢了。一般此類錯誤通常是碰到「跨日交易」，用戶在23:59分下單，在00:01分支付。
- 長款差錯：我們的訂單中沒有記錄，但支付渠道收到錢了。簡單講就是多收錢了。一般此類錯誤多是我們的系統未正確接受支付渠道下發的支付成功返回信息。這種手動調整交易狀態即可。
- 錯賬：兩邊都有記錄，但金額對不上。
2.退款類對賬
退款類對賬的錯誤，其實和收款大同小異。一般有這幾種情況。
- 本地未退款，渠道已退款：一般是渠道返回數據異常，按照渠道狀態修改本地退款狀態即可。
- 本地已退款，渠道無記錄（或反過來本地無記錄，渠道已退）：可能是「跨日交易」問題，如不是，只能人工排查處理。
- 本地與本地均為退款狀態，但兩邊金額不同：需要人工排查處理。
如果會計的思路不好理解，我們也可以按數據組來分。如下表
我們來看這兩張表，左表為我方訂單數據，右表為支付渠道數據。兩表之間由訂單ID關聯。
我們可以看到 ID1 兩邊數據一致，即「對平」 ；ID2和ID4 兩表格分別缺失，即「單邊」；ID3雖然兩邊都有數據，單交易金額不一致，即「錯帳」。
對賬系統會自動標記「單邊」和「錯帳」的訂單，這些訂單需要進入「差錯處理」來人工處理。
第六章：對賬引擎邏輯設計
一、起終日期在對賬系統中的作用
1.按時間順序對賬
因為訂單付退款關聯順序、跨日等因素，對賬必須按時間順序，順序對賬，不能跨日對賬。如項目其實日為1號，雖然今天已經是15號，對賬時，也必須從1號開始對。因為 t 天單邊賬，需要在 t+1 天裡繼續核對。跳躍對賬會產生非常多不必要的麻煩。
2.對賬引擎設計
請務必從「開始」沿箭頭方向走一遍這張圖，此圖信息量較大，請先仔細查看流程圖，然後再繼續閱讀。
以「我方對賬數據」作為基點，用「訂單號」作為關聯鍵，將我方對賬數據與渠道方對賬數據進行逐條對比。對比結果包含「對平」、「單邊（長短款）」、「錯賬」。
3.對賬任務創建與查詢
整個對賬引擎跑在服務器內，前端是看不到的，也不需要看。財務人員在創建任務時，只需要設定對賬的起始日期和終止日結，勾選需要對賬的訂單庫即可，剩下的交給對賬引擎來完成。對賬完畢後，財務人員再繼續差錯處理。
第七章：對賬差錯處理
自動對賬執行完畢後，總會有一些系統無法自動匹配的錯誤。這些錯誤會在對賬過程中被標記出來。在上一章我們已經講過，差異錯誤包含「長款」、「短款」、「錯帳」三個大類，實際對賬過程中，出現對賬差異的原因，千奇百怪，但不論差異有多奇怪，我們設計的差錯處理流程，都應該能覆蓋到。
一、差錯處理邏輯設計
對於常見的有規律的差錯單，我們可以設計一些規則來自動處理，比如跨日交易問題、三方渠道優惠券減免計算規則細微差異、貨幣轉化等問題。
各家都有自己獨特的交易流程，財務管理辦法，業務特性，所以對賬中出現的差錯也是千奇百怪，好在這些差錯均可以窮盡，我們只需要將碰到的差錯歸類，設計好解決方案，一個問題解決了，這一類問題就都解決了。
當自動規則無法平賬時，需要我們手工處理。當下無法處理的，可以考慮掛起賬單，未來合適的時間再處理。
二、差錯處理業務規則系統化
當差錯無法自動處理，需要人工手動處理時，我們需要把一套規範的流程和標準步驟寫在系統裡。
舉例：當對賬差錯為「長款」時，支付渠道顯示支付成功，我方訂單查詢為空，我方掉單。這時，財務人員需要發起「補單」，這個「補單」補單審核流程，我們可以把它當作一個處理選項，放在「人工手動處理」。
三、核對模塊四種狀態
- 對平正常：兩邊對比無異常，標記為正常。
- 差錯未處理：兩邊對比異常，標記異常等待人工處理。
- 差錯已處理：人工處理後標記已處理。
- 差錯已掛起：某些暫時無法處理或永久忽略的問題標記掛起。
第八章：如何快速搭建對賬系統
我用卡拉雲（https://kalacloud.com）按照本文思路搭建了一套對賬系統，幾個月的活，5天干完。卡拉雲幫助後端程序員解決了數據庫接入、API 調用等問題，前端組件拖放即用，可快速構建企業內部工具。
卡拉雲接入數據庫及 API 的頁面，支持常見的數據庫和 API ，只需簡單填寫表單即可完成複雜的數據接入。
第九章：擴展資料
一、支付對賬系統快速搭建工具
- 卡拉雲 - 支持快速接入數據庫、API，前端組件即拖即用。可快速搭建對賬系統。
二、支付渠道接入文檔
三、對賬系統搭建參考資料及拓展閱讀
本文作者
蔣川，卡拉雲CMO，B端產品經理，專注研究企業內部效率工具實施搭建
我的個人微信：HiJiangChuan ，歡迎加我微信一起交流。