Odoo 20 for Implementers: What Changes in a New Project

On a new Odoo 20 project, five design decisions are taken differently from an Odoo 19 project: security is designed as a domain on each access right instead of separate record rules, the chart of accounts is structured with parent accounts (codes become optional), Point of Sale and eCommerce can run on simplified inventory without the Inventory app, user roles include a Light role, and AI needs IAP credits in the budget. Each is cheap to decide during design and expensive to change once users and postings exist, so all five belong in the design document before configuration starts.

This page is for whoever writes that document. It is not a feature tour or an upgrade guide. Everything below comes from Odoo's Odoo 20 release notes and the Odoo 20.0 documentation, plus one 19.0 page where the 20.0 page is not written yet, all checked on 13 October 2026, followed by the decision we think each change implies.

First, the documentation has not caught up

On 13 October 2026, the 20.0 page on access rights still described a Record Rules tab on the group form, the developer security reference still documented ir.rule, and the 20.0 chart of accounts page still explained account groups and the Allow Reconciliation checkbox. Apart from its version label, that chart-of-accounts page matched its 19.0 counterpart line for line. The release notes, the newer statement, say record rules and account groups have been replaced and Allow Reconciliation is now Payment Reconciliation.

The working rule: design from the release notes, confirm every screen in your own 20.0 database, and never reuse a 19.0 design document unchecked.

The decision register at a glance

Area	What 20.0 changes	Decision to record	Decide by
Security	Record rules removed; a domain sits on the access right	Per group: which models, which operations, which records	End of design
Users	A Light role alongside User and Portal	The role of every named person	Before the user import
Chart of accounts	Parent accounts replace account groups; codes optional	Codes or no codes; the parent structure	Before any posting
Bank and assets	Bank entries must come from bank transactions; depreciation lives on asset accounts	How opening bank balances load; depreciation settings	Before data migration
Stock	POS and eCommerce can run without the Inventory app	Simplified inventory or the Inventory app	End of design
AI	All AI features need IAP credits	Features in scope, credit owner, provider key, MCP exposure	Before user testing

1. Security: design the domain on the access right

Until 19.0, a security specification had two layers: access rights (which models a group can read, write, create or delete) and record rules (which records inside those models). The 20.0 release notes state that "access rights have been simplified by removing record rules and adding a domain directly at the access right level to determine which records the access right applies to."

What that implies:

• Write one security matrix, not two. One row per group and model, with the four operations and the record condition together ("records where the salesperson is the current user"). Add conditions only where the business really separates data by company, team, salesperson or warehouse.
• Test users who belong to several groups on purpose. The 20.0 developer reference still states that access rights are additive. How several domains on the same model combine for one user is not described in the documentation we read, so prove it in testing.
• Never test security as an administrator. Superuser mode "allows the user to bypass record rules and access rights", so a check done that way proves nothing. Log in as a real user from each role, in a duplicate database.
• Use the new audit trail. "User group changes are now logged in the user's chatter as well as in the console logs." During testing, that history shows whether a tester's access changed or was never right.

2. Users: decide the role of every person

The 20.0 access-rights page lists three internal roles (User, Administrator and Light) plus Portal for external users; the 19.0 version of the same page has no Light role. A light user "can be linked to an employee record to provide limited access to the database, or can exist solely as an employee record without login access." With a login, they can handle their own employee information, leave and expense requests, Planning, Point of Sale sessions as an employee, Knowledge articles and barcode scanning, but they "do not have access to core business applications such as Sales, Purchases, Projects, or Accounting."

The decision carries a cost: "A Light user is automatically upgraded to a User role if they are granted access beyond their default reduced permissions," and the page refers to Odoo's pricing page for what that means. So classify every person as User, Light, Portal or employee without login before the user import, record which app makes each User a User, and re-count roles after every round of group changes in testing. The upgrade happens when someone grants a group, not when someone decides it.

3. Chart of accounts: parent accounts, and whether you keep codes

The release notes state: "Account groups have been replaced by parent accounts as the method of structuring charts of accounts. Account codes are now optional." Several localizations were reworked around this; the United Arab Emirates chart now "features a scalable 6-digit numbering system and reverse-liquidity sequencing", with parent account groups.

• Codes or no codes. Keep codes if your accountant, auditor, tax filings, consolidation or any export works by code. Drop them only when everyone reads the ledger by account name inside Odoo. Decide before the opening-balance import, because every mapping file depends on it.
• Parent structure. Build the parents around the reports management reads, not around the old system's numbering.
• Start from the 20.0 localization. A chart exported from an older database will not have the new parent structure.
• The hard stop still applies: "It is not possible to modify the fiscal localization of a company once a journal entry has been posted."

Other accounting defaults that change the setup

• Opening bank balances. "All journal entries impacting bank accounts must now originate from bank transactions." Load opening bank positions as bank transactions or a statement, not a manual journal entry, and rehearse it.
• Fixed assets. Asset models become depreciation models, and "essential information and automated behaviors are located on asset accounts themselves." Configure depreciation while designing the fixed-asset accounts.
• Fiscal positions. If a product's default tax "does not belong to the fiscal position set on an invoice, the tax is removed, even if there is no replacement." Map every tax into every fiscal position; the symptom of a gap is an invoice posted with no tax.
• Payment status words. "In Process" is now "Paid", and "Paid" is now "Reconciled". Put those definitions in training material and dashboards: in 20.0, "Paid" does not yet mean matched to the bank.
• Expenses. Approved expenses create draft bills in the default expense journal. Name who reviews and posts them.

4. Stock: simplified inventory or the Inventory app

Point of Sale and eCommerce "can now work with simplified inventory management, without installing the Inventory app. A single on-hand quantity is displayed per product and there are no required transfers." Accounting adds that stock on hand and valuation can be managed without the Inventory app.

Choose simplified inventory when	Choose the Inventory app when
One on-hand quantity per product is enough	You need quantities per warehouse or location
There is no receipt, pick or delivery step to document	Receipts, transfers or deliveries must be recorded
Replenishment is decided outside Odoo	You want reordering rules (20.0 suggests minimum and maximum levels from demand history)
Your accountant accepts valuation without stock moves	You need landed costs, routes or the new stock aging report

One question the release notes do not answer is how a database moves from simplified inventory to the Inventory app later, for example when a second shop opens. We did not find it documented, so rehearse it in a duplicate database before calling it simple. If a second location is already planned, start with the Inventory app.

5. AI: a budget line and a security boundary

The release notes state: "All AI features now need credits, which can be bought via IAP." On 13 October 2026 the 20.0 AI API keys page was marked as under construction. Its 19.0 counterpart states that "API keys are required for Odoo.sh or On-premise databases to use AI features" (optional on Odoo Online), lists Gemini and OpenAI as providers, and notes that keys "may require additional fees through the provider." Check the same settings in your own 20.0 database before relying on them.

So the budget can carry two AI lines: IAP credits and, when self-hosted, the provider's usage charges. The documentation we read does not say how the two combine on Odoo.sh or on-premise, so confirm with Odoo before quoting a running cost. Per the IAP documentation, credits are prepaid per service, priced per service, and low-credit email alerts can be set up.

Record these decisions: which AI features go live first; who owns the credit balance and the alert; which provider, using a service-account key rather than a personal one (the 19.0 page notes that a key tied to a user is disabled if that user is removed from the provider organization or project); and which skills (formerly topics) each agent gets, since the agents documentation states that an agent without skills can only provide information.

Treat MCP as a security decision. The MCP server documentation connects an external AI client to database-url/mcp with a user API key in the MCP scope, valid for a set period; the key carries that user's identity and permissions. Five read tools are exposed by default (Get Fields, Get Models, MCP Retrieve initial context, Search, Read group). Any other server action must be ticked Available in MCP, and the Readonly Tool flag does not hide a tool, it only lets the client run it without asking. Connect MCP through a dedicated user whose access rights define what the client may reach, keep the key short-lived, and expose write tools one at a time.

6. Smaller defaults worth a line in the design document

• Manufacturing. The flexible-consumption setting on bills of materials is removed and "all manufacturing orders use flexible consumption by default." If the business relied on strict consumption, decide how component variances get reviewed.
• Sales. Order lines "no longer require a linked product by default." Turn on Mandatory Product if sales are analysed by product.
• Returns. The return wizard is removed, and eCommerce can let customers return products from the customer portal. Write the returns procedure from the new flow.
• Change history. Stored tracking values are removed; admins who need them "can install a dedicated module." If an auditor needs stored field-change history, decide before go-live.

7. Modules: the gate that sets the start date

Start on 20.0 unless a module you need has no 20.0 build. List every third-party and custom module in scope and get each vendor's 20.0 status in writing. For our parent company ECOSIRE's modules, the Odoo 20 compatibility page lists which have a published 20.0 build. Odoo's support policy gives each major version three years of standard support; on 13 October 2026 its table listed 20.0 with standard support planned until September 2029.

What goes wrong, and how to spot it

Symptom	Likely cause	Where to look
A user sees another team's records, or not their own	A domain on an access right, or a user in two groups	Log in as that user; read group changes in their chatter
An invoice to a foreign customer posts without tax	A tax missing from the fiscal position	The fiscal position's tax mapping
The opening bank balance will not post as a journal entry	Bank entries must come from bank transactions	Load it as a statement
Finance calls invoices "Paid" that are not in the bank	20.0 status wording	"Paid" versus "Reconciled"
A light user now shows as a User	A group granted beyond the Light defaults	The user's role after testing changes
AI stops working during testing	Credits used up, or no provider key when self-hosted	IAP services; AI app settings

A kickoff checklist for a new 20.0 database

• Every module in scope has a confirmed 20.0 build, in writing
• Security matrix with the record condition on each access right, tested as a real user per role
• Every person classified as User, Light, Portal or employee without login
• Account-code decision and parent structure agreed with the accountant
• Opening bank balances planned as bank transactions; every tax mapped in every fiscal position
• Simplified inventory or the Inventory app chosen, with the second-location question answered
• AI features, credit owner, provider key and MCP exposure recorded

For the go-live side, our Odoo implementation checklist orders pre-launch checks by how hard each is to undo. It was written for Odoo 19: most tiers carry over, but replace its access-rights and chart-of-accounts steps with the 20.0 versions above. For help writing the design document or running the project, see our Odoo implementation service.

Frequently Asked Questions

Should a new Odoo implementation start on Odoo 20?

In most cases, yes. A new 20.0 database gets the longest run under Odoo's three-year standard support policy and avoids an upgrade soon after go-live. The exception is a module the project depends on that has no 20.0 build yet.

Do record rules still exist in Odoo 20?

The 20.0 release notes state that access rights "have been simplified by removing record rules and adding a domain directly at the access right level." On 13 October 2026 the 20.0 user and developer documentation still described record rules, so check the forms in your own 20.0 database before writing the security design.

Can Odoo 20 Point of Sale run without the Inventory app?

Yes. Point of Sale and eCommerce can use simplified inventory management without the Inventory app: one on-hand quantity per product and no required transfers. Choose the Inventory app for stock per location, documented transfers, reordering rules or landed costs.

Do Odoo 20 AI features cost extra?

The release notes state that all AI features now need credits bought via IAP. Odoo's AI API keys documentation (the 19.0 page; the 20.0 page was under construction on 13 October 2026) adds that Odoo.sh and on-premise databases need an OpenAI or Gemini API key, which may add provider fees. Budget for both until Odoo confirms the charges for your hosting.

Are account codes required in Odoo 20?

No. Parent accounts replace account groups and account codes are now optional. Keep them if your accountant, auditors, tax filings or exports work by code, and decide before importing opening balances.