Skip to Content

Odoo 20: what's being said, what's known and what we found when we opened the code

We went to the public repository, the official documentation and the subscription agreement to verify what the next version really brings. And we're announcing that our electronic invoicing V3 is already being migrated, months before the release.
September 2, 2026 by
Odoo 20: what's being said, what's known and what we found when we opened the code
CHRISTIAN GARCIA

Every September the same thing happens. Odoo announces a new version, and in the weeks leading up to it the internet fills with articles promising the same thing in different words: revolution, artificial intelligence, the biggest change in the product's history.

We did something else. We went to the public repository, the official documentation and the subscription agreement, and verified what's there and what isn't. This article separates three things that usually come mixed together: what's being said, what's confirmed and what we found ourselves when we reviewed the code.

If your company runs on Odoo, the last part is the one that will either cost you money or save you money.

1. What's being said

Since April, notes have been circulating about the roadmap presented at the Partner Days. The recurring points:

  • Agentic artificial intelligence capable of executing multi-step tasks on its own
  • Support for more than 10,000 concurrent users with read replicas
  • Mobile interface rebuilt from scratch
  • Native financial forecasting, telephony inside CRM, simplified inventory model
  • New vertical apps by industry

It's worth taking that down a notch. Odoo itself describes its roadmap as a list of things it might do. Nothing on that list is a commitment. And to date, none of those figures have been published by Odoo: they come from third-party summaries that copy each other.

The version is expected to be presented at Odoo Experience in Brussels, September 24 to 26, 2026, with the stable build arriving between October and November. That date isn't confirmed on any official Odoo channel either at the time of writing.

2. What is confirmed

Everything below can be verified today, by anyone, in primary sources.

There is no version 20 yet

Odoo's public repository has branches 16.0, 17.0, 18.0 and 19.0. The master branch — the code that will be frozen as 20.0 — is identified internally as 19.5 alpha 1. There's no 20.0 branch.

The code can already be downloaded

Odoo publishes nightly builds of master every day, as source and as a Debian package. It's alpha software: it breaks between commits and has absolutely no business anywhere near a real operation. But it serves what we're using it for: testing portability months in advance.

The support calendar is public and has financial consequences

Odoo provides three years of standard support per major version:

VersionEnd of standard support
Odoo 16September 2025 — expired
Odoo 17September 2026
Odoo 18September 2027
Odoo 19September 2028

And the Enterprise Subscription Agreement is explicit about what happens after that. Verbatim quote from the contract:

Once a year, and no earlier than 6 months after the release of a new major version, if the Customer's database is on a version older than the Covered Versions, the Customer agrees to pay an extra fee equal to 25% of the annualized price.

In plain terms: if your company is on Odoo 16, that surcharge is already running. If you're on 17, it starts running when 20 comes out. It's not anyone's sales threat — it's in the contract you already signed.

New technical requirement: Python 3.12 or higher

Odoo 19 runs on Python 3.10. The development branch requires 3.12 at minimum. A server with Ubuntu 22.04 won't be able to run the new version without first upgrading the operating system. That's not an Odoo migration, it's an infrastructure migration, and a lot of people are going to find out late.

3. What we found when we opened the code

Here's the real news, and we didn't see it in any of the articles going around.

The permissions system changed completely

For more than a decade, every Odoo module declared its security in two separate pieces: access rights, which say what each group can do on each model, and record rules, which say which rows each person can see.

In the new version, those two pieces were merged into one. The model that governed record rules disappeared from the code base. So did the one that governed access rights. In their place there's a unified model, with a different file format: the four separate permissions collapse into a single string, the model reference changes form, and the record rule becomes just another column in the same row.

There's no compatibility layer. There's no automatic conversion of the source code.

What it means in business terms: every custom module your company has installed stops starting up until someone rewrites its security files, one by one. It's not a cosmetic adjustment. It's the deepest framework change in years, and it arrived quietly, inside an intermediate July release.

Binary fields changed format, and that reaches beyond Odoo

Attachments, PDFs, signed XMLs, images: all of that stopped traveling encoded the way it used to. There's also a declared change in the format in which binary fields are transmitted through the integration interfaces.

This doesn't just break modules. It breaks what's outside: connectors to in-house systems, migration scripts, third-party integrations, anything that talks to Odoo from another program. It's the kind of failure that doesn't show up in screen testing and does show up on a Monday at eight in the morning.

Deep changes almost nobody is going to mention

  • Modular PDF engine. Document generation is no longer tied to a single tool and becomes selectable by configuration. Good news in the medium term; verification work in the short term, because every custom report has to be checked in print again.
  • New HTTP server. The web service was rebuilt on a different foundation. It affects deployments, reverse proxies and persistent connections.
  • Website modules that relied on accessing the browser request from the model: that access was removed.

4. Artificial intelligence: less and more than they say

This is the part where noise and reality diverge the most.

What it brings, confirmed in the official documentation: conversational agents configurable with instructions, skills and indexed document sources; a new type of automated action where the model decides which tool to run and with what arguments; and a server that lets external assistants connect to the database.

What it doesn't bring, and you'd better know before budgeting:

It's not a workflow orchestrator. There's no node canvas, no branches, no retries, no catalog of connectors to other systems. The automated action evaluates a text of instructions and picks one tool. Business logic is still written by a programmer. The documentation says it bluntly: tools must enforce business rules explicitly in their own code.

It's not in the Community edition. We checked the public repository: there's no artificial intelligence module in the free edition. It's an Enterprise-only feature, with a mandatory API key on self-hosted installations and on Odoo.sh.

It only works with two providers: OpenAI and Google Gemini. There's no support for Anthropic or for local models. If your internal policy, your regulator or your customer requires another provider, there's no configuration option: it's just not there.

And a security warning that shouldn't be overlooked. The official documentation states that if the model chooses a tool, that tool runs unconditionally, unless its own code prevents it. In other words: between a language model's decision and a real write to the database there's no approval layer out of the box. Add to that the fact that authentication for the external assistant server is a static key, and anyone who's going to enable this in production has to build validation into each tool. It's not optional and it doesn't come built in.

5. Where VALTRIOM comes in

All of the above leaves three concrete gaps. All three are exactly where we work.

Gap 1: AI stayed on the expensive-license side

Thousands of companies in Panama run on the Community edition, for cost reasons or as an architecture decision. For them, all of the above simply doesn't exist.

VTBrain, our own artificial intelligence and business automation platform, doesn't depend on that license. Génesis, its assistant, converses with business data, answers in natural language and works on the company's real information, without requiring the Enterprise edition or per-user fees in order to think.

Gap 2: two providers aren't enough

Our Integration Hub lets you choose the model engine per instance, Anthropic included, with a configurable fallback chain to other providers and a local fallback. For a bank, a regulated entity or a company with its own data policy, being able to decide which model processes its information isn't a technical luxury: it's often the requirement that decides whether the project happens or not.

Gap 3: business messaging

The channels where people actually buy today — WhatsApp, social media, website chat — we handle from our own omnichannel layer with Génesis, integrated into the sales flow and not bolted on the side.

We don't compete with the new version: we cover what it leaves out.

6. Panama: what Odoo still hasn't solved

We reviewed the development branch. The included Panamanian localization is still only the chart of accounts and taxes. Zero electronic invoicing. Zero CUFE. Zero integration with the DGI. Zero connection with authorized providers.

It's not an oversight: there's tax localization documentation for Mexico, Colombia, Peru, Ecuador, Guatemala, the Dominican Republic and Uruguay. Panama isn't on that list, and it won't be in this version.

Meanwhile, Resolution 201-6299 of July 29, 2025 took effect on January 1, 2026: the free platform was limited, in general terms, to taxpayers with up to B/.36,000.00 in annual revenue and 100 documents per month. Anyone above that must invoice through an authorized provider.

The obligation exists. The native solution doesn't. We've been filling that gap for years.

7. The announcement: electronic invoicing V3, already in migration

Version 3 of our electronic invoicing module suite for Panama is being migrated to the new version of the platform, before that version is released.

The entire suite is included: the base Panamanian localization module, document and voucher handling, taxpayer lookup against the DGI, point of sale integration, e-commerce integration and the connectors to the various authorized providers on the market.

Why we started before and not after. Because the permissions system change we described above has been known since July, and waiting for the stable build in November means delivering in the second quarter of 2027. Our customers invoice every day; their tax compliance can't be left waiting for someone to start reading release notes in December.

Starting with the alpha code has a cost: you're working on shifting ground. We absorb it, not the customer.

What this means if you already work with us. Your electronic invoicing will be ready when the new version is stable, not six months later. And we'll hand you a tested migration path, not an improvised one.

8. What you should do, depending on where you are today

If you're on Odoo 16 or earlier: you're already paying the 25% surcharge or you're without support. This doesn't wait for the new version. It's this quarter's conversation.

If you're on Odoo 17: the surcharge starts running with the release. You have a short, known window.

If you're on Odoo 18 or 19: you have time — 2027 and 2028 respectively. Use it. What you won't have time to do is inventory your custom modules the month before migrating.

In all three cases, do these three things now:

  1. Inventory your custom code. How many in-house modules you have, who wrote them, which ones are still in use. It's the most uncomfortable conversation in a migration and it always gets put off.
  2. List your external integrations. Everything that talks to your ERP from another system. That's where the binary field format change will hit without warning.
  3. Check your server's Python version. If it's 3.10, your migration includes the operating system. That changes the timeline and the budget.

Don't migrate to the first stable build. Ever. Odoo's point-zero releases stabilize over the following months, and this one brings a deep framework change. The sensible window starts in the first quarter of 2027 — which is exactly the timeline we're preparing ours for.

Let's talk

If you want to know how your specific installation stacks up against the new version, we run the assessment: inventory of custom modules, integrations at risk, server condition and a migration path with dates.

And if you're not invoicing electronically yet, or if your current provider left it half-done, that's been our territory from the start.

Article based on primary sources: Odoo's public repository, official documentation for the development branch and the Odoo Enterprise Subscription Agreement, consulted on September 2, 2026. Information about unreleased versions may change before launch.

Share this post
Tags