Enterprise software accumulates scar tissue. Features get built, half- implemented, shipped, and then quietly ignored while the rest of the system grows around them. Documentation lags behind reality. Edge cases go undocumented because the people who know about them assume everyone else does too. Every few months, someone sweeps through and fixes the obvious ones. This week, Odoo fixed four.
The Tax Scope Filter Did Nothing
Since at least Odoo 16, the accounting module has included a field called Tax Scope on every tax record. It offered two options: Goods and Services. The idea was straightforward — restrict certain taxes to only apply to product types matching their scope, so a services-only tax wouldn’t accidentally appear on a physical goods invoice.
The problem: it didn’t do anything. The field existed in the interface, accepted input, saved to the database, and then was completely ignored by every tax computation in the system. No validation checked it. No filter used it. Setting a tax to “Goods” scope had zero effect on whether that tax could be applied to a service invoice line. It was a setting that looked like it worked because there was never an error message telling you it didn’t.
Odoo has now removed the Tax Scope section from its accounting documentation entirely. The internal conversation is whether to fix the feature — make it actually filter taxes by product type — or remove the field from the code altogether. For now, the documentation no longer describes a capability the software doesn’t deliver.
This matters more than it sounds. Accountants and implementation consultants who read the documentation and configured Tax Scope fields were building their tax setup on a false assumption. Some likely spent time debugging why services taxes were appearing on goods invoices, not realizing the filter they’d configured was decorative. Ghost features like this erode trust in configuration surfaces — if one field doesn’t work, which others might not?
Postal Mail Has an Eight-Page Cap Nobody Documented
Odoo’s Snailmail feature lets businesses send physical letters directly from the system through Pingen, a postal automation provider. It’s used for customer invoices, payment reminders, and official correspondence that needs to arrive in a paper envelope. You buy credits through Odoo’s IAP (In-App Purchase) system, attach a PDF to a customer record, and the system handles printing, folding, and mailing.
What the documentation never mentioned: your document cannot exceed eight physical pages. Send a nine-page invoice and the system rejects it. This limit has been in place for four years, hardcoded into the integration regardless of what Pingen’s own API supports. The reason is economic rather than technical — Odoo charges a flat rate per credit while Pingen’s pricing scales with page count, so Odoo caps the page count to keep the credit pricing viable.
The documentation now explicitly states the eight-page maximum alongside the existing requirements for address formatting and supported countries. It’s the kind of limit you only discover when you hit it, and discovering it at 4 PM on the day your quarterly statements need to go out is not ideal.
PLM Won’t Install Itself With Manufacturing
Odoo’s Product Lifecycle Management module exists to manage engineering change orders for bills of materials. It’s exclusively a manufacturing companion — it doesn’t do anything without the Manufacturing app installed, and its entire feature set revolves around BOM revisions, ECO workflows, and production change tracking.
Despite this tight coupling, PLM is not installed automatically when you install Manufacturing. It’s a separate module that needs to be found in the Apps marketplace and installed manually. The landing page for PLM now includes explicit installation instructions, including a note about how installing additional modules may affect your subscription.
For manufacturing teams that assumed PLM would be part of their MRP setup, this has been a recurring source of confusion. The ECO features don’t appear in menus, the shop floor integration doesn’t surface, and nothing in the Manufacturing app tells you that a companion module exists and needs separate installation. Adding install instructions to the PLM landing page is a small fix for a gap that has probably generated more support tickets than anyone tracked.
You Don’t Need a Basiq Account for Australian Bank Sync
When Odoo launched Basiq integration for Australian bank synchronization last month, the documentation included instructions for creating a Basiq account through the provider’s website. Users were told to visit the Basiq dashboard, register, and follow setup steps before connecting their bank in Odoo.
That was wrong. A Basiq account is only needed by Odoo’s internal support team for managing the integration backend. End users — the Australian businesses connecting their bank accounts — don’t need a Basiq account at all. They just follow the connection steps in Odoo’s accounting module, which handles the Basiq authentication flow transparently.
The documentation now states this clearly: “A Basiq account is not required to synchronize your bank accounts with Odoo. Simply follow the connection steps to start the synchronization.” The business banking section was also updated to clarify the CDR (Consumer Data Right) opt-in process, directing users to contact their bank rather than configure anything in Basiq directly.
This correction came from a post-merge review — someone read the original documentation after it shipped and realized the instructions would send users on an unnecessary account creation detour. The fix arrived within a week, which is faster than most documentation corrections cycle through, but it’s still a week where Australian users may have been creating Basiq accounts they didn’t need.
The Cost of Undocumented Limits
None of these fixes are dramatic. A removed field, a page limit, an install step, a corrected prerequisite. They won’t appear in release notes or keynote presentations. But each one represents a real scenario where a user hit a wall they couldn’t see coming: an accountant trusting a filter that didn’t filter, a finance team blocked by an undocumented page cap, a manufacturing engineer searching for a module that should have been obvious, a bookkeeper in Sydney creating an account on a website she never needed to visit.
These are the details that separate software you can use from software you can trust. When the documentation matches reality, users can plan around limitations instead of discovering them in production. When non-functional features get removed instead of left in place, the remaining configuration surface becomes more reliable. It’s maintenance work, not feature work, but for the people it affects, the distinction doesn’t matter.