Erpification / Guides / The real cost of an ERP
The real cost of an ERP, line by line
An ERP has three bills and your supplier only sends one. The quoted bill is the predictable
one. The other two are paid out of your payroll and out of work that does not happen, and neither appears in the
proposal you are comparing.
Guide · updated 2026-10-17
The cost of an ERP is three budgets, not one. The quoted budget is licence plus implementation
services: written down, negotiable, and the most predictable of the three. The payroll budget is
your own people's hours and whatever covers the rest of their jobs, invisible because it is already inside payroll
and therefore never lands as project cost. The foregone budget is output that does not happen:
the close that takes two weeks instead of five days, the projects the controller is not doing while sitting in
workshops. Price all three, then compare quotes.
Then the part that decides the size of budget two, which the published cost guides do not price at all.
The payroll budget is not set by the size of your company. It is set by how fast you decide and how clean
your data is. Both are free to fix before you sign. Both cost a consultant day rate to fix after user
acceptance testing has started.
Three budgets, one invoice
Where does the money for an ERP actually leave the business?
Budget one → quoted
Licence and services
Subscription or licence, implementation services, migration, integrations, training delivery. It arrives as a
document, which is why it gets all the attention. For a smaller company it is also the smallest and steadiest of
the three.
Budget two → payroll
Your hours, and their backfill
Already funded, so nobody counts it. Every hour a process owner spends on the project is an hour of their job
that somebody covers, somebody works late for, or nobody does. Those are three different prices, not one.
Budget three → foregone
Output that does not happen
Slower months, a longer close, deferred work. It never appears as an invoice, which is exactly why it is rarely
managed. It shrinks when the project is short and decisive, and grows when it drifts.
Why this split mattersTwo quotes with the same total can carry very different budget twos.
The difference is in what the supplier has moved into your column, which is visible only if you have priced your
own column first.
The internal-hours line, built before the quote
The cost pages that rank for this question list “internal staff time” as a soft cost: one bullet, no
arithmetic. Here is the arithmetic. Do it before you request a single quote, so you have a number of your own to
compare against.
- List the roles the project actually consumes. Executive sponsor, internal project manager,
finance owner, operations owner, IT, and one named owner per master-data file: customers, items, suppliers,
pricing, bills of material.
- Assign a percentage allocation per phase, not per project. Design and user acceptance testing
consume a process owner heavily; configuration barely touches them. One average across the whole project hides
the weeks that break people.
- Multiply allocation by the weeks in that phase, and by a loaded hourly rate. Loaded means
salary plus your own employer burden: statutory contributions, benefits, paid leave. Take that figure from your
own payroll reports, per entity, rather than from any published uplift percentage. The published ones are not
so much wrong as not yours, and this is the one input in the whole budget you can get exactly right.
- Record a backfill decision per role, in writing: cover it, pay overtime, or let it slip. All
three are costs. Only the first one looks like one.
- Total it and put it beside the quote. That comparison is the point of the exercise.
Then make the supplier state the allocation they need, per role, per phase, in the statement of
work, and compare it with the arithmetic you have just done. That one request does three things. A bidder
whose figure sits far below yours has either implemented this in a business much simpler than yours, or is
planning to do your share of the work themselves at a day rate. A bidder who will not put a figure in writing has
answered a different question, which is who carries the schedule risk. And a figure that is in the document is one
you can hold them to in month four, when the project is slipping and the reason given is that your people were
not available.
The arithmetic nobody writes down: a process owner at thirty per cent on the project is doing one
hundred and thirty per cent of a job unless somebody covers the rest. Unfunded, that gap is paid in
overtime, in errors, or in the foregone budget.
| Role | Why the hours cannot be delegated | What the backfill decision costs |
|---|
| Executive sponsor | Only this person can settle a cross-department disagreement about process, which is what most “technical” delays actually are | Rarely backfilled. The cost lands in the foregone budget, as the decisions this person normally makes elsewhere |
| Internal project manager | Holds the decision log, the testing plan and the supplier to the statement of work. The supplier's project manager runs their side, not yours | Either a seconded internal role plus a backfill, or a contract hire. Do not leave this role as somebody's evening work |
| Finance owner | Owns the chart of accounts, the opening balances and the reconciliations nobody else can sign | Peaks exactly at month-end close. Either close support, or an accepted slower close for the duration |
| Operations owner | Knows what actually happens on the floor, as opposed to what the written procedure says | Usually overtime, because daily operations cannot pause. Budget it as overtime rather than discovering it as attrition |
| Master-data owner, per file | Only the owner can decide which of two near-identical customer records is the real one | The most commonly unfunded line on the project. See the diagnostic below before accepting a migration estimate |
| IT | Access, networks, devices, the interfaces to whatever you are keeping | Normal work stops for the duration. Name what is being deferred so it is a decision rather than a surprise |
Whose line is it
One rule sorts almost every task on an ERP project, and it also tells you how to read a cheap quote.
Anything that requires knowing how your business actually works is yours. Anything that requires product
knowledge is theirs.
| Yours, because it needs your knowledge | Theirs, because it needs product knowledge |
|---|
| Cleansing and deduplicating your data | Mapping, load scripts, reconciliation tooling |
| Deciding the chart of accounts | Building and validating it in the system |
| Writing the new procedure your staff will follow | Configuring the system to support it |
| Acceptance testing against your own transactions | Defect fixes and integration code |
| Training your own people, after their trainer trains yours | Product training and the upgrade path |
A quote that looks unusually cheap has usually moved a row from their column to yours. Compare
quotes by what they moved, not by the total. The decisions in the left column are permanent in a way the right
column is not, which is the argument of which chart of accounts
changes are free and which are never reversible.
One decision, four prices
Scope creep is blamed on the integrator. The actual cost driver is usually how long your own side takes to decide,
because the same decision carries a different price at each stage.
Deferring a decision is legitimate. Deferring it silently is not: it reappears during testing, when it is dearest.
Write it on the phase-two list instead, with a price and a date.
Reading the statement of work
Nobody teaches quote-reading, and the quote is the only document in the process you can audit before spending
anything. Each item below is checkable in the file you were sent.
- Fixed fee, or time and materials with a cap. If it is fixed, find the clause that says what
makes it not fixed.
- How many user acceptance testing cycles are included, and who pays for the third one.
- Whether an “hour bank” is drawn down by your questions or only by their build
work. This single sentence decides whether you can afford to ask anything.
- The hypercare end date, and the day rate that applies the morning after. A period with a date
and no exit conditions is a calendar entry, which is the argument of
hypercare ending on a condition rather than a date.
- Travel and per diem, and whether remote work is priced differently.
- Who owns and maintains the data-mapping document, during the project and after it.
- The change-order unit price, and who on your side may approve one. Without the second half,
anybody in a workshop can commit your budget.
- The assumption clause. It usually says you will supply cleansed data in their template by a
stated date. That one sentence transfers data cleansing, and its schedule risk, to you.
The data-readiness diagnostic
Run these five before you accept a migration estimate, because the estimate is priced on the assumption that all
five answers are yes. Every “no” is weeks of your own staff's time, in the evenings, not the
integrator's.
- Can you produce one customer list with no duplicates?
- Does every active item have one unit of measure and one price?
- Do open receivables and the general ledger agree today?
- Is there one chart of accounts, or one per entity?
- Can you name the owner of each master-data file?
Three or more noes and the cleansing is a project of its own, best started before you sign anything, because it is
the one piece of work that is cheaper early and useful whatever system you end up buying.
The migration checklist sets out the loading order and the
reconciliations that have to tie, which is what the cleansing is ultimately for.
Every gap found in workshops, four ways
Design workshops produce gaps: the system does not do it the way you do it. There are four responses and the quote
prices only one of them.
| Response | Cost now | Cost at every upgrade | Who fixes it at 7pm on a Friday | Effect on your next migration |
|---|
| Configure | Inside the quoted work, if raised before configuration closes | Carried by the vendor's release testing | Your own administrator, or the vendor's support line | Portable: configuration is documented and re-creatable |
| Customise | Change order at the day rate, plus its own testing | Regression testing of the customisation, every release, forever | Only the developer who wrote it, if still reachable | The part nobody can move, and the reason some systems are never replaced |
| Change the process | No build cost. Training, documentation and internal argument instead | None | Your supervisor, with the written procedure in hand | Easiest to carry, because you are now standard |
| Live with it | Nothing, visibly. A manual workaround somebody performs | None in the system; a recurring cost in hours | Whoever happens to know the workaround | Invisible until that person leaves, then urgent |
The column that decides it in practice is the fourth, and it appears in no vendor comparison. Ask it out loud in
the workshop. It is also what a scripted demo is for: grading each step as native, configured or promised rather
than scoring it out of five, as in running the demo on your own
transactions.
Parallel run, decommissioning, timing
Three lines missing from the published cost guides, and each of them is decided by a date you are choosing
anyway.
The parallel run, decided rather than discovered
Run finance parallel for exactly one month-end close, and price that close: both ledgers live, double entry of the
postings that matter, a reconciliation of the two, and overtime for the close team. Do not run operations parallel
at all. Double entry on daily transaction volume is abandoned quietly by the people doing it, and an abandoned
parallel run leaves you with two systems that are both wrong and no way to tell which. Decide each separately,
write down which one you chose, and budget both systems' licences for the overlap months. The
overlap is also where the freeze log and the replay rule in the
cutover runbook earn their place.
Decommissioning, before you set a go-live date
Pull the renewal date and the notice window out of every contract you are replacing, and read the notice clause
itself rather than assuming what it says. That window, not your project plan, is what constrains the go-live date,
and it is the contract term nobody checks until the invoice has already arrived. Ask each vendor what a full data
export costs, in money and in lead time, and get that in writing while you are still a paying customer. Then
decide where a read-only archive lives for your statutory retention period, and who can read it. A go-live
four weeks after a silent auto-renewal costs a full extra year of a system nobody opens.
Go-live timing as a priced choice
Every page says avoid your busy season. True, and useless, because most companies do not have a quiet month.
The usable test is narrower. The first month-end close in the new system is the expensive one, so go live
in the month whose close you could afford to deliver late. That rules out fiscal year end, an audit
period, a covenant or lender reporting date and your renewal or billing campaign, for one reason instead of four,
and it tells you what to buy when no such month exists: close support for a single cycle, bought deliberately and
in advance. It is the cheapest line on this page, and it displaces the overtime, the error correction and the
longer stabilisation that the quote silently assumes you will absorb. If the calendar leaves no window at all,
that is information about the plan, not about the calendar.
Phase two in writing, and an owner for year one
Two habits move money out of the expensive columns and into the cheap ones.
Write the phase-two list on day one. Record what is deliberately deferred, each item with a price
and a date: the three reports, the second integration, the nice-to-haves. An unwritten phase two does not
disappear. It reappears as change orders during testing, when the price is at its highest. A written one is a
budget instrument: it tells everyone that “not now” is a decision that has already been taken.
Name an internal system owner with real allocated time for the first year after go-live, and have
them write your procedures in your own words while the consultants are still on site. Skip this and the same
knowledge comes back as support tickets at a day rate, which is the one ongoing line that grows in year two instead
of shrinking. This is also the difference between the outcomes traced in
why implementations fail, stage by stage.
§
The template
One page, three columns, filled in with your own figures. The totals are the comparison the proposal cannot give
you. Keep the three columns separate: adding them makes a scary number, while separating them makes a manageable
one.
| Line | Quoted | Payroll | Foregone |
|---|
| Licence or subscription | Year one, plus the renewal uplift cap you negotiated, plus any user true-up you can foresee | none | none |
| Implementation services | Per the statement of work, with the exclusions listed | none | none |
| Data migration, load and reconcile | Theirs: mapping, scripts, reconciliation | Your reviewers at each load | none |
| Data cleansing | none | Hours per master-data file, by owner | Whatever those owners are not doing |
| Integrations | Priced per endpoint, not as one line | Your testing per endpoint | none |
| Training | Their delivery, by cohort | Your own documentation and internal sessions | Hours away from the floor |
| Internal project hours | none | By role, by phase, at a loaded rate | none |
| Backfill and overtime | none | One decision per role, priced | The roles you chose to let slip |
| Parallel-run overlap | Both systems' licences for the overlap months | Double entry and the close reconciliation | A slower close while it runs |
| Decommissioning and archive | Export fees, archive hosting | The notice letters and the retention decision | A full extra year if a renewal date is missed |
| Contingency | Held by you, not by the supplier, and released against named risks | none | none |
| Year two: optimisation and training | The written phase-two list, priced | The internal system owner's allocated time | none |
Most cost pages are built from numbers that cannot be traced to a sample, a year or a currency. Where others cite
a figure, this page describes the mechanism, because the mechanism is what you can act on. Four worth naming,
since you will meet them in the next proposal you read.
- “Between fifty-five and seventy-five per cent of ERP projects fail”, attributed to
Gartner, and its hardened form at three quarters. Follow the citations yourself: they arrive at other suppliers'
pages rather than at a publication with a sample, a year and a definition of failure. Several of the pages
carrying it also report, further down the same page, that most organisations call their own implementation a
success, which should have ended the figure's career.
- “Budget one to three per cent of annual revenue.” It appears as one to two, two to
three, and “about three”, sometimes from the same publisher, with no dataset anywhere.
- “Implementation runs one to three times the software fee.” A rule of thumb
presented as a finding. The only part worth keeping is the direction, that services cost more than licence, and
you do not need the rule to know it: your own quote states both figures on the same page. Read them there and
discard the multiple.
- Annual maintenance at a fixed percentage of the software investment. Meaningful for
on-premises licence maintenance, meaningless for a subscription where support is already inside the fee. The
pages apply it to both.
The same applies to overrun surveys cited without their year or their sample. If a number matters to your
decision, ask what was measured, when, in which currency, and across how many companies. Your own arithmetic beats
all of them, because it is about your roles, your data and your calendar.