A company commissions an Odoo instance audit when something is wrong, without always knowing exactly what. The accounts fall behind, the tool feels sluggish, a key employee who knew the configuration has left the company, or a version upgrade is approaching and no one knows what it will break. The audit answers this uncertainty with a factual status report, not a disguised commercial proposal. The deliverable is a diagnosis and a set of priorities, which you remain free to act on as you see fit, including with a provider other than AX-Fiduciaire.
This document explains in which situations an audit is worthwhile, what it actually examines, what a fiduciary's perspective adds compared with a purely technical audit, and what the final deliverable contains.
An audit is sometimes requested “just to check”, with no specific trigger. That is legitimate, but the exercise becomes more effective when it starts from a concrete question: what do we want to know for certain by the end of this audit? A live Odoo instance accumulates decisions made at different times, by different people, often with no connection between them. After a few years, the actual configuration and the company's understanding of it drift apart, sometimes considerably. The audit closes that gap.
In which situations an audit is worthwhile
An Odoo instance audit is not a routine exercise: it responds to a specific trigger. The most common situations are as follows.
- Before a version upgrade. Odoo 19 is the current stable version, and Odoo 20 is unveiled on 24 September 2026. Migrating without knowing what customisations exist, or which are compatible with the new version, exposes the company to unpleasant surprises in production. See our dedicated page on Odoo migration.
- Before changing provider. An audit establishes a neutral starting point: what actually exists, independent of what the documentation or the current contract claims.
- A slowing instance. Reports that take time to display, imports that fail, an interface that freezes at peak times: these symptoms have identifiable causes, rarely down to chance.
- Accounting figures that don't add up. Bank reconciliation discrepancies, VAT returns that don't match expectations, inconsistent balances on auxiliary accounts.
- Users working around the tool. Parallel Excel files, duplicate data entry, information circulating by email rather than in Odoo: a sign that the configuration no longer matches actual needs on the ground.
- Customisations accumulated over time. Bespoke modules, added fields, automations stacked up by successive different contributors, with no overview or documentation.
- Access rights that have become blurred. Former employees still active in the system, overly broad rights granted for convenience, no clear rule on who can see or change what.
- Doubts about backups. Many companies only discover the real state of their backup policy after an incident.
What we examine
The audit covers every layer of an Odoo instance, from accounting configuration to technical infrastructure. None of these dimensions is examined in isolation: application slowness can have an accounting origin (reports that are too heavy, built on a poorly controlled data volume), just as an accounting error can have a technical origin (a poorly configured module or a badly designed automation). The audit systematically cross-references these angles rather than treating them as separate silos.
Accounting and VAT configuration
When a company is set up in Switzerland, Odoo automatically installs the Swiss localisation (the l10n_ch module), which lays down the base chart of accounts and VAT rates. We check that this localisation has been correctly kept and adapted: VAT rates applied (8.1%, 2.6% and 3.8% since 01.01.2024), the reporting method chosen, mapping accounts, and consistency between the entries generated and the reality of the business. See also our Odoo Accounting page.
Payroll configuration
When the payroll module is used, we check the configured salary rules, the management of social security contributions, and the compliance of the electronic salary transmission. Details on our Odoo Payroll & HR page.
Active and unused modules
An instance often accumulates modules that were installed and then abandoned, which consume resources and complicate maintenance without adding value. We draw up a list of what is actually used and what no longer is.
Customisations and their impact on version upgrades
Every added field, every automation, every bespoke module represents a potential risk at the next version upgrade. We map these customisations and assess which are documented, which are fragile, and which could be replaced with a standard feature. For ongoing or upcoming development work, see Odoo development.
Data quality
Duplicate customer or supplier records, mandatory fields left blank, incomplete history following a rushed data migration: data quality determines the reliability of everything that depends on it, including accounting reports. A single piece of badly entered data propagates silently into every report and every statement built on it, which makes it hard to spot without a targeted review.
Performance
View loading times, background task duration, hosting sizing: we identify whether the slowness observed comes from the configuration, the data volume, or the infrastructure. The distinction matters, because the fix is not the same: a configuration issue is corrected at no infrastructure cost, whereas genuine under-provisioned hosting cannot be solved through configuration.
Rights and security
Mapping of user groups, access rights granted, accounts still active when they should not be. A rights audit often reveals broader access than the company thinks it has granted.
Backups and restoration
Whether a backup policy exists, how often it actually runs, and above all: has restoration ever been tested. A backup that has never been restored is only an assumption.
Integrations
Connections with banks, invoicing tools, third-party platforms: we check their reliability and their consistency with the rest of the system.
The specific perspective of a fiduciary
A standard technical audit checks that a module works, that an integration responds, that performance is within an acceptable range. It does not generally check that the figures produced are correct in Swiss accounting and tax terms. This is where a fiduciary's perspective comes in: checking that the VAT return generated genuinely matches the business activity, that closing entries are consistent, that the payroll configuration produces statements compliant with social insurers' requirements.
This dual expertise, technical and accounting, makes it possible to detect problems that a purely IT audit would miss: a configuration that is perfectly functional from a systems point of view can very well produce incorrect accounting. The reverse is also true — correct accounting can rest on a fragile technical configuration that will eventually cause problems. The audit examines both dimensions together rather than separately.
In practical terms, this means we do not limit ourselves to checking that an invoicing or payroll module “works” in the sense of producing a document without an error message. We check that the document is the right one: that the VAT rate applied matches the actual nature of the transaction, that the accounting entry booked is the expected one, that the salary rule reflects the contractual situation of the employee concerned. That is a level of scrutiny purely technical expertise does not cover.
The deliverable
The audit concludes with a structured report, designed to be usable regardless of who reads it:
- A map of the current state: active modules, customisations, integrations, users and rights.
- Risks ranked by severity and likelihood, not a simple flat list of findings.
- Quick wins: simple, low-effort, high-impact fixes, identified separately from heavier undertakings.
- A prioritised roadmap, distinguishing what is urgent from what can wait, without imposing an arbitrary timeline.
What happens after the audit
The report is yours. You can have it carried out in-house, hand it to another provider, or ask AX-Fiduciaire to take on all or part of the identified corrections — this last option is discussed separately, once the diagnosis is established, never before.
Sometimes the conclusion is reassuring: the instance is correctly configured, the risks identified are minor, and the report then serves as a reference snapshot for the future, particularly before a future version upgrade. In that case, the audit has not changed your day-to-day operations, but it has replaced an impression with a verified certainty — which has value in itself.
Depending on the priorities identified, the follow-up may involve upgrading the accounting configuration, work on payroll, taking over specific development work, moving through support, or a team training session. If the audit reveals that a previous project was never completed, the situation is closer to an Odoo project rescue than a simple adjustment. For an overview of our services, see Odoo ERP in Geneva and our Odoo in Geneva page. For full support on a new deployment, see Odoo implementation.