Running Recurring Billing on Odoo Subscriptions

How the recurring billing engine actually runs

The part of Odoo Subscriptions that quietly does the work is the recurring billing engine, not the subscription record you can see on screen. According to the official Odoo 19.0 documentation, the Subscriptions app will automatically generate quotations and invoices for customers by default. That happens through a scheduled action (a cron job) that scans every active subscription, checks its next invoice date, and produces the next period's invoice from the original contract — not by creating a brand-new sales order each cycle.

This distinction matters operationally. One subscription record stays open, and a chronological stream of invoices flows from it into Accounting, where each one is reconciled against the customer's payment method or bank statement. There is no monthly ritual of cloning orders, no duplicate customer cards, and no period-end cleanup of near-duplicate documents. The audit trail stays clean because the contract is the single source of truth.

Default behaviour invoices at the start of the period. Teams that need end-of-period (arrears) billing for services delivered first will not find a one-click product flag for that in the standard docs — it is a common implementation discussion and often needs process design or light customization rather than a plan checkbox. Know that expectation before you promise post-paid cycles on a pure SaaS-style setup.

If you want the higher-level picture of what the module is and how it connects to CRM, Sales, and Helpdesk, our [introduction to Odoo Subscriptions](/learn/subscriptions) covers that. This guide assumes you already understand the app conceptually and focuses on the operational decisions that determine whether your recurring revenue lands cleanly every cycle.

Configuring recurring plans for clean billing cycles

Recurring plans are the time windows in which subscriptions are active before they renew again, and they are configured under Subscriptions app ‣ Configuration ‣ Recurring Plans. The Odoo documentation states that the Billing Period field determines the frequency with which the subscription is billed, set in units of Weeks, Months, or Years plus a numerical value. Monthly and Yearly ship by default, and custom plans like Bi-weekly or Quarterly can be added.

Three DETAILS fields drive most of the recurring-billing behaviour you will operate against. Automatic Closing is a number of days after which the subscription closes automatically if payment is not made — so a monthly plan that renews on the 1st with Automatic Closing set to 15 days will close on the 16th if payment never lands. Align to Period Start bills new and recurring plans on the first day of the next billing period and shows a reduced, prorated cost on the mid-period invoice. Invoice Email Template assigns the template used for invoice communications, defaulting to Invoice: Sending, which the docs recommend using for price-transparency and regular customer communication.

Odoo 19 docs are explicit about a hard limit on Align to Period Start: setting a custom period start date (for example the 5th of each month) requires custom development and is not available by default. If your industry invoices every mid-month or on a customer-specific anniversary that is not the 1st, plan for that in implementation rather than assuming a configuration toggle exists.

One documented constraint is load-bearing for operations: the Days unit of measure cannot be used as a Billing Period for subscription products. The daily recurrence period is designated for rentals and cannot be added to subscription-based sales orders, explicitly to avoid sales orders that would generate daily invoices. If a customer asks for daily billing on a subscription, the answer is that Odoo routes that to the Rental model, not Subscriptions.

The Pricing tab on a recurring plan holds plan-specific price rules that take precedence over the default price on the subscription product form. That is the supported place for deal pricing, plan-level discounts, and incentives tied to a cadence (annual vs monthly) without inventing a second product catalog.

Automatic payments: tokenization and supported providers

By default the engine generates invoices but does not charge them. To charge automatically you need a payment provider that supports tokenization. Tokenization, per the Odoo documentation, lets customers save their payment details — credit card or banking account information — for automatic billing. Saved details become a token that Odoo reuses for future online or recurring subscription charges.

The Odoo 19.0 automatic-payments documentation names the providers that support tokenization: Adyen, Authorize.net, Flutterwave, Razorpay, Stripe, and Xendit. Setting up automatic payments means choosing one of these, following the provider's setup guide to create an account and configure its API credentials in Odoo, then enabling the provider, configuring its payment methods, and configuring tokenization.

Tokens are captured either at checkout or through the customer portal. The documentation confirms that payment providers create tokens with customers' saved payment details during the checkout process, and that customers can also log into their customer portal and enter their payment information there. Some providers save details automatically; others give the customer the choice — and if a customer chooses not to save their information, they cannot make automatic payments. This is the single most common reason a subscription silently falls back to manual invoicing: no token was ever stored.

Treat missing tokens as an ops metric, not a one-off support ticket. A weekly filter for In Progress subscriptions with no payment token (or with Payment Failure history) catches involuntary churn before Automatic Closing kills the contract. B2B retainers that pay by bank transfer can stay on invoice-and-reconcile without tokenization; consumer or high-volume SaaS-like flows usually need a tokenized provider from day one.

Failed payments: Payment Failure, Contract in exception, and finance handoffs

Failed automatic payments are where recurring-billing operations live or die, and Odoo handles them with a deliberate safety mechanism rather than a silent retry loop. When an automatic payment fails, the sales order is updated with a Payment Failure tag and the Contract in exception checkbox is ticked in the Subscription section of the Other Info tab.

That checkbox is the important part. Being marked Contract in exception prevents scheduled actions from running, which the documentation states explicitly keeps the system from accidentally double-charging the customer if the automatic payment actually went through. Because the payment status failed to register with the system, a human must check whether the payment was made before automatic payments and scheduled actions resume. This is a feature, not a bug: it trades a small amount of manual triage for protection against the worst possible recurring-billing failure — double billing is a trust killer practitioners still call out across the wider subscription industry.

The recovery procedure is documented step by step. Navigate to Subscriptions app ‣ Subscriptions ‣ Quotations, open the subscription, and read the Chatter to see if the payment was made. If it was not made, enter developer mode, open the Other Info tab, untick Contract in exception, reload the sales order, and confirm the Payment Failure tag is gone. If it was made, you must create and post a new invoice manually (which updates the next invoice date), then untick Contract in exception and reload. Once the checkbox is clear, Odoo handles renewals automatically again. Subscriptions that stay in Payment Failure are ignored until the sales order is closed.

Separate that freeze from Accounting payment follow-ups. Accounting can still run multi-level Payment Follow-Up (reminder emails and escalation on open invoices) while the subscription contract is frozen. Design a finance handoff: (1) subscriptions owner owns Contract-in-exception triage, (2) AR owns follow-up levels and collections language, (3) CS owns card-update outreach when the portal can fix the token, (4) product/ops decides whether service access pauses while the contract is in exception. Without those roles, failed payments pile up as ignored contracts and your MRR dashboard looks healthier than cash.

Operational SLA that works for most SMEs: triage new Payment Failure orders daily, clear or escalate anything older than Automatic Closing / 2, and never leave a paid-but-exception order sitting — that is the double-charge path if someone clears the checkbox without posting the manual invoice first.

• →Trigger: automatic payment fails → Payment Failure tag + Contract in exception ticked.
• →Safety: scheduled actions stop on that order to prevent a double charge.
• →Triage: read the Chatter to determine whether the payment actually landed.
• →If not paid: developer mode → untick Contract in exception → reload → confirm tag cleared; push card update via portal.
• →If paid: create and post a new invoice manually (updates next invoice date), then untick and reload.
• →Finance handoff: AR follow-ups run on the open invoice; subscriptions ops owns the exception checkbox.
• →Stale orders: subscriptions remaining in Payment Failure are ignored until closed or cleared.

Native Odoo vs purpose-built billing: maturity gap table

Odoo Subscriptions is strong when recurring revenue is one motion inside a broader ERP — CRM quote, sales order, subscription contract, invoice, deferred revenue, and service delivery in one stack. Purpose-built platforms such as Stripe Billing and Chargebee are built for product-led SaaS where billing is the product surface: deep dunning graphs, usage metering, credit wallets, and consumer-grade pause/resume. Comparing them honestly prevents a bad architecture choice.

Use Odoo native when you are an SME with monthly or annual retainers, seat-based or flat service plans, mid-cycle upsells, and you already run (or want) Odoo for sales and accounting. Prefer Stripe Billing or Chargebee when usage metering, sophisticated smart retries, complex mixed-cart consumer bundles, or advanced customer-portal pause/swap flows are core revenue mechanics — then integrate billing events into Odoo Accounting rather than forcing every edge case into Subscriptions.

Industry chatter in 2026 still splits consumer subscription fatigue from B2B value renewals: recurring charges stick when the outcome renews monthly, not when the deliverable was a one-time download. That fits Odoo's sweet spot — B2B services, maintenance contracts, SaaS-like ops for SMEs — better than high-churn consumer subs with granular pause and promotional stacking.

If you outgrow native depth later, keep the subscription commercial record and customer master in Odoo and treat the external biller as the charge engine. Migrating the other way (billing platform first, ERP second) is usually more painful because finance already lives on invoices and deferred revenue in the ERP.

Selling subscription products on eCommerce

Odoo 19 documents a full path for selling subscriptions through the eCommerce shop: mark products as subscription products, attach recurring plans, and let checkout create the subscription sales order when the cart is paid. That is how self-serve SaaS-like or membership products enter the same recurring engine as manually quoted B2B contracts.

Operational checklist before you put a plan on the storefront: (1) product has Subscriptions and Sales enabled, (2) at least one recurring plan is valid for that product, (3) a tokenization-capable payment provider is live so renewals can charge without a human, (4) Invoice Email Template and portal self-service toggles match what a shopper should be able to do alone, (5) Align to Period Start behaviour is understood so the first invoice amount matches the storefront messaging.

eCommerce is also where missing tokens hurt most. If the provider offers optional save-card and the shopper declines, the first charge may succeed while renewals fall back to unpaid invoices. Prefer providers and checkout settings that capture a token for subscription SKUs, and test a full cycle (buy → next invoice → auto-charge) on staging before launch.

Mixed carts (one-time goods plus a subscription line) are possible but need clear product-type design: remember upsell proration later only applies to Service types. Physical kits sold with a service plan should be modelled so finance and the customer both understand what prorates and what does not.

Renewal operations: prerequisites and the Renew button

Renewals extend an active subscription into its next billing period. Most companies automate renewal so it happens on the cron, but Odoo documents the manual path too, and the manual prerequisites tell you exactly what a subscription must look like before the engine can renew it cleanly. A renewal quotation can only be created if a quotation with a subscription product has been confirmed, a configured recurring plan is selected, and payment from the customer for the initial subscription has been invoiced and registered.

You can verify those prerequisites by opening Subscriptions app ‣ Subscriptions ‣ Quotations and selecting the subscription. A properly configured subscription shows in the Sales Order stage with an In Progress tag and a Renew button above the order form. Clicking Renew instantly produces a new renewal quotation tagged Renewal Quotation, with the start date and next invoice date automatically added to its chatter. From there the standard sales flow applies: confirm the quotation, invoice the order, and register payment.

The automatic path is what most subscription businesses actually rely on. Because the recurring engine posts each period's invoice from the original contract, renewal is the default state of an active subscription — the Renew button is the manual escape hatch for cases where you want to renegotiate the terms mid-cycle. Either way, once a renewal quotation is confirmed and becomes a sales order, a Sales History smart button appears that shows every sales order attached to that subscription along with its individual Subscription Status, which is how you audit the contract's history without reconstructing it from invoices.

Optional Plans on self-service and salesperson-driven Optional Plans changes create a new subscription or renewal quote to accommodate the change. Treat plan switches as commercial events with a clear next invoice date, not as silent field edits on a live order, so finance and the customer see the same transition.

Upsell mechanics: proration, discounts, and the Service-only rule

Upselling is the operation that lifts monthly recurring revenue without churning and re-acquiring the customer, and Odoo exposes it through a dedicated Upsell button on the subscription sales order. The documentation is explicit that a subscription sales order must be invoiced before it can be upsold, so upsell is always a mid-cycle operation on a live, paid contract.

Clicking Upsell opens a new quotation form marked with an Upsell icon, with the original subscription product already in the Order Lines tab. The lines carry a reminder that recurring products are prorated based on the original subscription's starting date — and here the documentation contains a rule that catches many implementers off guard: the prorated amount is only applied to Service product types. It is not applied to Goods, even if the message appears and suggests otherwise. If your subscription includes a physical box or bundled hardware, the upsell quotation will show the proration language but will not actually prorate the goods line. Plan your product model around that, or you will publish invoices that disagree with what the customer expected.

Discounts are a separate feature that must be turned on before you can use them in an upsell. To enable discounts, navigate to Sales app ‣ Configuration ‣ Settings, scroll to the Pricing section, tick Discounts, and Save. Once enabled, unit price, taxes, and discount can all be adjusted on the upsell quotation before it is sent. You can also use Create Alternative to present a second upsell quotation alongside the first, linked to the original subscription — useful when a customer is weighing two upgrade paths. After the customer confirms, the upsold products are added to the initial subscription and the prices are prorated for the remaining time in the current invoicing period.

Downgrades and mid-cycle plan changes via Optional Plans or a negotiated renewal quote should follow the same honesty rule: show the customer the credit or remaining-period charge before confirmation. Do not rewrite historical invoices to fake a clean month; keep the original invoice trail and apply the commercial change forward with proration where Service lines allow it.

• →Prerequisite: the subscription must already be invoiced before Upsell is available.
• →Proration: applied to Service product types only — never to Goods, despite the on-screen message.
• →Discounts: enable Sales ‣ Configuration ‣ Settings ‣ Pricing ‣ Discounts first.
• →Create Alternative: present a second, linked upsell quotation for comparison.
• →On confirm: upsold lines join the initial subscription, prorated to the period's remaining time.
• →Plan switches: use Optional Plans / renewal quotes so the next invoice date stays auditable.

Closing subscriptions and capturing churn cleanly

Closing a subscription terminates it and records the reason, and that reason is what feeds your retention analysis later — so capturing it consistently is an operations discipline, not a formality. The documentation states that a subscription must have been invoiced before it can be closed; subscriptions that have not yet been invoiced may be cancelled instead. That distinction keeps your churn numbers clean: a cancellation before the first invoice is not churn, it is a failed conversion.

Administrators close from inside the Subscriptions app by opening the in-progress subscription and clicking the Close button, which opens a form with a When field for the close date and a Reason drop-down. Custom reasons can be created by choosing Search more in the drop-down, and on Submit the chatter records the reason while a Churned banner appears on the order with the updated end date. Customers close their own subscriptions through the user portal, where they must choose a pre-configured reason — they cannot enter a custom one. Administrators create the selectable reasons under Subscriptions app ‣ Configuration ‣ Close Reasons, so the reason taxonomy is something you design once and reuse everywhere.

Whether self-service is even available is controlled on the recurring plan. Enabling Closable in the Self-Service section of a Recurring Plan adds a drop-down that lets customers close either on a date of their choosing or at the end of the current renewal period. Sales teams with strong offboarding processes may deliberately leave Closable unchecked to force a save interaction; teams optimising for low support volume enable it. Either is legitimate — the point is that the decision is intentional and lives on the plan, not on each individual subscription.

Recommended close-reason taxonomy for honest retention analysis: price, product fit, switched vendor, project ended, service quality, payment / billing friction, other (admin only). Keep customer-facing labels short; map them in reporting so "billing friction" can drive portal and dunning improvements rather than product roadmap noise.

Self-service portal configuration checklist

The Self-Service section on each recurring plan is where you decide how much of the recurring-billing lifecycle a customer can run without your team. Odoo documents four optional fields, and each one removes a category of support ticket when enabled. Closable lets customers close their own subscriptions. Add Products lets customers add new products or edit existing product quantities on their recurring sales orders, which generates an Upsell quotation whenever a customer performs a quantitative adjustment. Renew lets customers manually create a renewal quotation, and Optional Plans lets customers switch plans, creating a new subscription or renewal quote to accommodate the change.

The economics of these toggles are worth thinking through. Add Products turns every customer-initiated upgrade into a self-driven upsell — the same mechanism covered in the upsell section, but triggered by the subscriber instead of a salesperson. Optional Plans lets a downgrading customer move to a cheaper tier without a human in the loop, which is usually better than losing them to churn. Renew gives annual customers a one-click way to continue. Each toggle trades a small amount of control for a meaningful reduction in routine finance and support work.

Self-service is mediated through the customer portal. Customers manage subscriptions by clicking Subscriptions on the portal home page, which lists every subscription on their account including closed ones, and each detail page exposes the actions enabled on its plan. Administrators can preview exactly what a customer sees by using the Preview button at the top of any subscription sales order — useful before you enable a toggle broadly, so you can confirm the experience matches your expectation.

Portal also hosts payment-method updates for tokenized providers. Pair "update card" access with your failed-payment runbook: most involuntary churn is a stale card, not a decision to leave. Preview the portal after every plan change, and keep Closable policy consistent across similar plans so support scripts do not contradict what the UI allows.

MRR reporting that keeps recurring billing honest

Recurring billing only stays healthy if you can see it, and Odoo Subscriptions ships four reporting pages, each answering a different operations question. The documentation describes Subscriptions Analysis (counts, recurring revenue, and quantities, groupable by sales team, salesperson, plan, product, and next invoice date), Retention Analysis (cohort retention over time and churn), MRR Breakdown (the change in recurring revenue, with MRR Change selected by default), and MRR Analysis (MRR and ARR tracked over time).

For day-to-day operations the most useful measures are the ones that show movement rather than totals. On Subscriptions Analysis, Monthly Recurring measures gross MRR and Yearly Recurring projects annualized revenue regardless of the recurrence period — together they let you compare a monthly and an annual plan on the same footing. On MRR Breakdown and MRR Analysis, the MRR Change, ARR Change, and Active Subscriptions Change measures isolate the net movement in a period, which is exactly what you need to spot whether new sales are keeping pace with churn.

Filters let you turn these reports into operational queries. The documented filters include In Progress, Paused, Churned, To renew, Recurring, Non-recurring, First contract date, Next Invoice Date, and End Date, so you can answer focused questions like which subscriptions renew next week, which churned last quarter, or how much revenue sits in paused contracts.

Honesty pitfalls that corrupt board numbers: (1) counting Contract-in-exception or unpaid renewals as healthy MRR because the contract is still In Progress, (2) mixing pre-invoice cancellations into churn, (3) annualizing discounted first months as full ARR without noting the promo cliff, (4) ignoring multi-company scope so one entity's plan appears company-wide, (5) celebrating MRR up while cash collections lag because exceptions and AR follow-ups are not in the same review. Pair MRR Change with a Payment Failure queue age report and a cash collected vs invoiced check every cycle.

If you want the deeper treatment of how these reports combine into a board-level MRR, ARR, churn, and lifetime-value view, see our module overview; here the emphasis is on using them to run the billing operation, not only to report to the board. Annual prepays should also be considered under Accounting deferred revenue so cash today is not booked as earned revenue tomorrow without a release schedule.

Recurring-billing gotchas and how to avoid them

Most recurring-billing pain in Odoo comes from a handful of predictable traps, and knowing them in advance is worth more than any single feature. The first is the Days billing-period constraint: the daily recurrence is reserved for rentals and cannot be used for subscription products, so any quote that promises daily subscription billing has to be re-modelled before it will work. The second is the Goods proration rule: upsell proration applies to Service products only, so a subscription that bundles physical goods will not prorate the goods line even though the upsell form says it will.

The third trap is the Contract-in-exception backlog. Because a failed payment stops all scheduled actions on that order to prevent a double charge, a fleet of failed-payment subscriptions can quietly accumulate as ignored contracts. Operations teams should run a regular filter for subscriptions in Payment Failure and triage the Chatter on each, because those orders will not self-heal — they stay ignored until a human clears them or closes them. Pair this with a sane Automatic Closing value on each plan so non-paying accounts churn on a schedule rather than lingering indefinitely.

The fourth trap is closing before invoicing. A subscription that has not yet been invoiced cannot be closed — it can only be cancelled — which means your churn reporting will not capture it. If your funnel lets customers sign up and leave before the first invoice fires, design your reporting to separate cancellations from true churn so the numbers stay honest.

Fifth: custom anniversary billing day (not period start) is not a stock Align to Period Start option — the docs state custom period start dates need custom development. Sixth: end-of-period (arrears) invoicing is a frequent ask and is not the default start-of-period behaviour. Seventh: multi-company plans scoped with the Company field will not appear for the wrong entity — mis-scoped plans look like "missing products" during sales. Eighth: no token means no auto-charge even when invoices generate perfectly.

These are configuration and process decisions, not customisation, and they are exactly the kind of thing to lock down during rollout. For the broader rollout plan across the Odoo suite, see our [Odoo implementation guide](/learn/odoo-implementation); for how the per-user plan pricing covers the Subscriptions app itself, see our [Odoo pricing guide](/learn/odoo-pricing).

Putting recurring billing operations into practice

Running recurring billing well on Odoo comes down to a short list of operational disciplines, each rooted in a documented capability. Configure your recurring plans deliberately — Billing Period, Automatic Closing, Align to Period Start, Invoice Email Template, Pricing rules, and Self-Service toggles — because those fields define the rhythm and recovery behaviour of every subscription on the plan. Stand up a tokenization-capable payment provider so the engine can charge automatically, and treat the absence of a stored token as the first thing to check when a subscription is not billing.

Triage Contract-in-exception orders on a cadence rather than reactively, because those orders will not resume on their own. Wire AR Payment Follow-Up to the same invoice stream so collections language matches the freeze. Use the reporting pages to watch MRR Change and cohort retention, not just totals, and subtract or flag exception backlog so the board does not confuse booked MRR with cash. Design your close-reason taxonomy once so every churn — administrator-driven or self-service — lands in the same analysis.

Be honest about maturity: if your roadmap is usage metering, consumer pause stacks, or Chargebee-depth dunning graphs, integrate a purpose-built biller and keep Odoo as the commercial and accounting system of record. If your motion is B2B retainers, seats, and service plans inside an ERP, native Odoo Subscriptions plus Accounting deferred revenue is usually the cleaner stack.

Because recurring billing sits inside the wider Odoo finance and sales stack, the ledger mechanics, payment terms, and reconciliation it depends on are shared with the rest of the suite. Our [Odoo Invoicing guide](/learn/invoicing) covers how invoices post under double-entry rules and how payments reconcile, and our [Odoo Sales guide](/learn/sales) covers the sales-order-to-subscription path that creates contracts in the first place. If you are evaluating whether to standardize your subscription business on Odoo, we implement the platform for SMEs across Canada, the UK, and the USA — [talk to an Odoo partner](/solutions/odoo) about your plans, products, and reporting needs.

Frequently asked questions