想必所有的系統都會涉及到“出賬結算”，只要平臺有交易，就少不了這一步。本文就入手充電運營平臺（國內）建設進行總結，談談運營商賬單/發票/結算這幾類的相關詳情，希望對你有所幫助。

“出賬結算”想必在任何系統基本上都會涉及，平臺只要有交易，那這個功能基本上是必不可少，可能初期是通過人工臺賬進行，但業務多后考慮的是系統自動出賬、自動轉賬及發票全流程數字化管理。

一、賬單類型

運營商入駐平臺，在不考慮采用銀行清分系統情況，平臺按合同約定結算周期，一般T+1最受歡迎（運營商最想的），也可以是T+30（平臺方最想的）。根據合約及可周期性出賬并打款結算。

一般充電運營合約有幾個核心約定內容：生效周期、結算周期、生效站點、抽傭方式（按服務費、按電費+服務費、保底抽傭+浮動比例、固定抽傭金額），運營商賬單會根據這些條件進行自動出賬。

值得注意的是，針對平臺涉及互聯互通給其他平臺，這個結算是平臺與平臺建立的結算體系，并且需要另起合同約定（第三方平臺作為引流會收取一部分傭金，結算給平臺方，平臺方收到款項后再抽一部分傭金，最后跟運營商結算）

綜上所述，可理解兩部分賬單：平臺運營賬單、互聯互通賬單。

T+1一般是第二天凌晨出賬，T+30一般是自然月最后一天，具體控制時間根據平臺充電高峰期進行設置，雖結算周期不同，但國內通用做法會進行每日出賬（匯總），保持更直觀對運營數據查看。

二、賬單異常

異常賬單主要也是兩個因素進行考慮，一是前一天的訂單第二天支付或實際支付幾天后，那這個訂單歸屬到哪個賬單里？二是用戶訂單退款（為結算退款、已結算退款）怎么進行補差？

針對異常情況采用是正常出賬（按支付時間或訂單時間，各日進行出賬）、后補出賬（不滿足出賬條件的訂單，當滿足條件后不會出日賬單，會統一進行賬單出賬）。

為讓運營商更滿意，減少經驗支付風險，平臺進行擔保，按訂單計費出賬。

用戶在進行充電后，可能因為各種原因，導致用戶沒有完成訂單支付，這種出賬按訂單應付金額進行出賬，用戶后續不支付風險由平臺承擔。

平臺按用戶支付狀態進行出賬結算，用戶如忘記或者不再使用，那這筆損失由運營商進行承擔，或者一直等待用戶完成最后交易，這種情況出賬以用戶支付時間為準。（至于作為用戶運營怎么催收、怎么提醒、怎么風控就自行先補補）

案例拆解：結算規則是T+30，合同2023-10-25至2024-10-25

當前是10月29日，正常當天充電當天支付訂單總計10單。

當前是11月01日，正常當天充電當天支付訂單總計13單，當天充電隔天支付訂單總計1單，隔天退款訂單總計1單。

以上總共訂單數=13+1+1=15（后補退款是前面已出訂單）

為什么后補賬單不在每天出？這里主要是實際工作便利，針對訂單時間與支付時間不在同日情況下，統一月度后補，人員對賬就可以對一個異常表格核對并確認，這里后補出賬“退款訂單”出賬金額是負數（退款金額），因為對應的是在“正常出賬”時候進行了金額累加。

三、發票管理

發票有幾種情況，一種是平臺方作為用戶入口，可能存在直接給用戶代開出發票，二是平臺方會將用戶發票推送給運營商，運營商直接開給用戶，三是平臺抽傭+服務費，平臺方開票給運營商。

針對這三種情況，實際就產生了賬單核對無歧義情況，發票怎么處理問題？是先結算后回票還是先開票后結算。如果希望通過系統跟蹤，最好相關約定在合同里，賬單跟著合約走，整個流程“合同 -> 賬單生成 -> 運營商賬單確認 -> 運營商補開發票 -> 平臺方審核 -> 自動轉賬結算 -> 平臺方自主開票”。而針對抽傭+服務費部分則在賬單結算后調取開票系統API，賬單對應的發票做好管理歸類即可。

開票設計功能：運營商開票代開服務、開票稅率、運營商結算發票先回還是先付款。這些都需要配置在合約關鍵參數項里面，從而控制賬單的合理流轉。

四、賬單狀態管理

賬單狀態分三類管理，一是以賬單本身的流轉狀態，二是賬單涉及的開票狀態，三是賬單涉及的支付狀態。

1. 賬單狀態

出賬中- 按結算周期判斷，即周期長的，在未到結算結束日期前都是出賬中。

待結算- 賬單生成，需要人工進行核實（甲乙方確認），這種情況只在前期保留，當賬單全系統驗證不會有偏差或者漏單后，無效人工操作。

結算中-這種就包含兩個事項（發票、支付），賬單在結算支付前都是這個狀態。

結算停滯- 出現賬單異常，運營商有歧義時候可進行申訴或者客服接入，結算屬暫停中，等待人工復核相關內容。

已無效- 指出現問題后，平臺方主動作廢掉賬單（在結算中才可操作），讓系統從新生成一份新賬單。

已結算- 賬單完成最后支付。

2. 開票狀態

（1）收回發票

未上傳 – 等待運營商操作提交

待審核 – 指運營商提交需要的發票，等待平臺相關人員審核。

已駁回 – 運營商提交發票稅率、金額跟合約、賬單對不上等，進行審核拒絕。

已審核 – 發票符合當前賬單要求

（2）開出發票

未開票 – 在賬單未支付情況下，都屬于未開票

已開票 – 開票系統（第三方）返回結果成功及附件地址

開票中 – 平臺收到賬單支付回調，從而發送請求給開票系統（第三方），這等待返回結果期間。

開票失敗 – 可能開票數量、系統問題等導致，這種情況下，平臺需要支持手動補開一鍵操作按鈕。

3. 支付狀態

待支付?– 發票確認無誤前的狀態，確認后，系統調取支付系統（銀行銀企直連）

支付中 – 等待接口返回前的狀態

已支付 – 支付接口返回成功

支付失敗 – 支付接口返回失敗，這種情況下平臺要有重試機制，如金額不足、系統問題，在補全金額或者第三方系統修復后可再次發送請求

五、互聯互通賬單

賬單管理思路同上，這里互聯互通賬單除考慮給運營商出互聯互通賬單，還需考慮出第三方平臺賬單，實際充電數據是在自己平臺，第三方平臺用戶的訂單需要跟平臺進行對齊，這個平臺與平臺的互聯互通賬單不僅僅要實現頁面管理，還要考慮后期的API開放，這樣第三方平臺可實現API初期核賬。