本文所描述的對賬，非金融機構內部的對賬場景。適用于公司自研以及采購的類電商系統(tǒng)，在此種場景下，平臺背后支付渠道可能對接微信、支付寶亦或者是其他第三方聚合支付公司的通道。

一、支付系統(tǒng)綜述

在如下圖體系中，對賬的目的是保障如下的等式成立：

客戶支付的錢-支付渠道手續(xù)費=應結賬款

有些渠道因為根據(jù)結算周期不一樣或者其他運營因素，結算需要手續(xù)費。此種情況：應結賬款-結算手續(xù)費=到賬金額。

在一個完整的電商交易平臺中，還會涉及折扣、積分兌換、滿減、余額等支付場景，而且其中又夾雜多商戶聚合支付。這種場景會讓新入行的小伙伴手足無措。

以上兩種場景的邏輯不應該放支付系統(tǒng)（支付模塊）處理，而是應該放在交易模塊的訂單管理子模塊處理。

支付系統(tǒng)只關注實付金額的處理，一筆訂單的訂單金額、折扣等都不是支付系統(tǒng)關心的。在一個復雜的電商系統(tǒng)中（淘寶、京東、亞馬遜），交易模塊的核心工作之一就是處理好業(yè)務訂單和支付訂單的關系。

業(yè)務訂單的核心屬性：業(yè)務訂單編號、下單日期、訂單金額、訂單狀態(tài)、折扣信息、商戶信息、客戶信息。

支付訂單的核心字段：支付訂單編號、業(yè)務訂單編號、支付時間、支付金額、商戶信息、支付狀態(tài)。

二、對賬綜述

明白了支付系統(tǒng)的定位和分工，在對賬階段所要關注的核心工作也就清楚了。

對賬主要是保證三項數(shù)據(jù)的一致性：支付訂單、支付流水、渠道流水。

這三項是分別是業(yè)務系統(tǒng)、支付系統(tǒng)、支付渠道的支付主數(shù)據(jù)，保證三者的ID關系和狀態(tài)吻合既保證了支付流程的正確性。而渠道需要保障的渠道流水中的應結金額和實際結算金額的一致性，這個是支付渠道內部對賬需要解決的問題。

第一階段對賬中會涉及會員積分的核銷、運營折扣的匹配所以后期會專題分享；第二階段與第三階段很像，都是根據(jù)下游系統(tǒng)生產的對賬文件和本地的訂單或者流水核對。詳細對賬流程看下節(jié)。

三、對賬流程

如下圖，一般對賬文件都是隔日才會生成，因為需要下游系統(tǒng)每日處理完前日的內部對賬后才會生成給上游的對賬文件。

1. 獲取對賬文件：格式化存儲，原始數(shù)據(jù)所有字段均存儲；
2. 創(chuàng)建對賬批次：因為有些系統(tǒng)涉及商戶很多或者對接多個支付渠道，所以可以根據(jù)實際需求創(chuàng)建對賬批次易于分類管理。常見以日期為一批次。但是下游對賬文件出問題時，可能需要當日需要再重新創(chuàng)建批次亦或是全量覆蓋；
3. 對賬處理：從格式化的對賬文件中抽取六流水號、類型、狀態(tài)、金額、商戶號等關鍵字段和本系統(tǒng)的訂單匹配；
4. 如果 ID+金額+狀態(tài) 一致，則該筆訂單直接核銷，打上對賬標記。

ID 指發(fā)送請求給下游時，下游返回存儲在本系統(tǒng)的唯一主鍵。

對于不一致的場景會有三種情況，分別對應不同處理方案：

1. 本地有ID，下游有ID；可以匹配但是狀態(tài)不對；調用狀態(tài)查詢接口同步狀態(tài)；
2. 本地有ID，下游無ID；根據(jù)ID查下游訂單；
3. 本地無ID，下游有ID；根據(jù)ID查本地訂單，或查詢日志。

差錯處理這一塊，在實際涉及中，建議預留好人工處理的工具，等運行穩(wěn)定后再根據(jù)實際情況把一些頻繁出現(xiàn)的場景通過系統(tǒng)自動處理。

四、總結

本文中的對賬針對場景是類電商系統(tǒng)和支付系統(tǒng)以及支付渠道之間的訂單對賬，并沒有涉及錢包、資金托管模式下的財務對賬。

本文提供的方法也主要是從業(yè)務需求出發(fā)，解決當平臺的交易流程比較復雜的情況下，怎么保證訂單信息、支付信息一致性的問題。

其他關于資金流水、應結資金、結算資金設計和財務ERP、企業(yè)網(wǎng)銀（通過銀企互聯(lián)獲取賬戶流水）的對賬，后續(xù)文章在一一介紹。

#專欄作家#

俠之大者，微信公眾號：俠之大者（ID：xzdzkamil），人人都是產品經理專欄作家。關注互聯(lián)網(wǎng)金融和企業(yè)信息化轉型。

本文原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議。