The Costs ERP Vendors Leave Out of the Quote

Every ERP proposal has a headline number, and it is almost never the number you end up paying. That's not usually deliberate deception — sales teams quote the parts of the deal they control, which is licensing and sometimes a standard implementation package, and leave the parts that depend on your specific environment for "discovery" later. Here's what tends to be missing, and how to price it before it becomes a surprise change order.

Customization and configuration beyond the standard build

Every vendor demo shows the out-of-the-box workflow. Almost no company runs the out-of-the-box workflow unchanged — approval hierarchies, custom fields, industry-specific document formats, and one-off reports for a regulator or a major customer all cost money to build, and the standard implementation package usually assumes a modest, bounded amount of this work. Ask for the number of configuration hours included and the hourly rate beyond that, not just "customization is included."

Data migration and cleanup

Migrating data from a legacy system is quoted as a line item; cleaning the data before it migrates almost never is. If your customer master has 15 years of duplicate records, your item master has inconsistent units of measure, or nobody has audited your chart of accounts since 2011, that cleanup work has to happen somewhere in the project — and if it's not scoped, it becomes unplanned hours billed at whatever rate the implementation partner charges for change requests.

Integration to systems the vendor doesn't sell

ERP rarely runs alone. Integrations to a CRM, an e-commerce platform, a warehouse management or shop-floor system, a payroll provider, or a banking portal are usually quoted separately — if they're quoted at all in the initial proposal — because the vendor doesn't control the other system's API, documentation quality, or willingness to cooperate. Get a specific integration list with a cost against each one, and ask what happens to the price if a "standard" integration turns out to need custom middleware.

Internal staff time

This is the cost that never appears on any vendor invoice because the vendor doesn't pay it — you do, in the form of your own employees' time. A realistic ERP implementation pulls key staff (finance, operations, IT) partly or fully off their regular jobs for months: testing, data validation, process documentation, and user acceptance sign-off all take real hours from people who still have a day job. Budget for backfill, overtime, or simply reduced output from those departments during the project — it's a genuine cost even though no one invoices you for it directly.

The second year of "one-time" training

As covered in our TCO calculator guide on five-year modeling, training gets quoted once but needed continuously. Every new hire and every internal transfer into a system-touching role needs training, and most vendors don't include an ongoing training allowance in their standard package.

Upgrade and version-migration costs

For on-premises systems, "upgrade included in maintenance" often means the software media is included — the labor to test and re-implement customizations against the new version is not. For cloud/SaaS systems, forced version upgrades are usually included, but any custom integrations you built have to be re-validated against the new version, and that validation work is on you.

A checklist to take into vendor negotiations

• Configuration hours included, and the rate for hours beyond that
• Data cleanup — is it scoped as a project task or assumed to be "your data is ready"?
• A named list of every integration, priced individually, not bundled as "standard integrations"
• An estimate of internal staff hours required per department, so you can plan backfill
• An ongoing (not one-time) training line, sized to your expected annual hiring/turnover
• What upgrade testing costs for your specific customizations, in writing

Get written numbers against every item on that list before you compare vendors on price. Two proposals that look $60,000 apart on the headline licence figure can flip entirely once you price in what each one leaves out. Model the full picture — licence, implementation, training, and multi-year maintenance — with the ERP TCO calculator, and use it as the basis for an apples-to-apples comparison across every finalist.

How to get these numbers before you're in a negotiation, not during one

The checklist in this guide only works if you ask for numbers early enough to act on them. Send a written request to every finalist vendor before the final proposal stage, asking specifically for a itemized breakdown against each category above — not "what's included," which invites a vague answer, but a dollar figure or an hourly rate against configuration, data cleanup, each named integration, and post-go-live support. Vendors who answer promptly and specifically are telling you something about how they run projects; vendors who deflect to "we'll figure that out in discovery" are telling you something too.

A real example of what gets missed

A 140-person services firm signed an ERP contract with a $210,000 all-in quote that the sales team described as covering "implementation and standard integrations." Eight months later, the actual spend had reached $298,000 — a 42% overrun. The gap traced to three items that were technically true statements at signing but incomplete ones: "standard integrations" turned out not to include the firm's specific payroll provider, which needed $34,000 of custom middleware; the data migration scope assumed clean source data, and three weeks of unplanned cleanup work cost another $19,000; and the "included training" covered only the initial rollout, with a second training round needed after a January hiring wave that added $12,000 more. None of these were dishonest on the vendor's part — they were gaps in what the buyer asked to have itemized before signing.

Turning the checklist into contract language

A checklist only protects you if its answers end up in the signed contract, not just in a sales conversation. Where possible, get specific numbers written into the statement of work rather than left as verbal assurances: a capped or fixed-fee implementation scope with a defined change-order process for anything beyond it, a named list of integrations with individual pricing, and an explicit ongoing training line item rather than an assumption that one training session covers the system's lifetime. A vendor confident in their own scoping will generally agree to this without much friction; resistance to putting numbers in writing is itself useful information about how the rest of the project is likely to go.

Frequently asked questions

Is it reasonable to ask a vendor for itemized pricing before a formal RFP?

Yes, and most established vendors expect it from a serious buyer. A vendor unwilling to break out configuration, integration, and data-migration pricing before a formal process is either not used to selling to sophisticated buyers or is intentionally keeping the full picture vague until you're emotionally committed to their platform — neither is a great sign.

Who should own the data-cleanup work — us or the implementation partner?

Usually a mix: the implementation partner can identify what needs cleaning and often run bulk-correction scripts, but decisions about which records are authoritative, which duplicates to merge, and which legacy data simply isn't worth migrating require institutional knowledge only your own staff has. Budget internal time for this even if the partner is doing the technical work.

How do we know if an integration is "standard" or will need custom middleware?

Ask the vendor for a reference customer using the exact same integration (same third-party system, ideally same version) and, where possible, a technical scoping call with that integration's specific API documentation in hand before signing — "we've integrated with systems like that before" is a much weaker signal than "we have three live customers on this exact integration."