Design the chart of accounts before configuring anything else, because it is the only part of an Odoo build that is genuinely expensive to change after go-live. CRM pipeline stages can be reworked in an afternoon. An account structure that turns out to be wrong means every transaction posted since go-live sits in the wrong place, and fixing it means either reposting history or accepting a permanent break in your comparatives.
Why the chart is the irreversible decision
Almost every module in Odoo posts to the general ledger. Inventory valuation, payroll, project costing, manufacturing variances, landed costs, bank reconciliation. The chart of accounts is not the accounting module's private business. It is the structure the whole system reports through.
That is why the order matters. Configure the CRM first and you have made no decisions that constrain anything else. Configure inventory and sales first, and you have already made accounting decisions implicitly, because those transactions have to post somewhere.
By the time an accountant looks at it, stock is valued against an account that does not distinguish the categories they need, and the fix is a migration rather than a setting.
What wrong looks like
The chart came across from Xero unchanged. Charts that grow inside accounting software accumulate. Accounts get added for one-off situations and never removed. A 250-account chart where 80 would do is common, and every extra account is a place for a transaction to be misposted.
Dimensions have been built as accounts. This is the specifically Odoo mistake. Separate GL accounts for Wages Sydney and Wages Melbourne, or Sales Wholesale and Sales Retail. Odoo has analytic accounting for exactly this: one wages account, with location as an analytic dimension. Building dimensions into the GL multiplies your chart, breaks consolidated reporting, and has to be undone later.
The P&L cannot be read. If gross margin is not visible without a spreadsheet, the account structure is wrong regardless of how technically correct it is.
GST treatment was decided per transaction. GST-free, input-taxed and out-of-scope are different things and they drive different BAS labels. If the treatment is applied by whoever entered the invoice rather than set on the account and the product, the BAS is a reconstruction every quarter.
Why teams start with the CRM anyway
Because it demos well and everyone has an opinion about it. Pipeline stages are visible, easy to discuss and satisfying to configure. A chart of accounts is not, and the people who care most about it are usually not in the room during scoping.
There is also a sequencing pressure. Sales teams want to see something working, and the CRM is the fastest thing to stand up. That is a reasonable instinct and it is why chart design gets deferred until it is a problem.
What to design before configuring anything
- The reports you need to produce. Design backwards from the P&L, balance sheet and management reports you want, rather than forwards from a template.
- What is an account and what is a dimension. Anything you want to slice by, department, project, location, channel, is usually a dimension. Anything that is a genuinely different kind of transaction is an account.
- Cost of goods sold structure. If margin matters, this is where it is decided. Getting COGS wrong means margin reporting never works properly afterwards.
- Tax treatment by account and product. GST codes set once, applied automatically, so the BAS assembles itself.
- Who signs it off. Your external accountant should see the chart before it is built, not after the first BAS.
The Australian specifics
BAS structure, GST codes, PAYG withholding and Single Touch Payroll categories all depend on the account and tax configuration underneath them. Odoo's Australian localisation gives you the framework. It does not make the decisions.
One point worth building in deliberately: the ATO publishes small business benchmark ratios by industry. Structuring the P&L so your figures map to those benchmarks makes it possible to compare your business against the range for your industry, and makes it obvious when something is outside it. Most charts are not built this way and cannot be read against them without manual work.
Migrating from Xero or MYOB
Do not copy the chart across. The migration is the one moment when restructuring costs nothing, and skipping it means importing years of accumulated compromise into a system that will hold it for years more.
The practical approach is to design the new chart from the reporting requirements, map the old accounts to it, and bring across balances rather than structure. Historical detail usually stays in the old system as an archive, which is cheaper than migrating it and adequate for audit.
What skipping this costs
Rework, mostly, and it is not cheap. Restructuring a chart after go-live means remapping transactions, reposting or restating, and re-cutting every report built on the old structure. It is also the point at which a project loses the finance team's confidence, and that is harder to recover than the money.
The cases where it matters most are the ones where the chart looked fine until something was asked of it: margin by product line, job costing, or a consolidated view across entities.
Further reading
Andy Cuddihy wrote Start with the Chart, a practical guide to designing an Odoo implementation around the chart of accounts. It covers chart design against ATO benchmarks, GST, BAS and PAYG setup, migrating from Xero and MYOB, payroll integration, and what to customise against what to leave alone. Available on Amazon.
How we work
Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. We run fractional CFO services alongside Odoo implementation, which is why chart design comes first in our builds rather than last.
See Odoo ERP Implementation for how a build is scoped, or Why do most Odoo and ERP projects blow out? for what else goes wrong when sequencing is decided by what demos well.
Frequently asked questions
Should the chart of accounts be set up before the CRM in Odoo?
Yes. The chart is the only structure that is expensive to change after transactions start posting, and almost every module posts to it. CRM configuration constrains nothing else and can be reworked at any point.
Can we reuse our existing Xero or MYOB chart of accounts?
You can, but it is usually a mistake. Charts that grow inside accounting software accumulate one-off accounts and rarely lose them. The migration is the only moment when restructuring is free.
What is the most common chart of accounts mistake in Odoo?
Building reporting dimensions as separate GL accounts. Department, location, project and channel should be analytic dimensions, not accounts. Separate accounts for each multiplies the chart and breaks consolidated reporting.
How many accounts should a chart of accounts have?
Fewer than most businesses arrive with. If a distinction can be made with an analytic dimension, it does not need its own account. The test is whether you would ever want to see the account on its own line in a statutory report.
Who should sign off the chart of accounts?
Your external accountant, before it is built. They are the ones who will work with it at year end, and reviewing it after the first BAS is too late to change cheaply.
Can the chart of accounts be changed after go-live?
Accounts can be added at any time. Restructuring is different: transactions already posted have to be remapped or restated, and reports built on the old structure re-cut. Possible, but it is a project rather than a change.
