Odoo Implementation Checklist: Tasks Before Go-Live

An Odoo implementation is ready for go-live when the settings that are expensive to change later — fiscal localization, chart of accounts, taxes, inventory valuation, document sequences and access rights — have been verified in a copy of the production database, and when the opening data has been imported and reconciled there first. Everything else (reports, dashboards, most automations) can be adjusted after launch. The checklist below is ordered by that principle: the hardest-to-reverse items first, each with the Odoo 19 menu path, the check to run, and the symptom that tells you it was missed.

This is not a project plan. If you need phases and durations, read our Odoo implementation timeline. This page is the list you tick off in the final weeks, app by app, before anyone posts a real invoice.

How to use this checklist

Three rules make a checklist like this useful instead of decorative:

1. Run it in a duplicate of the production database, not in a sandbox you configured separately. A test database that was set up by hand drifts from production within days. Duplicate production, run the checks, fix production, duplicate again.
2. Give every line an owner and a date. "Finance" is not an owner. The person who will sign the first VAT return owns the tax lines.
3. Record evidence, not ticks. For each line, keep the screenshot, the exported report or the test document number that proves it. When something looks wrong three months after go-live, that evidence tells you whether the setting changed or was never right.

The legend for the tables: Reversibility is how painful the item is to correct once live transactions exist — Hard means correcting it usually involves reversing or re-posting documents, Medium means it affects new documents only but leaves an inconsistent history, Easy means you can change it any time.

Tier 1 — Accounting foundations (hardest to reverse)

Odoo's own accounting onboarding puts these at database creation or before implementation, not at go-live, for a reason: every other app posts through them. The Odoo 19 accounting "get started" guide lists them in that order.

Check	Where in Odoo 19	How to verify	Reversibility
Fiscal localization package matches the company's country	Accounting ‣ Configuration ‣ Settings ‣ Fiscal Localization	The package field shows your country; tax report lines exist for your jurisdiction	Hard
Chart of accounts matches what your accountant will report from	Accounting ‣ Configuration ‣ Chart of Accounts	Accountant signs a mapping of old account → new account, including every balance-sheet account that will carry an opening balance	Hard
Taxes, including price-included vs price-excluded	Accounting ‣ Configuration ‣ Taxes	Post one test invoice per tax rate; the tax report shows each in the right box	Hard
Fiscal positions for foreign customers, exempt customers and reverse-charge vendors	Accounting ‣ Configuration ‣ Fiscal Positions	One test invoice per fiscal position; tax and account mapping applied automatically	Medium
Currencies activated and rate source chosen	Accounting ‣ Configuration ‣ Settings ‣ Currencies	A foreign-currency test invoice converts at the expected rate	Medium
Financial year end and tax return periodicity	Accounting ‣ Configuration ‣ Settings	Dates match the statutory calendar, not the calendar year by default	Medium
Journals: one per bank account, sales, purchase and miscellaneous	Accounting ‣ Configuration ‣ Journals	Each bank journal points to its own ledger account; no two banks share one	Hard
Payment terms	Accounting ‣ Configuration ‣ Payment Terms	Due dates on a test invoice match your contracts	Easy

What goes wrong: the localization is installed for the wrong country because the database was created from a default, or the chart of accounts was "cleaned up" after test postings existed. Both show up the same way — the first tax return cannot be produced from the tax report and someone starts building it in a spreadsheet. If your finance lead is exporting journal items to calculate tax by hand in week three, go back to this tier.

Decision point — keep or replace the default chart? Keep the localization's chart and add accounts where your reporting needs them, unless a group reporting structure or an auditor requires specific account codes. Replacing a localized chart wholesale tends to break the links between taxes and tax report lines that the localization ships with.

Tier 2 — Inventory valuation (hard to reverse once stock moves)

If you run Inventory with Accounting, decide the costing method and the valuation timing before the first receipt. Odoo 19 offers three costing methods — Standard Price, FIFO and AVCO — and two timings: periodic, where valuation is updated during the stock closing process, and perpetual, where valuation is updated when bills and invoices are posted (Odoo 19 inventory valuation). The defaults are set in Accounting ‣ Configuration ‣ Settings and can be overridden per product category.

• Costing method per product category agreed with the accountant. Standard suits stable, manufactured items with a known cost; AVCO suits most distribution; FIFO suits lot-heavy or perishable stock where the auditor expects layers.
• Valuation timing chosen, and the stock input, output and valuation accounts on each category point to the right ledger accounts.
• Opening stock imported with a cost, not zero. A zero-cost opening quantity silently distorts AVCO for every later receipt.
• The stock valuation report equals the inventory balance on the trial balance after the opening import. This single comparison catches most category-account mistakes.
• Units of measure and purchase units on products checked against a real vendor bill (boxes vs units is the usual trap).

What goes wrong: categories were created by importing products, so they inherited the default category's accounts, or the costing method was switched after receipts existed. The symptom is a stock valuation report that disagrees with the balance sheet and a gross margin that moves when nothing was sold.

Tier 3 — Sequences, numbering and the audit trail

• Invoice, bill and credit note numbering matches any statutory format your country requires, and the first number is correct if you continue a series from the old system. Odoo lists document sequencing as an accounting configuration to settle before implementation (accounting get started).
• Sales order, purchase order and delivery references use prefixes your team and customers will recognise.
• Lock dates planned. Odoo 19 prevents changes to posted entries on or before a lock date, set in Accounting ‣ Accounting ‣ Lock Dates, and a hard lock date is irreversible by design (Odoo 19 year-end closing). Decide now who may set them and set the first one on the day before go-live, once opening balances are posted and checked.

What goes wrong: test invoices were posted in production "just to see", so the real first invoice carries number 7. Duplicate production for tests; never post tests in the live database.

Tier 4 — Users, companies and access rights

Access rights are easy to change technically but hard to change socially: once people have seen data, removing it causes friction, and a misconfigured group can lock administrators out. Odoo's own documentation warns that changes to access rights can have a detrimental impact on the database, including leaving no user able to change access rights (Odoo 19 access rights).

• Every user exists, with the right role per app (Settings ‣ Users ‣ user ‣ Access Rights). Map each person to a role in a table first; configure from the table.
• At least two administrators, neither of them a shared login.
• Sales users see only their own documents if that is the policy — test by logging in as that user, not by reading the setting.
• Multi-company rules checked if you run more than one company: a user who should see one company cannot open another's invoices.
• Portal users (customers, vendors) see only their own orders and invoices; test with a real contact that has two contacts under the same company.
• Departed-employee and test users archived.

Tier 5 — Email, documents and what customers see

This is where go-lives embarrass themselves in public. The first invoice email lands in spam, or the PDF carries the wrong address.

• Outgoing email from your own domain. Odoo's guide lists the DNS records (SPF, DKIM, DMARC), the alias domain on the company, the outgoing mail server record and the bounce, catchall and default-from aliases, each of which needs a real mailbox (Odoo 19 outbound email).
• Send a test quotation and invoice to an outside mailbox (a personal address at a different provider) and check it arrives in the inbox, not spam.
• Replies route correctly. Reply to that test invoice and confirm the reply lands in the document's chatter.
• Document layout: company address, registration and tax numbers, bank details and logo on the invoice PDF, reviewed by finance, not only by the implementer.
• Payment instructions or online payment provider tested end to end with a real, small payment and a refund.

Tier 6 — Data migration and opening balances

Odoo's onboarding treats opening invoices and bills, opening inventory, the opening trial balance and bank transactions as the work done at the time of implementation (accounting get started). The checks:

• Every import file has an External ID column mapped from the old system's key. Odoo's import guide notes that the External ID lets you re-import the same file without creating duplicates and link related records, and that imports cannot be undone (Odoo 19 import and export). Use its Test button on every file first.
• Import order respected: contacts before products, products before open orders, open invoices and bills before payments.
• Open receivables and payables imported as individual documents, not as one balance per customer, so they can be reconciled with incoming payments.
• Opening trial balance posted as a single dated entry, and the new trial balance equals the old system's closing trial balance line by line.
• Aged receivables and aged payables in Odoo match the old system's reports per partner.
• Bank journals connected or statement import tested. Odoo creates a journal and account for each bank account you add and can connect to supported banks from the Accounting dashboard (Odoo 19 bank and cash accounts). Reconcile the first imported statement before go-live.

Decision point — how much history to migrate? Open documents and balances are required; closed history rarely is. Every year of closed history you migrate adds cleaning, mapping and reconciliation work, and it is usually cheaper to keep the old system read-only for lookups. Migrate closed history only where a report the business genuinely uses needs it in Odoo.

Tier 7 — Operational apps: one real scenario each

For each app you are launching, run one end-to-end scenario in the duplicate database, as the user who will do it, with real data:

App	Scenario to run before go-live	Evidence
Sales	Quotation → order → delivery → invoice → payment → reconciliation	The customer ledger shows zero for that order
Purchase	RFQ → order → receipt → vendor bill (matched to receipt) → payment	Bill matching shows no quantity difference
Inventory	Receipt → internal transfer → pick/pack/ship according to your routes	Stock valuation and on-hand quantities agree
Manufacturing	Bill of materials → manufacturing order → component consumption → finished goods	Finished-goods cost equals the expected cost roll-up
Point of Sale	Open session → sales in each payment method → close session	Session closing entry posts to the right journals
eCommerce / connectors	One order from each channel through to invoice	No duplicate contact or product created

If a scenario needs a workaround to complete, that is a defect to fix or a decision to record before go-live, not a training topic.

Tier 8 — Cutover and the first week

• Freeze date agreed: the moment after which no new transactions go into the old system.
• Final delta import rehearsed on the duplicate database, with timing recorded, so you know how long cutover takes.
• Old system set to read-only, not switched off.
• Scheduled actions reviewed: automated emails, follow-ups and recurring documents are on only where intended — imported open invoices can trigger reminder emails on day one.
• Backups and restore tested on your hosting (for Odoo Online and Odoo.sh, know where the backups are; for self-hosting, restore one to a spare server).
• Named first-week support: who answers a user question within the hour, and who can change configuration.
• First lock date set once the opening balances are verified.

Where teams usually get stuck

The configuration clicks are rarely the hard part. The recurring failure pattern is a Tier 1 or Tier 2 decision taken by whoever happened to be setting up the database, rather than by the person accountable for the numbers — and nobody notices until the first tax return or the first month-end. Assign those decisions explicitly and most of this list becomes routine. If you want someone to work through it with you, our Odoo implementation service covers go-live readiness as part of the project.

Frequently Asked Questions

What must be finished before Odoo go-live, and what can wait?

Finish everything that shapes posted accounting data: fiscal localization, chart of accounts, taxes and fiscal positions, journals, inventory costing and valuation, document sequences, access rights and opening balances. Custom reports, dashboards, most automated actions and nice-to-have integrations can follow after launch, because changing them does not rewrite history.

Can I change the inventory costing method after go-live?

Odoo lets you set the costing method per product category, so it is technically possible, but changing it after stock has moved affects how existing stock is valued and makes historical cost reporting harder to interpret. Decide it with your accountant before the first receipt and treat any later change as a planned accounting event, not a setting tweak.

Should we test in a separate Odoo database or a copy of production?

A copy of production. A separately configured test database drifts from the real one, so a check that passes there proves little. Duplicate production, run the checklist, fix production, and duplicate again before the final rehearsal.

How do we prove opening balances are correct?

Compare three reports between the old system and Odoo on the go-live date: the trial balance line by line, aged receivables per customer and aged payables per vendor. If inventory is valued, also compare the stock valuation report with the inventory account balance. All four must agree before the first lock date is set.

Who should own the checklist?

One named person per tier, with a single project owner who has authority to delay go-live. Accounting tiers belong to the person who will sign the first tax return; access rights to whoever approves who sees what; data migration to the owners of each data domain.