Historical context. The original 13 October 2022 date is retained. Odoo announced version 16 on 12 October 2022. Forecasts below describe that period; current editions, prices and rules need separate verification. Two weeks earlier, NetSuite held its first in-person customer event since 2019 and spent it talking about analytics, configure-price-quote and vertical depth. Two products with almost nothing in common commercially, and they keep landing on the same shortlist for companies somewhere between fifty and five hundred people. That convergence is new, and it is not marketing. Functional coverage at the mid-market level has closed to the point where a feature matrix no longer discriminates. What still differs, sharply, is the shape of the cost curve and the operating model each product commits you to.
Every ERP is cheap in year one. Price year three
In year one you pay licences and an implementation, and both vendors look defensible. Year three is where the products diverge, because that is when the customisations need to survive an upgrade, the headcount has grown, the second country has been added and somebody asks for a consolidated audit pack. The Odoo curve starts low and rises with what you build. Licensing per user is modest, the implementation is usually cheaper, and the platform rewards customisation — which means you will do more of it than you planned. The recurring costs that matter are annual version upgrades and maintaining whatever your partner wrote. The NetSuite curve starts high and rises with modules, users and renewal. Customisation is possible but structurally discouraged by twice-yearly forced upgrades, which is a constraint that also protects you from your own worst instincts. The recurring cost that matters is the renewal negotiation. Neither curve is wrong. They suit different companies, and the question is which curve matches your next three years.
The three questions that actually decide it
Will your processes be standard or genuinely different? If your operating model is unusual and it is the reason you win business, Odoo's flexibility is a real asset. If your processes are ordinary and you have been telling yourself they are special, that flexibility is a liability that will be spent reproducing your current inefficiencies in a new system. When do you need statutory consolidation, multi-book accounting and auditor-grade traceability? Not whether — when. If a group audit, an investor or a listing sits within three years, weight that heavily now, because retrofitting it is more expensive than buying it. Who maintains it? NetSuite's model assumes you buy maintenance from the vendor and its ecosystem. Odoo's model assumes you have, or will hire, technical capacity — internally or through a partner you trust for years, not for a project. Choosing Odoo without answering this question is the most common way the cheaper option becomes the expensive one.
What is actually new in Odoo 16
Version 16 is a finance-heavy release, which matters because accounting usability has historically been the product's weakest point in front of a sceptical controller. The bank reconciliation interface has been rebuilt, there is a dedicated mode for accounting firms managing multiple clients, and the release adds credit limit warnings, early payment discounts, recurring invoices and support for storno accounting, which reverses entries with negative postings rather than mirror entries — required in several jurisdictions and previously a workaround. Beyond accounting, purchasing gains a call-for-tenders flow, inventory adjustments work with storage categories, loyalty and coupon programmes are unified, and the release carries broad performance work. None of this is revolutionary. Collectively it removes several of the objections a finance team raises in a demonstration.
What NetSuite still brings
Evaluate the exact NetSuite edition, required consolidation and multi-book functions, configured controls and audit evidence. No product guarantees acceptance by a Big Four auditor, and this article does not verify a customer count or hiring outcome. The forced upgrade cycle deserves a second mention as a feature rather than a nuisance. Oracle documents two major NetSuite releases a year with phased upgrades, and recommends customer testing of processes, configurations and customisations. Hosted releases do not remove customer access, integration, configuration, audit or security responsibilities. That is precisely the failure mode on the other side.
The upgrade question is the Odoo risk, and it is manageable
Each annual Odoo release is a migration project, not a background update. Heavily customised deployments fall behind, then fall further, and eventually sit on an unsupported version because the upgrade cost exceeded anybody's appetite. This is the single most common way an Odoo estate goes bad, and it is entirely predictable. Two disciplines prevent it. Budget the upgrade as a recurring annual line rather than a surprise, at a realistic figure. And keep a written register of every core modification, with a standing preference for configuration, studio-level customisation and small separable modules over changes to core behaviour. A deployment that can upgrade in a fortnight stays current; one that cannot, does not.
| Obligation | Evidence from each proposal |
|---|---|
| Maintenance | Scope, owner, support window and funded regression/upgrade plan. |
| Localisation | Named module, regulatory-change maintainer and live reference. |
| Finance fit | Scripted close and multi-entity scenarios using the required edition. |
| Exit | Tested extract format, frequency, access and cost. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for ERP Comparison Consultation
- Model five years of total cost, including upgrades, customisation maintenance and internal headcount — not licences and implementation.
- Write down your three genuinely non-standard processes and test both products against those, not against a generic feature list.
- Decide the maintenance model before the product, because it determines which curve you can afford.
- Name the compliance deadlines you must meet and ask for the specific module that meets each, with its owner.
- Demand a scripted demonstration using your own data, including a month-end close and a multi-entity report.
- Ask both vendors what a bad implementation looks like and check the answer against two reference customers you found yourself.
- Put upgrade obligations and version support in the contract rather than in the proposal.
- Agree the exit position at signature — data extract format, frequency and cost.
The Regional Angle
Three regional factors should carry more weight in this decision than any feature comparison. The first is a hard date. Saudi Arabia's e-invoicing programme moves into its integration phase from the first of January, with the largest taxpayers in the first wave and further waves to follow through next year. That means integration with the tax authority's platform, in a specified format, with clearance behaviour built into the invoicing process — and it is not a reporting add-on that can be bolted on afterwards. Ask both vendors the same question and accept only a specific answer: which named solution delivers this, who maintains it, is it vendor roadmap or partner module, what happens when the specification changes, and which of your reference customers is live on it today. The honest answer from both camps will usually involve a local partner, and the difference between the products in practice is who is contractually responsible when the specification moves. Get that in writing before the licence discussion, because it is the fastest way to discover which proposal is real. The second is deployment flexibility, which is a genuine architectural difference rather than a preference. One product is software as a service and only that, hosted where the vendor hosts it. The other can run on the vendor's cloud, a partner's infrastructure, or your own hardware in country. For most commercial buyers this is irrelevant. For anyone selling to government, working under sector rules on data location, or operating in a regulated vertical here, it can settle the decision before functionality is discussed at all — and it is worth establishing early rather than after four months of evaluation. The third is that a system chosen now will be configured under one tax regime and operated under another. Federal corporate tax in the Emirates applies to financial years beginning on or after the middle of next year, which means the chart of accounts, entity structure and intercompany design being drawn up in this implementation will need to support an entity-level taxable income computation and transfer pricing documentation within months of go-live. Most regional implementers are still designing charts of accounts for value-added tax reporting because that is what they know. Insist that the design review includes the tax adviser, that intercompany transactions are capturable by entity and counterparty from day one, and that entity-level profit and loss is a standard report rather than a spreadsheet exercise. Retrofitting this after go-live is a second implementation wearing a smaller name.
The objection worth taking seriously
The strongest objection is that the comparison is a category error. A company that genuinely needs NetSuite would not seriously consider Odoo, and a company well served by Odoo would be buying far more platform than it needs. A shortlist containing both is evidence that requirements were never defined. And the cheaper product is not cheaper anyway, because implementation and maintenance dominate licence cost in every mid-market programme ever studied. Underneath all of it sits the uncomfortable finding that product choice explains very little of the variance in ERP outcomes — data quality, scope discipline and change management explain almost all of it. That last point is correct and should temper the entire exercise. A disciplined programme on the wrong product beats a chaotic one on the right product, consistently. But the category-error argument was more true five years ago than it is today. Functional coverage at this size genuinely converged, and the shortlists are converging because buyers noticed. And while product choice may not determine success, it does determine your cost trajectory, your upgrade behaviour and who you depend on for the next decade. Which is the correct use of a comparison like this one: not to crown a winner, but to make explicit the operating model you are signing up for, so that the choice is made deliberately rather than discovered in year three.
Common Questions
Is Odoo credible for a company planning to reach five hundred people?
Yes, with the maintenance question answered honestly and upgrade discipline in place from the start. The failures at that scale are almost always customisation debt, not capability limits.
Does NetSuite's forced upgrade cycle cause problems?
Rarely for standard configurations, occasionally for heavily scripted ones. Regression testing twice a year should be planned capacity, not an emergency.
How long should a mid-market selection take?
Six to eight weeks, with scripted demonstrations on your own data. Longer than that and the requirements document has become the project.
What should we expect over the next twelve months?
Expect the new Odoo release to reach partners and customers slowly, as always, with most regional implementations still deploying the previous version well into next year. Expect NetSuite to continue pushing analytics, quoting and vertical editions, and to price renewals firmly in an inflationary year. Expect the Saudi integration phase to force genuine compliance module decisions by the end of this quarter, which will separate serious vendors from optimistic proposals. Expect budget pressure to push a number of mid-market replacements into next year. And expect some of those deferrals to become expensive when corporate tax arrives and the existing system cannot produce entity-level numbers.
ERP Comparison Consultation — we model both cost curves over five years, test each product against your genuinely non-standard processes, and pin down who is contractually responsible when the tax specification changes.