編輯導語：很多人都有記賬的習慣，但是記到後面卻發現自己的帳算不清楚，記賬不能隻靠着單方面的賬單，還要進行對賬才能确保無誤；本文将會從産品設計的業務知識點出發，詳細介紹對賬業務流程，并列舉會出現的常見問題和解決方法。

業務背景：

對賬模塊是支付系統的核心能力之一，是信息流和資金流關聯的重要依據，平台如果隻使用渠道的單邊賬單或者平台流水訂單，出現差錯或渠道惡意扣單的風險極高。

為提高資金賬務的正确性和保障平台的利益，需要通過平台系統對賬能力與上遊渠道對賬單逐筆勾兌确認，如有差異能及時解決或歸檔。

用戶畫像：

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. 對賬信息：記錄對賬任務基本情況；
2. 對賬結果信息：顯示關鍵對賬字段值；
3. 挂銷賬信息：顯示是否有挂銷賬訂單及金額；
4. 對賬異常信息：顯示是否有對賬異常訂單及金額；
5. 備注：将系統自動處理的過程記錄，也可以手動修改。

四、對賬單下載

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. 挂賬，對賬時若上遊無我方有，訂單放入挂賬訂單中。
2. 銷賬，若匹配中挂賬訂單匹配上了，記錄為當日平台賬單，挂銷賬狀态改為已銷賬。

七、差錯處理

關于差錯流程，每個系統的業務特性、運營團隊流程、公司财務管理辦法不一樣，不能生搬硬套，但原則是一樣的，所有的異常訂單的報銷賬必須有理有據，多重審核。

1. 異常原因

（1）若出現訂單金額不一緻的情況，一般是平台調用上遊交易接口時，雙方字段的定義不匹配導緻的。

（2）若出現手續費金額不一緻的情況，一般是平台手續費計算規則和上遊不匹配導緻的，差額不會太大，可以設計閥值若在可以接受的範圍類不計為異常。

（3）若出現上遊對賬單存在，平台訂單不存在的情況，通常是有第三方繞過平台系統與上遊系統發生支付或退款交易。需要及時核查是否存在交易密鑰洩露或被繞過商戶去上遊系統平台操作。

2. 修正

選擇以平台為準或以上遊為準，修改訂單金額、訂單狀态、手續費金額。此時寫入修正原因很重要，便于後期業務追蹤考求。

3. 平賬

将平台異常訂單狀态改為平賬，并将平賬時的時間作為賬單時間，合入至平台賬單。平台會根據平台賬單計算渠道分潤金額和商戶結算金額。

八、業務規則系統化

最後，每個平台産品細節都會有其特定的業務規則，就不具體說明平台頁面和和平台操作功能，筆者不做詳情說明。以上業務規則系統化，系統流程圖如下，讀者可以結合自己平台業務情況提取細化。

本文由 @Jamie Gao 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部