Odoo for Subscription Businesses:
Recurring Revenue Management, MRR Tracking & Dunning Automation

Why Subscription Businesses Break Generic ERPs

Most ERPs were designed for companies that ship a product, invoice once, collect cash, and close the sale. Subscription businesses do the opposite of all four. The same customer is invoiced forever. Revenue recognition stretches across months or years. Plans change mid-cycle. Payment cards expire. And the reporting questions that matter — MRR, ARR, churn cohorts, net revenue retention, CAC payback — have nothing to do with a traditional P&L line item.

This is why SaaS founders arrive at Odoo already carrying a stack of bolt-ons: Chargebee or Recurly for billing, QuickBooks for books, Stripe for payments, a spreadsheet for MRR, Baremetrics for dashboards, and HubSpot for CAC attribution. Each system owns a slice of the customer, none owns the whole picture, and reconciliation consumes half of month-end close.

Odoo 19 consolidates that stack. The Subscriptions module handles recurring billing, plan management, proration, and renewal alerts. Invoicing and Accounting close the loop with GAAP-friendly deferred revenue and ASC 606 handling. Analytic accounts and tags give you native MRR and cohort reporting. Stripe integrates for automated charges and dunning. This guide shows how to architect the whole thing — from subscription templates to churn recovery — so a single Odoo instance replaces five SaaS tools and still produces numbers your auditor will sign off on.

Odoo Subscriptions Module: The Deep Dive

The sale_subscription module is where the commercial lifecycle lives. A subscription record is essentially a long-running sales order that auto-generates invoices on a recurrence schedule. But the real power — and the real complexity — is in how templates, recurring rules, plans, and renewal automation combine. Our companion piece on setting up recurring invoices and subscriptions in Odoo 19 covers the base mechanics; here we focus on what changes when your entire business runs on it.

Subscription Templates: The Blueprint for Every Plan

A subscription template defines how a plan behaves: billing frequency, invoice generation timing, auto-close behavior on payment failure, and the email sequences that fire on key events. You should have one template per commercial plan — not per customer. If you find yourself creating ad-hoc templates for individual deals, you have a process problem: move those differences into custom pricing on the order line, not the template.

<odoo>
  <data>
    <record id="sub_plan_pro_monthly" model="sale.subscription.plan">
      <field name="name">Pro — Monthly</field>
      <field name="billing_period_value">1</field>
      <field name="billing_period_unit">month</field>
      <field name="auto_close_limit">15</field>
      <field name="user_closable">True</field>
      <field name="invoice_mail_template_id"
             ref="sale_subscription.mail_template_renewal_reminder"/>
    </record>

    <record id="sub_plan_pro_annual" model="sale.subscription.plan">
      <field name="name">Pro — Annual (17% off)</field>
      <field name="billing_period_value">12</field>
      <field name="billing_period_unit">month</field>
      <field name="auto_close_limit">30</field>
      <field name="user_closable">False</field>
    </record>
  </data>
</odoo>

Recurring Rules and Auto-Invoicing Cycles

The recurrence engine is a scheduled action (sale_subscription.cron_account_analytic_account) that runs daily and generates invoices for any subscription whose next_invoice_date is today or earlier. Three configuration choices will save you weeks of cleanup:

• Run it at a fixed server time (02:00 UTC is common) so you have deterministic invoice dates across timezones.
• Generate draft invoices, not posted, if your finance team wants to review. Flip to auto-post only after 90 days of clean runs.
• Cap the horizon — don't let the engine generate six months of invoices ahead. One cycle at a time keeps MRR reports clean.

Plan Management: Upgrades, Downgrades, Add-Ons

Never edit an active subscription's price or quantity directly — doing so silently backdates MRR and corrupts cohort reports. Instead, use the Upsell and Renewal wizards. An upsell creates a new sales order linked to the subscription, generates a prorated invoice for the current period, and updates the recurring amount going forward. The subscription history table (sale.subscription.log) captures every MRR change with a timestamp — this log is the source of truth for your MRR waterfall.

from datetime import date

# Customer wants to add 5 seats mid-cycle on a $99/seat/month plan
subscription = env['sale.order'].browse(subscription_id)
seat_product = env.ref('my_module.product_pro_seat')

# Create upsell order (prorates automatically)
upsell = subscription._create_upsell_order({
    'order_line': [(0, 0, {
        'product_id': seat_product.id,
        'product_uom_qty': 5,
        'price_unit': 99.0,
    })],
})

# Compute proration for remaining days in cycle
days_remaining = (subscription.next_invoice_date - date.today()).days
period_days = 30
prorated_amount = (5 * 99.0) * (days_remaining / period_days)

_logger.info(
    "Upsell %s: $%.2f prorated for %d days",
    upsell.name, prorated_amount, days_remaining,
)

# Confirm → invoices immediately, adds seats to recurring MRR
upsell.action_confirm()

Renewal Alerts and Churn Status Tracking

The renewal alert system is one of the most underused features in Odoo Subscriptions. You can configure alerts to fire based on days-from-renewal, subscription status, MRR threshold, or custom domain filters — and trigger actions ranging from email to CSM task creation to Slack webhook. For annual contracts, we configure three alerts by default: 60 days out (early renewal conversation), 30 days out (formal renewal quote), and 7 days out (escalation to account owner).

<record id="alert_renewal_30d" model="sale.subscription.alert">
  <field name="name">Annual Renewal — 30 Day Notice</field>
  <field name="trigger_condition">on_date</field>
  <field name="trigger_date">end_date</field>
  <field name="trigger_date_offset">-30</field>
  <field name="action">mail_post</field>
  <field name="mail_template_id"
         ref="my_module.mail_template_annual_renewal"/>
  <field name="domain">[('plan_id.billing_period_value','=',12)]</field>
</record>

Integration with Sales, Invoicing, and Accounting

Because a subscription is a sales order in Odoo, the handoff to Invoicing is native — no middleware, no CSV exports. Each generated invoice posts to Accounting through the configured journal, and the recurring revenue maps to a deferred revenue liability account if the product is configured for deferred recognition. The chain looks like this:

1. Sale.order (subscription template applied) → defines recurrence.
2. Cron generates account.move (invoice) on schedule.
3. Payment provider (Stripe) charges the saved payment method.
4. account.payment reconciles against the invoice.
5. Deferred revenue schedule recognizes revenue monthly.
6. Analytic account tags the MRR movement (New / Expansion / Contraction / Churn).

The analytic account step is what unlocks cohort and MRR reporting. We cover it in the next section — and in depth in the broader Odoo for SaaS companies guide.

Stripe Integration: Recurring Charges, Card Updates, and Tax

For a subscription business, the payment provider is not a peripheral — it's core infrastructure. Stripe is the default choice for Odoo SaaS deployments because its Billing APIs, SCA compliance, and tax engine are best-in-class. Our companion guide on Odoo 19 payment providers covers the baseline setup; here we focus on the subscription-specific wiring.

Recurring Charges: The Token Flow

Odoo calls this a "payment token" — it's a Stripe payment_method ID saved against the customer. The first time a customer pays, Stripe returns a tokenizable payment method; Odoo stores the reference in payment.token. Every subsequent invoice from the subscription cron finds the token and issues an off-session charge via Stripe's PaymentIntent API.

def _process_subscription_payment(self, invoice):
    """Charge the customer's saved token for a subscription invoice."""
    token = invoice.partner_id.payment_token_ids.filtered(
        lambda t: t.provider_id.code == 'stripe' and t.active
    )[:1]
    if not token:
        invoice._trigger_dunning_no_card()
        return False

    tx = self.env['payment.transaction'].create({
        'provider_id':    token.provider_id.id,
        'payment_method_id': token.payment_method_id.id,
        'token_id':       token.id,
        'partner_id':     invoice.partner_id.id,
        'amount':         invoice.amount_total,
        'currency_id':    invoice.currency_id.id,
        'invoice_ids':    [(6, 0, [invoice.id])],
        'operation':      'offline',  # critical: off-session charge
    })
    tx._send_payment_request()
    return tx.state == 'done'

Payment Failures and Card-Update Flows

Cards expire, banks decline, customers change providers. Stripe reports roughly 10–15% of recurring charges fail on first attempt in B2C SaaS, 5–8% in B2B. Without intervention, every one of those failures becomes involuntary churn. The recovery mechanism is a dunning sequence (covered in the next section) combined with a card-update portal accessible to the customer without requiring support contact.

Configure Odoo's customer portal to surface a "Update Payment Method" link on the subscription page. The link opens a Stripe SetupIntent flow; on success, the new payment method becomes the default token and Odoo immediately retries any unpaid invoices in the customer's account.

Tax Calculation at Subscription Time

Subscription tax is not trivial. US sales tax varies by state and sometimes by ZIP code, with economic nexus thresholds triggering collection obligations in 45+ jurisdictions. EU VAT depends on B2B/B2C status and customer country. The pragmatic decision tree:

Stripe Billing vs. Odoo Subscriptions: Who Owns What?

A common confusion: Stripe has its own subscription product (Stripe Billing). Should you use it alongside Odoo Subscriptions? Our strong recommendation is no — pick one source of truth. For any business using Odoo as ERP, the subscription logic must live in Odoo so that MRR, deferred revenue, and accounting stay consistent. Stripe's role is charging only.

The division of responsibility:

• Odoo owns: subscription lifecycle, plan changes, proration math, MRR, invoicing, tax application (via Stripe Tax or Avalara), accounting, revenue recognition.
• Stripe owns: card vaulting, PCI compliance, SCA authentication, charge execution, 3DS challenges, payout aggregation, tax rate lookup (if using Stripe Tax).

Teams that try to run Stripe Billing and Odoo Subscriptions end up with two systems generating invoices, two churn numbers that disagree, and an accountant who hates everyone.

Dunning: Recovering Involuntary Churn

Dunning is the polite art of chasing failed payments. Done well, a dunning sequence recovers 35–50% of otherwise-lost revenue. Done poorly (one grumpy email and a cancel), it recovers 5% and upsets the customers you did want to keep.

The Recommended Sequence

1. Day 0 — Payment fails. Auto-retry 24 hours later (Stripe Smart Retries is excellent; enable it).
2. Day 1 — Friendly email: "We couldn't process your payment. [Update card]."
3. Day 3 — Retry charge. If still failing, send reminder #2 with same link.
4. Day 7 — Retry + email: "Your account access may be affected."
5. Day 10 — Enter grace period: service continues, red banner in-app.
6. Day 14 — Subscription paused: access restricted, final email.
7. Day 21 — Subscription auto-closed, data retained 90 days for win-back.

<record id="dunning_day_1" model="base.automation">
  <field name="name">Dunning — Day 1 Friendly Reminder</field>
  <field name="model_id" ref="account.model_account_move"/>
  <field name="trigger">on_time</field>
  <field name="trigger_field_id" ref="account.field_account_move__invoice_date_due"/>
  <field name="trg_date_range">1</field>
  <field name="trg_date_range_type">day</field>
  <field name="filter_domain">
    [('state','=','posted'),
     ('payment_state','=','not_paid'),
     ('move_type','=','out_invoice'),
     ('subscription_id','!=',False)]
  </field>
  <field name="action_server_ids" eval="[(4, ref('action_send_dunning_1'))]"/>
</record>

A disciplined dunning sequence plus in-app card-update prompts typically reduces involuntary churn by 40–60% relative to a bare-minimum Odoo install.

Frequently Asked Questions