How much does an ERP system cost? There is no single universal figure. A reliable answer requires a breakdown of scope, risk and responsibility. Total cost commonly includes licences or subscriptions, implementation, data, integrations, customisations, training, stabilisation and maintenance. Management can obtain a comparable estimate only when suppliers work from the same business requirements and assumptions.
For an initial view, it is useful to separate software cost from the cost of changing how work is done. ERP may be a standardised product, but its use reaches sales, purchasing, production, warehousing, finance and reporting processes. For that reason, the cost of ERP implementation is not only a technology procurement question.
An ERP proposal can look simple until its items are separated. The purpose of separation is not more administration. It is to reveal costs, assumptions and areas of responsibility.
This item may cover the right to use the software, user roles, modules, cloud infrastructure or on-premise use, vendor support and upgrades. The model depends on the product and contract.
When comparing proposals, check:
A lower initial subscription does not by itself indicate a lower total cost. The same applies to a one-time licence. Review the contracted model over the period relevant to management, with assumptions stated clearly.
Implementation covers the work required to move from a selected product to a usable business system. Typical activities include process analysis, project planning, configuration, workshops, testing, management of open issues and go-live preparation.
For this item, the planned amount of consulting work is not the only important point. More important are the deliverables the team is required to provide, who makes business decisions and how acceptance of each phase is confirmed. A proposal without clear deliverables may show a lower initial amount while leaving a substantial part of the work outside the contracted scope.
Migration is not merely a technical transfer of records. The organisation needs to determine which data to move, who cleans it, how codes are aligned, how quality is checked and who approves the final state.
The scope may include, for example:
The proposal should distinguish data preparation by the client from tools, mapping, loading and control by the implementer. Without that split, misunderstandings about expected work can arise easily.
ERP is often connected to other systems, such as an online shop, payroll system, bank, warehouse equipment, production machinery, business intelligence platform or external portal. Integration cost depends on the business flow, interface availability, data quality, error-handling rules and responsibilities of third parties.
For each integration, request a separate description of:
The name of an integration is not enough for comparison. Two proposals can mean materially different scopes under the same name.
A customisation can be justified when standard processing does not meet a real business need. However, every customisation requires specification, development, testing, documentation and maintenance through upgrades.
Before accepting a customisation, clarify four questions: whether standard functionality exists, whether the process can reasonably align with the standard, what the business consequence is without the customisation and who takes responsibility for maintenance after go-live.
The same applies to reports. A list of report names says too little. Describe the data source, calculation, filters, permissions, refresh frequency and acceptance criterion.
Training covers more than a single system presentation. User roles, real scenarios, work instructions and time to practise affect readiness for work. The proposal should state the target group, training format, materials and responsibility for organising users.
Stabilisation is the period after go-live when reported issues are resolved, operating procedures are confirmed and the transition to regular work is monitored. Maintenance is a separate, longer-term service. Clearly distinguish what belongs to stabilisation, what belongs to regular support and what is charged as additional work.
The most common mistake in comparing ERP proposals is comparing the total amount without checking its contents. A more reliable comparison starts with a shared worksheet that every supplier completes in the same way.
The worksheet can include the following sections.
List the companies, sites, business units, processes and user roles included in the project. Separate the mandatory initial scope from possible later phases. If production belongs in a second phase, that decision needs to be visible in every proposal.
For each process, state the required outcome, key scenarios and known deviations from standard operation. Rather than a requirement such as "support warehouse operations", it is more useful to state goods receipt, reservations, issue, stocktaking, traceability or another specific flow relevant to the organisation.
Request separate amounts or clearly labelled estimates for:
When an item cannot be estimated without further analysis, the supplier can state the assumption and estimation method. This is more useful than an apparently fixed amount without explanation.
Assign an owner to every activity. The client commonly prepares data, makes process decisions, provides key users and accepts deliverables. The supplier configures the system, runs agreed workshops, develops contracted integrations or customisations and documents delivery. Third parties may be responsible for external systems and access.
This division is not a formality. Unclear responsibility for data, decisions or access to another system can change the cost and course of ERP implementation.
Every proposal should contain assumptions, such as key-user availability, source-data quality, access to external systems or timely decisions. It is equally important to state exclusions.
A scope change is not necessarily a problem. The problem occurs when the change is not recognised. Agree a method for recording requests, assessing consequences and obtaining approval before additional work starts.
Acceptance criteria turn a general promise into a verifiable outcome. For a process or integration, they may include successful execution of an agreed scenario, data reconciliation under an established procedure, recording user permissions or delivery of agreed documentation.
Acceptance should not be reduced to a subjective impression. Clear criteria protect both client and supplier from differing interpretations.
Management can build its own total-cost model without turning that model into a universal market figure. The following structure is an example calculation, not an ORKA proposal or a claim about market pricing:
Total estimate = A + B + C + D + E + F + G + H.
This structure reveals two important points. First, comparing only A and B can omit a large part of total cost. Second, H is not an implementer's invoice, but it can be a real budget and organisational cost for management.
An ERP screening is justified before a detailed proposal when the organisation does not yet have a sufficiently clear scope for comparison. This often appears through conflicting requirements, unknown process owners, a large number of connected systems, unclear data quality or an unresolved question of whether to change the process, configure the standard or develop a customisation.
Screening is not an extra layer without a purpose. Its value lies in structuring decisions before contracting work that depends on those decisions. Its outcome can include a priority scope, a list of key processes, an integration overview, initial data assumptions, risks and solution-selection criteria. Read more about this approach in ERP and process screening .
Screening is not necessary in every situation. An organisation with well-documented processes, a clearly defined scope and validated requirements can move directly to a structured proposal. Even then, it is useful to confirm that all proposals follow the same worksheet.
An initial estimate can be useful for budgeting, but it does not replace a confirmed scope. Its reliability depends on the quality of input information. The largest unknowns often lie in data, integrations, local process exceptions and the availability of key users.
For this reason, it is not reasonable to expect the same level of certainty from a supplier for a standard, clearly described process and for an unexplored integration with a third-party system. A better approach is to mark what is fixed, what is estimated, what is excluded and which discovery could change the scope.
For broader context on processes and the role of the system, read the Guide: what is an ERP system . When preparing a budget or comparing proposals, start with a shared worksheet and request the same level of detail from every supplier. If key assumptions are still unknown, the next step is an ERP screening before the final proposal.