What UAE Businesses Actually Customise in Odoo — an analysis of 140 modules across 10 implementations

Every Odoo buyer in the UAE asks the same question, ten minutes into the first meeting: how much of this will we have to customise? The honest answer has always been "it depends". This time I counted instead — 140 modules across 10 Odoo implementations delivered by the team I lead in Dubai.

Why I ran this

Ask a software vendor how much customisation an ERP needs and you get one answer; ask an implementation partner and you get the opposite. Both are marketing. The evidence, meanwhile, was sitting in ten git repositories, and code has no commercial position to defend: a manifest records which Odoo app a module extends, and a git log records how much work happened after a third-party app was installed.

How the data was derived

Every __manifest__.py file across 10 Odoo implementation repositories was parsed programmatically, producing 140 modules. "Module" here means an add-on module carried in the implementation repository — written in-house or bought in — not Odoo's own core apps. Each was classified from evidence in the repository, not recollection:

• Built from scratch (63 modules) — authored in-house, identified from the manifest author field and our naming convention.
• Adapted in-house (48 modules) — a third-party app with more than one commit touching it in git history: work after import, read from the commit log rather than asserted.
• Installed as-is (29 modules) — present with no post-import commits at all.

App-extension counts come from each manifest's depends list; theme counts from keyword classification of module name, manifest name and summary. A module usually depends on several apps, and can carry more than one theme — a POS report counts under both — so neither the app percentages nor the theme percentages sum to 100%. Every percentage on this page is a share of the same 140 modules, not a share of a category. No client is named: the implementations are impl-A to impl-J, and no third-party app or vendor is identified.

Limitations

This is a small study; better that you know its limits than discover them:

• n = 10. Ten implementations show a shape. They do not prove a distribution.
• It is one consultancy's portfolio, shaped by which clients hired us rather than sampled from the market. This is not a representative sample of the UAE Odoo market.
• Module count is a proxy for effort, not a measure of it. One module is a two-field tweak, another a quarter of engineering. Nothing here estimates cost or time.
• The sample is uneven. Implementations carried between 1 and 34 modules, median 8, so a few large projects drive the totals.
• "Adapted" is a mechanical definition. An app heavily configured but never edited in code counts as installed as-is, because git cannot see configuration.
• This was a team's work. I am Head of Projects: these are implementations I have led, written by a team of engineers, not by me alone.

Finding 1: the ledger absorbs the most customisation

48 of the 140 modules — 34% — declare a dependency on account, Odoo's accounting app: more than twice the next app, point_of_sale at 22 modules (15%).

Source: depends lists parsed from 140 module manifests. Modules usually depend on several apps.

The UAE reason is not mysterious. VAT changed what an invoice has to prove; e-invoicing is changing what an invoice has to be; corporate tax laid a second reporting frame over the same ledger; and mainland-plus-free-zone group structures multiply all of it by the number of companies. All of it lands on the journal entry, the tax grid, the report — the detail is in my guides to UAE VAT in Odoo and the e-invoicing mandate.

Two other entries reward a second look. point_of_sale at 22 is high for an app only some of these businesses run at all: when a business does run a till, it customises it hard — the pattern behind our POS work for UAE retail. And mail at 17 (12%) is not messaging: it is approvals and notifications.

Finding 2: a fifth of all customisation exists to answer questions

By theme rather than by app, accounting and finance leads with 36 modules (25%). The second-placed theme is the more interesting: reporting and dashboards, 29 modules, 20%.

Source: keyword classification of module name, manifest name and summary. Themes overlap.

One module in five does nothing operational. It books no sale, moves no stock, posts no entry — it exists so somebody can see something. Standard Odoo reporting answers standard questions well; what it cannot know is the handful of numbers a particular business runs on.

The same figure carries a warning: reporting is the easiest customisation to ask for and to accumulate. A fifth of the work is well spent if those reports are load-bearing, and waste if they were built once and never opened again.

Finding 3: most bought modules needed work after they were installed

48 of the 140 modules were third-party apps our team had to change after installing them — more than one commit each in git history. Only 29 came through untouched, so across these repositories more bought modules were edited than survived unedited. The three most-worked carried 41, 23 and 20 commits; the next two carried 13 each.

Forty-one commits is not a bug fix. That is sustained engineering on somebody else's codebase: fitting it to a chart of accounts it never anticipated, a tax treatment it did not implement, a workflow its author never saw. The listing price buys a starting position, not a finished feature.

So budget a bought module as a component, and ask before you buy who maintains the modified version through the next upgrade — one of the sharper questions for a prospective partner.

Finding 4: payroll is the dog that did not bark

HR and payroll is the smallest theme: 3 modules, 2%, last of the ten categories. I expected more, because UAE payroll carries real local obligations and clients ask anxious questions about it.

Two explanations fit and this data cannot separate them: either standard Odoo payroll and its localisation are sufficient here, or payroll never came into Odoo at all. My experience says mostly the second — but this study measures what was customised, not what was implemented, and I would rather flag the ambiguity than dress an opinion up as a finding.

What this means if you are buying Odoo

• Budget the ledger first. Accounting led by app (48 modules) and by theme (36) — where UAE implementation cost tends to land.
• Ask what "reporting" means before you sign. A fifth of the work here was reporting; "standard reports" usually becomes a change request later.
• Price third-party apps as components. 48 needed work after purchase, the most-worked carrying 41 commits. Ask who owns the modified version at upgrade.
• Expect a small project to be genuinely small. These ranged from 1 to 34 modules, median 8 — the typical project is single-digit.
• Do not read customisation as failure. 111 of 140 modules being built or reworked is what a platform is for; the question is whether each earns its maintenance.

Cite this research

Frequently asked questions