Where the Money Actually Goes in a UAE ERP Implementation

The quote arrives as a PDF. Somebody opens it, scrolls past the methodology slides, and stops at the licence line. That line becomes the number everyone repeats in meetings for the next three months.

It is the wrong number to fix on. Not because it is dishonest — it is usually the most accurate figure in the document — but because it is accurate for the same reason it is unimportant. Licensing is the only part of an ERP project that can be priced without knowing anything about your company. It is a per-user rate multiplied by a headcount you supplied. Everything else in the total depends on facts nobody has looked at yet.

This piece is about the rest. Not what an implementation costs, which nobody can publish honestly, but where the money goes, in what order, and which lines are wrong in almost every quote you will receive.

Why the licence line is the easy part

Consider what has to be known before each number in a quote can be produced.

To price a licence, a vendor needs a user count. That is it. Your business could be a two-branch trading company or a contractor running twelve sites and the arithmetic does not change.

To price implementation services, somebody has to know how many genuinely distinct processes you run, how many entities they run across, how much of your work is exception rather than rule, and how quickly your organisation settles a disagreement. None of those are in the RFP. Most of them are not known inside your own company at the point of signing.

So the quote you receive is one precise number and a set of estimates dressed to look like it. The precise number is small relative to the estimates. That asymmetry is the single most important thing to understand about ERP budgeting, and it is why comparing bids on licence price ranks vendors in an order that has almost nothing to do with what you will eventually pay.

The relationship is worth stating structurally, because the absolute figures vary by product, by band and by year. Implementation services are a multiple of annual licence, not a fraction of it. For a first ERP in a mid-market UAE company with real inventory, projects or manufacturing, services dominate the first-year total, and the tail after go-live keeps costing money long after the project team's invoices stop. Any comparison that ends at year one is comparing the smallest and least variable part of the decision.

The order in which money actually leaves

Cost tables in proposals are organised by category. Cash leaves in a different order, and the order is what makes budgets fail. Below is the sequence as it happens, rather than as it appears in a document.

When	What is being paid for	Who quoted it	Typical accuracy at signature
Before contract	Discovery, process mapping, sometimes a paid proof of concept	The partner, separately	Reasonable, because the scope is small
Signature	First services milestone, first licence period	Both	Exact
Months one to three	Configuration workshops, design decisions, environments	The partner	Reasonable if discovery was real, optimistic if it was not
Months two to six	Data extraction, profiling, cleansing, trial loads	Under-scoped, always	Poor, because it was priced against data nobody had opened
Months three to seven	Integrations, one line per interface	The partner, sometimes the far-end vendor too	Poor, because the far end has its own opinion and its own rate card
Months four to eight	Change requests arising from decisions nobody made in month one	Nobody	Not in the budget at all
The month before go-live	Training, parallel running, extra environments, overtime	Partially quoted	Half of it appears late
Go-live and the eight weeks after	Hypercare, defect fixing, the second training round	Rarely in full	The second round is usually missing
Every month thereafter	Support, licence renewal, new users, new entities, small enhancements	Priced as a percentage of licence, which understates it	Understated by design
Continuously, from week one	Your own people	Nobody	Absent from every quote ever written

Two things stand out in that sequence. The first is that the least accurate lines are all in the middle, where changing your mind is most expensive. The second is that the largest single cost — your own staff — is the one line no supplier has any incentive to mention, because it is not theirs to sell.

The lines that are always underestimated

Internal staff time

The people who understand how your business actually works are the people the project needs in the room. They are also, without exception, the people who are already fully committed. An implementation does not create spare capacity; it consumes the scarcest capacity you have.

A finance manager who is half-removed from her job for nine months is a real cost whether or not anyone books it. It shows up as delayed month-ends, as a receivables ledger nobody chased, as a hiring decision deferred. Companies that budget for backfill — a temporary hire, an outsourced bookkeeper, a delayed initiative — pay this cost visibly and manage it. Companies that do not pay it invisibly and describe the result as the project being disruptive.

The test is simple and worth doing before signature: name the two or three people the project cannot succeed without, then write down what they will stop doing. If the answer is nothing, the plan assumes an eleventh working day per week.

Data

Data migration is priced against data nobody has opened. That sentence explains most of the change orders in this industry.

A partner quoting your migration has seen a record count and a list of tables. What they have not seen is that your customer master contains the same company three times under three spellings, that half your item records carry a unit of measure that was a placeholder in 2016, or that opening balances in one of your entities were last reconciled by a person who left. Those facts do not change the effort of writing an extraction script. They change the effort of everything else — deciding what is true, getting a human being to sign that it is true, and doing it again when the trial load rejects a third of the file.

This is why data migration kills more projects than software ever does, and it is why the honest way to buy migration is not a fixed price. It is a profiling exercise first, priced small and delivered early, and then a migration priced against what the profile found. A partner who will sell you the profile separately is telling you something good about how they work.

Integrations

An integration is quoted as one line and delivered as a negotiation with a third party who was not in the room.

The bank's file format has a version. The e-commerce platform's API has a rate limit and a support desk in another time zone. The payroll system's vendor charges for changes at their own rate, on their own schedule. The customs or logistics provider has a portal rather than an interface. Each of these turns a two-week task into a two-month one, and none of the delay is within your partner's control.

Before signature, for every interface in scope, write down who owns the far end, whether they have done this before, and what they charge. If any of the three is unknown, that line is an estimate with no basis, and it should be carried in the budget as a range rather than a figure.

The second training round

Almost every proposal contains training before go-live. Very few contain training after it.

The first round teaches people a system they have not yet used to do work they have not yet done in it. Most of it does not stick, and it cannot, because there is no context to attach it to. The round that changes behaviour happens four to six weeks after go-live, when everyone has discovered what they get wrong and has specific questions. That is the session that stops the workarounds becoming permanent.

If it is not in the scope, it becomes a change request at the worst possible moment: during hypercare, when the budget is exhausted and the sponsor's patience is thinner than it has ever been.

Environments

Development, test and production are three environments and they are frequently quoted as one. So is the extra copy you will want during data rehearsals, and the one you will want six months after go-live when somebody asks whether an upgrade is safe.

This is a small line that becomes a schedule problem rather than a money problem. A team without a proper test environment tests in production, and testing in production is how a Tuesday afternoon becomes an incident.

The support tail

Post-go-live support is generally priced as a percentage of licence, which is convenient and structurally wrong. Support effort scales with the complexity of what was built, not with the number of people using it. A heavily customised system with three integrations and a bespoke report pack generates far more support than a lightly configured one with the same user count, and the percentage does not know that.

Ask every bidder to price years two through five in writing: the annual uplift, the cost of adding twenty users, the cost of adding one entity, and what support explicitly excludes. Configuration changes, new reports and new users are excluded more often than buyers realise. The cheapest year one is regularly the most expensive year four, and the only way to see that is to make everyone quote the same four years.

What actually drives the total

If you want to predict cost rather than react to it, stop counting users and start counting these.

Entities and jurisdictions. One company in one free zone is a different project from four companies across mainland and free zone with intercompany trading between them. Each entity multiplies the chart of accounts work, the approval matrix, the tax configuration and the consolidation design. This is the single largest structural driver in most UAE projects and it is frequently discovered rather than declared, because groups describe themselves by trading name rather than by legal structure.

Genuinely distinct processes. Not modules. Processes. If your three business lines quote, deliver and invoice in three different ways for good reasons, that is three designs. If they do it in three different ways for no reason, it is one design and a difficult conversation.

Exception rate. Two hundred invoices a month where nearly all are straightforward is a different system from two hundred where a meaningful share are partial deliveries, retentions, credit notes against prior periods and foreign-currency settlements. Volume is cheap. Variation is expensive. A requirements document without an exception rate attached to each process is describing the easy version of your company.

Integration endpoints, weighted by ownership. An interface to a system you control is a task. An interface to a system a third party controls is a project.

Decision latency. This one surprises people. The elapsed time between a question being raised and answered is a cost driver, because a consultant waiting is a consultant billing. Organisations that cannot settle a small question inside a week accumulate a backlog of small questions, and the backlog is what everyone later calls the project running late. The remedy is free: a standing weekly hour with somebody who has authority to decide, and a written record of what was decided. This is the cheapest cost control available and the one most often skipped, which is one reason governance belongs in the plan before the platform does.

Customisation, measured after go-live rather than before. A customisation is not paid for once. It is paid for at build, then again at every upgrade, then again whenever a support person has to understand it before answering a question. Deciding what to configure and what to genuinely build is the highest-leverage cost decision in the project, and it is taken in workshops, months after the budget was approved.

The costs that arrive because a decision was avoided

There is a category of spend that no vendor causes and no buyer forecasts. It comes from decisions that were available in month one and were taken in month six instead.

Whether the group reports by entity or by business line. Whether stock is valued at standard or average cost. Whether the shared service centre or the site raises purchase orders. Whether a project code is a customer's project or an internal one. Each of these looks like a detail in a workshop and each of them, changed after transactions exist, means rework across configuration, data, reports and training.

The pattern is consistent: the cost of a decision rises roughly in step with how much has been built on top of it. A decision taken in design costs a conversation. The same decision taken during user acceptance testing costs a change request. Taken after go-live, it costs a change request plus a data correction plus a retraining session plus the credibility of the system with the people who have just learned it. This is why the sequencing of decisions before you choose a platform matters more to the budget than anything in the licence tier.

How to read a quote so it tells you something

Three questions extract most of the information a proposal is hiding.

What is excluded? Ask for the exclusions list in writing and read it before the inclusions. Data migration beyond a stated record count, integration beyond a stated number of interfaces, training beyond a stated number of sessions, and anything described as "standard reports" are the usual places where the boundary sits.

What is the assumed volume behind each estimate? Every services line rests on an assumption: this many master records, this many interfaces, this many approval levels, this many reports. Ask for the assumptions. Then check the two or three that are most likely to be wrong. If the assumptions cannot be produced, the estimate was a feeling.

What happened on your last three comparable projects? Not the average across the practice. Three named projects: quoted figure against final figure, and what caused the difference. A partner who has the answer and gives it is worth more than one whose quote is lower, because the second one will find the same variance and you will pay for it as a surprise.

There is a fourth question that is really a test of the sales process rather than the price. Ask what they would remove from the scope to reduce the cost by a fifth. A good answer names specific things and explains what you lose. A bad answer discounts the same scope, which tells you the original number contained a fifth of margin you were meant to ask for.

Phasing is a cost control, not a delay

The instinct in a first ERP project is to buy everything at once, because a single mobilisation looks cheaper than two. Sometimes it is. Frequently it is not, and the reason is that a large phase concentrates every uncertain line — data, integration, undecided design — into one date that slips as a single object.

A first phase that is genuinely usable on its own, and that produces a benefit somebody can name, does three useful things. It converts unknowns into knowns before the expensive parts are committed. It gives your own team the experience to specify phase two properly, which is the cheapest way to buy better requirements. And it produces a working system if the programme loses its funding or its sponsor, which is a risk nobody puts in a risk register and which happens.

The counterargument is real: phasing has a mobilisation cost and can leave you running two systems in parallel for a period. That is a genuine expense and should be budgeted. It is usually smaller than the expense of discovering, in month nine of a single monolithic phase, that the design does not survive contact with your data.

What to do with all of this before you sign

Write down the four or five processes that actually matter, with volumes and exception rates. Name the entities, including the dormant ones somebody forgot. List the interfaces with the far-end owner beside each. Name the two people whose time the project will consume and decide what they stop doing. Ask every bidder to price four years, with the exclusions stated. Then compare.

That comparison predicts your total far better than a licence rate does, and you can build most of it in a fortnight without a consultant. If you want a structured starting point for the sizing conversation, the ERP cost estimator walks through the same drivers described here and produces a shape you can take into a vendor meeting — which pairs naturally with running a demo that tests your own transactions rather than the vendor's.

If you would rather have the assumptions checked by someone who has cleaned up the consequences of getting them wrong, that written diagnosis is the first thing we produce on an ERP implementation.