Bespoke Odoo development

Odoo development is never a purely technical operation when it touches invoicing, VAT, wages or accounting. It commits the business over the long term, with Swiss legal obligations that are not negotiable through a specification document. In the French-speaking Swiss market, this reality often pits two profiles against each other: integrators who master Odoo's code without knowing the Swiss chart of accounts, the QR-bill or Swissdec standards; and accounting firms who master accounting but do not develop anything themselves, referring every customisation request to a third party. AX-Fiduciaire, an official Odoo partner, brings both skill sets together in the same team: development (modules, fields, workflows, reports, connectors) and fiduciary expertise (accounting, VAT, wages, Swiss compliance). This page presents our bespoke Odoo development: what it covers, the method followed, and the limits we set ourselves.

When bespoke development is justified

Standard Odoo covers a large share of an SME's management needs: accounting, invoicing, purchasing, stock, sales, human resources. Some of these needs are settled without writing a line of code, through configuration or through Odoo Studio. Bespoke development is only justified once these options are exhausted: a business process genuinely specific to the company, a management rule the standard does not provide for, a connector to an external system that exists in no form of module, or a document whose structure matches no template provided.

Conversely, development is not justified when:

• the need is already covered by standard configuration (additional fields, invoicing rules, sequences, access rights);
• Odoo Studio allows the field, view or automation to be added without touching the source code;
• an existing OCA (Odoo Community Association) module meets the need, with the advantage of being maintained by a community rather than a single provider;
• the real need is a change of working habit, not a limitation of the software.

This discipline determines whether the development survives over time. A module added to reproduce a habit rather than to meet a genuine constraint becomes, at the first major version upgrade, an extra piece of work with no clear justification. The deciding criterion is not the number of functions a development can add, but its ability to carry through future versions of Odoo. Odoo 19 is the current stable version; Odoo 20 is unveiled on 24 September 2026. Every bespoke development must be designed with this continuity in mind, not just to meet today's need.

This question arises with particular sharpness as soon as a module touches accounting, VAT or payroll. A field added to an invoice, a calculation rule inserted into a validation workflow, or an automation that alters an accounting entry are never trivial developments: they run on every transaction, often without direct human oversight. The question to ask before any development is therefore not only "is this possible", but "will this development still be correct in two years, with a different team, on a different version of Odoo". It is this question, more than technical feasibility, that distinguishes a sound development from one that will become a problem.

What can be developed in Odoo

Bespoke development in Odoo covers several levels, from the simplest to the most structural. They are often combined within the same project: a connector is almost always accompanied by a new data model to store what it receives, a workflow generally alters a view to remain legible.

Modules

An Odoo module groups together a coherent set of features: data models, views, business rules, access rights. A bespoke module installs alongside the standard modules without modifying them, which limits the impact on future version upgrades. This is the level we favour by default, rather than intervening directly in the code of the modules supplied by Odoo.

Fields and models

Adding a field to an existing form, creating a new data model to track information specific to the business (a file number, an internal category, a specific status), and linking this information to existing models — customers, invoices, orders, employees. This is often the starting point for a broader development: once the information is stored, it must be displayed, filtered, and sometimes carried onto a document.

Views

Adapting the display of a form, a list or a dashboard so that it matches the team's real workflow, without overloading the standard interface with options that are irrelevant to other users. A poorly designed view, added for a single workstation, often ends up getting in everyone else's way.

Workflows and automations

Automating a sequence of steps — approval, notification, status change — according to rules specific to the business, within limits where the automation remains understandable and correctable by a person. An opaque automation that no one can explain or fix poses a greater risk than the time it saves.

Reports and documents

Designing printed or PDF documents (invoices, payslips, delivery notes, analysis reports) that follow a particular visual identity or information structure, while remaining generated from Odoo's real data — never from a parallel source that risks diverging.

Connectors and APIs

Connecting Odoo to an external system — bank, till, e-commerce platform, third-party business software — via the Odoo API (XML-RPC, JSON-RPC or REST depending on the case) or via connectors dedicated to Swiss payment standards, ISO 20022 and the QR-bill. A poorly isolated connector can cause an entire synchronisation to fail over a minor error on the external system's side; the impact analysis described below exists precisely to limit this risk.

Portals

Opening limited, secure access for third parties — customers, suppliers, employees — to view or submit documents, without giving them access to the full management interface. Portal access rights must be defined with the same rigour as those of an internal user.

The method followed for each development

An Odoo development that touches management data follows a fixed working sequence, whatever its size.

Two steps in this method are often neglected by integrators unfamiliar with Swiss accounting: impact analysis, which must include a reading of the accounting and tax consequences of the development, and acceptance testing, which must be validated by someone able to judge whether the result produced is correct in accounting terms, not just functional terms.

The Swiss constraint: what dual expertise changes

A development that touches accounting, VAT or payroll is never a neutral piece of development. It must comply with the chart of accounts adopted by the business, the fiscal positions applied to each type of transaction, the QR-bill structure, the ISO 20022 payment standard, and Swissdec requirements for payroll management. A field added without regard to these constraints can produce an incorrect accounting entry, an incorrect VAT position, or a non-compliant QR-bill.

Odoo automatically installs the Swiss localisation (l10n_ch module) when the company is configured in Switzerland, which provides a correct foundation for the chart of accounts and VAT rates — 8.1%, 2.6% and 3.8% since 1 January 2024. This standard foundation does not exempt anyone from checking, with each development, that the customisation remains aligned with it rather than bypassing it.

On payroll, Odoo is listed on the Swissdec register at the "swissdec certified basic" level (certificate no. 1203.25, for ELM 5.3, verified on 22.09.2026). Any development touching salary calculation or transmission must comply with this certification framework: this is not an area where a departure from the certified standard can be allowed. It is precisely at this intersection that AX-Fiduciaire's dual expertise matters: understanding both what the code must do and what Swiss law requires of that result. Our developments that touch accounting connect with our Odoo accounting offering; those that touch wages, with our Odoo payroll and HR offering.

Maintaining a development over time

A delivered development is not a finished development. It lives alongside the rest of the system and must remain compatible with its changes. This is a point that projects driven solely by initial go-live often neglect: the cost of a development is not measured only at delivery, but in what it costs to maintain across successive versions.

• Version upgrades: every new major Odoo version can alter APIs, models or views that a bespoke module relies on. A well-designed module, without modification of standard modules, limits this risk without eliminating it. See our Odoo migration offering.
• Technical debt: every development added increases the surface area to maintain. A development that is undocumented, untested or redundant with the standard becomes a burden that builds up.
• Regression testing: checking, at every update, that existing developments continue to work as intended.
• Documentation: recording what was developed, why, and according to which business rules, so that another developer can pick up the work without having to guess the original intent.
• Reversibility: a development must be able to be disabled or removed without breaking the rest of the system, if the need that prompted it disappears.

This ongoing follow-up is part of our Odoo support offering, which covers both standard modules and developments carried out by AX-Fiduciaire.

Taking over an existing development made by another provider

We also work on Odoo developments carried out by a previous provider, whether to fix an anomaly, prepare for a version upgrade, or take over maintenance of a system whose original provider is no longer available. This takeover always begins with an analysis of the existing code: what it actually does, how it was built, whether it modifies standard modules or lives in separate modules, and what risks it presents for future version upgrades.

This analysis may show that an existing development is sound and deserves to be kept as is, that it needs to be documented before any further intervention, or that it needs to be partly revised because it directly modifies standard modules or bypasses an accounting rule. In every case, the takeover is based on what exists, not on a systematic rewrite.

This type of work is common after a version upgrade reveals developments that have become incompatible, or when a development touching accounting or payroll was carried out by a provider without fiduciary expertise and needs to be checked substantively, not just on the code's form.

What AX-Fiduciaire will not do

These limits are set at the scoping stage, not discovered mid-project.

• Develop what the standard already covers. If a configuration setting, a native option or an existing OCA module meets the need, we do not propose bespoke development instead.
• Bypass an accounting, tax or payroll rule through code. A development is never used to produce a result that departs from the applicable chart of accounts, VAT positions or Swissdec requirements.
• Deliver without testing. A development that touches management data goes through functional testing and regression testing before going into production, without exception.