IOSOR 知識庫

報表必須對齊 DLR 送達回執而非提交數量

已提交不等於已送達。財務與產品報表匯出必須遵循 DLR 送達回執——切勿僅憑接受傳送總數進行週結算請款。

提交數量(Submit counts)讓人感到安心：代表 API 已成功接受訊息，因此本週維運看似「正常運作」。然而，這種心理安慰會徹底破壞請款週與財務對帳的精確度。將提交量等同於成功的報表，必然會與 DLR(送達回執)、多分段流量的預付錢包扣款以及 Webhook 稽核日誌產生嚴重矛盾與不一致。

IOSOR 嚴格鎖定這項維運規則：報表匯出必須嚴格遵循送達回執。已提交(Submitted)、排隊中(Queued)和已接受傳送(Accepted-for-send)僅能作為維運層面的過程軌跡與除錯紀錄。真正供財務與產品團隊審核、爭議對帳與計算利潤的核心欄位，永遠只有已送達(Delivered)、失敗(Failed)和未知狀態(Unknown)。

已提交是過程軌跡，而非結算指標

「已接受傳送」僅能證明系統與閘道成功接受了該項任務，並不能證明目標用戶的手機已實際收到簡訊。如果您的報表套件將提交量視為核心 KPI 或成功率分子，那麼當電信業者網路出現延遲、未知狀態增加或終端失敗比例上升時，您將大幅誇大營運成功率。如果對維運觀察有用，請將提交量保留為網路吞吐量觀察欄位，但絕不可將其作為已送達的替代指標或計費依據。

建立正確的週結算復盤習慣：開啟報表時，必須先檢視 DLR 狀態欄位——包含未知、失敗與已送達數量——接著再快速查看提交總量以瞭解整體流量規模。產品發布復盤與客戶報告也應遵守相同順序，確保行銷或商務團隊無法在週中隨意變更數據定義來重新定義成功標準。

匯出欄位必須遵循送達回執

報表匯出結構必須明確命名並區分回執狀態。已送達(Delivered)必須具備來自電信業者的終端 DLR；失敗(Failed)必須具備終端失敗信號與對應錯誤碼；未知(Unknown)在收到明確回執前必須保持未知狀態——它絕非「軟性送達」或預設成功。在請款週中將未知狀態隱藏或歸類於成功數據內，必然引發典型的「未知佔比不等於已送達」財務爭議。

當多分段簡訊計算與最終帳單金額出現分歧時，請從具備回執支持的資料列及其實際分段計數開始核對，而不是拿提交總數乘以估算的平均分段倍率。簡訊請款週的分段核對路徑與此緊密相連，但報表系統依然必須堅決拒絕將提交量直接視為已送達。

依據相同的回執核對 Webhook 與總帳

針對預付總帳匯出資料進行 Webhook 稽核對帳，是證明報表真實不虛的核心方法。每日 Webhook 接收日誌、DLR 最終狀態以及預付總帳扣款明細必須呈現完全一致的敘事。如果 Webhook 紀錄顯示發送失敗，而財務報表卻顯示成功送達，則該報表絕對存在錯誤——您應該立即修正報表匯出邏輯，而不是去「手動調整」預付錢包的餘額。

保持維運稽核流程的嚴謹與規範：隨機抽查指定一日，對齊 Webhook 回執紀錄、預付總帳匯出明細與報表套件，並精確比對訊息 ID(message ids)。發現數據缺口時移交維運團隊處理，任何虛構的成功數據則應直接退回給資料庫與報表結構負責人修正。

拒絕僅依據提交量進行的帳單週結算

任何僅依據 API 提交數量進行計費或慶祝的結算流程都應被強制阻斷。請重新編寫您的報表套件，讓財務團隊能夠圍繞已送達與未知佔比進行交叉分析。即使合作夥伴或客戶合約中仍記載「成功的 API 提交」，也請將該用語翻譯為 DLR 補充說明與實際送達數據，切勿為了迎合不正確的文字表述而扭曲系統欄位定義。

從 IOSOR 開始

在 IOSOR 控制台打開本週報表包，確認每個頭條 KPI 都依 DLR 回執（delivered、failed、unknown）統計，而不是 submit 或 API accept。若圖表仍把 submit 當成成功，先改名或刪掉再開帳。匯出一次，讓產品與財務共用同一套回執欄位。

IOSOR 要點

報表以 DLR 回執收口：delivered、failed、unknown，不是 submit。submit 只衡量吞吐，不能當送達真相，也不能拿來吵帳單。

要做：鎖定一份回執欄位匯出。不要：產品慶祝 accept，財務卻拿 failed DLR 對帳。

這篇指南有幫助嗎？