The Odoo Chart of Accounts: Structure, Codes and Multi-Company

What an account actually is in Odoo

An account is a record on the account.account model. The fields that decide its behaviour are a

short list, and almost every setup mistake traces back to one of them:

• account_type is the selection that tells Odoo what kind of account this is. It drives report

placement, whether the balance carries forward into the next year, and how the account is treated

at close. This is the field that matters most and the one people set carelessly.

• code is the number you see in the interface and on reports.
• reconcile is a boolean that decides whether journal items on this account can be matched off

against each other. Receivable and payable accounts need it. Most expense accounts do not.

• internal_group and group_id position the account for grouping and reporting.

The type is not a label. Setting a bank account to the wrong account_type does not produce a

warning, it produces a balance sheet that is quietly wrong in a way nobody notices until year end.

Account codes are company-specific in Odoo 18 and 19

This is the single most surprising thing about the model, and it is easy to trip over in a

multi-company database.

In Odoo 17, the code is a plain stored column on the account:

code = fields.Char(size=64, required=True, index=True)

One account, one code, everywhere.

In Odoo 18 and Odoo 19, that changed. code became a computed field backed by a

company-dependent store:

code = fields.Char(string="Code", size=64, compute='_compute_code',
                   search='_search_code', inverse='_inverse_code')
code_store = fields.Char(company_dependent=True)
placeholder_code = fields.Char(compute='_compute_placeholder_code')

The consequence is that a single account record can carry a different code in each company.

The model also gained code_mapping_ids and a company_ids many2many, which is the mechanism that

makes a shared account list workable across companies with different national numbering schemes.

Two things follow from this that catch people out:

1. Reading code gives you the code for the company in the current context. If you query over

RPC or in a scheduled action without setting the company deliberately, you get whichever company

the environment happened to be in.

2. An import that sets code sets it for one company. If you expected it to apply to the whole

group, it will not, and the other companies will show the placeholder instead.

If you are on 17 and planning an upgrade, this is a real behavioural change rather than a cosmetic

one, and it is worth testing against your own multi-company setup rather than assuming.

Deprecated became active in Odoo 19

A smaller change, same category of surprise.

Odoo 17 and 18 both declare a deprecated boolean on account.account. Setting it keeps the

account visible for history but blocks it from new entries.

Odoo 19 removes that field. account.account instead carries a standard active boolean, so

retiring an account is ordinary archiving.

The user-facing outcome is nearly identical. What breaks is anything that wrote the old field: an

import template, a data file, a server action or an integration that sets deprecated has nothing

to set on 19.

Structure the chart before you build it

The mechanical work of creating accounts is trivial. The decisions are not:

• Start from the localisation, do not hand-build. Odoo ships localisation packages that install

a compliant chart for your country. Starting from that and adjusting is faster and safer than

building from a spreadsheet, and it wires up the tax structure at the same time.

• Decide the depth of your analytic reporting separately. A common and expensive mistake is

encoding department, project or cost centre into the account code, which multiplies the chart and

freezes the structure. Odoo has a dedicated mechanism for that dimension. Use it instead.

• Keep reconcile honest. Turn it on for accounts you actually match, not as a default.

Reconciliation on an account that never needs it just adds noise to the reconciliation views.

• Agree the numbering with whoever files your accounts. They will have to work with it long

after the implementation is finished.

Where this connects

The chart of accounts is the foundation the rest of the accounting configuration sits on. Fiscal

positions remap the taxes and accounts that transactions land in, and analytic accounting adds the

reporting dimension that does not belong in the account code. Both assume the chart underneath them

is stable.