Designing the chart of accounts in Odoo before migration

A chart of accounts is not a file you import at the start of a project and then forget. It is the structure every financial and management report in Odoo is built on, and once real invoices have been posted, every later change becomes a trade-off between the integrity of history and the integrity of current reporting. We treat chart design as an accounting decision that comes before migration, not as a technical step inside configuration.

What the fiscal localization installs and what your team must still design

When you enable the Accounting app and choose the fiscal localization package for the country, Odoo loads a ready chart template together with tax groups, taxes and fiscal positions, and it links default accounts to journals. That template is a starting point compatible with the statutory statement layout of the market, but it is not a design for your business. What remains yours to decide: the length of the account code and the meaning of each level, the sub-accounts you genuinely need, the analytic plans and analytic accounts, the journals that must be separated, the taxes that apply to each kind of transaction, and the clearing accounts used for reconciliation.

Open the settings, then the chart of accounts, and review it line by line before any migration. A standard template carries many accounts a given business never uses, and every extra account needs its type, default tax and reconciliation policy configured, plus a user who understands what it is for. Narrowing the chart to what you actually post to is kinder to the team than inheriting hundreds of accounts, and it is the first thing we review when work starts on Odoo Accounting.

Account code structure and digit count before any entry

Build the code in levels: one or two digits for the broad class, then two for the group, then two for the detail. A simple example: 1 for assets, 11 for current assets, 1101 for cash and cash equivalents. Odoo accepts hierarchical codes, and you can write them with separating dots or without, but fixing a constant length is what makes sorting and reports readable to anyone who opens them.

Why is renumbering after posting expensive? Odoo links every journal item to the account record, not to the code you typed, so in principle you can change a code later without breaking entries. The cost shows up elsewhere: comparative reports display prior-period balances under the new code, any statutory output or reconciliation file built on the old code has to be re-mapped, and external files such as payroll exports, e-invoicing tooling and bank matching sheets need manual updates. The real cost is not in the database, it is in everyone who memorised the old code. Fix the length and the structure before migration; if an account must be retired later, use the Deprecated flag rather than deletion. Odoo will not delete an account that already carries journal items, and deprecating it removes it from new entry fields while keeping its history.

The account type, not the name, drives reporting

In Odoo the Account Type field decides where an account appears in the financial statements and how the system treats it; the name and the code do not. An account named Bank whose type is an expense will never appear under cash, and an account named Supplier whose type is a current asset will not behave as a liability. The types cover the familiar groups: Receivable, Payable, Cash, current, non-current and fixed assets, current and non-current liabilities, equity and Unaffected Earnings, income and other income, expenses including direct cost and depreciation, and Off-Balance accounts.

This field is what lets the year-end close know where to move the result, what lets the aged report know an account is a receivable that needs reconciliation, and what lets the cash flow statement classify a movement correctly. Beside it sit small decisions with large effects: the Allow Reconciliation flag, the account default tax, and the account currency when it is a foreign currency account. When you review the chart, read the type first and the name second. A wrong type does not show on the account form, it shows in the statement the finance manager reads.

Management reporting through analytic accounts, not multiplied accounts

The most common chart design mistake is turning every management need into a new account: one per branch, one per department, one per project. The result is a bloated chart and a period close that depends on manual detail nobody can verify. The alternative in Odoo is to separate the statutory dimension from the management dimension: the chart stays small and tied to the nature of the expense, while the management dimension rides on analytics.

Analytics in Odoo work through analytic plans and the analytic accounts beneath them, with an Analytic Distribution recorded on invoice and journal item lines. A distribution can be a share of the line or a fixed amount, and it can apply to more than one dimension at once. The practical order we follow:

1. Decide the dimensions that are actually read in management reports: branch, department, project, contract or sales channel.
2. Create one analytic plan per dimension, and never mix two dimensions in one plan.
3. Create the analytic accounts under each plan to mirror the reporting structure you need.
4. Set the default distribution on accounts and products, and decide how strictly it is enforced at posting.
5. Test the analytic report on sample data before go-live and confirm its totals agree with the general ledger.
6. Agree who may change a distribution after posting, because changing it later rewrites comparable figures.

The advantage is that an analytic account never disturbs the trial balance, so when the management structure changes you do not need to renumber the chart or post correcting entries.

Journals, their sequences, and how taxes attach to accounts

A journal in Odoo is the container entries are posted into, and each journal type has a job: sales, purchases, bank, cash and miscellaneous. A journal carries a short code and a sequence that produces the document number; the sequence can restart with a period prefix, and refunds can run on their own sequence. The practical decision is how many journals you need. Separating cash from bank, and perhaps separating branches, is useful operationally, but every extra journal is another reconciliation that must be closed, and too many journals scatter bank matching.

At account level you can set a default account on the journal to reduce manual selection at posting. Taxes are not merely a number typed on an invoice: an Account Tax is defined by whether it is used for sales or purchases, by how it is computed, whether as an amount derived from the base or as a fixed amount, and by whether it is included in the price or added to it. Most importantly, the tax repartition lines decide which account the tax posts to; if those lines are wrong, the invoice looks right while the chart is wrong. Default taxes attach to the account or the product, and Fiscal Positions swap the tax and account set according to the kind of transaction, such as exports or dealings with an entity under a special treatment.

Tax treatment and e-invoicing are a separate discipline with its own statutory owner, and the way VAT, withholding and the invoice itself are configured in e-invoicing setup depends directly on this chart: which account carries the tax, which account offsets receivables, and how a submitted invoice is later read in the balance sheet. The entity and its accountant remain responsible for the classification and for any filing.

From the legacy chart to the opening trial balance

Moving off a legacy system is not copying balances; it is rebuilding what each balance means. Start with a written mapping from every legacy account to its new counterpart, and decide explicitly what happens to accounts with no counterpart: merged, dropped, or given a new account. Then review the following before you post anything:

• A complete mapping covering every account that appeared in the last trial balance.
• Receivable and payable balances at counterparty level, not as a single total, so they can be reconciled later.
• One clear opening entry in a miscellaneous journal, with an explicit balance and a comprehensible counterpart for rounding differences.
• An opening trial balance that matches the legacy trial balance at the cut-over point, with any difference explained in writing.
• A declared cut-over: the last document posted in the old system and the next document that starts in Odoo.
• A trial posting of a small batch before go-live, reviewed with the responsible accountant.

The most common failure is pushing the old chart into the new system unchanged. It feels safe because it is familiar, but it carries every old design problem into Odoo: accounts with near-identical names that nobody can tell apart, summary accounts that support no analysis, account types that were set incorrectly long ago, and accounts with no movement at all. The new reports are then built on old entries that mean little, and the period close starts with a manual reconciliation between two systems. Redesigning before migration is far cheaper than re-migrating afterwards.

The chart you design here is what you will read every day in Odoo Accounting. Where the team has no spare accounting capacity for this work, accounting software implementation usually begins at exactly this stage: designing the chart, wiring analytics to reporting and preparing the opening balances, while the accounting decision itself stays with the entity.

What we do not guarantee

• We do not guarantee any particular commercial outcome, and we do not guarantee search ranking.
• We do not quote a binding price before analysing your data and your current chart of accounts.
• We do not state a binding duration before a written scope agreed by both parties, and any time estimate we mention remains a planning range.
• We do not provide a legal or tax ruling; tax classification and its consequences remain with the entity and its accountant.
• We do not claim any vendor partner tier, official standing or formal credential.
• We do not guarantee that the chart we design will never need revision; changes in activity or regulation require a fresh review.