How to calculate the five-year cost of an ERP system: the build fee is just the start

“This one quotes NT$1,500,000, that one quotes NT$1,200,000. That's NT$300,000 apart. Obviously we go with the cheaper one.” Eight out of ten owners compare ERP quotations this way: lay the quotes side by side and look at the bottom line. Three years later they run the numbers again and find that the NT$300,000 was eaten long ago by annual maintenance fees, add-on features, and the hours staff spend on the system. Sometimes they end up paying more. They compared the build fee carefully. The four years after it never entered the math.

I'm Johnny Yang, founder of Brightstream Technology in Taiwan. In 7 years of running the company we've done 252+ projects across 32+ industries, and we deliver more than NT$20,000,000 in systems a year. When I review a quotation for an owner, the first thing I do is never to cut the build fee. It's to spread it over five years.

The short answer: break the five-year cost of an ERP into five layers. Layer one is the build fee. Layer two is the fixed money every year: maintenance, licenses or subscriptions, hosting. Layer three is your own staff's time, both during implementation and after go-live. Layer four is change requests and growth: new features, regulatory changes, add-on purchases as headcount grows. Layer five is the most expensive and the one almost nobody counts: the cost of a system nobody uses, and the exit cost when you want to replace it five years later. The build fee is only one layer. When you compare quotations, ask each vendor to write out the terms for every layer over five years, convert them into one total, and compare that. Not just year one.

Why comparing only the build fee means regret five years later

First, a word in defense of the instinct. The build fee is the biggest payment in year one, and it's the only number that is written out clearly enough to compare. Everything else is either “billed separately from year two” or not written at all. Comparing the numbers you can see is reasonable.

And owners budget one year at a time. Finding NT$1,500,000 this year already hurts. Five years out feels far away. Get through this year first.

But the real problem is that an ERP is not a machine you buy once. It's something that keeps costing money. The build fee decides whether you go live. The next four years of money decide whether you keep paying after you do. A quotation with a cheap build fee, maintenance that rises with headcount, and add-on features billed separately can easily cost more over five years than one with a slightly higher build fee and fixed terms.

The most common pattern I see: the owner picks the vendor with the lowest build fee. From year two on, every month is a negotiation with the vendor over “does this count as maintenance.” Every small change is a new quotation. The money goes out in small pieces, nobody adds it up, and all anyone feels is that this system never stops costing money.

ERP total cost of ownership, in five layers

The table below is the five-layer framework I use on site. The third column matters most: it tells you whether that layer's money usually shows up on a quotation.

Layer one, everyone calculates. I went through a quotation line by line in Can't read your ERP quotation?. Layer two, everyone knows exists, but often only looks at year one. What actually blows up the total is layers three to five, because they are not on any quotation at all.

Layer two: annual fixed costs, and what they rise with

With annual fixed costs, the point is not the amount. It's what the amount rises with. Priced per user: grow from 60 to 100 people and the fee grows with you. Priced per module: every new module is another line. “Adjusted to market rates”: the vendor decides how much it goes up.

This is the layer where subscription and one-time purchase differ most. I worked out which one comes out cheaper over five years in Subscription ERP or a custom-built purchase. Just one reminder here: ask the vendor, “If our headcount doubles, how much does the annual fixed cost change?” The answer tells you more than the unit price.

Layer three: staff time is money too

During implementation, every department has to send people to requirements interviews, process reviews, testing, and data cleanup. Their normal work doesn't shrink. They squeeze the time out. After go-live, the company also needs one person as the system contact: handling accounts, answering colleagues' questions, dealing with the vendor.

This time never shows up on an invoice, but it is a real cost. The longer the implementation and the more the requirements change, the bigger this layer gets.

Layer four: change requests will come, so agree on pricing first

The company changes, so the system has to change with it. A new location, a new pricing model, a format change required by regulation, a new report the owner wants to see. None of these are things you can foresee at implementation.

So the question in layer four is not “will there be change requests” but “how are they priced.” Requoting and renegotiating every time may not cost much per change, but it eats a lot of your time in negotiation. It also makes you start hesitating about whether to change anything. Eventually you stop changing it and let staff patch the gaps in Excel. The cost of not changing ends up in layer five.

Running the numbers for an 80-person company (hypothetical)

A framework alone isn't concrete enough, so let's work through a hypothetical company. Every number below is an assumption. The goal is to show you the structure. Swap in your own numbers.

Say an 80-person company has a build fee of NT$1,500,000. After go-live, maintenance is NT$20,000 a month, which is NT$1,200,000 over five years. Implementation takes 4 months, with 3 key users each spending 1 day a week on the project. At an assumed NT$50,000 a month in personnel cost per person, that's about NT$120,000. After go-live, 1 employee doubles as the system contact. Assume it takes 10% of their time: about NT$300,000 over five years. From year two, there are some new features or adjustments every year. Assume NT$200,000 a year: NT$800,000 over four years.

In this scenario, the build fee is less than 40% of the five-year total. In other words, the NT$300,000 you negotiated off the build fee comes right back as soon as annual fixed costs or change requests run a little higher.

This table doesn't include layer five yet. Not because layer five doesn't matter, but because its range is too wide: if the system gets used, it's close to zero. If it doesn't, it can exceed the first four layers combined.

The most expensive cost is not on any quotation

Layer five needs its own section, because it's where I've seen the most companies actually lose money.

We worked with a printing company that, before coming to us, had already spent more than NT$1,000,000 on two ERP systems. Neither got used. That money isn't just the price of the systems. It also includes staff time across two implementations, and all the rework during the years when nobody used the system and everyone kept working in Excel and LINE. The third system was built around their own process, and adoption went from under 20% to over 90%. I wrote up the whole story in Spent more than NT$1,000,000 on two ERPs nobody used.

The cost of non-adoption usually looks like this: the system is live, but only accounting uses it. Sales and the warehouse still keep their own Excel files. So the company is paying maintenance on the system and also paying for someone's time every day reconciling data between the two. That's the double cost, and it keeps running until someone decides to deal with it.

The other one is exit cost. Five years from now, if you want to switch systems, whether you can get your data out, in what format, and who holds the source code and accounts all decide how much the switch costs. Agreeing on this at signing costs almost nothing. Negotiating it when you want to leave costs a lot. To see which maintenance contract clauses determine your exit cost, check the 12 items in What to put in a system maintenance contract.

Three quotations side by side: how do you convert them into a five-year total?

Once you know the five layers, the next step is making every vendor answer in the same format. My suggestion: make your own sheet, send it to each vendor, and ask them to fill in these questions in addition to their quotation.

• What does the build fee include, and what doesn't it? Especially who cleans the data, how many trial migrations, how many training sessions.
• What is the annual fixed cost for each of years two through five? Five numbers, not “per contract.” If it changes with headcount or modules, have them calculate it using your projected growth.
• How are small changes after go-live priced? Changes to fields, reports, menus: included in maintenance, or quoted separately each time?
• How are change requests priced? By person-day, by item, or requoted each time? Will the rate change?
• Which of our people, and how much of their time, does implementation need? Few people ask this, but vendors already know the answer.
• When the contract ends, in what format is the data handed over? What happens to the source code and accounts? Is there an extra charge?

When the answers come back, put every vendor's answers into the same five-year sheet, and fill uncertain numbers with the same assumption. Only then are you comparing the same thing.

The process has a side effect: you quickly see which vendors are willing to lay out their terms. The ones who answer clearly and are willing to put it in the contract usually cause fewer problems later. For the ones who keep saying “we'll see when we get there,” estimate that layer with more conservative assumptions.

How to bring the five-year total down

Once you know where the money goes, you know where to save. The decisions below work far better than haggling over the build fee.

First, cut requirements before you talk price. The sentence I say to owners most often is “Don't build this.” Of ten things you want to automate, roughly two are worth building into a system, five are fine with off-the-shelf tools, and three shouldn't be touched at all. Every item you drop saves not just build fee but four more years of maintenance and changes.

Second, write the scope as a written feature list, then quote a fixed price. The clearer the scope, the fewer change requests in layer four. Brightstream writes the scope as a written feature list first, then quotes a fixed price. No signing first and raising the price later. Payment is in stages, and each stage is billed only after the agreed result is running.

Third, ask exactly what the annual fixed cost rises with. Headcount, modules, or whatever the vendor says. Brightstream as an example: maintenance starts at NT$20,000 a month, quoted by system size, and during the maintenance period, UI/UX, field, and report display changes within the written feature list are not charged extra. I'm not saying you have to pick this pricing model. I'm saying you need to know to ask.

Fourth, treat adoption as cost control. The closer the system fits how staff already work, the smaller layer five gets. That's why we build company systems inside LINE: staff don't have to learn new software, they can use it on day one, and you lose the training time and the rework of going back to Excel.

Fifth, agree on exit terms at signing. Data export format, access to source code, accounts registered in your name. These cost almost nothing at signing and can save you a lot five years later.

Frequently asked questions

How many years should ERP total cost of ownership (TCO) cover?

I recommend at least five. Three is too short: many cost differences haven't shown up yet, like add-ons from headcount growth or the first major change. More than seven is too long: the company and the technology both change, and assumptions get less reliable. Five years covers one full cycle of growth and adjustment.

Does staff time spent on ERP implementation really count as cost?

Yes. During implementation these people attend meetings, test, and clean up data, and their regular work doesn't shrink. Usually it means overtime or pushing other things back. Leave it out and you underestimate the burden of implementation, and you'll think a delayed implementation is just a schedule problem, not a cost problem.

Is a subscription ERP always more expensive over five years?

Not necessarily. A subscription has a lighter upfront burden and suits companies whose processes are close to standard and whose headcount growth is predictable. A one-time purchase or custom-built system costs more upfront, but annual fixed costs are easier to control. The key is to convert both options into a five-year total, with your headcount growth and change request assumptions built in, and then compare.

Is there a way to estimate change request costs before signing?

The most effective way is to write the scope as a written feature list, quote anything outside the list separately, and spell out how change requests are priced in the contract. Also, ask the vendor what changes similar-sized projects usually needed in their first year after go-live. How they answer tells you whether they've actually thought about it.

Look at ERP price over five years

In one sentence: the build fee decides whether you go live. The next five years of money decide whether the system is worth it. Only after laying out all five layers do you know whether you're comparing the same thing.

If you have a few ERP quotations in hand and want to convert them into five-year totals before comparing, start with How ERP implementation works to see how scope and pricing terms should be settled up front.