企業支付結算數字化建設思考
作者做了多年的企業支付結算解決方案,一致專注于支付結算領域。繼前面數字化和中臺之后,這篇分享一下作者對該領域數字化建設的思考。希望本文對參與到企業數字化建設,特別是涉及交易、支付結算、財務的同學們有幫助。
這幾年做了不少企業支付結算解決方案,作為產品專注于支付結算領域參與了從售前、業務方案、產品設計、開發交付到推廣運營落地再迭代的完整生命周期,隨著案例增加和自我認知更新,繼之前2篇企業支付結算文章后有必要再做迭代更新。
一、支付,結算,清結算和企業結算概念要清晰
支付:字面意思就是一方付錢一方收錢的過程?;诮灰?,由買方付錢,賣方收錢,買方消耗自己擁有的資產,權益或債務(理論上只要賣方認可,一切皆可支付,本質上是信任機制下的憑證轉移),完成交易支付,包括付款和收款;
結算:交易維度有實際的資金(或資金等價物)轉移,財務維度做相應的債權關系轉移;
清結算:可以拆解為清分,清算和結算。
- 清分:一筆交易,記錄各參與方基于這筆交易的應收應付(以用戶在淘寶上下單使用支付寶成功支付為例,1個是淘寶作為交易平臺會做清分(平臺分賬),計算出商家貨款和平臺傭金(如有優惠活動,需要增加優惠分賬的邏輯);另1個是支付寶作為收單機構,計算出渠道費用和商戶落賬金額);
- 清算:專指金融機構之間通過備付金或準備金做資金轉移;銀聯或網聯作為有清算資質的金融機構,記錄本次收單支付涉及各金融機構(一般由收單方、銀聯/網聯、卡方)的金額,并通過大小額等專項通道對接央行,最終由央行完成各金融機構之間專戶的資金清算;
- 結算:最終由金融機構完成對商家,淘寶法人主體的資金結算,完成最終的資金結算收款。
企業支付:企業作為買方或買方基于自有資金參與付款和收款,按賣方對象類型是否為企業可分為公對公和公對私支付;
- 性質:公對公支付涉及企業對公賬戶資金轉移,公司名義開設,包括基本戶、一般戶、專用戶等;公對私涉及的是企業將資金從對公賬戶轉移到個人賬戶,這可能是因為股東分紅、員工工資發放、費用報銷等情況。
- 用途:公對公轉賬通常涉及商業合作、貨款結算等正規商業活動,資金往來透明度高,監管嚴格;公對私轉賬可能涉及個人消費、儲蓄等,操作更為靈活,但也更容易涉及挪用公款、偷稅漏稅以及洗錢等風險。
- 監管程度:公對公的資金往來一般是有據可查的,銀行的監管不那么嚴格;公對私因為可能涉及上述風險,銀行對此監控較嚴,需要提供相關資料。
- 風險:公對公的風險相對較低,因為涉及的是正規商業活動;公對私可能涉及多種風險,包括挪用公款或偷稅漏稅等。
企業結算:企業和服務方做資金結算,完成收入支出,必須滿足企業的財務核算規則:交易信息流,資金流,銷項進項發票必須做到可一一核算,相互匹配關聯;
憑證:分為交易原始憑證和記賬憑證,訂單,小票,出庫單,發貨單,發票,高鐵票等都是我們常見的交易原始憑證;記賬憑證根據原始憑證填制,記載經濟業務簡要內容,確定會計分錄,作為記賬依據的會計憑證。
對賬:賬證實(交易賬務,交易憑證,實物/資金)的核對,本質上是為了確保同一個事務的數據描述在不同業務或系統下記錄一致而進行的相互之間的一致性比對(對比的對象可以是單據或賬戶,對比的維度可以是明細,總數或計算后的統計數據);
賬單:統計賬證實流水,周期性的生成流水清單,便于買賣雙方按需了解和確認交易,收付和履約等相關情況;
渠道和路由:支付結算需要有處理來源,誰提供處理服務誰就是渠道,有多條支付結算處理源時,就需要做路由,基于路由規則(靜態或動態規則)明確走哪條渠道實現支付結算。
二、企業經營和財務要有認知
2.1 企業經營
我們把企業經營按管理到執行從上到下,拆分為戰略,經營模式,業務能力和流程,然后基于和支付結算業務的關聯度,重點放在業務能力和流程上面。
戰略:支付結算作為企業業務交易的一環,可弱化對企業戰略的洞察要求,了解即可。
經營模式:
- 熟知企業的經營模式,在行業中的定位和價值;
- 熟知主營業務特別是核心業務的完整流程,是怎么產生收入,支出和利潤的;
- 熟知和上下游怎么做業務往來和收付結算。
業務能力和流程:梳理出企業經營中和上下游及內部的核心業務能力,這里以制造類企業為例梳理了主業務能力,和業務對象,業務流程,企業組織架構的關系(這點對后續業務架構,數據架構設計,系統上下文串聯非常重要)。
2.2 財務認知
財務:財務這塊,之所以單獨拎出來,主要是考慮到:
- 企業作為法人組織,需要嚴格的在國家和企業自身財務規則下經營業務,做到合規;
- 財務作為企業專業職能(監督,核算,并提供財務數據支撐企業業務決策),和支付結算息息相關;
- 財務相關的職能部門,是企業支付結算業務的主要業務對象,涉及職能管理,組織協作,流程管理,最終實現業務和財務的流程閉環。
作為企業支付結算產品經理,個人認為對財務的認知,思維上需要對企業的經濟活動有財務角度監督和核算的思維;專業上對初級會計內容要有基本熟知,可以和財務人員做方案溝通,下面是個人梳理的支付結算產品要懂的財務知識。
三、業務方案
基于企業經營業務能力,對象和流程梳理,可以梳理出完整的收付款業務能力,對象和流程,并結合企業實際業務場景和數字化程度,形成完整的企業支付結算業務架構。
下面按業務目標,業務場景,業務架構來具體說怎么形成業務方案。
3.1 業務目標
支付結算產品定位上用來更好的支撐企業完成交易收錢和付錢的閉環(業務交易閉環,財務監督和核算閉環);有效并靈活的支撐交易在線(滿足企業服務可以靈活的觸達B端和C端用戶,特別是新業務的在線交易);通過搭建標準的支付結算服務,可做快速技術對接,不再需要煙囪式的開發,降本增效;當企業經營業務不斷通過標準的支付結算服務產生交易數據,可以不斷的產生從交易,支付結算,發票到賬務的完整數據,以實現數據賦能業務打好基礎。
3.2 業務場景
從業務模式的角度看,其實就是業務參與方的利益分配,我習慣用交易對象的角度來鎖定業務,分為雙方交易和多方交易(雙方交易的多個組合),雙方交易好理解:就是交易的生命周期中只有買方和賣方2方參與并完成(比如街道上擺菜攤的大媽,我付現金買菜)。
多方交易理解為:交易的生命周期中有多方參與,形成了多個“雙方交易”才能完成交易閉環,最典型的就是電商業務。
以淘寶為例,涉及的參會方一般會有平臺、商家、快遞公司、用戶、收單支付機構等。
明確完交易對象,可以更好的理解涉完成一個交易場景,涉及多少交易業務,理解基于交易怎么做支付、分賬、結算、發票和稅要怎么走。
下圖是典型的BBC平臺交易:
3.3 企業結算方式
一般分為按單/合同結算和對賬結算,按單結算主要是電商場景,交易訂單完成履約閉環后,結算給商家對應的訂單貨款(可提現);對賬結算主要是企業之間的結算,需要周期性的生產賬單進行賬證實的核對,完成核對后確認賬單并進行付款結算,比如我們常說的日結,月結,企業越大,溢價權越高一般結算周期更長。
企業間交易使用先貨后款為多(有自己的授信體系,詳細可見企業數字化系列——授信業務數字化設計),很品牌溢價權的則喜歡現款后貨,收取預付款;另外除了支付現金外,在大宗交易場景,存在很多票據支付的情況。
3.4 業務架構
業務架構的核心作用是在了解完企業所有的經營業務,對象和流程后,可以梳理清楚所需的完整業務能力,并未后面的產品設計打好業務框架。
下面支付結算業務架構覆蓋了一般企業全渠道業務在線運作所需的支付結算業務:
四、產品設計
基于業務架構,切入場景,搭建產品架構,并按領域驅動設計方法論對支付結算產品架構做領域劃分和中心設計。需要對底層的數據和基礎技術有系統性了解。
4.1 領域設計
業務需要邊界,產品和開發設計都需要邊界,這是我理解的領域概念,作為支付結算產品,就應該做好支付結算領域內的事,什么都做就等于什么都沒做,好的領域設計要確保獨立性和可擴展。
我把領域設計分成2個維度,橫向的業務領域,通過定義不同的業務對象做區分;縱向的架構領域,通過分層來解耦業務對象處理問題的復雜性(業務驅動領域設計,so不是業務領域,分層設計越多越好,比如只通過微信小程序試點自營商城業務,為了快速驗證業務,只需要能做微信小程序支付足以)。
4.2 業務需要閉環
當了解了企業客戶的整體業務和后面的戰略規劃后,就可以規劃需要做哪些業務領域的設計來支撐當前業務,又滿足后面的可擴展(需要平衡效率和成本,分的越細,技術上分布式事物的一致性設計越復雜,產品上看新業務的驗證和打磨更關鍵)。
支付結算領域,正常都會分為支付,清結算,對賬,賬戶,計費和財務集成,下面拿一筆企業交易的整體流程形成完整的業務上下游閉環。
其中:
- 支付核心是支付訂單,主要是明確交易的支付來源,收付款方,金融,支付方式和最終執行支付的處理源(支付渠道);
- 清結算核心是結算單,主要是明確基于交易的應收應付,結算的渠道做資金結算;
- 賬務核心是賬戶(一般涉及到金融端的銀行結算戶,支付機構的支付賬戶,交易端的賬簿);
- 對賬核心是對賬單,涉及對賬數據(賬證實)的接入,清洗,對賬處理,差異處理,賬單輸出;
商戶就是參與到交易的交易對象,基本分為個人,企業和個體戶,賬戶都需要關聯到對應的商戶下面(按賬戶權限做商戶認知,比如收單特殊商戶需要做實體認知)。
4.3 領域架構設計
我理解的業務架構,通過層級來定義同1個業務的輸入和輸出邊界,通過模塊來定義同一層的不同能力或者服務,比如很多架構都會有應用層,邏輯層或物理層等。
對于支付結算領域來說,個人習慣應用層,邏輯層到核心層的3層或2層設計,應用層做服務的輸出,邏輯層做業務解析和領域內的邏輯處理,核心層定義業務對象的核心能力和屬性。
以聚合支付服務為例,應用層就是標準的聚合支付服務接口輸出,外部應用通過調用接口獲取聚合支付服務,獲取到支付的業務訂單數據后做業務解析,明確收付款方,支付方式等信息,通過支付路由規則明確支付方式對應的渠道。
有些場景(比如組合支付)還涉及邏輯的處理(組合支付需要基于主支付訂單,拆分多條支付渠道流水,并要求所有的支付渠道流水成功才算組合支付成功),核心層就是拿著明確的支付方式,支付渠道,收付款方和金額等信息調用支付渠道做最終的支付處理。
業務驅動支付產品設計。
五、平臺運營
企業支付結算平臺只是工具,要給企業帶來價值,需要有業務主人(一般需要由專職財務,產品和市場業務人員組成專項組織)基于平臺的功能和對外服務做運營推廣,迭代優化和數據服務賦能企業管理層決策。
5.1 運營推廣
運營主要包含企業金融資源對接,支付結算渠道管理,異常數據監控。支付結算平臺搭建后,只有不斷的服務好新的業務場景,才能不斷給企業產生價值。推廣過程主要包含:
- 輸出平臺可以提供的支付結算渠道資源和服務功能清單(API接口清單),明確自己的定位,能提供哪些服務,解決哪些問題;
- 了解新場景交易模式,支付結算場景及需要解決的痛點;
- 基于推廣場景需求提供支付結算解決方案,協同業務,財務還有金融渠道方做方案確認,一般財務會從監管和賬務維度做評估,金融渠道會從資金監管維度做評估;
- 提供對應的支付結算接口清單做對接說明,進入開發聯調測試階段;
- 協同業務,財務還有金融渠道方做上線方案確認,執行上線。
注意點:
1)基于自身定位,需要明確業務,財務,金融渠道和支付結算平臺的邊界,一旦涉及平臺范圍外的需求,產品層面需要和項目經理或相關領導確認,該走什么流程就走什么流程;
2)作為多方參與集成開發,接口說明和聯調測試非常重要,盡量在前期就把問題暴露出來;
3)上線方案必須多方一起確認,可能涉及歷史交易數據遷移;
4)早期支付結算平臺搭建,可以弱化風險管控,主要針對異常交易數據做監控,主要是:
- 推廣的交易場景一般都是企業內部子公司業務,業務可管控;
- 企業財務目標和規則基本一致(過不了是不讓開發的);
- 資金監管由金融機構管控;
5.2 數據服務
隨著支付結算平臺推廣的交易場景增多,會源源不斷的產生支付結算數據,可以通過幾種形式輸出數據服務:
1)周期性的輸出各種類型的支付結算數據報表供企業財務和業務方查看;
2)提供數據給企業統一的數據平臺(數據中臺,數據湖,數據倉庫等);
3)監控異常數據,輸出異常數據分析報表,來優化產品,對接更安全有效的支付結算渠道,優化業務交易和財務中可能存在的風險;
4)提供統一的上下游交易數據核對服務。
5.3 迭代
支付結算平臺準守MVP產品的迭代思路,以滿足切入的具體場景需求來定義搭建的服務能力。
迭代的整體思路按平臺的縱向專業能力和橫向推廣能力推進,其中專業能力按各領域中心自身規劃需要的完整服務能力迭代,橫向主要結合業務場景推廣會對接更多的金融資源,提供更多的支付結算服務選擇。
5.4 支付結算數字化案例
這里還是以HE集團為例,作為國內最大的幾家家電企業之一,企業戰略上開始從傳統分銷到賦能分銷商,直接觸達終端客戶提供零售服務的轉型,通過企業數字化,實現庫存在線,交易在線,資源在線,營銷在線和組織在線,以更好的支撐服務多元的交易場景,嘗試新的服務業務,通過標準化業務獲取完整的有效數據,并驅動數據賦能業務。
支付結算以開發平臺的產品形態,統一對接金融和企業授信,返利等資源,輸出標準的支付結算和賬戶服務來滿足2B,2C的不同交易場景。
六、業財一體
業財一體的核心在于業務對企業經營要有財務思維,你可以理解為企業所有的經濟活動,理論上都可以按財務規則翻譯并做賬務處理,因此不是說企業數字化后才開始有業財一體,而是之前企業業務和財務割裂,很多企業只有到算總賬時候才發現不是業務沒有賬,就是記賬業務說不清楚,分析起來也是因為統計口徑不同,錯誤百出。
同時財務只注重管控,做的是核銷的人力活,特別是月底結賬,出季度年度報表的時候,苦不堪言,因此業財一體的另一個核心在于財務要對企業經營心里有底,從財務管控到財務經營,賦能業務。
支付結算平臺一般切入企業全渠道銷售場景,上下游分別有具體的業務交易履約和財務賬務,資金結算場景,是業財一體非常好的切入點和基礎服務,讓各種交易憑證(訂單、出入庫單、發票、下票等),資金支付結算流水,記賬憑證可以基于具體的交易場景和節點自動關聯,完成核算。當然也可以從財務主數據管理,搭建統一的預算費用平臺等切入點出發,逐步實現業財一下化。
七、總結
企業支付結算產品從戰略角度是企業數字化轉型的一環,因此整個產品規劃和設計的核心依賴于企業數字化戰略和搭建方法論(比如企業架構框架TOGAF),同時從專業角度,企業結算,財務基礎和中國支付清結算體系又是必須要賬務的,最后才是基于企業的實際經營情況出解決方案,迭代落地。
本文由 @哈哈的鯨魚 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
非常棒,將清分和清算單獨抽離,我也覺得是個非常好的實踐,可惜現有大部分的b端系統未將兩個模塊獨立,企業系統的迭代太慢了