報表檢視與原始錢包總帳列之比較

報表檢視與原始錢包總帳列在月結資料夾中看起來非常相似，但它們回答的是完全不同的營運與財務問題。報表檢視專門為產品和財務團隊彙總已送達(Delivered)、失敗(Failed)、未知(Unknown)狀態以及相應的扣款支出。而原始錢包總帳列則是用戶預付帳戶中每一筆實際發生的扣款、預留、退款或加值明細。

IOSOR 嚴格維持這兩者的界線。當您需要產品或財務的總體彙總數據時，請匯出報表；當您需要驗證每一筆資金預留、扣款、退款和儲值紀錄時，請開啟錢包總帳。將兩者混為一談只會創造出第二套資金真相，進而引發內部稽核與客戶爭議。

報表檢視彙總產品與財務真實數據

報表檢視的核心功能是回答特定傳輸通道(Corridor)的表現狀況：包括已送達比例、未知狀態比例、延遲區間以及相對於預付餘額的總支出金額。產品團隊利用這些彙總數據進行新服務上線後的效能審查；財務團隊則在結算週使用完全相同的彙總資料進行對帳，而不是使用一套包含不同狀態標籤的私有試算表。

請確保報表欄位嚴格遵循統一的 DLR(派送回條)術語定義。已送達(Delivered)代表收到了終端電信商的明確回條；已送出(Submitted)絕對不等於已送達；在收到最終回條之前，未知(Unknown)狀態必須保持為未知。如果報表擅自將未知狀態歸類為『成功』，產品與財務團隊後續必然會與錢包總帳產生嚴重的金額衝突。

原始總帳列保留於錢包模組

錢包模組在每日或每月 02:00 執行的月末匯出作業是標準的總帳任務。該檔案詳細列出了預扣(Hold)、實際扣款(Debit)、退款(Refund)與加值(Top-up)等單一明細行。這份檔案的唯一目的是證明資金的實際流動，而不是用來繪製產品的送達率圖表。如果強行將總帳明細行貼入產品儀表板中，極易導致退款被重複計算，或是漏掉多分段簡訊(Multi-segment)的扣款細節。

營運團隊應將所有資金爭議案件直接引導至錢包模組，而將送達率或回條爭議引導至報表與 DLR 排查路徑。切勿透過修改報表 CSV 檔來『修正』缺少的扣款紀錄。錢包總帳是唯一的資金真實來源；報表的作用是向總帳進行核對，而不是取代總帳。

營運指標匯出是同級時鐘而非總帳

在 02:00 執行的營運指標匯出作業主要用於追蹤佇列深度(Queue Depth)、Webhook 新鮮度、延遲時間與錯誤區間。雖然它與錢包匯出共享相同的月結時間點，但它既不是錢包資料的傾印，也不是財務開立發票的依據。營運人員應使用此指標來解釋異常偏高的未知狀態或延遲現象，然後返回報表查看總額彙總，並返回錢包查看資金明細。

白標 DLR 延遲報告必須保持真實透明：延遲區間可以用來向企業客戶解釋客服工單的處理情況，但絕不能將未知狀態重新命名為已送達。報表可以引用這些延遲區間數據，但不能藉此創造出另一套平行總帳。

拒絕將總帳列貼入報表包的混合型 CSV

如果一個壓縮包中同時混雜了『report_success.csv』與原始扣款列，這將會誤導組織成員將報表檢視當作資金轉帳的憑證。團隊必須堅持發布兩種獨立的產出物：報表包(包含彙總欄位、DLR 狀態與支出總額)以及錢包總帳匯出檔(包含各項明細行)。當合作夥伴要求在單一檔案中提供『完整資金與發送報表』時，正確的做法是提供兩個獨立連結：報表連結用於檢視彙總，錢包連結用於查閱總帳列。

相關營運路徑

• 錢包月末匯出於 02:00
• 02:00 營運指標匯出
• 向企業客戶解釋派送回條延遲指標

從 IOSOR 開始

請從主控台匯出每月的報表檢視，藉此核實產品審查所需的通道投遞率與訊息回條延遲彙總。若要稽核扣款、保留款與退款且避免狀態變更遭重複計算，請務必直接從錢包專區擷取原始帳本明細項目。請將帳本匯出檔案交付給財務部門，並將報表包交付給產品負責人，作為兩個獨立的產出。

IOSOR 要點

將原始扣款明細混入彙總的產品報表中，會產生失真的支出指標，並重複計算已退款的訊息片段。報表檢視可確立通道健康狀況與投遞真實性，而錢包帳本則能提供財務餘額變動的不爭證明。

請務必於月底發布兩份獨立的匯出檔案——一份供營運團隊使用的報表彙總包，以及一份供會計部門使用的專屬錢包帳本匯出檔。切勿將原始的帳本扣款列貼到投遞儀表板中，也切勿將彙總的報表檢視視為明細對帳單。