Back to all articlesSales & CRM

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.

APAAPublished Content updatedApplies to Odoo 19
Odoo 19 Subscriptions: Invoicing, Failed Payments and MRR Decisions
Illustrative cover image, not an Odoo operation screenshot or client case.

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

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

Considering Odoo for your business?

Talk to APAA about a tailored Odoo implementation for your Hong Kong SME.

Enquire about Odoo services
Odoo 19 Subscriptions: Invoicing, Failed Payments and MRR Decisions | APAA