Almost every ERP project we run starts with the same request. Somewhere in the first workshop, someone says: “Our process is different, so the system will need changes.” Sometimes that’s true. More often, the process is fine and the standard system already handles it, just under a name nobody recognised.
Custom development isn’t bad. We build custom modules regularly. But each change you make to an ERP is something you’ll be paying for, testing and upgrading for as long as you use it. So it’s worth being picky.
What companies usually ask us to change
In the UAE and the wider GCC, the requests fall into a few groups:
- Printed documents. Invoices with Arabic and English side by side, a TRN in the right place, a stamp area, the bank details your customers expect.
- Approvals. “Purchase orders above AED 20,000 need the GM.” “Leave in December needs HR sign-off.”
- Reports. Usually the exact Excel layout the finance manager has used for years.
- Industry processes. Rental of scaffolding or equipment, project costing for contractors, van sales for distributors.
- Payroll rules. WPS files, gratuity, air tickets, overtime on site.
The first three almost never need real development. Odoo, Zoho and Business Central all have document layouts, approval rules and report builders. It’s configuration work, and a good consultant can do it in days.
The last two are where it gets interesting. Industry processes sometimes do need a custom module. Payroll rules shouldn’t. If your HR system can’t produce a WPS SIF file or calculate gratuity under the 2021 labour law, the problem is the system, not your process.
Configure first. Customise only what’s left.
Our rule of thumb is simple. Before anyone writes code, we try to solve the requirement with settings, a different workflow, or an app that already exists. Only what’s left after that becomes development.
It sounds obvious, but it changes budgets. On a typical project, a long list of “must have” changes shrinks to a handful once people see the standard screens working with their own data. The rest turn out to be habits from the old system.
The cost nobody puts in the quote
The price of a custom module is mostly paid later. Odoo releases a new version every year. Business Central updates twice a year. Each time, custom code has to be checked, sometimes rewritten, and tested again with real data.
It’s common to find systems stuck two or three versions behind because nobody wants to touch the customisations. By then, upgrading costs more than the original project. Keep that in mind when a change looks cheap.
So when we do build something, we keep it in its own module, document what it does and why, and avoid editing the core system. It’s slower on day one and much cheaper in year three.
Four questions before you approve a change
- Can we do this with configuration, even if it’s not exactly how we do it today?
- Will this still matter in two years, or is it a workaround for something temporary?
- Who will maintain it when the person who asked for it has moved on?
- What happens to it at the next version upgrade?
If the answers are “no, yes, us, and we’ve planned for it”, build it. Otherwise, think again.
Local rules are configuration, not customisation
Many “customisations” requested in this region are really country rules that a properly localised system already covers. Before you pay for code, check these:
- UAE: 5% VAT invoices with TRN, bilingual layouts and WPS SIF files should be standard.
- Saudi Arabia: ZATCA Phase 2 e-invoicing is part of the Odoo and Zoho localisation, and GOSI belongs in payroll.
- Qatar: QID tracking, WPS and gratuity are HR features, not development.
- Oman: make sure end of service follows the 2023 labour law before building anything.
- Kuwait: indemnity and PIFSS are payroll settings.
- Bahrain: 10% VAT and SIO contributions are configuration.
- India: GST, e-invoicing and TDS come with the Indian localisation; PF, ESI and professional tax belong in payroll.
We implement Odoo ERP, Zoho and Microsoft Business Central, and we build our own ZEO Cloud HR & Payroll. That means we write code ourselves when it’s needed, and we’ll also tell you when it isn’t. If you have a list of changes you’re not sure about, send it to us and we’ll go through it with you.