入站 MO 計費對出站 MT：同一本預付費帳上的雙向錢包行

路演只講出站。上線後租號開始收回覆、STOP、偶發語音回撥，錢包多出財務沒寫進模型的行。入站 MO 不是免費禮貌。雙向產品在同一本 prepaid 帳上同時走 MT 與 MO。若匯出只有「發送條數」，財務會把入站借記當成雜訊，直到月用量接近 USD 1,000+ 時才變成商務問題。

IOSOR 是 white-label prepaid：出站與入站同一 ledger，client-safe 錯誤，沒有第三方門戶當日常。目錄 live 才是雙向生產；in setup 不是便宜收件匣。參見 雙向訊息收件匣指南 與 租用號碼上的收件匣事件。先證據，再規模。

財務沒規劃到的 MO 借記

財務模型若只乘 MT 單價，會漏掉租號上的 MO 行：入站簡訊、關鍵詞確認、有時語音事件。這些行在回覆到達時借記，不在行銷日曆上。產品說「我們做了雙向」，財務問「哪一行是入站」。答不上來就不是控制。入站 MO 的計費應在 console 中清晰標示，並與出站 MT 的計費區分開，即使它們共用同一個 prepaid wallet。財務報表必須包含 DLR 狀態，以便追蹤訊息傳遞的完整性，並將入站事件與相應的出站執行緒關聯起來，避免幽靈借記。

同一匯出裡的 MT 與 MO

把 MT 與 MO 放進同一份匯出：時間、號碼、方向、借記額、correlation ID。財務必須能按方向過濾，而不是把入站揉進出站平均。STOP/HELP 是合規行，也是可能借記的行。租號生命週期綁在收件匣上：釋放號碼必須乾淨停入站事件，否則幽靈行會在下月出現。不要用全球平均數掩蓋一條貴的入站走廊。確保 webhook 能正確接收並處理入站事件，並將其與相應的 OTP 或關鍵詞回覆關聯，以避免計費混亂。

自動回覆循環抽乾錢包

無上限的自動回覆會把一次 MO 變成一串 MT，直到錢包空。機器人對機器人、引用原文的 HELP、未冪等的 webhook 重試，都會抽乾 prepaid。給每個執行緒設回覆上限，並把 STOP 寫成立刻抑制。詳見 入站自動回覆循環抽錢包。策略說停時錢包必須停，即使產品還想「再確認一次」。循環樣本在接近 USD 1,000+ 時應進入商務覆盤，而不是凌晨工單。實施 quiet hours 策略，限制自動回覆在特定時段觸發，防止不必要的費用累積。

收件匣事件與關聯

收件匣是證據，不是聊天玩具。每條入站事件應顯示號碼、時間、安全脫敏正文，並在有執行緒時鏈到出站上下文。營運需要可重放的死信，而不是把上游載荷扔給座席。關聯失敗時，財務無法解釋 MO 借記，產品無法證明雙向「有效」。租號續訂按 UTC 自然月；收件匣負責人必須知道號碼何時到期。確保 DLR 報告的準確性，並將其與入站事件的處理時間進行比對，以識別潛在的延遲或丟失。

危險信號

• 財務模型只有 MT 單價
• 匯出分不出方向
• 自動回覆沒有執行緒上限
• STOP 當閒聊，不抑制
• 座席看見原始上游載荷
• 號碼已釋放仍有入站借記
• 目錄 in setup 卻承諾雙向生產

開始使用 IOSOR

在同一條已租 DID 上送一則入站 MO、一則出站 MT。匯出兩列錢包，證明原因碼不同。給自動回覆加頂，入站不得鑄造無限 MT。這是雙向預付列誠實，不是發票週的混合報表，也不是媒體儲存上限。確保 console 中能清晰看到每個 OTP 或關鍵詞回覆的計費詳情，並與其對應的入站事件關聯。

IOSOR 要點

MO 與 MT 共用錢包，不共用一列。入站 MO 的計費應在 console 中清晰標示，並與出站 MT 的計費區分開，即使它們共用同一個 prepaid wallet。財務報表必須包含 DLR 狀態，以便追蹤訊息傳遞的完整性，並將入站事件與相應的出站執行緒關聯起來，避免幽靈借記。確保 webhook 能正確接收並處理入站事件，並將其與相應的 OTP 或關鍵詞回覆關聯，以避免計費混亂。實施 quiet hours 策略，限制自動回覆在特定時段觸發，防止不必要的費用累積。

該做：入站扣款與出站扣款分開標。別做：把 MO 軋進 MT，或把入站列藏到月底。