There’s a quiet kind of bug that does more damage than a crash: documentation that confidently describes behavior the software doesn’t actually follow. For businesses running recurring billing through Odoo Subscriptions, one such description has been sitting in the scheduled actions page for a while, telling administrators that when a subscriber has no saved payment token, the system creates an invoice and sends it to the customer for manual payment.
That’s not what happens. And the correction matters more than it might seem at first glance.
The Old Story vs. What Actually Happens
The previous description painted a straightforward picture: no payment token on file, so the system generates an invoice, emails it to the subscriber, and waits for them to pay it manually. Logical enough. The problem is that Odoo doesn’t do it that way.
What actually happens follows a different sequence entirely. When a subscription renewal comes due and no payment token is attached, Odoo fires a dedicated scheduled action — “Sale Subscription: send reminder for subscriptions with no token” — which sends the subscriber a payment reminder email. No invoice exists yet. The subscriber receives the reminder, makes their payment manually, and only after that payment is confirmed does the system generate an invoice for the subscription.
The sequence is reversed: reminder first, payment second, invoice third. Not invoice first, payment whenever.
Why the Sequence Matters
For accounting teams, invoice timing isn’t a technicality. An invoice that exists before payment creates a receivable on the books. In the old (incorrect) description, every tokenless subscription renewal would generate an open receivable immediately, inflating accounts receivable with amounts that may never be collected from subscribers who’ve already drifted away.
The actual behavior is cleaner. No invoice means no receivable until money actually changes hands. The reminder email is just that — a nudge, not a financial event. This distinction affects revenue recognition, cash flow reporting, and how finance teams think about their subscription receivables.
For SaaS operators tracking MRR and churn, it also changes how you interpret the gap between “renewal triggered” and “payment received.” If you were assuming invoices existed for all renewals and reconciling against that, the numbers never quite added up. Now the documentation matches the reality.
A Fourth Scheduled Action Joins the Roster
Alongside the workflow correction, Odoo has updated its documentation to reflect that there are now four subscription-specific scheduled actions, not three as previously stated. The addition is the payment reminder action itself, which had been running in the background but wasn’t listed in the documentation alongside the other three.
The four actions now cover the full lifecycle: generating recurring invoices for subscribers with payment tokens, sending reminders to those without tokens, handling automatic closing logic for lapsed subscriptions, and managing rating requests. Each runs on its own schedule, and each can be customized independently through the Technical menu.
Smaller Fixes in the Same Update
The same documentation pass cleaned up a few other items. The field previously labeled “Date of Next Invoice” is now simply “Next Invoice” — matching what the interface actually displays. References to “ticked checkboxes” were updated to “selected checkboxes,” aligning with Odoo’s current style guide. And the separate sections explaining invoice generation and automatic closing were consolidated into a single, coherent example flow.
None of these are individually significant. But together with the payment token correction, they turn a page that was subtly misleading into one that accurately describes how subscription billing actually works in production.
What This Means for Subscription Businesses
If you’ve been running Odoo Subscriptions and wondering why your scheduled actions seem to generate fewer invoices than expected, or why some subscribers appear to pay before an invoice exists in the system, the answer was always in the code. The documentation just hadn’t caught up.
The practical takeaway: don’t build your collections workflow around the assumption that every renewal creates an invoice. For tokenless subscribers, the system sends a reminder and waits. If the subscriber doesn’t respond, no invoice is created, no receivable hits the books, and the subscription eventually moves toward the automatic closing logic on its own schedule.
That’s actually a more defensible approach than the alternative. It keeps the books clean, prevents phantom receivables from accumulating, and gives the reminder system a chance to recover the payment before any financial records are created. For subscription businesses at scale, that kind of precision in billing mechanics is the difference between financial statements you trust and ones that require manual cleanup every month.