Odoo 19 Subscriptions: Invoicing, Failed Payments and MRR Decisions
Separate recurring invoices from collected cash, verify tokenization and failure handling, and interpret MRR with a fictional HKD example.

Applicability
For Odoo 19, subject to the plan, hosting, apps, permissions and provider eligibility described below; not every database has these enabled.
Research method
Research based on Odoo 19 and applicable official policies; no new Odoo operation, payment or messaging tests.
Recurring invoicing does not guarantee recurring collection. Decide whether customers transfer money or authorize automatic charges, and name the reviewer for uncertain payment results. This Odoo 19 guide is documentation research; no subscription or charge was executed.
Contents
- Choose recurring billing for a defined service
- Automatic invoicing and payment need different inputs
- Resolve a failed charge before retrying
- Read MRR separately from cash and profit
- Define four acceptance outcomes
Choose recurring billing for a defined service
A fictional Hong Kong maintenance business charges HK$800 monthly for a fixed support scope. Extra on-site work requires a separate quotation. If scope and price must be renegotiated every month, settle those rules before automating invoices.
Configure billing intervals in recurring plans and prepare subscription products/pricing. The documentation does not allow Days as the billing-period unit for subscriptions; do not force daily rental into daily subscription invoices. Check invoice dates, payment terms and service start separately.
Automatic invoicing and payment need different inputs
Automatic charging needs a provider supporting tokenization, enabled provider/payment methods and a usable customer payment token. Stripe is among the documented providers, but merchant-country, currency and method eligibility still require provider checks. Adding a method or paying once does not guarantee future automatic collection.
Customers can save details at checkout or in the portal. Without saved payment details, that flow cannot make future automatic payments. A portal can support this without opening a shop; choosing eCommerce adds Website requirements. Never collect full card numbers in an improvised text field.
Resolve a failed charge before retrying
Odoo documents Payment Failure and Contract in exception after a failed automatic payment. The exception stops scheduled actions to reduce duplicate-charge risk when a result is uncertain; clearing a flag alone does not prove a safe retry.
Inspect the provider transaction and Odoo chatter/invoice evidence first. A confirmed unpaid transaction and money collected with a failed status callback require different handling. For the latter, the documented process includes manually creating/posting the invoice to update the next invoice date before clearing the exception. An authorized administrator should perform developer-mode steps and preserve payment references. Do not repeatedly charge as a diagnostic.
A subscription remaining in Payment Failure is not processed like a normal one. Assign one owner for exception review, customer communication and retry decisions so support and accounting do not both charge again.
Read MRR separately from cash and profit
Illustrative calculation: ten contracts at HK$800 monthly plus one at HK$12,000 annually normalize to 10 × 800 + 12,000 ÷ 12 = HK$9,000 per month. If two monthly invoices remain unpaid, that does not make HK$9,000 the month's bank receipts. Timing, contract states and report definitions need separate checks.
MRR excludes neither staffing nor payment costs and is not a statement of profit or statutory revenue recognition. The example explains normalization, not an exact promise for every Odoo report. Read recurring revenue beside unpaid invoices, churn reasons and fulfilment costs.
Define four acceptance outcomes
Prepare cases for a normal renewal, no saved payment details, confirmed failure and collected money with an uncertain callback. Specify invoice, payment reference, exception state and next invoice date in each. None was executed in this rewrite; this article does not replace payment acceptance testing.
Next write down one contract's interval, payment method, failure owner and service-stopping conditions before enabling automatic collection.
Sources
- Odoo 19 Subscriptions
Recurring plans and invoicing configuration.
Source checked
- Odoo 19 Subscriptions and automatic payments
Tokenization, customer consent and Payment Failure/Contract in exception handling.
Source checked
- Odoo 19 Subscription reports
Recurring-revenue reporting and MRR metrics.
Source checked