Odoo 15 was released on 3 October and is being demonstrated this week at the company's annual conference, held online again this year. The release notes run past a thousand items, which is the number that gets quoted and the number that tells you least. Most of those entries are refinements to modules you do not use. For an organisation actually running its business on Odoo, the useful question is narrower: does anything in this version change how work is done, and does it change the calculus on when to upgrade? This year, unusually, the answer to the first question is yes — and it has nothing to do with the feature count.
The spreadsheet is the story
Odoo 15 embeds a real spreadsheet inside the application, connected to live data. You can insert a pivot from any Odoo report, apply conditional formatting, use find and replace, and link cells to records and menus. It behaves like the tool your finance team already uses, except that it refreshes against the database rather than against a file somebody emailed on Thursday. Understand what that addresses. The characteristic failure of every ERP implementation, in every product, is that reporting leaves the system. Somebody exports to a spreadsheet because the standard report is eighty per cent right, adds a column, fixes a mapping, and circulates it. Six months later that file is the version of truth, the board pack no longer reconciles to the ledger, and the organisation is running on a workbook whose logic lives with one person. An in-product spreadsheet does not eliminate that failure. It relocates it, which is a genuine improvement — the data refreshes, the lineage is visible, permissions apply — but only if the organisation makes some decisions rather than simply enabling the feature.
Four decisions to make before anyone builds a workbook
Which reports are canonical. Name the small set of reports that are the official numbers. Everything else is analysis. Without that line, you will have three revenue figures by Christmas. Who may publish. Building a spreadsheet for yourself is analysis. Circulating one is publishing, and publishing needs an owner and a review. Whether formulas may override source values. They should not. The moment a workbook contains a hard-typed correction to a figure pulled from the ledger, it has become a parallel accounting system with no audit trail. Whether it is a report or a model. Reports read data. Models make assumptions. Both are legitimate; mixing them in one file is how forecasts end up presented as actuals. Get those four written down in a page, and the spreadsheet is the most useful thing Odoo has shipped in three releases. Skip them, and you have moved shadow reporting inside the perimeter and given it better credentials.
| Decision | Boundary |
|---|---|
| Canonical reports | Name which reports are the official numbers |
| Publication | Assign an owner and review before circulation |
| Overrides | Keep source corrections in the governed source process |
| Assumptions | Distinguish actual-data reports from models |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What else is worth noting
The editor used across the mail composer, website and content surfaces has been rebuilt, which brings consistency and reduces the training problem of three different editing experiences. Point of sale gets a proper secure login for sessions, which matters more than it sounds in retail: cashier identity per session is the difference between an audit trail and a shrug. There is a new import screen, which sounds trivial until you are loading opening balances or a supplier master at go-live. The website configurator has acquired an automated build capability that is more interesting to marketing than to anyone running finance or operations. None of those individually justifies a project. Together with the spreadsheet, they make 15 a sensible target version rather than a release to skip.
The upgrade decision, honestly
Odoo ships annually and supports roughly three versions at a time. That cadence is the actual planning constraint, and most users ignore it until they cannot. If you are on 13, you are near the edge of support. If you are on 12 or earlier, your upgrade is no longer an upgrade; it is a re-implementation wearing a smaller word, because migration scripts, community modules and partner tooling are all tested version to version rather than across four years. The realistic policy for a mid-sized business is to move every second version, budgeted in advance, rather than to upgrade when a feature is wanted. Feature-driven upgrades arrive at the worst moment and are always justified with the least relevant reason. Before committing to a date, do the inventory. List every non-standard module in the database and sort it into three piles: functionality that has since arrived in the standard product and can simply be dropped, third-party applications whose maintainer may or may not have published a version 15 branch, and genuinely bespoke code written for you. The first pile is a saving. The third is predictable work. The second decides your timeline, and checking each dependency's availability takes about fifteen minutes and prevents the most common upgrade failure, which is discovering in week six that the module running your delivery routing has no maintained release.
Practical Guidance for Odoo 15 Implementation
- Inventory custom and third-party modules first, and check version availability for each before setting any date.
- Drop what the standard product now does rather than migrating it, and count that as the project's first win.
- Decide the spreadsheet governance rules before the first workbook is published, not after the third revenue number appears.
- Test with production data volumes, because performance regressions do not appear in a demo database.
- Never upgrade across a statutory close — schedule after the period is filed, not before.
- Keep a read-only copy of the old database for audit and comparison, with a defined retention period.
- Re-test every printed document, since document layouts are legal records, not cosmetics.
- Budget the upgrade every second version as a standing line rather than as an exceptional project.
The Regional Angle
Three regional considerations should shape the timing of any Gulf upgrade to 15, and the first is a hard date. Saudi Arabia's electronic invoicing obligation begins its first phase on 4 December, which requires compliant generation of invoices with the prescribed content and format. Any Odoo installation serving a Saudi entity has, therefore, about eight weeks to be demonstrably compliant. That single fact should settle the upgrade sequencing question for every group with a Saudi company in the database: do not run a version upgrade and a statutory compliance deadline through the same team in the same eight weeks. Either complete the invoicing work on your current version and upgrade in the first quarter of next year, or upgrade immediately and leave clear air before December — which, realistically, is no longer available. The dependency to verify this week is whether the localisation you rely on, whoever maintains it, has a release for the version you intend to be running on 4 December. The second concerns Arabic and printed documents, and it is the test most upgrades skip. A rebuilt editor and a new spreadsheet surface are precisely where right-to-left rendering regressions appear. That would be a cosmetic annoyance in most markets. Here the printed tax invoice is a legal document with mandated content in Arabic, so a template that reflows, truncates a field or loses a bilingual label has not created a formatting bug — it has produced a non-compliant document, at volume, before anybody notices. Put Arabic invoices, credit notes, bilingual purchase orders and statements at the top of the acceptance test, and have somebody who reads Arabic sign them off rather than somebody checking that the page renders. The third is an opportunity that upgrades create and almost nobody takes. Regional groups routinely run several entities in one database across increasingly divergent tax regimes: five per cent in the Emirates, fifteen in Saudi Arabia, ten in Bahrain, and Oman's new regime introduced only this April. In most installations those were bolted on as each obligation arrived, with rates configured in the wrong place, tax mappings duplicated per company and reporting assembled manually. An upgrade forces a review of tax configuration anyway. Use it to set tax up per company properly, to move rates out of anywhere they have been hard-coded, and to get statutory reporting generated by the system for each jurisdiction. Doing that work during an upgrade is a fraction of the cost of doing it as its own project, and the next rate change in this region will not be the last.
The objection worth taking seriously
The strongest objection is upgrade fatigue, and it deserves a real answer rather than a vendor's one. An annual release cycle is convenient for the vendor and expensive for the customer. A business running well on a stable version gets no measurable benefit from a version number, the upgrade consumes real money and the attention of the same handful of people who are needed everywhere else, and every upgrade carries regression risk against processes that currently work. Staying put is frequently the rational choice, and skipping a single version usually costs nothing. That argument is sound for one version and collapses at three. The cost of deferral is not linear. It accumulates in three places: security and bug fixes stop arriving for unsupported versions; statutory functionality — tax rules, invoicing formats, reporting layouts — is developed against recent versions, so falling behind converts a compliance deadline into an emergency migration; and community and third-party modules quietly stop maintaining old branches, so the further back you sit the more of your estate becomes orphaned code that only your current partner can touch. There is also a staffing dimension that is sharper this year than last. The pool of consultants fluent in a four-year-old version shrinks continuously, and in a market where implementation talent is scarce and being bid up, the people willing to work on your old release will be the ones nobody else wanted. Upgrading is not about features. It is about staying inside the supported, staffable, statutorily maintained part of the product.
Common Questions
Should we upgrade to 15 immediately?
Unlikely, unless you are already on 14 with few custom modules and no year-end or statutory deadline in the next quarter. For most, plan it for the first or second quarter of next year with the dependency check done now.
Is the spreadsheet a replacement for a reporting tool?
For operational and management reporting against Odoo data, largely yes. For consolidation across multiple systems, no. Do not let its arrival cancel a data warehouse decision that exists for a different reason.
What is the most common upgrade failure?
An unmaintained third-party module discovered halfway through, followed by a printed document layout that nobody tested until the first customer complained.
What should we expect over the next twelve months?
Expect version 16 to be announced at next year's conference on the same annual rhythm, which means 15 will be a well-supported target for the next two years and a sensible place to land. Expect the spreadsheet to acquire the features it is currently missing quickly, since it is clearly a strategic surface for the vendor. Expect regional localisation work to dominate Gulf implementation capacity into next year as the Saudi invoicing programme moves toward its integration phase and other administrations study the model. And expect a wave of businesses on versions 12 and 13 to discover during next year that what they postponed as an upgrade has quietly become a replacement project.
Odoo 15 Implementation — we scope the upgrade against your actual module inventory, sequence it around statutory deadlines rather than into them, and put reporting governance in place before the first spreadsheet is published.