The Five-Year Number: What an ERP Costs After the Project Team Leaves
· 10 min read · Faceela
The finance director who signed the contract has usually moved on by the time the fourth invoice arrives. Whoever inherits it opens the renewal, compares it against a business case written three years earlier by somebody else, and finds a gap nobody can explain. Not a scandal — no clause has been breached and no invoice is wrong. The gap is simply the accumulated difference between what was modelled and what was bought.
Year one is the number every selection committee argues about. It is also the year in which the decision matters least, because year one is largely a project cost and projects end. Years two to five are the years you actually live in, and almost nothing in a standard proposal describes them.
This is a piece about building the other four years before you sign. It assumes you already understand where the money goes during the implementation itself; the concern here starts the week the consultants stop coming.
Why year one predicts so little
A first-year total is roughly two thirds project and one third system. Implementation services, data migration, integration build, training, environments — none of these recur. What recurs is licence, support, hosting and the people you now employ to keep the thing running. That recurring base is the smaller part of year one and the entire part of year five.
So a comparison that stops at twelve months compares two bidders on the component that disappears and ignores the component that compounds. It routinely ranks them in the wrong order, and the reversal is not marginal. A bidder who is a fifth cheaper in year one and applies a higher renewal uplift on a larger licence base overtakes on total cost somewhere between year three and year four, which is exactly the point at which switching has become unthinkable.
The other reason year one misleads is that it is the only year priced against a known quantity. Your user count, entity count and process count on the day of signature are facts. Every subsequent year is priced against what those numbers become, and they only ever move in one direction.
The five compounding lines
Five things grow after go-live, mostly quietly, and each of them has a different mechanism.
Renewal escalation
Subscription contracts contain an uplift. Sometimes it is stated as a fixed percentage, sometimes as an index, sometimes as "the vendor's then-current list price", which is not a number at all. Frequently the first-year figure carries a new-business discount that expires without anyone in your organisation noticing, so what looks like a modest annual rise is actually a rise plus a discount unwinding.
The arithmetic is unforgiving. A 7 per cent annual uplift takes the licence line to about 1.31 times its original value by year five. A 10 per cent uplift takes it to about 1.46. Neither figure looks unreasonable in a clause, and neither is in most business cases.
The negotiation point is now, not later. Cap the uplift for the full initial term in writing. Ask for the mechanism, not the number: an index-linked clause and a percentage clause behave very differently over five years, and a "then-current list price" clause is an open cheque with a signature already on it.
User-count creep
You budgeted the licence against a user list drawn from the org chart during selection. You renew against the users the design actually created.
The mechanism is not opportunism, it is design. During configuration somebody decides that the storekeeper needs to see the purchase order, that the site engineer should raise the material request himself rather than emailing it, that the two branch accountants need their own logins rather than sharing one. Every one of those decisions is correct. Each one adds a user. A design decision taken in month three arrives as an invoice in month fourteen, and by then nobody connects the two events.
Compound this with the escalation and the effect is larger than either alone. An 8 per cent annual growth in users alongside a 7 per cent uplift produces a licence line at year five roughly 1.78 times the year-one figure. Two individually unobjectionable numbers nearly double a cost line.
Three things reduce it. Model users from the process design rather than the headcount — walk each process and count who touches a record. Ask, before signature, what a read-only or occasional user costs, because products differ enormously here and some have no such concept at all. And secure the right to reduce the user count at renewal, not merely to increase it; most contracts are silent on reduction, and silence favours the party that issues the invoice.
The marginal entity
Every group in the UAE acquires entities. A new free zone company for a new trade licence activity, a branch in Abu Dhabi, an offshore holding entity somebody's tax adviser recommended, a joint venture. Ask any group what they will look like in five years and the honest answer contains at least one legal entity that does not exist today.
The cost of adding one is rarely a licence question and almost always a services question: a chart of accounts, a tax configuration, document sequences, an approval matrix, intercompany relationships with everything already there, and a consolidation that has to keep balancing. On some products, multi-company capability sits on a higher tier entirely, so entity number two also re-prices every existing user.
Get the price of entity number two into the contract before you sign, when you have leverage, and read what actually changes between free zone and mainland structures before you assume they are the same configuration exercise.
The upgrade
Whatever the deployment model, the software you buy in 2026 is not the software you run in 2030. On subscription products the version moves under you on the vendor's calendar; on licensed products you move it yourself or you sit on an unsupported release. Either way the platform change is not the cost — the cost is everything you built on top of it.
The size of that bill is set on the day somebody decides to close a gap with code rather than configuration. Every custom module, every bespoke report, every integration written against a version-specific interface has to be re-tested at each version change, and the re-testing is yours regardless of who does the technical migration. The document that prices your year-three upgrade is the customisation register you keep in year one, which is why the split between configuration and custom code is the highest-leverage cost decision anyone makes on the project.
Put a number in the model. If you have no basis for one, put the cost of a small project in years three and five and label it honestly as an estimate, because a model that shows zero in upgrade years is not conservative — it is wrong. The arithmetic of when an upgrade is worth doing at all is the framework for judging it when the time comes.
The support contract
Post-go-live support is almost always priced as a percentage of licence, which is administratively convenient and structurally incorrect.
Support effort scales with what was built, not with how many people use it. A lightly configured system with forty users and no custom code generates a fraction of the tickets of a heavily customised one with the same forty users, three integrations and a bespoke document pack. The percentage cannot see the difference, so one buyer subsidises the other, and it is not usually the simple one who benefits.
More importantly, ask what the percentage excludes. The list is longer than buyers expect and usually contains: configuration changes, new reports, adding users or entities, anything arising from a version change, and anything the partner classifies as training rather than defect. If those are out of scope, your real annual figure is the contract plus an enhancement budget, and the enhancement budget is the one that grows.
The line nobody sells you
There is a sixth cost, larger than several of the above, and no supplier will put it in a proposal because it is not theirs to sell.
After go-live somebody inside your company owns the system. Not the department — the person. They approve configuration changes, they hold the master data standards, they answer the question about why the report differs from last month, they decide which change requests are worth paying for, and they are the reason the system still resembles its design in year three.
If you appoint that person, they are a salary or a real fraction of one, and it belongs in the model. If you do not, you pay the same cost in a worse currency. Systems without an owner do not fail loudly. They drift: master data degrades, workarounds harden into procedure, reports stop being trusted, and three years later somebody concludes the ERP was a bad choice when what actually happened is that nobody was accountable for it.
Training belongs in the same paragraph. It is treated as a project line and it is an annual one, because staff turn over. Every departure removes trained knowledge and every arrival adds an untrained user. A company with reasonable turnover retrains a meaningful share of its user base every year whether or not it has budgeted to.
The model on one page
You do not need a consultant for this and you do not need a week. You need one table, five columns, and the discipline to make every bidder fill in the same one.
| Line | Year 1 | Years 2 to 5 | What makes it move | Where to fix it |
|---|---|---|---|---|
| Licence or subscription | Known exactly | Compounds with uplift and user growth | Renewal clause, design decisions about who gets a login | Cap the uplift; price a read-only user; secure the right to reduce |
| Implementation services | The largest line | Should approach zero | Scope creep, decisions taken late | Acceptance criteria written as tests |
| Data migration | Under-scoped almost always | Recurs only if you acquire | The state of your master data | Profile before you price |
| Integrations | Per interface | Maintenance plus rework at each version change | Who owns the far end | Name the far-end owner and their rate now |
| Support contract | Part-year | Rises with the licence it is a percentage of | What was built, not who uses it | Get the exclusions list in writing |
| Enhancements and change requests | Late in the project | Every year, forever | Anything support excludes | Fix the day rate and its validity period |
| Upgrade | None | A project in year three, another around year five | Volume of custom code | Keep a customisation register from week one |
| Hosting and environments | Sometimes quoted | Grows with data volume and entity count | Database size, number of environments | Confirm test and development are included and for how long |
| Third-party components | Small, itemised badly | Renew separately, on their authors' calendars | Store apps, accredited e-invoicing provider, BI tool, payment gateway | List every one with its own renewal date |
| Internal owner and training | Absent from every quote | Every year | Turnover, system complexity | Name the person before go-live |
Two rules make the table honest. Every bidder fills in the same one, in writing, with the assumption behind each cell stated. And every cell in the years two to five column carries a direction of travel rather than a repeat of year one, because nothing in that column is flat.
Then test three assumptions and only three. What happens to the total if user count grows by a quarter over five years. What happens if the uplift is applied at the contractual maximum rather than the figure discussed in the room. What happens if you add one entity in year three. If your model survives those three, it is defensible in front of a board. If it collapses under any one of them, you have found the term to negotiate before signature rather than the surprise to explain afterwards.
The comparison this produces
Once four bidders have filled in the same table, the ranking usually changes, and it changes for reasons that were invisible in the first-year total.
A product with a higher licence and a genuinely low customisation requirement can beat a cheaper one that needs code to fit, because the code is paid for at build, again at every version change, and again every time a support person has to understand it before answering a question. A partner with a higher day rate and a written gap list can beat a cheaper one with no gap list, because the missing gap list is not a saving — it is an unpriced change order with a later date on it. And a bidder who will commit to a capped uplift and a fixed price for entity number two has removed two of your three largest uncertainties, which is worth real money in a model.
None of this requires you to predict the future accurately. It requires you to make everyone predict the same future, on the same page, with their assumptions written down. That single act does more for cost control than any negotiation on the licence rate, and it costs a fortnight of somebody's attention.
If you want a structured starting point for the sizing conversation before you build the model, the ERP cost estimator works through the same drivers. And if you would rather have the five-year assumptions checked by people who have seen what happens when they are wrong, that written diagnosis is where an ERP implementation starts with us — before anything is quoted.