適用範圍
適用 Odoo 19；方案、部署、模組、權限及服務商資格依正文條件，並非所有資料庫均已啟用。
研究方法
依據 Odoo 19 與適用官方政策研究；沒有新增 Odoo 操作、付款或訊息實測。
訂閱模組能安排經常性開票，並不保證每期已收款。先決定你的客戶使用銀行轉帳還是授權自動扣款，以及扣款不確定時由誰查核。本指南以官方 Odoo 19 文件研究，沒有建立訂閱或進行扣款。
目錄
適合週期收費還是逐次報價
虛構香港保養公司提供每月 HK$800 的固定支援。固定服務範圍與週期適合訂閱；額外到場工程仍需另行報價。若每月用量與價格均需議價，先釐清合約與計費規則，不要把任何服務都包成無條件自動開票。
在 Subscriptions 的 recurring plans 設定計費週期，再準備訂閱商品與價目。官方文件不允許以 Days 作訂閱計費單位，日租需求不要硬套為每日訂閱發票。開票日期、付款條款與服務開始日也要分開核對。
自動開票與自動扣款的前置不同
自動付款需要支援 tokenization 的支付服務商、已啟用的服務商／付款方式，以及可用的客戶付款 token。官方列出的服務商包括 Stripe 等，但香港商戶、幣別與付款方式仍須按各服務商資格確認。新增付款方式或輸入信用卡一次，不代表之後必定自動扣款。
客戶可透過結帳或入口網站儲存付款資料；若不儲存資料，就不能靠該流程建立未來自動付款。可使用客戶入口網站，不一定要先開網店；選擇網店才需要 Website 等應用。不要在自訂文字欄位收集完整卡號。
扣款失敗時先排除重複收款
官方流程在付款失敗時加入 Payment Failure，並勾選 Contract in exception，暫停排程動作以免不確定的結果造成重複扣款。這不是催款狀態一改就安全恢復的情況。
先查支付服務商交易與 Odoo 討論紀錄／發票，確認是否實際已扣款。未扣款與已扣款但回報失敗有不同處理；官方文件對後者要求人工建立及過帳發票，更新下次開票日，再按流程解除例外。涉及開發者模式的操作交給獲授權人員，保存交易參考，不反覆按付款作診斷。
若仍有 Payment Failure，訂閱不會如一般狀態繼續處理。指定一名負責人處理例外、客戶通知及重試決策，避免客服與會計同時重扣。
MRR 是收入指標而不是現金或利潤
虛構例子：10 份每月 HK$800 合約，加一份每年 HK$12,000 合約，簡化月度換算為 10 × 800 + 12,000 ÷ 12 = HK$9,000。若其中兩份月費未收，不能因此把 HK$9,000 全當成當月銀行入帳；付款時點、合約狀態與實際報表口徑須分別查核。
MRR 也未扣員工、支付費及其他成本，更不等於法定財務報表的收入確認。本例只幫助理解週期正規化，不宣稱等同所有 Odoo 報表結果。檢視 MRR 時連同未付發票、流失原因與履約成本閱讀。
上線前定義四個驗收結果
準備正常續期、客戶未儲存付款資料、扣款確定失敗、服務商扣款但回報不確定四個案例。每個案例列出應見發票、支付參考、訂閱例外及下次開票日期。本輪沒有執行這些案例，不能用本文取代正式付款驗收。
下一步先把一份合約的週期、付款方式、失敗負責人與停止服務條件寫清楚，再決定是否啟用自動扣款。
參考來源
- Odoo 19 Subscriptions
週期方案及開票設定。
來源查核日期
- Odoo 19 Subscriptions and automatic payments
付款憑證化、客戶授權及付款失敗／合約例外處理。
來源查核日期
- Odoo 19 Subscription reports
經常性收入報表及每月經常性收入指標。
來源查核日期