編輯導語：很多人都有記帳的習慣，但是記到後面卻發現自己的帳算不清楚，記帳不能只靠著單方面的帳單，還要進行對帳才能確保無誤；本文將會從產品設計的業務知識點出發，詳細介紹對帳業務流程，並列舉會出現的常見問題和解決方法。
業務背景：
對帳模塊是支付系統的核心能力之一，是信息流和資金流關聯的重要依據，平臺如果只使用渠道的單邊帳單或者平臺流水訂單，出現差錯或渠道惡意扣單的風險極高。
為提高資金帳務的正確性和保障平臺的利益，需要通過平臺系統對帳能力與上遊渠道對帳單逐筆勾兌確認，如有差異能及時解決或歸檔。
用戶畫像：
1）清結算專員：負責發起清分的操作者，首先確保信息流對平，然後確認資金流應收款和信息流平帳帳單金額一致。希望能及時發現長短款問題，並解決，保障資金清算給商戶（平臺可收款用戶）的時效性。
2）對帳異常訂單處理專員：負責核算異常訂單原因，並在平臺操作將異常訂單執行修正、平帳。
一、必須知道的業務知識點
1. 對帳
在會計上概念：指為了保證帳簿記錄的正確性而進行的有關帳項的核對工作；做到帳證相符、帳帳相符、帳實相符。
在支付系統上的體現：
1）帳證核對：是將帳簿記錄與記帳憑證進行核對。這裡是記帳憑證是指第三方上遊提供的渠道對帳單，第三方渠道會根據對帳單金額實際結算資金，也就是常說的信息流對帳。（有的支付公司或銀行只要收到對帳單了且平帳，即使資金未實際到帳，業務也允許發起清分以提高清算時效性）
2）帳帳核對：是把有相互關係的多個帳簿記錄進行核對，有相互關係的帳簿記錄，包括總分類帳簿間核對，明細帳簿間核對等多種類型。整個支付系統可以被拆分成了多個子系統，如交易系統、帳戶系統、會計系統、帳戶系統，每個子系統在處理各自的業務並記錄，其實就相當於會記理論中的帳簿。系統間的對帳，主要用於修正內部系統的數據不一致。
3）帳實核對：是各項資產物資的記錄數值與實際真實數額間的核對。確認第三方匯款到銀行帳戶資金和平帳對帳單結算金額是否匹配，也就是常說的資金流對帳。
2. 軋帳
對帳系統主要做的是信息流的對帳，若對帳中發現有差異的訂單歸類記入對帳異常訂單表，可稱為軋帳。
3. 平帳
對帳異常訂單進入差錯流程，可以通過人工或者自動的方式，按照事先設計好的規則處理這些異常差錯，可稱為平帳。
4、渠道對帳單
上遊渠道會按照平臺在其申請的渠道帳戶維度推送對帳單，渠道帳戶也就是常說的支付通道。
如果是第三方支付公司或銀行，上遊渠道是微信、支付寶、銀聯二維碼（雲閃付）等等。例如：支付平臺申請有微信2通道和微信6通道，則微信側會生成2份對帳單文件。
每份對帳單會包括支付成功訂單和退款成功訂單。第三方會以對帳單中的結算金額（支付訂單金額-支付訂單手續費）-（退款訂單金額-退款訂單手續費）結算匯款給到平臺資金帳戶。
5、銀聯二維碼（難點）
銀聯二維碼是銀聯平臺自主推出的支付產品，C端使用雲閃付、各手機銀行APP支付，訂單底層走的都是銀聯二維碼通道。
為什麼銀聯二維碼需要重點說呢？
因為它不同於微信、支付寶通道統一費率的原則，銀聯會根據C端用戶支付時使用的銀行卡借貸性質和交易金額是否大於1000作為費率規則，並且還會收取額外的品牌服務費，詳情參見下圖。
所以設計銀聯二維碼通道對帳時，還需考慮到多費率及品牌服務費的場景。
二、對帳流程
1. 業務流程
對帳業務可以插解為5個業務環節，本文主要說明每個環節的能力職責、常見問題和通用解決方法，具體的產品方案還需要結合讀者平臺自身的業務特點和系統架構設計。
三、對帳任務
對帳是一個日常操作，正常情況下上遊渠道都會以D+1的周期生成渠道對帳單。
每天系統可以默認生成定時對帳任務，每個上遊渠道生成時間不一樣，可以事前和上遊確認，並結合平臺對帳的處理時效和商戶到帳需求，設計一個合理的時間執行。
對帳任務設計前需確認，渠道對帳單推送方式、解析方法、匹配欄位，並提前做好聯調適配工作；例如渠道有可能會需要申請白名單權限或提供SFTP地址信息，要謹防上線後才發現系統無法正常獲取對帳單的情況。
1. 創建任務批次
創建批次一方面是為了防止重複對帳，另一方面需要在對帳結束的時候將對帳的結果信息存儲到批次中。
2. 記錄任務信息
對帳任務信息，例如：通道名稱、通道編號、渠道商戶號、對帳任務批次、對帳任務狀態、交易時間、任務創建時間、下載開始時間、下載結束時間、下載狀態、對帳開始時間、對帳結束時間、對帳結果、對帳方式；
對帳方式為對帳處理時的對帳規則，可以根據業務實際情況分為：無需對帳、以渠道為準、以平臺為準。
以渠道為準，則若對帳訂單平臺交易狀態為支付中或支付失敗，但渠道為支付成功，則平臺狀態改為支付成功。以平臺為準，則是若出現上述情況，對帳訂單記錄為異常訂單。
3. 重置任務機制
考慮到對帳過程中可能會遇到的來自上遊渠道的問題或平臺系統自身問題，需要設計重置機制。
上遊渠道對帳單錯誤，需求二次或多次推送，所以需要設計重新下載渠道對帳單或重新上傳渠道對帳單；有可能平臺自身數據錯誤導致出現大量的差異訂單，修復後需要重新對帳。
4. 對帳任務詳情示例
對帳信息：記錄對帳任務基本情況；對帳結果信息：顯示關鍵對帳欄位值；掛銷帳信息：顯示是否有掛銷帳訂單及金額；對帳異常信息：顯示是否有對帳異常訂單及金額；備註：將系統自動處理的過程記錄，也可以手動修改。
四、對帳單下載
1. 獲取文件
渠道對帳單獲取方式，一般提前作為任務規則寫死。
大多數銀行都要求接入方提供ftp服務，銀行定時將對帳單推送到接入方提供的ftp伺服器上面；
還有一部分銀行會提供對帳單的下載服務，通過ftp/http的都有，ftp方式居多；
另外網銀的對帳單比較特殊，一般都需要結算登錄網銀的後臺管理系統中，手動下載，結算下載完對帳單後在導入到對帳系統。
2. 判斷文件是否存在
任務自動獲取文件的情況下需要判斷任務是否存在：
自動獲取渠道對帳單：不存在需要設置輪詢，每間隔一段時間重新獲取。重試次數和間隔的設置需要小心，重試太頻繁，容易把伺服器打死.；時間間隔太大，又會阻塞後續處理步驟。5～10分鐘是一個合適的重試間隔區間。
手動導入渠道對帳單：要設計導入入口，導入成功後任務狀態也要做相應的變更。
3. 下載文件
技術實現上可以做成工廠模式，不同的支付渠道有不同的下載類，如果是http接口將文件寫入到對帳單，如果是ftp伺服器，將伺服器中的對帳單下載到本地帶解析的目錄中。主要涉及的代碼ftp工具類、http(s)工具類，相關IO讀寫。
4. 判斷來源渠道
獲取到上遊對帳單文件後，很有可能多個渠道的對帳單在同一個SFTP地址，根據文件名匹配到對應的對帳任務，文件名一般會包含帳單時間、渠道商戶號，然後再執行下一步。
五、文件解析
1. 解析文件
解析文件主要是將下載的對帳文件解析成我們可以對帳的數據類型並且入庫。
解析的文件不同渠道有不同的類型，因此也可以設計成不同的解析模板，使用工廠模式將不同格式的文件解析成可以對帳的統一數據類型。
解析的文件類型一般包括：json、text、cvs、excle等，另外部分銀行會對帳單做加密或者提供zip打包的格式，這裡就需要額外開發zip工具類和加解密工具類進行處理。
對帳文件中包含的主要信息有：商戶訂單號、交易流水號、交易時間、支付時間、付款方、交易金額、交易類型、交易狀態這些欄位。
2. 轉換入庫
每個渠道的帳單格式都不盡相同， 在得到帳單後，下一步是對帳單做標準化處理，這樣軋帳以及後續工作就可以統一處理了。
標準化後的帳單數據可以放在文件系統或者資料庫中，這取決於交易數據量；每天百萬以上的量，還是使用文件系統，比較合適，資料庫操作相對比較慢，也浪費資源。
基於文件系統的標準化涉及如下內容:
文件格式標準化統一使用csv或者json或者xml格式，如果是使用hadoop或者spark來對帳，也可以使用csv。文件存儲統一化文件目錄，文件名都需要遵循統一命名規範。
六、對帳單處理
1. 獲取對方對帳單
將事前準備的上遊對帳單標準文件放入緩衝對帳池。
2. 獲取我方對帳單
本地交易記錄的準備，總的來說有如下方法:
啥都不做，直接用訂單表的原始數據：鑑於大部分系統使用的是MySQL，這也意味著在MySQL上做對帳。對帳時需要大量的數據查找工作，必然會影響線上業務。在數據規模較大，比如超過100萬時，就不太合適了。
使用備庫來執行對帳：這樣既簡單，也不影響線上業務，這是典型的空間換時間的做法。
採用分表分庫對帳：如果業務大到需要分表分庫才能處理，那對帳數據準備也不一樣。
3. 逐一匹配
前文有提到對帳方式有三種，不對帳、以渠道為準、以平臺為準，大部分的情況下的對帳方式都以渠道為準，信息流的傳遞方向，支付成功結果是由上遊渠道通知平臺的，平臺很有可能會因網絡或系統問題而沒有收到通知。
一般按照交易金額、交易狀態、手續費金額逐一匹配，對帳方式選擇以渠道為準的處理邏輯為例：
1）交易金額不匹配：記入異常訂單。
2）交易狀態不匹配：若上遊為支付成功，我方為未支付或支付失敗，則以上遊為準。
若我方訂單為支付成功，上遊只會推送支付成功的訂單為對帳單，上遊對帳單不存在的情況，將我方訂單記入為掛帳訂單；若上遊對帳單存在，我方不存在的情況，記入異常訂單。3）手續費金額不匹配：記入異常訂單。
4. 掛銷帳處理
常會存在因日切時間點不一致或網絡延時等情況，導致我方平臺訂單時間與上遊渠道時間不一致，同一個訂單在渠道交易時間是1月1號，但在平臺是1月2號。
掛帳，對帳時若上遊無我方有，訂單放入掛帳訂單中。銷帳，若匹配中掛帳訂單匹配上了，記錄為當日平臺帳單，掛銷帳狀態改為已銷帳。
七、差錯處理
關於差錯流程，每個系統的業務特性、運營團隊流程、公司財務管理辦法不一樣，不能生搬硬套，但原則是一樣的，所有的異常訂單的報銷帳必須有理有據，多重審核。
1. 異常原因
（1）若出現訂單金額不一致的情況，一般是平臺調用上遊交易接口時，雙方欄位的定義不匹配導致的。
（2）若出現手續費金額不一致的情況，一般是平臺手續費計算規則和上遊不匹配導致的，差額不會太大，可以設計閥值若在可以接受的範圍類不計為異常。
（3）若出現上遊對帳單存在，平臺訂單不存在的情況，通常是有第三方繞過平臺系統與上遊系統發生支付或退款交易。需要及時核查是否存在交易密鑰洩露或被繞過商戶去上遊系統平臺操作。
2. 修正
選擇以平臺為準或以上遊為準，修改訂單金額、訂單狀態、手續費金額。此時寫入修正原因很重要，便於後期業務追蹤考求。
3. 平帳
將平臺異常訂單狀態改為平帳，並將平帳時的時間作為帳單時間，合入至平臺帳單。平臺會根據平臺帳單計算渠道分潤金額和商戶結算金額。
八、業務規則系統化
最後，每個平臺產品細節都會有其特定的業務規則，就不具體說明平臺頁面和和平臺操作功能，筆者不做詳情說明。以上業務規則系統化，系統流程圖如下，讀者可以結合自己平臺業務情況提取細化。
本文由 @Jamie Gao 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議