Which Odoo modules to implement first, and why not accounting

An Odoo implementation is not one project. It is a sequence, and the order changes how much it costs and whether anyone trusts the result.

The instinct is to start with accounting. It feels foundational, the finance team is usually the one pushing for change, and every other module eventually posts into it.

We would usually start somewhere else.

Why the ledger is a bad first module

Accounting is the least forgiving place to learn a new system. It has a statutory deadline every month, an auditor at the end of the year, and no tolerance for a period where the numbers are approximately right while people find their feet.

It is also downstream of everything. The general ledger is fed by sales, purchasing and inventory, so implementing it first means either running it disconnected from the operations that should feed it, or implementing those at the same time and turning a sequence into a big bang.

And crucially, accounting is usually the part of the business where the existing system is working. Whatever else is broken, the accounts are generally being done. So you take on the highest risk change in the area with the least upside.

Start where the pain is and the data is decent

Two tests, and you want a module that passes both.

Where does the business currently lose time or money? Usually inventory accuracy, or a production process held together with a spreadsheet, or quoting that takes three days. That is where a win is visible to the people who have to adopt the system, which matters more than any technical consideration.

Where is the underlying data good enough to move? A module whose data is a mess will make the new system look worse than the old one, and first impressions of an ERP are extremely durable. Sometimes the right answer is to start with the second most painful area because the most painful one needs three months of data cleanup first.

In practice, for most operational businesses, that means starting with inventory and purchasing, or sales and quoting, and bringing accounting in second once those are producing clean transactions to post.

A sequence that tends to work

Roughly, and it varies:

1. Inventory and purchasing. Get stock accurate and receipts clean. Everything downstream depends on this, and it is where the credibility of the system is won or lost.
2. Sales and quoting. Now orders come in against real stock rather than a guess.
3. Accounting. With sales and purchasing feeding it, the ledger is mostly a consequence rather than a data entry exercise.
4. Manufacturing or projects. Whichever describes how the business actually adds value. This is the module with the most configuration decisions, and it benefits most from a team that already understands the system.
5. Everything else. Field service, maintenance, quality, whatever is genuinely needed rather than available.

The one thing worth resisting is enabling modules because they are there. Every active module is surface area to configure, train on and maintain, and an unused one still confuses people looking for the right menu.

The counter-argument, honestly

There is a real case for accounting first: if your current accounting system is the thing that is actually broken, or if it is end of life, or if the business is small enough that the whole implementation is a few weeks anyway.

For a business under about fifteen people running simple operations, the sequencing argument matters much less and a single phase is often correct.

What decides it

The honest answer is that the right first module comes out of a discovery exercise rather than a rule of thumb, because it depends on where your data is clean and where your pain is. That is why we price discovery separately and do it before committing to a build.

If someone has proposed a module order before looking at your data, they have proposed a template.