王靜崢

摘 要：在信息化變革深入到各行各業(yè)的過程中，許多商業(yè)或服務業(yè)企業(yè)都開始在線上開通交易入口。大中型企業(yè)交易平臺建設中，往往出現(xiàn)業(yè)務信息流與財務信息流不一致、業(yè)務與財務功能割裂的問題，直接導致財務部門進行交易對賬、資金清算時候出現(xiàn)各種困難，應當以產品化思維解決相關問題。

關鍵詞：財務; 結算; 信息化

在信息化變革深入到各行各業(yè)的過程中，許多商業(yè)或服務業(yè)企業(yè)都開始在線上開通交易入口。小企業(yè)更多選擇與天貓、京東等平臺商戶簽約，而許多大中型企業(yè)會額外搭建一套本單位的線上交易平臺，承載銷售、服務功能。而大中型企業(yè)交易平臺建設中，往往出現(xiàn)業(yè)務信息流與財務信息流不一致、業(yè)務與財務功能割裂的問題，直接導致財務部門進行交易對賬、資金清算時候出現(xiàn)各種困難。究其原因，往往是因為技術人員不熟悉財務知識、無法理解財務需求，業(yè)務部門信息處理流向單一，財務部門缺少產品部門的設計思路。

為解決信息化交易平臺構建中財務模塊薄弱的問題，既需要財務部門具備產品思維、有效梳理信息與資金的關系，也需要財務部門積極溝通、爭取在交易平臺當中融入專門的財務報表。筆者結合自身工作經驗與思考，就產品思維指導下信息化交易平臺的財務報表開發(fā)規(guī)范提出一系列建議。

1.定義財務信息流向

從末端的結果呈現(xiàn)方面分析，財務部門無非需要獲取庫存流轉、收入、成本、資金收付、發(fā)票開收、稅費核算幾個方面信息，而業(yè)務交易平臺在處理過程中，是按照消費、支付、退款、退換貨等口徑設置業(yè)務流程，與財務口徑區(qū)別極大。因此，必須首先確保業(yè)務信息流規(guī)范，進而將業(yè)務信息流轉換為財務信息流。

業(yè)務系統(tǒng)設計過程中，有一種相對簡便的訂單處理機制，即以流線型模式，固定生成訂單的金額、商品信息、支付狀態(tài)和訂單處理狀態(tài)，訂單處理狀態(tài)分為消費、退款退貨等，一旦客戶發(fā)起退款退貨等請求，實時修改訂單狀態(tài)。但這種模式雖然便于交易處理，但會造成財務模塊取數(shù)的巨大困難：（1）財務部門的核算是要求收入的正數(shù)發(fā)生金額與負數(shù)發(fā)生金額分別記錄，避免收入確認與納稅義務混亂，而直接修改訂單狀態(tài)的業(yè)務處理模式會導致財務部門無法追蹤收入發(fā)生與紅字信息，導致收入確認與開票無合理依據;（2）交易系統(tǒng)如設計了主訂單（一級訂單）與子訂單（二級訂單）的模式，財務部門必須花費極大的時間成本定位資金流向與停留節(jié)點。

因此，財務部門為實現(xiàn)交易數(shù)據取數(shù)準確的目的，應當要求交易處理采用日志型記錄模式，具體設計如下：

訂單ID是交易系統(tǒng)自動生成的訂單串號（流水號），其中同一主訂單下的不同子訂單共享同一主訂單ID;商戶類型分為自營與外接商戶，通常是考慮到一些大型公司可能在搭建交易平臺的時候考慮自營之外會接入第三方商戶入場經營，因此會導致自營款項為平臺收入、外接商戶款項為平臺代收代付款的情形，在業(yè)務口徑可以共同作為平臺交易流量，但在稅法與會計口徑適用不同的規(guī)定;定價與折扣金額是交易平臺面向客戶展示的金額，并不能作為財務結算或確認金額的依據;商品ID應當與企業(yè)自建的ERP及交易系統(tǒng)中SKU管理模塊的信息一致;商品結算金額是并根據交易平臺設置的算法確認的特定商戶名下單一品類商品在訂單中的總結算金額;子訂單結算金額是根據子訂單匯總同一商戶下不同商品匯總的結算金額，作為多方分賬依據;主訂單結算金額是同一主訂單下所有子訂單結算金額，作為客戶付款的依據;交易類型分為消費與退款退貨，當用戶消費時創(chuàng)建訂單并標記消費，當用戶退款時以SKU為基礎分別標記退款退貨信息，消費與退款退貨作為不同的交易類型滾動發(fā)生、不得直接改寫原有訂單狀態(tài)下交易類型記錄，避免無法追溯交易轉換過程。除非平臺規(guī)定固定的手續(xù)費金額，否則通常在交易平臺不考慮手續(xù)費，因為支付機構確認的手續(xù)費算法與平臺算法不盡相同，無法完全事先確認。

需要特別注意的是，折扣金額在本質上是面向客戶進行展示的金額，客戶付款、訂單最終價格的生成機制，可能是基于訂單總金額的滿減、單個商品的折扣或客戶使用代金券，以上均為業(yè)務處理系統(tǒng)應當負責的工作，財務模塊只需要要求業(yè)務處理系統(tǒng)根據自身算法將具體折扣金額分攤到單個SKU上即可。財務模塊不應參加對折扣金額的計算、只需要獲取結果，原因在于加載復雜算法將導致財務信息與業(yè)務信息混同，無法最終在多重優(yōu)惠算法下核定各項優(yōu)惠情況并還原為財務信息。

2.對賬結算的信息流

2.1.構建交易平臺與支付機構的信息流

為交易平臺在完成正常的交易后結算準確，必須在訂單與資金方面構建可靠的勾稽關系，主要方式是構建準確的報文機制。

交易過程中，在客戶創(chuàng)建交易并支付時對交易平臺生成的子訂單不會產生感知;支付過程中也是以主訂單為單位進行一次支付、不會分商戶逐一付款。支付機構在受理付款請求的時候也隨之以交易平臺上行的支付請求信息為依據生成支付訂單。

對賬過程中，以銀行（包括廣義的第三方支付機構）為起點，分別發(fā)布對賬文件、結算文件，最終送達交易平臺。

交易平臺在接入支付機構的同時，會根據支付機構的標準接口規(guī)范設置報文格式，此時必須要求交易平臺以主訂單ID為支付訂單上行報文的必要字段，同時要求交易平臺在實時交易結果響應的下行報文中回傳主訂單ID、在對賬文件中同樣包含主訂單ID。因此，整個勾稽鏈條的核心是主訂單ID。

2.2.對賬基礎數(shù)據的抓取與生成

2.2.1.數(shù)據來源

交易平臺應當在接入支付機構時分析不同機構的對賬文件特征。目前市場普及度最高的機構是支付寶、財付通、中國銀聯(lián)等機構，標準化的對賬文件通常包括日期、時間戳、支付流水號、對賬流水號、交易金額、手續(xù)費金額等。交易平臺流水號通常不是支付機構對賬文件必要的字段，但交易平臺方應當作為必要字段并在接口規(guī)范中進行相應開發(fā)。

2.2.2.數(shù)據解析

不同機構的對賬文件雖然核心字段類似，但具體格式千差萬別，需要進行專門的數(shù)據解析，因此需要系統(tǒng)開發(fā)相應的功能自動清洗數(shù)據。

首先應解決對賬文件的格式問題。不同的機構可能選擇TXT、CSV、XLS等文件類型，在抓取數(shù)據的過程中應當注意不同的文件格式，并轉化為本公司統(tǒng)一的文件類型。此外，文本標識符、字段精度等格式問題也應納入考慮范圍，避免匯總過程中出現(xiàn)異常。

其次應解決金額記錄問題。支付機構的資金結算通常采取軋差結算的方式，但不同機構對賬文件的記錄和展示方式也不盡相同。有的機構直接以軋差后的金額作為對賬文件中的結算金額（實際上類似于結算文件），有的機構在同一條記錄中分別設置支付訂單金額、手續(xù)費金額、結算金額對應字段，有的機構分兩條記錄顯示同一筆支付訂單對應的支付金額與手續(xù)費金額、不直接顯示軋差后結算金額。

再次應解決不同的支付類型記錄問題。支付機構的交易類型通常分為正常支付、沖正、退款，交易平臺應當根據不同機構的對賬文件格式識別支付交易的類型并進行標記。

2.2.3.數(shù)據匯總與整理

數(shù)據清理后，應當進行匯總及整理。

首先，應將不同機構的對賬文件信息整理為統(tǒng)一格式，核心字段包括

其次，補足信息缺口。必要的對賬文件要素應包括日期、時間、交易流水號、支付流水號、對賬流水號、支付訂單金額、手續(xù)費金額、軋差結算金額。信息缺口主要在金額字段，需要將要素不全的對賬文件信息進行還原，可以提取交易日志的支付請求金額補足支付訂單金額字段，軋差結算金額字段可能可以從對賬文件直接提取、也可能通過支付訂單金額與手續(xù)費金額添加算法進行計算。

再次，標記對賬文件來源。交易平臺在接入多個支付機構的情況下，應當分別為每條記錄標記交易的對手機構。

3.對賬機制及結果呈現(xiàn)

因為支付機構的對賬結果代表了最終的資金流向，是對賬的總體原則是以對賬文件為準、以支付機構為對賬起點。

交易平臺應提供日期、主訂單ID、支付請求金額，對賬文件應提供支付機構名稱、日期、時間、交易流水號、支付流水號、對賬流水號、支付訂單金額、手續(xù)費金額、軋差結算金額。最終形成的對賬文件應包括對賬通過、銀行多賬、銀行少賬三部分。

銀行多賬通常表明交易平臺因出現(xiàn)掉單、支付機構成功響應超時或其他原因漏記交易，導致交易平臺未生成成功交易訂單、但客戶資金已成功劃扣并將參加結算，因此需要在交易平臺后臺查詢原始記錄，為客戶辦理退款或補發(fā)貨。針對銀行多賬交易，應當為財務部門展示為預收款項。

銀行少賬是另一種單邊賬形式，通常是支付機構失敗響應超時、實時沖正交易失敗等原因導致支付失敗，而交易平臺錯誤記錄支付結果、標記交易成功，進而向客戶辦理發(fā)貨。這種情況下應當及時聯(lián)系客戶辦理補繳款或收回商品。針對銀行少賬交易，應當為財務部門展示為應收款項和發(fā)出商品。

4.資金結算

4.1.支付機構結算

支付機構的資金結算嚴格按照對賬文件的數(shù)據進行，對企業(yè)而言包括對賬通過部分的資金以及銀行多賬部分的資金。通常的結算周期為T+1工作日，即第二個工作日結算前一日或多日（節(jié)假日）發(fā)生的交易款項。財務人員應當及時根據報表數(shù)據與銀行到賬金額進行核對，確認收款信息。

4.2.分賬機制及結算資金流

交易平臺在完成與支付機構的對賬后，即應進行平臺商戶間的分賬及結算。分賬機制以訂單SKU記錄的商品結算金額為基礎，對對賬通過及銀行多賬且客戶認可補發(fā)貨的訂單進行清算。

具體原則是：（1）以交易平臺生成的數(shù)據為準、按商戶（平臺自營作為自營商戶）進行清算;（2）不考慮對客戶的展示價格及折扣，以客戶付款金額進行結算;（3）交易平臺不得軋差結算資金、避免坐扣平臺手續(xù)費。

交易平臺向商戶出具賬單后，經平臺與商戶對賬確認后即可進行資金結算;商戶應向交易平臺支付手續(xù)費、由交易平臺方向商戶開具手續(xù)費發(fā)票。

5.財務口徑下的報表展示

5.1.對賬結算表

對賬結算表用于交易平臺面向支付機構、商戶進行對賬和結算。

5.2.應收匯總表與應付清分表

匯總表通常在宏觀層面匯總企業(yè)在特定期間向支付機構應收的金額，可作為財務部門匯總記賬憑證的依據。

5.3.收入、成本展示

針對交易平臺方自營的商品或服務，可以以適當形式匯總收入、庫存結轉成本、退貨等信息，并作為財務部門核算的基礎。但應注意與企業(yè)ERP系統(tǒng)保持一致、定期核對。

6.特殊情況分析

6.1.實時交易的中間狀態(tài)

在客戶提交交易訂單并發(fā)起支付后，支付機構與交易平臺直接可能因單方系統(tǒng)內部超時或系統(tǒng)間交互超時，導致交易平臺沒有收到支付機構對支付結果的響應，交易平臺無法確認支付結果是成功或失敗。

此時，交易系統(tǒng)應設置針對響應超時的應對機制，及時掛起中間狀態(tài)交易，并告知客戶等待處理結果。通常在次日支付機構發(fā)布的對賬文件中會確認該筆交易對應的支付訂單對賬結果，以對賬文件為準，如果對賬文件包含該筆支付記錄、明確資金參加結算，則應告知客戶補發(fā)貨，否則該筆交易訂單標記失敗，財務系統(tǒng)中不對其進行任何處理。

6.2.支付沖正交易

支付沖正交易是支付機構在成功通知客戶劃扣成功后，實時回退扣款、將資金退回客戶賬戶的操作。與退款交易不同，退款交易通常是交易方發(fā)起、支付機構被動受理將款項退回客戶賬戶的操作，發(fā)生在原交易成功完成、資金參加結算的情況下。沖正交易不會發(fā)生真實的資金往來，僅僅是在成功交易之后由支付機構主動發(fā)起一筆撤銷交易。在對賬文件中，有可能原始交易與撤銷交易同時記錄，也可能完全不記錄兩筆交易，交易平臺在解析對賬文件的過程中應當予以特別注意。

6.3.系統(tǒng)日切時間差異

國內的銀行機構系統(tǒng)日切時間為每日23時，而大部分普通企業(yè)的系統(tǒng)日切時間為每日24時。在每日23時至24時之間發(fā)生的交易會被交易平臺記錄為當日、被銀行系統(tǒng)記錄為次日，因此可能導致跨日單邊賬，交易系統(tǒng)對賬結果顯示為前一日銀行少賬、后一日銀行多賬。交易平臺應當在接入支付機構時關注對方的日切時間，針對日切差異期間發(fā)生的交易進行特殊處置或短時間暫停交易。

目前，第三方支付機構通常采取正常交易機構墊資、非正常交易一概退回的形式，將日切時間強制調整為每日24時，故此交易平臺不需要進行特殊處理。

6.4.客戶扣款但機構未退款

在某些極端情況下，有可能實時交易過程中已經成功扣款，但次日對賬文件并未包含相關交易、資金未正常結算的情況。出現(xiàn)這種情況的原因是客戶作為持卡人，在支付過程中發(fā)卡機構、轉接機構、收單機構分別為不同機構，交易過程中發(fā)卡機構成功扣款的結果因通訊故障或系統(tǒng)時間差異等原因，導致支付參與方記錄出現(xiàn)錯誤，最終資金流與信息流出現(xiàn)差異。

這是一種比較極端的情況，無法通過常規(guī)渠道處理，除非相關機構查詢磁盤信息并進行對賬。因此當客戶明確提供支付憑證后，交易平臺應當發(fā)貨，但因無法正常收款，因此財務上通常需要確認損失。