How to Choose an ERP System in the UAE Without Being Sold One
· 16 min read · Faceela
Most ERP selections in the UAE start in the wrong place. A shortlist arrives first, usually from a board member, an auditor or a search result. Three demos are booked. A comparison grid is built out of vendor websites, and by the time anyone asks how the work is actually done today, the shortlist has already decided the answer.
This guide is the other order: the stage before the shortlist.
The disclosure, because it should change how you read this
Faceela implements ERP systems, and Odoo is the product we know best. Every other page ranking for ERP system UAE or best ERP for small business Dubai was written by someone who sells one product, and in part so was this one.
So what follows is not a claim of neutrality. It is a method you can run without us, to a conclusion that is not our product. Nothing below tells you what to buy. It tells you what you have to be able to describe before that question can be answered at all.
The decision before the decision
Somebody has said the company needs an ERP. Before you spend a day on vendors, write down what decision you cannot make today, and what not making it costs you.
One paragraph. In language a person outside finance can read. Then apply the test: if the sentence would still be true after buying any of five different systems, it is not a problem statement. It is a mood.
These are problem statements:
- We cannot tell what a job cost until three weeks after it finished, so we price the next one on feeling.
- Month-end close takes eleven working days, and two are spent agreeing which stock figure is correct.
- Nobody can produce, on the day it is asked for, what we owe subcontractors against what the client has certified.
These are not:
- We need better visibility.
- Our current system is outdated.
- We want to be ready for growth.
The difference matters because the first list can be tested in a demo and measured after go-live. The second cannot, which is why projects that start there end with nobody able to say whether the money worked.
Published ERP failure rates sit between 60 and 70 per cent depending on who is counting; Panorama Consulting Group's 2025 research puts it at 68 per cent. Every study defines failure differently, so the number matters less than the pattern behind it — and what actually kills these projects is almost never the software.
Three problems that look like an ERP problem and are not
A large share of the companies that ask us to scope an implementation are describing something else. Buying software for these three does not fix them. It makes them permanent, because now they are encoded, licensed and paid for annually.
A process problem
The symptom. Two people describe the same process differently, and both descriptions are correct, because both are happening.
The test. Ask four people how a purchase gets approved. If you get four answers, you do not have a process. You have four processes and a shared vocabulary.
What software does to it. A configuration decides which of the four is now the only one. If you have not decided, the implementation team decides for you, from whichever description they heard last. That is where "the system does not work how we work" comes from, eight months later.
A data-ownership problem
The symptom. Three departments report a different figure for the same month, and each can defend theirs from its own records.
The test. Name the person accountable for the customer master. Not the department. The person. If the answer takes more than five seconds or contains the word "everyone", you have found it.
What software does to it. Moving three disagreeing sources into one database produces one database containing three disagreeing sources, now behind a single authoritative-looking front end. A dashboard everybody believes is more dangerous than a spreadsheet nobody trusts, and it is how reporting starts confidently lying to you.
A governance problem
The symptom. Decisions have no forum. Approvals happen by relationship. When two directors disagree about a field on a form, the question sits for six weeks.
The test. Write down who signs off the chart of accounts. Then who signs off a change to it after go-live. If those are different people, or unnamed people, the project has no decision-making machinery and the implementation will supply the delay.
What software does to it. Nothing. Every ERP project generates several hundred decisions, most of them small and irreversible. An organisation that cannot settle a small question in a week will accumulate a backlog of them, and the backlog is what people later call "the system being late".
Requirements that mean something are observed, not chosen from a list
A requirements document assembled from vendor feature lists will match every vendor's feature list. That is not a coincidence and it is not useful. Requirements have to come from watching the work.
Here is a method that fits inside three or four weeks and does not need a consultant to run it.
- Name your spine processes. Most companies have five or six: quote to cash, purchase to pay, plan to deliver, record to report, hire to pay. A contractor's spine runs tender to BOQ to measurement to interim payment certificate (IPC) to cash. Write yours in your own vocabulary, not in module names.
- Take one real document per spine, from last month. A genuine one, with the mess still in it. Not a clean example. The clean example is the process you wish you had.
- Walk it, sitting next to the person doing it. Do not interview them at a desk elsewhere. Watch the screen.
- Record five things at every step: who touches it, which system or file it lives in at that moment, what they are waiting for, what they retype from somewhere else, and how the approval was actually given. "WhatsApp voice note from the GM" is a valid and important answer.
- Record the volume and the exception rate. Two hundred invoices a month with a nine per cent exception rate is a different system from twenty thousand invoices with none. A requirement without a volume attached is decoration.
- Write each requirement as actor, action, evidence, volume, exception. Not as a capability. Capabilities are what vendors sell; the sentence is what you will test.
- Separate must from should honestly. The only valid test for "must" is that you can name what breaks and who complains. Everything else is a should, however strongly it is felt.
| Written like this | Why it is useless | Write it like this |
|---|---|---|
| Full inventory management | Every product on earth ticks it | A storekeeper records a part receipt against a purchase order and the balance stays open; about 400 receipts a month, roughly 15% part-delivered |
| Multi-currency support | Says nothing about how gains and losses land at your year end | AP invoices in USD and EUR settle against AED accounts, exchange difference posted automatically to a named account; about 60 a month |
| Real-time dashboards | Nobody has said which number, or who may disagree with it | The commercial manager sees committed cost against budget per project, sourced from approved purchase orders only, with committed defined in writing |
| VAT compliant | A compliance claim, not a system requirement | VAT return figures reconcile line by line to the ledger for the period, with reverse-charge and designated-zone transactions identifiable in the export |
| Approval workflows | Every product has them; none has yours | A purchase order above AED 50,000 needs two approvals, the second from outside the requesting department, and the record shows who approved it and when |
The requirements that disqualify vendors fastest are the local ones, and they are cheap to check early. In the UAE the list usually contains: a VAT return that reconciles to the ledger and survives an FTA audit, with retention and audit trail to match; a bilingual invoice that is legally acceptable in Arabic; e-invoicing under the Ministry of Finance programme and the integration seam to an Accredited Service Provider — check the ministry's own page for current dates and thresholds rather than any consultant's summary, including this one; WPS payroll files and end-of-service accrual; and, across free zone and mainland entities, a structure that consolidates without a monthly spreadsheet.
Answer the local list before anything else. It removes candidates for reasons nobody can argue with, which is the only kind of shortlisting that survives an executive meeting. It is also where an independent read is worth more than a proposal, and why our own engagements start with a written diagnosis before anything is quoted.
Reading the market: bands, not winners
There is no best ERP, and any page that answers "best ERP for small business Dubai" with one name is a sales page. What exists is a rough fit between the shape of a company and the class of product that tends to serve it without either drowning it in cost or running out of capability in year two.
| Your shape | What usually fits | The failure mode at this band |
|---|---|---|
| One entity, one country, under about twenty users, no manufacturing, simple stock | An accounting package plus one or two specialised tools. An ERP may be premature | Buying a suite to fix a reporting problem, then paying to implement modules nobody opens |
| One or two entities, real inventory, projects or light manufacturing, 20–150 users | Mid-market suites, open-source and commercial | Choosing on licence price, then finding the implementation multiple was the number that mattered |
| Multi-entity, multi-currency, group consolidation, statutory reporting in more than one country | Upper mid-market suites with genuine multi-company capability | Under-scoping the entity and inter-company design, which is expensive to change once transactions exist |
| Regulated, listed or very large; complex group reporting; heavy sector-specific process | Large-enterprise platforms, usually with a systems integrator | Treating the platform's reputation as a substitute for a scope |
Two things distort this map in the Gulf, and both are worth knowing before a demo.
The first is that sector fit beats brand fit. Contracting retention chains, real estate service charges, landed cost in re-export trading and job-costed manufacturing all contain work that generic products do not cover, whatever the brand. The honest question is not "do you support construction" but "show me a retention ledger and an advance recovery on a live record". We publish that gap map for our own product — where Odoo fits and where it does not — because the alternative is finding it in month five at your expense.
The second is that at this band the partner matters more than the product. The same product, implemented by two different teams, produces two different systems — which is why the evaluation below scores the team as heavily as the software.
The demo, scripted on your own data
A standard demo is a rehearsed film. It proves the vendor can operate their own software, which was never in doubt. Replace it.
Send the same script to every vendor two weeks ahead, with a small extract of your real data: twenty customers with their actual naming mess, fifty items, one bill of materials or BOQ, a part-delivered order, a foreign-currency supplier invoice, and the one transaction your team argues about. Same script, same order, same audience, same scoring sheet for every vendor.
Three rules do most of the work. Ask "show me", never "can it". Count clicks rather than watching slides. And ask who is operating the demo and whether that person will be on your project — the answer is often no, and it is better to know in the room.
| What you are scoring | How to score it | Evidence that counts |
|---|---|---|
| The script completed on your data | Completed, completed with a workaround, or not | The screen, not the explanation |
| Clicks for your highest-volume transaction | Count them; multiply by monthly volume | Someone from your team times it |
| Your exception case | Configuration, customisation, or a process change demanded of you | Which of the three, stated plainly |
| Standard versus custom | Which parts of the script needed code | A written list in the proposal, before contract |
| Reporting from live data | The vendor builds a report you asked for, in the room | Not a pre-built sample |
| Who does the work | Named individuals and their availability | CVs and a key-personnel clause, not a logo slide |
A scripted demo proves the flow exists, that the vendor prepared, and how they behave when something fails in front of an audience — the most predictive minute of the day.
It proves nothing about performance at your real volume, whether the configuration survives your month-end, upgrade safety, or support response when the invoice run fails on the 28th. Those come from references, from the contract, and from a small paid discovery before the main contract. A vendor who will not sell you one has told you something.
Reference calls, and the questions that reveal something
Vendors offer references who will say pleasant things. Better questions turn them into useful ones. Do the calls yourself, with no vendor on the line, and ask for one reference the vendor did not choose — same sector, live for two or three years.
| Ask this | What a bad answer sounds like |
|---|---|
| Who from the vendor was on your project, and are they still at the vendor? | "I would have to check the names" — nobody forgets the consultant who ran their go-live |
| What did you change about your process because the system could not do it your way? | "Nothing, it did everything" — nobody implements an ERP without changing something |
| What was in the original scope that came back as a change order? | "There were a few extras" with no figure attached |
| How long from go-live to your first clean month-end close? | "It went smoothly" — ask for the number of days, twice if necessary |
| What do you still do in Excel that you expected the system to do? | "Nothing at all" — untrue everywhere, and the honest list is the most valuable thing in the call |
| What did your year-two invoice look like against year one? | "About the same, I think" — this is the number that decides five-year cost |
| Who inside your company owns the system now? | A department name rather than a person |
| If you were signing again, what would you put in the contract? | "I would not change anything" — this answer never comes from someone who has been through it |
The shape of the cost, and why nobody can honestly quote you a number on a web page
Anyone publishing a price for "ERP cost UAE" is quoting a project they have not seen. What can be published honestly is the shape: the lines the cost is made of, who quotes each one, and when it actually arrives.
| Cost line | Who quotes it | When it actually lands | The question to ask now |
|---|---|---|---|
| Licence or subscription | The vendor, early and precisely | Monthly or annually from signature | What is the edition tiering, the minimum user count and the uplift at renewal? |
| Implementation services | The partner, as a multiple of annual licence | Across the project, front-loaded | What multiple did your last three comparable projects finish at, against the quote? |
| Data migration | Under-scoped, because it is priced against data nobody has opened | Halfway through, as a change order | Who profiles our data, when, and what happens to the price if it is worse than assumed? |
| Integrations | Per interface, if at all | Late, when the far end has its own opinion | Who owns the other end, and what do they charge to change it? |
| Training | As sessions | Twice: before go-live, and after, when you know what people got wrong | Is the second round in scope? |
| Post-go-live support | As a percentage of licence | From the moment the project team leaves | What does support exclude — config changes, new reports, new users, new entities? |
| Internal staff time | Nobody | Every week for the length of the project | Who covers the day job of the two people we are about to half-remove from it? |
| Infrastructure and environments | Sometimes | When you need a test environment you did not budget | Are development, test and production all included, and for how long? |
Two lines ruin business cases.
The first is internal staff cost. The people who understand your process are the people the project needs, and they are already fully occupied. Half of a good finance manager for nine months is a real cost, and it is rarely on anybody's quote. Budget it, or pay it in missed month-ends.
The second is the support tail. Compare bids over five years, not one. Ask every bidder to price years two to five in writing, including the annual uplift, the cost of twenty more users and the cost of one more entity. The cheapest year one is frequently the most expensive year four.
Contract terms that decide what year three looks like
Selection ends in a contract, and the contract is where most of the leverage you will ever have is spent. Six things are worth arguing about.
Scope defined by outcome, not by module. "Finance module" is not a scope; it is a shopping category. "Produce a VAT return that reconciles line by line to the general ledger from live data" is a scope, because it can be accepted or refused. Write acceptance criteria as tests, and tie payment milestones to the tests rather than to dates.
Day rates versus fixed scope. A fixed price against a scope nobody has defined does not transfer risk; it relocates the argument to a later, worse moment. Time and materials against a governed backlog can be entirely honest, but only if you have someone able to govern the backlog. Choose on the capability you actually have.
Who owns the configuration. Configuration, custom modules, reports, integrations and documentation. Name each, and name who may modify it and who holds the source. If custom code is written for you, the contract should say you have it, can read it, and can pay somebody else to change it. That clause is the difference between a supplier and a dependency.
What happens at renewal. Cap the uplift. Secure the right to reduce user counts as well as raise them. Get the price of the modules you already know you will add in year two, before you have signed away your only leverage.
Version and roadmap. Ask in writing how long your version is supported, what a major version change costs, and who pays to move your customisations. Read the answer alongside the arithmetic of when not to upgrade, because it decides whether your fourth year is maintenance or a second project.
Exit and data portability. A full export in a documented format, on demand, including attachments and audit trail, within a stated number of days at a stated cost. Test it during the implementation, not at the exit — the exit is the one moment the vendor has no reason to help. A contract you cannot leave is a price you have not finished paying.
What selection has already decided about your implementation
By the time the contract is signed, most of the outcome is fixed. Selection hands three things to implementation, and a project can only be as good as the worst of them.
A scope somebody can test. If the requirements came from a feature list, there is nothing to accept against, and every disagreement in month six becomes a negotiation rather than a reference to a document.
Data you have already opened. Selection is where you find that the item master has three naming conventions and the customer file has duplicates from 2011. Finding it then is a cleansing plan. Finding it at cut-over is a crisis.
Named owners. Every data domain and every process needs a person who decides. Appoint them during selection, while you still have everyone's attention, because the project cannot appoint them later without a mandate it does not have.
Then plan the ninety days after go-live now, while the contract is still open. Go-live is when most organisations disband the team that understands the system, and the ninety days that follow are where projects are actually lost. Put hypercare, the second training round and the day-90 business case review into the contract rather than into the plan. Things in the contract happen.
Where this leaves you
If you can describe how your work is done today — process by process, with volumes, exceptions and named owners — the choice of system becomes reasonably easy. If you cannot, no shortlist will save you, and the demo will return whichever answer the vendor prepared.
The sequence: write the problem statement, observe the spines, write requirements as testable sentences, disqualify on local compliance, band the market, script the demos on your own data, call the references the vendor did not pick, price five years, and argue about the contract while you still have leverage. Six to twelve weeks for a mid-market company, and the cheapest part of the whole programme.
If that points at a system, and you want it scoped against your real processes rather than a module list, that is how we scope an ERP implementation: a written diagnosis first, phases that stand alone, named owners before configuration.
If it tells you the problem was never the ERP — the numbers disagree because nobody owns the data, or you are already paying for systems nobody opens — the honest next step is not a purchase. It is an independent read of the systems you already run, which costs less than a licence and occasionally makes one unnecessary.