Every Odoo chart of accounts has two structures at once: the list of accounts you post to, and the hierarchy that turns those accounts into readable reports. Up to Odoo 19, the hierarchy came from account groups — a separate layer that inferred structure from account codes. In Odoo 20, that layer is gone. The release notes state it in one sentence: account groups have been replaced by parent accounts as the method of structuring charts of accounts, and account codes are now optional. It sounds like housekeeping. For anyone with custom reports, multi-company charts, or a carefully numbered chart built over years, it is one of the accounting changes most worth understanding before upgrading.
How account groups worked
Account groups existed to list multiple accounts as sub-accounts of a bigger heading, so reports such as the Trial Balance could consolidate them with subtotals. The mechanism was code-driven. By default, groups were handled automatically from the account code: a new account 131200 fell into the group 131000 simply because of its prefix. You could also attribute a specific group to an account manually through its Group field.
Creating your own groups was deliberately out of the way. It required developer mode, and a group was defined by a name, the company it applied to, and a code prefix range — with the instruction that the same prefix had to be entered in both the From and To fields. To see the structure, you opened the Trial Balance, went to Options, and enabled Hierarchy and Subtotals.
This design had real virtues: if your numbering was disciplined, hierarchy appeared for free. It also had a structural weakness. The hierarchy was a side effect of your numbering scheme. Want an account to appear under a different heading? You effectively had to renumber it or override its group. Want a hierarchy that does not correspond to numeric prefixes at all — grouping by business meaning rather than by code ranges? The group system pushed back. And because groups were derived from codes, the code stopped being a mere identifier and became load-bearing structure: change a code carelessly and a report quietly rearranged itself.
What parent accounts change
Odoo 20 replaces the inferred layer with an explicit one: the hierarchy now lives on the accounts themselves, as a parent–child relationship. Each account can point to a Parent Account, and reports build their hierarchy from those links. Odoo's localization documentation describes the resulting model plainly: set the appropriate Parent Account on each account to create a hierarchy for reports; accounts without a parent are level 1 accounts, accounts below them are level 2, and so on.
Three consequences follow.
- Structure is declared, not inferred. An account sits under a heading because someone put it there, not because its code starts with the right digits. Reorganizing a report means re-pointing a parent, not renumbering accounts.
- The hierarchy and the numbering are decoupled. You can keep a legacy numbering scheme for familiarity while arranging reports semantically — or drop meaningful numbering altogether, which leads to the second half of the change.
- One structure serves the chart. There is no longer a parallel group layer to keep in sync with the accounts it describes, and no developer-mode detour to define roll-ups.
Odoo has also rebuilt its standard localization charts around the new model: several country charts in the release notes are described as updated to scalable digit structures that group parent accounts, so a fresh Odoo 20 database starts life with a parent-based hierarchy rather than a group-based one.
Account codes are now optional
The companion change is easy to underestimate. Because groups were derived from code prefixes, codes were effectively mandatory structure. With parent accounts carrying the hierarchy, Odoo 20 makes account codes optional: an account can be identified by its name and its place in the tree.
That is liberating for small or new charts, where inventing a numbering scheme is pure overhead — name the account well, hang it under the right parent, and move on. It deserves more caution in established organizations:
- Codes are how accountants, auditors, and external systems refer to accounts. Spreadsheets, bank mappings, payroll exports, and BI extracts frequently key on the code.
- Many localizations and statutory reports are built around coded charts. Odoo's own localization docs still warn, in places, about numbering expectations and flag accounts whose numbering could cause problems in reports.
- “Optional” describes what the software requires, not what your audit trail prefers. Removing codes from a mature chart discards information other processes depend on.
The sensible reading: new accounts no longer need a code invented purely to satisfy the hierarchy — but an existing coded chart should keep its codes unless you have traced everything that consumes them.
Account groups vs parent accounts
| Aspect | Account groups (up to Odoo 19) | Parent accounts (Odoo 20) |
|---|---|---|
| Where the hierarchy lives | A separate group layer (account.group) alongside the accounts | On the accounts themselves, as parent–child links |
| How an account joins a heading | Automatically, by code prefix (e.g. 131200 into group 131000), or via a Group field override | Explicitly, by setting the account's Parent Account |
| Role of the account code | Structural — prefixes define the grouping | Identifier only — and now optional |
| Reorganizing a report | Renumber the account or override its group | Change the account's parent |
| Defining custom roll-ups | Developer mode; group defined by name, company, and code prefix range | Set parents on the accounts; level 1 accounts are those with no parent |
| Where it showed up | Consolidated reports such as the Trial Balance, via Hierarchy and Subtotals | Chart structure used for reporting and visualization |
What this means for reports and customizations
For standard reports, the practical effect is that the hierarchy you see is the hierarchy you declared. That is an improvement in auditability: when a subtotal looks wrong, there is a concrete parent link to inspect instead of a prefix rule to reverse-engineer.
The upgrade risk sits outside the standard reports. Anything that consumed the old structure needs review:
- Custom reports and dashboards that grouped, sorted, or subtotalled by account group or by code prefix no longer have the same inputs. Rebuild them against the parent hierarchy and compare totals against the pre-upgrade reports.
- Integrations and exports — BI connectors, consolidation tools, spreadsheet models — that read group assignments or assumed code-based roll-ups must be re-pointed.
- Studio and custom-module logic referencing account groups should be tested in a staging upgrade with a full month of real transactions, because structural accounting errors typically surface at month end, not at first login.
Odoo's upgrade path converts the chart itself, but no migration can know what your external reports meant by a group. Inventory those dependencies before the upgrade, not after the first board pack comes out wrong.
Designing a clean hierarchy in Odoo 20
If you are setting up or cleaning up a chart under the new model, a few practices help:
- Keep the tree shallow. Two or three levels cover most reporting needs; deep trees make reports harder to read and parents harder to maintain.
- Let parents be headings. Use top-level and intermediate accounts as grouping nodes that mirror how management actually reads the balance sheet and profit and loss — current assets, cash and equivalents, operating expenses — and post day-to-day transactions to the leaf accounts beneath them.
- Name for the reader, code for the system. Even though codes are optional, keep them where external references exist; rely on names and parents to carry the meaning.
- Harmonize across companies deliberately. For a group running several subsidiaries, a shared parent structure is what makes consolidated reporting comparable. Odoo partners highlight exactly this scenario — a group harmonizing charts of accounts across subsidiaries — as the moment to revisit how accounts are organized, and parent accounts make that harmonization explicit rather than a numbering negotiation.
The bottom line
Parent accounts are a small sentence in the Odoo 20 release notes and a foundational change underneath it. The chart of accounts stops deriving its shape from numbering conventions and states it directly, account by account. Fresh implementations get a simpler model with optional codes. Upgraders get a cleaner structure too — provided they audit the reports, exports, and integrations that quietly depended on account groups, and verify the new hierarchy against a closed month before trusting it.
Further reading
- Odoo 20 Release Notes — the Accounting section: “Account groups have been replaced by parent accounts… Account codes are now optional.”
- Chart of accounts — Odoo 20.0 documentation — account configuration, types, and how the chart is organized.
- Mexico — Odoo documentation — a localization's guidance on setting Parent Account to build report hierarchies, level by level.
