Odoo implementation: from initial audit to go-live

Implementing Odoo is not a matter of installing modules and entering a few settings. It is a project that touches how the business invoices, collects payment, declares VAT and, often, pays wages. In Switzerland, these three areas — accounting, VAT, payroll — are governed by precise rules, and a configuration that ignores them at the scoping stage is paid for at the first VAT return, not before. That is the difference between an integrator who installs software and an accounting firm that designs the implementation around what the accounts ultimately need to produce.

This page describes the method we follow, phase by phase, from the initial audit to the support that follows go-live. It also addresses, plainly, what causes an ERP project to fail or go off track: these are known, recurring and avoidable causes, provided they are anticipated.

When a business is ready for Odoo — and when it isn't yet

Odoo makes sense as soon as a business runs several processes that don't currently talk to each other: invoicing in one tool, stock on a spreadsheet, payroll with a third party, with no overall view. The clearest signal is manual re-entry — the same information typed two or three times into different tools — and a lack of real-time visibility over cash flow or margins.

Conversely, certain signals indicate that it is better to wait, or to fix an upstream problem first:

• Current processes are not yet settled. If the business is still regularly changing the way it invoices or manages purchasing, computerising an unstable process simply locks the disorder in place.
• No one can be freed up to lead the project on the business side. Without an available internal point of contact, configuration decisions get made by default, often poorly, and are corrected later at greater cost.
• The source data is in very poor condition (large numbers of duplicates, an inconsistent chart of accounts, no reliable history) and no one is ready to clean it up before the project.
• The business is going through a major reorganisation (merger, change of legal form, restructuring) that will change its processes in the coming months regardless.

In these cases, the best decision is sometimes to postpone the project by a few months rather than start it on unstable ground. A preliminary audit makes it possible to decide objectively.

The preliminary audit

Before any configuration, we document the existing situation:

• Processes in place: how quotes, orders, invoices, payments and wages currently flow, and who is involved at each step.
• Current tools: accounting, invoicing and payroll software, spreadsheets, and how they connect — or don't — with each other.
• Data: where it resides, in what format, and how clean it is (duplicates, incomplete fields, inconsistencies in the chart of accounts).
• Volumes: number of customers, suppliers, product references, annual entries, employees — these figures determine the complexity of data take-on and testing.
• Regulatory constraints specific to the business: VAT liability (applicable rates, reporting method), sector-specific obligations, collective agreements affecting payroll.

This audit produces a clear picture of what exists and what needs to change — it is the basis for the scoping that follows, not a formality.

Scoping: extent, modules, what gets postponed

Scoping translates the audit into a concrete project scope. This is the stage where much of the project's later success or failure is decided, because it sets what must work at start-up and what can wait.

Defining the scope of the first phase

The most useful rule is easy to state and hard to follow: start with the narrowest scope that covers the business's real operating needs, not the most complete scope possible. A project that tries to cover accounting, VAT, payroll, CRM, inventory and bespoke development from day one multiplies the decision points, the tests and the people to be mobilised at the same time — and delays precisely the moment when the financial foundation becomes reliable.

Choosing the modules

The choice of modules follows directly from the scope agreed. For most SMEs, the initial foundation covers accounting, invoicing and basic purchasing. Depending on the business, CRM and sales management, inventory and purchasing management, or payroll and human resources are added from the outset — but only if these building blocks are essential to day-to-day operation, not because they exist in the Odoo catalogue.

What is deliberately postponed

Explicitly documenting what is postponed, and why, avoids two pitfalls: the impression that something has been forgotten, and the temptation to add it urgently mid-project. Typically postponed to a later phase: integrations with non-critical third-party tools, advanced custom reports, e-commerce or project management modules when they do not condition basic operation, and any customisation that has not yet proven its necessity once the standard tool is in use.

Configuration

Once the scope is validated, configuration puts in place the technical and organisational foundations of the system:

• Company: legal name, legal form, contact details, base currency, financial year.
• Chart of accounts: account structure, groupings, balance sheet and profit and loss accounts adapted to the actual business — not just the default chart.
• Fiscal positions and VAT: linking accounts and products to the correct rates, handling exempt or foreign transactions, reporting method (effective method or net tax liability rate, subject to eligibility).
• Journals: sales, purchases, bank, miscellaneous operations, with correct numbering sequences and offsetting accounts.
• Bank accounts: linking real accounts, statement import formats, QR-bill configuration for issuing and receiving payments.
• Access rights: who can view, enter, amend or validate each type of document, by user profile.
• Approval workflows: approval chains for supplier invoices, expense claims and purchase orders, according to internal thresholds and responsibilities.

This configuration work is the least visible part of the project and the most decisive for the reliability of the figures produced afterwards.

Swiss localisation: checking and completing, not just installing

Odoo automatically installs the Swiss localisation module (l10n_ch) as soon as the company is configured with Switzerland as the country. This module provides a useful foundation: a chart of accounts structure adapted to Swiss practice, current VAT rates (8.1%, 2.6% and 3.8%, in force since 1 January 2024), and support for the QR-bill, the Swiss payment standard.

The implementation work does not stop there — it begins at that precise point. This generic foundation must be:

• Checked account by account, to verify that it matches the actual structure of the business rather than a generic model.
• Adapted to the actual fiscal positions: rates applicable according to services provided, VAT reporting method, including checking eligibility for the net tax liability rate thresholds (maximum turnover of CHF 5,024,000 and maximum tax due of CHF 108,000 per year, in force since 1 January 2025 according to the Federal Tax Administration (AFC)).
• Completed according to the company's journals, bank accounts and actual flows — the base localisation knows neither your bank accounts nor your internal organisation.

This is precisely the stage where the difference between a general integrator and an accounting firm shows: a localisation that is technically installed but not substantively checked produces figures that look correct until the first VAT return, when discrepancies appear. For everything relating to day-to-day bookkeeping once the system is in place, see our Odoo accounting page.

Data take-on

Data take-on answers three distinct questions, which must be decided separately.

What gets migrated

Generally: active customer and supplier records, the product catalogue, open invoices (not yet collected or paid), opening balances at the cut-over date, and the data needed for immediate operational continuity (current stock, ongoing contracts).

What is not systematically migrated

Detailed accounting history for closed financial years generally does not need to be re-entered line by line in Odoo. It remains accessible in the previous system or archived as PDF, which satisfies legal retention obligations without adding weight to the migration. Similarly, customer or supplier records that have been inactive for a long time, or data of doubtful reliability, are often deliberately left aside rather than migrated "just in case".

The cut-over date

It is chosen according to the business's accounting calendar — most often at the start of a financial year or VAT period, to avoid splitting a period across two different systems. The opening balances at this date are established with rigour: they are what guarantees accounting continuity between the old system and Odoo. For a project where the source system is already identified and documented, see our dedicated data migration page.

Development and integrations, where necessary

Standard Odoo covers most of an SME's needs. Bespoke development or integration with a third-party tool (e-commerce site, till system, sector-specific business software) is only justified when the standard genuinely does not meet the need — not as a matter of principle. Every development adds a dependency that will need to be maintained through future version upgrades; we systematically document what is custom-built and why, so that this choice remains traceable over time.

As a matter of methodological caution, any development not strictly essential to the operation of the first phase is postponed: premature customisation, decided before the teams have used the standard system, is often based on a habit from the old tool rather than a genuine need within Odoo.

Testing and acceptance

Acceptance testing verifies that the configured system produces correct results before the business moves its real operations onto it.

• Test data sets: representative data, built from the business's real cases, not generic data.
• Business scenarios: complete journeys — from order to collection, from receiving a supplier invoice to paying it, from calculating a wage to its statement — tested end to end, not function by function in isolation.
• Accounting validation: checking balances, bank reconciliations and a simulated VAT return before final cut-over. This is the check with the most value, because it is the one that reveals a poorly calibrated tax or accounting configuration before it produces an official figure.

Acceptance testing is carried out with the users who will actually use the system day to day, not only with the project lead — they are the ones who spot the gaps between the theoretical configuration and real-world use.

User training, by profile

Generic training, identical for everyone, leaves people to fend for themselves with functions that don't concern them and neglects the ones they actually need. Training is therefore built by profile:

• Accounting and finance: entry, matching, bank reconciliation, periodic closing, VAT returns.
• Sales and invoicing: quotes, orders, invoicing, payment collection tracking.
• Purchasing and stock, where this scope is included: supplier orders, receiving, inventory.
• Human resources, where payroll is included: employee record management, payroll cycle, social security statements.
• Management: reading dashboards and indicators, without necessarily operational data entry.

Neglecting training is a cause of failure just as frequent as poor technical configuration: a well-configured system that is poorly understood generates entry errors, which in turn produce incorrect figures. Our approach to training is set out in detail on the Odoo training page.

Go-live and the stabilisation period

Go-live is the moment the business permanently switches its operations onto Odoo. It is preceded by a freeze on entries in the old system while data take-on is finalised, and followed by a stabilisation period during which the first real cycles — first invoicing, first bank reconciliation, first VAT return — bring to light discrepancies that no acceptance testing, however careful, fully detects in advance. This period is planned as a phase of the project, with reinforced support, not treated as a series of unforeseen incidents.

Support and continuous improvement

Once stabilisation is over, the business moves to ongoing support: usage questions, minor configuration corrections, support for periodic closings, modest developments as needs arise. This is also when modules and features deliberately postponed during initial scoping can be reassessed and added, on what is now a stable foundation. See our Odoo support offering for details of this ongoing support.

What makes a project's duration and budget vary

We do not give a generic range for duration or cost: it would rest on assumptions we do not yet know at the time of writing this page. However, the factors that make an Odoo implementation project vary, upward or downward, can be identified:

• The scope agreed: number of modules activated in the first phase, number of companies or legal entities to configure.
• The state of the source data: clean, structured data is taken on quickly; scattered, inconsistent or duplicated data requires preliminary clean-up work that can weigh more heavily than the configuration itself.
• The availability of the internal point of contact: a project where decisions are made quickly progresses steadily; a project where every approval waits several weeks stretches out accordingly.
• The volume of bespoke development: each customisation adds a cycle of specification, development and testing on top of the standard configuration.
• The regulatory complexity of the business: multiple VAT rates, international activity, collective agreements specific to payroll, multiple companies — each of these adds cases to configure and test.
• The edition chosen, Community or Enterprise: this choice affects both the features available from the outset and the recurring per-user cost model.
• The version of Odoo installed: Odoo 19 is the current stable version; a recent version benefits from longer vendor support, which limits forced version upgrades in the short term.

It is precisely to weigh these factors against your actual situation, rather than a generic case, that the project begins with a documented audit and scoping — not a quote drawn up before we have seen your processes. If your business is based in Geneva or the surrounding region, also see our Odoo support in Geneva.