在電商、金融類產(chǎn)品里，對(duì)賬系統(tǒng)是一個(gè)很重要的模塊。本文采用STAR法則對(duì)對(duì)賬場(chǎng)景進(jìn)行的結(jié)構(gòu)化分析，希望可以幫到大家。

本文將采用STAR 法則的視角，結(jié)構(gòu)化拆解 對(duì)賬場(chǎng)景的案例分析，首先簡(jiǎn)要梳理下STAR 法則

1. Situation（情境）：描述事件發(fā)生的背景或情境。
2. Task（任務(wù)）：明確在該情境中需要完成的任務(wù)或面臨的挑戰(zhàn)。
3. Action（行動(dòng)）：敘述為了完成任務(wù)或應(yīng)對(duì)挑戰(zhàn)所采取的具體行動(dòng)。
4. Result（結(jié)果）：展示采取行動(dòng)后得到的結(jié)果或?qū)W習(xí)到的經(jīng)驗(yàn)。
5. Situation（情境）：

為出海商家提供支付服務(wù)解決方案，按照與商戶約定的結(jié)算周期如T+15進(jìn)行資金結(jié)算，其中必不可少的一個(gè)環(huán)節(jié)就是對(duì)賬，對(duì)賬是結(jié)算的基礎(chǔ)，當(dāng)前有些機(jī)構(gòu)是先對(duì)賬再結(jié)算，有些是對(duì)結(jié)分離。

一、對(duì)賬情境

為了確保同一個(gè)事務(wù)的數(shù)據(jù)描述在不同場(chǎng)景，記錄是否一致而進(jìn)行的一致性比對(duì)。

舉個(gè)例子：對(duì)于面館老板，顧客吃了一碗面，點(diǎn)菜小票就是原始憑【證】，付了10元錢是【賬】，老板電腦點(diǎn)菜記錄小票10元是【賬】，老板賬戶中余額增加10元是【實(shí)物】。

• 賬實(shí)對(duì)賬：是指我們記錄的賬與實(shí)物資產(chǎn)的實(shí)際數(shù)量進(jìn)行對(duì)賬。
• 賬證對(duì)賬：是指將自己的賬本與記賬憑證進(jìn)行核對(duì)。一般記賬憑證由與業(yè)務(wù)合作的第三方公司提供，在面館的例子里，記賬憑證由支付寶提供（交易記錄）。
• 賬賬對(duì)賬：是指在上下游相互關(guān)聯(lián)的賬本之間進(jìn)行對(duì)賬。在整個(gè)交易過程中，一般會(huì)涉及上下游多套賬，上游比如外部采購、對(duì)外銷售，下游比如快遞發(fā)貨賬、第三方服務(wù)費(fèi)等。這些賬和總賬之間有非常多的關(guān)聯(lián)性，所以一般賬賬核對(duì)，通常用于確認(rèn)及修正內(nèi)部賬之前的數(shù)據(jù)不一致。

1. Task（任務(wù)）

跨境支付機(jī)構(gòu)在對(duì)賬環(huán)節(jié)面臨的挑戰(zhàn)有幾個(gè)：

其一：對(duì)賬準(zhǔn)確，能對(duì)不同上游銀行的對(duì)賬文件解析準(zhǔn)確

其二：確保商戶資金結(jié)算體驗(yàn)，如期結(jié)算給商戶

其三：確保能對(duì)差錯(cuò)進(jìn)行處理

其四：搭建商戶獲取對(duì)賬單的系統(tǒng)或接口服務(wù)

2. Action（行動(dòng)）

渠道數(shù)據(jù)處理：

主要負(fù)責(zé)渠道對(duì)賬文件的下載，解析，以及數(shù)據(jù)落庫。

目前市面上第三方支付渠道對(duì)賬文件下載方式主要分為以下幾類：

• 第三方渠道定時(shí)推送到 SFTP/FTP。這種模式比較簡(jiǎn)單，我們定時(shí)從 SFTP/FTP 取對(duì)賬文件。
• 調(diào)用第三方渠道對(duì)賬文件下載接口。這種模式需要對(duì)接渠道下載對(duì)賬文件接口，定時(shí)調(diào)用下載。支付寶與微信為該模式。
• 手動(dòng)在支付渠道網(wǎng)站下載對(duì)賬文件。這種模式最不友好，需要我們花費(fèi)人力下載文件。

除了下載方式，對(duì)賬文件的格式也會(huì)存在一些區(qū)別。比如支付寶對(duì)賬文件格式為 csv，而微信的對(duì)賬文件格式為 txt，另外有些渠道為 xml,xls。

接下來，干貨來了，從對(duì)賬案例調(diào)研，對(duì)賬核對(duì)模塊，差錯(cuò)處理，系統(tǒng)優(yōu)化模塊進(jìn)行深入剖析！

二、對(duì)賬案例調(diào)研

案例一

叮咚支付向您提供兩種對(duì)賬形式， 您可以根據(jù)需要自行獲取對(duì)賬文件。

1. 通過商戶站下載對(duì)賬文件。
2. 叮咚支付向您提供SFTP及其相關(guān)參數(shù)供以登錄和下載。此選項(xiàng)需在叮咚支付開立SFTP賬號(hào)，在您與叮咚支付的協(xié)議簽署完成后，即可向工作人員申請(qǐng)開通您的商戶號(hào)所屬SFTP賬戶。

SFTP對(duì)賬

SFTP對(duì)賬是指您通過登錄**向您提供的SFTP賬戶， 獲取對(duì)賬文件的過程

獲取到您的SFTP賬戶信息之后， 您就可以通過訪問SFTP的方式獲取對(duì)賬文件， 下面我們以WINSCP作為示例， 演示獲取對(duì)賬文件的過程。

打開WinSCP。

輸入您的叮咚支付SFTP賬戶信息，連接SFTP。

在SFTP根目錄下， 打開以您的用戶名命名的文件夾。

打開以您的商戶號(hào)命名的文件夾， 獲取對(duì)賬文件。

案例二

叮叮支付對(duì)賬方式如下：

1. 商戶后臺(tái)
2. API對(duì)接

接口請(qǐng)求參數(shù)：

接口響應(yīng)參數(shù)：

商戶站對(duì)賬單時(shí)間周期：

商戶站快捷查詢?nèi)諏?duì)賬單，周對(duì)賬單，月對(duì)賬單，商戶站自定義時(shí)間范圍查詢

日對(duì)賬單，周對(duì)賬單和月賬單，不同范圍的對(duì)賬單下載模板是一致的

對(duì)賬文件模板

通?？梢栽趯?duì)賬單上查看商戶對(duì)應(yīng)的交易記錄信息，拒付，調(diào)單，偽冒，退款，費(fèi)用項(xiàng)信息匯總以及每項(xiàng)明細(xì)

文件結(jié)構(gòu)處理方式一：通常匯總對(duì)賬單表在對(duì)賬單表格文件的第一個(gè)sheet，各個(gè)分類的明細(xì)表放在第后面的sheet，優(yōu)點(diǎn)是商戶可以以先總后分的方式進(jìn)行核對(duì)查驗(yàn)，先了解當(dāng)前對(duì)賬周期的各項(xiàng)總額，再查看各項(xiàng)明細(xì)記錄

對(duì)賬粒度

對(duì)賬粒度分為兩種，分別是總數(shù)對(duì)賬和明細(xì)對(duì)賬。

1）總數(shù)對(duì)賬：選擇一個(gè)維度，進(jìn)行總數(shù)級(jí)別的對(duì)賬。比如賬期賬單消費(fèi)總數(shù)和賬期資金記錄總數(shù)對(duì)比，總數(shù)級(jí)別的對(duì)賬好處是對(duì)賬口徑的設(shè)計(jì)比較簡(jiǎn)單，可以快速實(shí)現(xiàn)，不易出錯(cuò)。缺點(diǎn)就是無法定位問題數(shù)據(jù)，一旦對(duì)賬發(fā)現(xiàn)問題。還需要進(jìn)一步尋找問題數(shù)據(jù)。

2）明細(xì)對(duì)賬：對(duì)雙方的每條數(shù)據(jù)按照業(yè)務(wù)規(guī)則依次進(jìn)行比對(duì)。它的優(yōu)點(diǎn)是可以準(zhǔn)確定位問題數(shù)據(jù)。缺點(diǎn)是對(duì)賬口徑的設(shè)計(jì)比較復(fù)雜，效率比較低。因?yàn)槲覀冃枰瑫r(shí)針對(duì)漏、重、錯(cuò)三種錯(cuò)誤類別設(shè)計(jì)出較為全面的對(duì)賬口徑，同時(shí)還要考慮到業(yè)務(wù)的邊緣場(chǎng)景。稍有不慎，就會(huì)影響對(duì)賬的準(zhǔn)確性。

因此，推薦的做法應(yīng)該是以總數(shù)對(duì)賬為主，首先確認(rèn)是否存在問題。以明細(xì)對(duì)賬為輔，對(duì)具體問題進(jìn)行定位。

• 對(duì)賬，我們一般稱為勾兌，支付系統(tǒng)的對(duì)賬，包含著兩個(gè)層面：支付系統(tǒng)內(nèi)部間的對(duì)賬，支付系統(tǒng)一般是分布式的，整個(gè)支付系統(tǒng)被拆分成了多個(gè)子系統(tǒng)，如交易系統(tǒng)、賬戶系統(tǒng)、會(huì)計(jì)系統(tǒng)、賬戶系統(tǒng)，每個(gè)子系統(tǒng)在處理各自的業(yè)務(wù)，系統(tǒng)間的對(duì)賬，就是以上系統(tǒng)的核對(duì)，用于修正內(nèi)部系統(tǒng)的數(shù)據(jù)不一致。
• 支付系統(tǒng)與渠道的對(duì)賬，這里的渠道泛指所有為支付系統(tǒng)提供代收付業(yè)務(wù)的渠道，如：第三方支付公司、銀行、清算中心、網(wǎng)聯(lián)、銀聯(lián)等。

對(duì)賬單關(guān)鍵字段解讀：

• 文件命名：商戶對(duì)賬單
• 通用文案：支付機(jī)構(gòu)聯(lián)系信息和品牌信息
• 商戶號(hào)以及公司名稱：支付機(jī)構(gòu)商戶唯一標(biāo)識(shí)碼
• 幣種：通常每個(gè)記賬幣種一個(gè)賬單分類，按不同的幣種分為不同sheet進(jìn)行匯總統(tǒng)計(jì)
• 賬單周期：2024-07-01-2024-07-31

對(duì)賬單分類匯總類目一：交易對(duì)賬

按交易類型分為：成功交易，退款，拒付，調(diào)單，申訴成功等

費(fèi)用對(duì)賬：

以上分類項(xiàng)收入，支出，收入筆數(shù)，支出筆數(shù)，也有記錄為借記，貸記，英文接口字段一般為Debit（通常為減號(hào)）和Credit（通常為記號(hào)）

其它調(diào)整：

案例三：支付寶商戶對(duì)賬方式

支付寶對(duì)賬 目前支付寶對(duì)外的常用對(duì)賬方式也有兩種：一種是通過在支付寶后臺(tái)下載賬單的方式來對(duì)賬；一種是通過調(diào)用接口的方式來實(shí)現(xiàn)對(duì)賬

方式一：

方式二：支付寶商家平臺(tái)業(yè)務(wù)賬單明細(xì)和業(yè)務(wù)匯總查詢下載表

案例四：微信支付商戶對(duì)賬

SUCCESS賬單字段：交易時(shí)間,公眾賬號(hào)ID,商戶號(hào),設(shè)備號(hào),微信訂單號(hào),商戶訂單號(hào),用戶標(biāo)識(shí),交易類型,交易狀態(tài),付款銀行,貨幣種類,應(yīng)結(jié)訂單金額,代金券金額,商品名稱,商戶數(shù)據(jù)包,手續(xù)費(fèi),費(fèi)率,訂單金額,費(fèi)率備注

REFUND賬單字段：交易時(shí)間,公眾賬號(hào)ID,商戶號(hào),設(shè)備號(hào),微信訂單號(hào),商戶訂單號(hào),用戶標(biāo)識(shí),交易類型,交易狀態(tài),付款銀行,貨幣種類,應(yīng)結(jié)訂單金額,代金券金額,退款申請(qǐng)時(shí)間,退款成功時(shí)間,微信退款單號(hào),商戶退款單號(hào),退款金額,充值券退款金額,退款類型,退款狀態(tài),商品名稱,商戶數(shù)據(jù)包,手續(xù)費(fèi),費(fèi)率,訂單金額,申請(qǐng)退款金額,費(fèi)率備注

注意：

• 符號(hào)：明細(xì)數(shù)據(jù)內(nèi)容每個(gè)字段前會(huì)增加1個(gè)字符 ` 用于避免獲取的內(nèi)容被excel展示為科學(xué)計(jì)數(shù)法的格式、丟失數(shù)據(jù)細(xì)節(jié)
• 下載賬單API為通用接口，交易/資金賬單都可以通過該接口獲取到對(duì)應(yīng)的賬單。
• 賬單文件的下載地址的有效時(shí)間為30s。
• 強(qiáng)烈建議商戶將實(shí)際賬單文件的哈希值和之前從接口獲取到的哈希值進(jìn)行比對(duì)，以確認(rèn)數(shù)據(jù)的完整性。

備注：哈希是一種將長(zhǎng)數(shù)據(jù)映射為短數(shù)據(jù)的方法，哈希的有多種用途，包括數(shù)據(jù)完整性驗(yàn)證、密碼存儲(chǔ)、數(shù)據(jù)檢索和加密安全

• 該接口響應(yīng)的信息請(qǐng)求頭中不包含微信接口響應(yīng)的簽名值，因此需要跳過驗(yàn)簽的流程。
• 微信在次日9點(diǎn)啟動(dòng)生成前一天的對(duì)賬單，建議商戶10點(diǎn)后再獲取。

三、對(duì)賬核對(duì)模塊

這一個(gè)模塊我們使用上一模塊提取出來的數(shù)據(jù)，核對(duì)訂單號(hào)與金額是否完全一致。

這個(gè)過程可能產(chǎn)生三類差異數(shù)據(jù)。

第一種情況為本端數(shù)據(jù)存在，對(duì)端數(shù)據(jù)不存在，我們稱為本端多賬。

第二種情況為對(duì)端數(shù)據(jù)存在，本端數(shù)據(jù)不存在，我們稱為對(duì)端多賬。

第三種情況為金額不一致。

三者如圖所示。

這里產(chǎn)生的差異數(shù)據(jù)存入一張差異表中，以便下個(gè)模塊使用。

四、差異數(shù)據(jù)處理模塊

這個(gè)模塊主要用來處理上個(gè)模塊產(chǎn)生的差異數(shù)據(jù)。

上面三類差異數(shù)據(jù)中，金額不一致相當(dāng)少見，這種情況需要人工判斷。

我們先討論本端多賬的情況。

本端多賬是對(duì)賬系統(tǒng)最常見的一種情況。這種情況可能由于交易的時(shí)候發(fā)生日切問題，導(dǎo)致雙方記賬日期不一致,從而發(fā)生不平賬。

我們先解釋日切的概念。

日切，通俗的來說就是更換系統(tǒng)記賬的時(shí)間，系統(tǒng)從當(dāng)前工作日切換到下一工作日。這個(gè)過程中，若我方的交易訂單剛好發(fā)生在 T 日 23:59:59，那么我方的記賬時(shí)間為 T 日。第三方渠道接收到訂單的時(shí)間為 T+1 日 00:00:01，這樣第三方渠道該筆的交易的對(duì)賬日期為 T+1 日。

第三方渠道 T 日對(duì)賬文件將缺少這筆，但是我方 T 日數(shù)據(jù)卻存在這筆，這就導(dǎo)致了核對(duì)過程中產(chǎn)生一筆本端多賬差異數(shù)據(jù)。

對(duì)于這類差異數(shù)據(jù)，我們可以選擇將這筆數(shù)據(jù)掛賬，等待 T+1 工作日對(duì)賬。T+1 日對(duì)賬的時(shí)候，對(duì)賬單會(huì)相應(yīng)多出數(shù)據(jù)，這樣在核對(duì)過程就會(huì)產(chǎn)生對(duì)端多賬的差異數(shù)據(jù)。

然后在 T+1 日差異處理模塊將前幾日差異數(shù)據(jù)都提取出來，逐筆核對(duì)本端多賬數(shù)據(jù)與對(duì)端多賬數(shù)據(jù)。若核對(duì)一致，將兩筆差異狀態(tài)都更新成處理完成。最后若無剩余差異數(shù)據(jù)，當(dāng)天賬單平賬。

偽代碼如下（引用）：

對(duì)端多賬的產(chǎn)生情況可能可能有兩種情況.

第一種情況測(cè)試環(huán)境與生產(chǎn)環(huán)境共用一份第三方渠道參數(shù)，這就導(dǎo)致測(cè)試環(huán)境交易訂單也會(huì)出現(xiàn)在對(duì)賬單中。若是這種情況，我們確認(rèn)測(cè)試環(huán)境存在這批數(shù)據(jù)之后，我們忽略這批差異數(shù)據(jù)即可。

第二種情況，本端交易訂單存在，但是狀態(tài)不是成功狀態(tài)。這種情況下，需要調(diào)用第三方渠道提供的查詢接口，查詢訂單最終狀態(tài)。若查詢成功，更新訂單狀態(tài)，然后將差異數(shù)據(jù)狀態(tài)更改為處理成功。

若第三方渠道無法查詢到訂單的狀態(tài)。這種若與渠道確認(rèn)訂單最終支付成功，我們需要將支付訂單改為支付成功，并修改差異賬的狀態(tài)。

最后我們?cè)俅沃匦聦?duì)賬，由于對(duì)端多賬的數(shù)據(jù)會(huì)有對(duì)應(yīng)的本端數(shù)據(jù)，將不會(huì)產(chǎn)生差異數(shù)據(jù)，這次對(duì)賬完成且平賬。

五、系統(tǒng)優(yōu)化

目前系統(tǒng)的對(duì)賬系統(tǒng)定時(shí)任務(wù)采用 Spring 定時(shí)功能。后期優(yōu)化準(zhǔn)備接入 elasticjob 這種分布式定時(shí)調(diào)度程序，可以做到快速修改定時(shí)任務(wù)的時(shí)間，而無需重啟程序。以及可以快速觸發(fā)定時(shí)任務(wù)。

1. 文件獲取

• 銀行，第三方支付，銀聯(lián)等，基本都會(huì)提供對(duì)賬單下載的功能。不過也有少數(shù)工作做不到位或者太到位的銀行，只提供賬單查詢后臺(tái)，不提供對(duì)賬單下載功能。對(duì)開發(fā)人員來說，這里有幾個(gè)坑：對(duì)賬單格式不一。文本，XML，csv的都有。為了后續(xù)能夠統(tǒng)一處理，在賬單下載完成后，需要進(jìn)行標(biāo)準(zhǔn)化處理。
• 下載方式不一，HTTP，HTTPS，F(xiàn)TP的，都有。下載程序需要按照渠道的協(xié)議來處理。
• 下載時(shí)間不一，一般是凌晨1點(diǎn)后，到中午12才能用的也有。如果在預(yù)定的時(shí)間取不到數(shù)據(jù)，需要注意重試讀取。
• 穩(wěn)定性差。FTP服務(wù)器出問題那是常有的事。渠道側(cè)解決方案往往就是重啟。所以重試機(jī)制是必要的。

看一下第三方支付的對(duì)賬單情況：

技術(shù)選型上，HTTP(S)用apache httpclient即可實(shí)現(xiàn)鏈接池和斷點(diǎn)續(xù)傳， FTP也可以使用Apache Commons Net API。但不管是哪一個(gè)，都需要設(shè)置重試次數(shù)和鏈接超時(shí)間。重試次數(shù)和間隔的設(shè)置需要小心，重試太頻繁，容易把服務(wù)器打死.；時(shí)間間隔太大，又會(huì)阻塞后續(xù)處理步驟。5～10分鐘是一個(gè)合適的重試間隔區(qū)間。鏈接超時(shí)指在服務(wù)器出現(xiàn)問題時(shí)，連接在指定時(shí)間內(nèi)獲取不到數(shù)據(jù)即自動(dòng)斷開。

這個(gè)很容易被忽略-渠道賬單數(shù)據(jù)解析器設(shè)計(jì)。

即：我們拉了很多的不同渠道的賬單，但是每個(gè)渠道的字段的命名不一樣，那我們要把這些字段根據(jù)我們的理解映射到統(tǒng)一的字段當(dāng)中，這樣我們就可以無差別的處理不同的渠道了，但是這個(gè)就要具體情況去具體分析

2. Result（結(jié)果）

商戶對(duì)賬是企業(yè)財(cái)務(wù)管理中的一個(gè)重要環(huán)節(jié)，它的好壞直接影響到企業(yè)的財(cái)務(wù)健康和運(yùn)營(yíng)效率。

以下是一些衡量商戶對(duì)賬好壞的標(biāo)準(zhǔn)：

1. 準(zhǔn)確性：對(duì)賬結(jié)果應(yīng)準(zhǔn)確無誤，確保所有的交易記錄都得到了正確的記錄和核對(duì)。
2. 及時(shí)性：對(duì)賬過程應(yīng)該及時(shí)進(jìn)行，以便及時(shí)發(fā)現(xiàn)并解決可能存在的問題，避免財(cái)務(wù)數(shù)據(jù)滯后。
3. 完整性：對(duì)賬應(yīng)涵蓋所有相關(guān)的財(cái)務(wù)活動(dòng)，包括但不限于銷售、采購、支付和收款等。
4. 合規(guī)性：對(duì)賬過程應(yīng)符合相關(guān)法律法規(guī)和行業(yè)標(biāo)準(zhǔn)，確保企業(yè)財(cái)務(wù)活動(dòng)的合法性。
5. 透明度：對(duì)賬過程應(yīng)該是透明的，所有相關(guān)人員都能夠清楚地了解對(duì)賬的進(jìn)度和結(jié)果。
6. 自動(dòng)化程度：高效的對(duì)賬流程通常依賴于自動(dòng)化工具和系統(tǒng)，減少人工操作，降低錯(cuò)誤率。
7. 風(fēng)險(xiǎn)管理：對(duì)賬過程中應(yīng)能夠識(shí)別和評(píng)估潛在的財(cái)務(wù)風(fēng)險(xiǎn)，并采取相應(yīng)的措施進(jìn)行管理。
8. 成本效益：對(duì)賬過程應(yīng)在保證質(zhì)量的前提下，盡可能地降低成本，提高效率。
9. 用戶友好性：對(duì)賬工具或系統(tǒng)應(yīng)易于使用，便于非財(cái)務(wù)專業(yè)人員理解和操作。
10. 數(shù)據(jù)分析能力：對(duì)賬不僅僅是數(shù)字的核對(duì)，還應(yīng)包括對(duì)數(shù)據(jù)的分析，以識(shí)別趨勢(shì)、問題和改進(jìn)機(jī)會(huì)。
11. 溝通和協(xié)調(diào)：對(duì)賬過程中應(yīng)有良好的內(nèi)部溝通和協(xié)調(diào)機(jī)制，確保所有相關(guān)部門和人員都能協(xié)同工作。
12. 持續(xù)改進(jìn)：對(duì)賬流程應(yīng)不斷根據(jù)反饋和結(jié)果進(jìn)行優(yōu)化和改進(jìn)，以適應(yīng)不斷變化的業(yè)務(wù)需求。

一個(gè)良好的對(duì)賬流程可以幫助企業(yè)減少財(cái)務(wù)錯(cuò)誤，提高資金使用效率，增強(qiáng)企業(yè)的市場(chǎng)競(jìng)爭(zhēng)力。相反，一個(gè)糟糕的對(duì)賬流程可能會(huì)導(dǎo)致財(cái)務(wù)數(shù)據(jù)不準(zhǔn)確，增加企業(yè)運(yùn)營(yíng)風(fēng)險(xiǎn)，甚至可能引發(fā)法律問題。因此，企業(yè)應(yīng)重視對(duì)賬流程的建設(shè)和優(yōu)化。

結(jié)語

總之萬變不離其宗，B端業(yè)務(wù)只要涉及對(duì)賬環(huán)節(jié)，無非就是理清業(yè)務(wù)邏輯，考慮清楚邊緣場(chǎng)景，為商戶呈現(xiàn)準(zhǔn)確清晰的對(duì)賬文件，提升對(duì)賬的用戶體驗(yàn)，為商戶提供更好的對(duì)賬服務(wù)。