支付清結算之對賬
隔了一周才來寫這篇文章,前一篇文章介紹了自己在渠道路由的處理經歷也得出了降低渠道成本的結論。這周正在做支付定向營銷方案,還在規劃中待后續有結果了再分享給大家。今天我主要說一下自己對于對賬的經驗和理解。
一、對賬介紹
看這篇文章的相信大家對支付都有了解,對于對賬來說應該不陌生,肯定也明白對賬的目的。簡單例子,就是你和另外一個人做生意,約定的結款是月結,他每天都從你這里進貨,你會記賬說我應該收多少錢,他也會記賬說他應該付多少錢;在月底結款的時候,他會說我應該結1w給你;然后給你一個進貨的明細單子,你拿著這個單子和你自己的單子對比看是否正確,這就是對賬。只是支付系統的對賬涉及到其他賬務處理事情相對感覺會比較復雜而已。
說到對賬,個人感覺不同公司業務場景不同對于對賬的訴求也就會有差別。比如我之前待的一家公司是做預付卡的,持有預付卡發行與受理的牌照,公司的商業就是純以支付為主,對賬只會存在與支付渠道的對賬,確保實收與應收相平,受理商戶則自己進行業務對賬,平臺只提供對賬單;現在這的這家公司有所區別,它應該跟其他具備支付牌照的互聯網公司業務類似,支付更多應用于公司內部業務場景,這種情況下由于公司職責劃分等的不同,對賬這塊就會分為渠道對賬和業務對賬兩塊,渠道對賬就類似上面的情況與支付渠道進行對賬確保應收和實收相平,業務對賬其實就是把支付作為外部公司看待,站在公司業務的角度完成業務的交易數據與支付對賬單的對賬,確保業務應收與實收相平。
二、渠道對賬
那我先來說說渠道對賬,這塊大家應該了解的最多。一般對于一個做支付的產品來說,接觸到這塊的機會應該不會太多,因為這塊基本上是在支付早期就會建立好的,后續基本就是簡單優化。
說起渠道對賬,由于支付渠道提供對賬單的方式不同進行渠道對賬的方式也就不同,總的來說對賬方式分為兩類:
- 自動對賬
- 手動對賬
1、自動對賬
自動對賬主要針對支付渠道能提供線上對賬單的渠道,如支付寶,微信,某些銀行等。
支持線上提供對賬單的渠道又會依據提供對賬單的技術方式進行細分,如:HTTP,HTTPS,FTP等,以及對賬單格式也不同 如:文本,XML,CSV等,對于這種是依據外部渠道為準,沒辦法統一標準的,基本都是在線上獲取后對賬單后通過定制化的腳本進行解析和轉換成標準格式。
對于自動對賬會涉及到支付渠道,資金對賬計劃,解析腳本等。 資金對賬計劃執行步驟與邏輯如下:
- 先會去拉取渠道的對賬單
- 拉取后根據編寫的對應腳本進行解析和格式轉化
- 將標準的清算流水與對應的對賬日的入賬流水進行對賬
- 生成對賬結果
2、手動對賬
手動對賬主要針對的需求是部分渠道不提供線上對賬單,即只能去渠道的商戶管理后臺下載或者是其他約定的手動方式獲取到的對賬單 比如 郵件每日發送等。
這部分功能相對就比較簡單,財務人員獲取到對應的渠道對賬單后,手動根據對賬模板整理成標準的對賬單并上傳到系統,并手動觸發對賬操作。邏輯流程如下:
- 財務人員按標準格式上傳對賬單到系統
- 上傳成功后,財務人員查詢上傳的清算流水并觸發對賬任務
- 對賬處理 并 生成對賬結果。
PS~ 我這里更多聊得是產品邏輯和設計,對于對賬的技術細節和具體處理大家也可以參考人人都是產品經理專欄作家鳳凰牌老熊寫的文章:《支付系統設計:對賬處理(二)》
上述完成對賬后,對賬結果有差錯怎么處理了? (這部分跟賬務處理有關, 會涉及到一點會計知識,這里簡單介紹下)
上述兩個步驟生成的對賬結果會有三種情況:
- 多賬:即約定日期的交易數據,支付渠道的數據多了。
- 少賬:即約定日期的交易數據,支付渠道的數據少了。
- 金額不符:即約定日期內的某筆交易,交易金額不同。
針對這三種情況,一般發現人都是財務,財務會根據將這些異常情況反饋給渠道與支付團隊進行定位,但是定位這個并非立馬就能出結果,有可能一天,有可能三天,有可能更久,那這些差錯賬不可能等著定位完了再處理嘛,那每天生成的支付會計報表里面就沒法體現出真實的資金情況。
一般對于上述三種情況,我們會與財務約定好具體操作,如下:
- 先反饋給渠道與支付團隊進行定位,排查系統問題以避免更大的影響。
- 對于未查明原因的多賬情況,可以先進行掛賬處理(會計處理的一種方式),待后續查明原因后進行銷賬;少賬的情況一般都是渠道清算流水少了,這種一般是依據渠道反饋新增清算流水,或者是渠道會在隔天補全這部分流水,這種就無需處理待隔天再查看即可;對于金額不符,一般都是讓渠道進行核實,如果確實是渠道錯誤則修改清算流水金額,如果是我方系統問題,則需要定位后完成系統修復,并根據實際問題進行相關登賬處理(會計處理的一種方式)。
有了上述的對賬功能和處理機制,更難的是與財務溝通與協調,形成一套標準的業務流程機制并及時完成,只有對賬能及時完成并發現問題才能保證資金流轉的準確,避免資金問題。附上與財務溝通確定的業務流程簡圖:
三、業務對賬
如果對上述的渠道對賬理解了,業務對賬相對就會容易很多。業務對賬的實質就是設計者角色的轉變,渠道對賬中設計者是站在支付系統的角度考慮,與支付渠道進行對賬;業務對賬中設計者是站在使用支付系統的業務方角度考慮,與支付系統進行對賬,本質上沒有區別。
業務對賬系統的需求可能不同公司差別會很大,因為業務對賬這塊基礎模塊即完成業務交易數據與支付系統的對賬,產生的對賬后歷史交易數據的處理需求可能會差別很大。這里我就先介紹與本文相關的重點即對賬。
業務對賬相對要簡單的多,因為畢竟是公司自有業務的對賬,對賬方式可以完成統一,即線上+固定交互方式(如HTTP+xml)等,基本可以實現完全自動化處理。具體自動化處理流程如下:
- 自動對賬任務 自動獲取支付系統與業務的對賬單
- 根據配置的對賬規則對對賬單進行解析與入庫
- 對賬處理
- 形成對賬結果
形成對賬結果后,后續基本為財務進行賬務相關的操作以確保賬務平衡了(與渠道對賬類似),這塊會涉及到大部分會計相關知識,后續我會專門抽一篇文章來寫。
好了,對賬就先寫到這里,很多細節可能需要根據實際公司場景來做調整。如果有什么問題,歡迎留言探討,希望分享的內容能對你有價值,感謝!
相關閱讀
本文由 @黑鍋我來扛?原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Pixabay,基于 CC0 協議
對于借貸平臺的對賬,期待來一篇
業務對賬和渠道對賬是什么意思還是不理解T T,求再通俗點的解釋~
支付系統學習中,個人理解哈~:
1. 業務對賬:支付系統與業務側對賬。業務側比如交易系統,支付系統跟交易業務系統的付款、退款等資金流水對賬,保證兩邊系統的應收實收對得上,沒有多收或者少收錢
2. 渠道對賬:支付系統與渠道側對賬。渠道側比如某銀行,支付系統跟那個銀行的賬單對賬,保證兩邊系統的應收實收對得上,沒有多收或者少收錢
流程不錯,專業名詞可以稍微優化下,如果能加上對賬的一些規則條件就更好了
對于借貸平臺的對賬,期待來一篇
看見你這個我下載進來的,這里面我還可以招聘人員是不是啊
流程和邏輯都很不錯,就是里面一些專業的名詞說法有點問題 ??
多賬 少賬應該是指長短款吧,看起來有點小 別扭
做賬務工作,還是有點會計基礎好一點,比如,你說長款,短款,就比說多賬,少賬逼格高一些
??
個人覺得,按照樓主這樣表達就可以了,畢竟很多人都不懂長款,短款是什么意思
那得在哪里說啊,現在面對的是一群想學習的人,說得對方聽懂才是關鍵!
寫的真不錯!
學習了!