Somewhere in almost every first conversation about Odoo, the question lands: should we run Community or pay for Enterprise? People expect a yes-or-no answer, and vendors are usually happy to give one — the ones who resell licenses say Enterprise, the ones who bill hours say Community. Both answers are suspicious for the same reason: they were decided before anyone looked at your business.
The honest answer is that the license question is not one decision. It is thirty small ones. Odoo is modular, and so is the choice: sales, purchasing, inventory, invoicing, HR, manufacturing — each area has a Community version, often a mature OCA alternative, sometimes an Enterprise feature that genuinely matters, and occasionally nothing that fits without custom work. Deciding at the level of 'the ERP' hides all of that nuance, and the nuance is where the money is.
So we decide module by module. Here is the method we actually use — including where we think Enterprise earns its license, and where it does not.
Community plus curated OCA is the default
Our starting position for any module is Community plus a curated selection from the OCA — the Odoo Community Association's ecosystem of open, peer-reviewed modules. Not because free is automatically better, but because for most operational areas the Community core covers the essential workflow, and OCA fills the practical gaps with code that is public, reviewed, and maintained by people who run it in production themselves.
Curated is the load-bearing word. We do not install OCA modules casually, and neither should anyone. Every third-party module we adopt goes through the same discipline as code we write: it lives in our Git tree at a pinned version, it passes upgrade testing before any version moves, and it reaches environments through the same versioned release pipeline as our own work. An OCA module nobody on your team can maintain is not a saving — it is an unpriced liability that comes due at the next upgrade.
Where Enterprise genuinely earns its license
We are not ideological about this, because ideology costs clients money in both directions. There are places where Enterprise is simply the better engineering decision.
Accounting is the clearest case. Enterprise's dynamic financial reporting — legal statements, drill-down reports, the reconciliation tooling around them — represents years of accumulated work that would be genuinely expensive to rebuild and even more expensive to keep correct as regulations and versions move. If accounting reporting is central to how a client operates, we say so plainly: this is where the license earns itself.
Some vertical apps fall into the same category. When Enterprise ships a deep, purpose-built application for a client's actual industry workflow and the Community-plus-OCA route would mean assembling and maintaining a patchwork, the subscription is usually the cheaper option once you count honestly. The official upgrade path that comes with the subscription is part of that honest count too.
For every module in scope, we work through the same short list of questions:
- Does the Community version cover the workflow this team actually runs day to day?
- Is there a mature, actively maintained OCA module for whatever is missing?
- Is the Enterprise feature load-bearing for this business, or merely pleasant in a demo?
- What would it cost to build the gap as custom code — and, more importantly, to carry that code through every future upgrade?
- Who maintains this choice three versions from now?
License cost versus custom-build cost
That last pair of questions is where most license debates should actually happen. An Enterprise subscription is a recurring, predictable line item. Custom development looks cheaper because the invoice arrives once — but the real cost of custom code is not writing it, it is carrying it. Every custom module we ship is versioned in Git and goes through upgrade testing before any release, and that discipline exists precisely because carrying code is the expensive part. When an Enterprise feature closely matches what you would otherwise build, the license usually wins the honest comparison.
The reverse case is just as real. Paying for Enterprise across the whole company because one department wants one feature is a poor trade when a small custom module — or an existing OCA one — closes the gap for a fraction of the recurring cost. We see both mistakes, and they come from the same root: answering a module-level question at the contract level.
Which is why, in our experience, the right answer is very often a mix — Community as the base, OCA where the ecosystem is strong, Enterprise where it demonstrably earns its keep, and targeted custom modules for what is genuinely specific to the business. That mix is exactly what our scoping phase produces: a module-by-module map with the reasoning written down, and a fixed price attached to it before any build starts. If you are weighing the two editions right now, that scoping conversation is the place to settle it — with your modules on the table, not someone else's sales deck.