An ERP request for proposal (RFP) should make competing vendors answer the same business questions in a comparable format. A long feature list is not enough: most vendors can claim that they support common functions, while the real differences emerge in process fit, configuration effort, integrations, implementation capability, data migration and long-term cost.
This guide explains how to structure an ERP RFP, which requirements to include, what to ask software vendors and implementation partners, and how to score responses. It is designed for finance, operations, IT and procurement teams evaluating a new ERP or replacing a legacy platform.
When should you issue an ERP RFP?
An RFP is useful when several ERP products or implementation providers remain under consideration and the decision affects multiple departments, sites or business processes. It creates a documented basis for comparing proposals and helps expose assumptions before contract negotiation.
A formal RFP may be unnecessary for a smaller, tightly scoped project where the product is already selected and the remaining decision is which partner will deliver it. In that case, a requirements brief and partner request for quotation (RFQ) may be more efficient. Be clear whether you are selecting software, an implementation partner, or both.
What to include in an ERP RFP
1. Company and project context
Give respondents enough information to understand the operating environment and estimate the work realistically. Include industry, business model, number of legal entities, countries, sites, employees, ERP users, transaction volumes, warehouses, product complexity and major pain points.
Describe the current application landscape, including accounting, CRM, ecommerce, warehouse, manufacturing, payroll, reporting and integration tools. Explain why the project is being considered, what outcomes matter and what is explicitly out of scope.
2. Project scope and success criteria
Define the processes, entities, locations and phases included in the project. State the expected deployment model, target timeline, key milestones, decision owners and constraints. Avoid writing a desired go-live date without explaining the operational blackout periods, resource availability and dependencies that affect feasibility.
Set measurable outcomes such as faster financial close, higher inventory accuracy, improved order fulfilment, reduced manual reconciliation or better management reporting. Establish the baseline and who will measure each outcome after go-live.
3. Functional requirements
Organise requirements by business process rather than copying a vendor’s product menu. For each requirement, record a unique ID, business owner, priority, rationale, acceptance evidence and whether standard configuration is acceptable.
| Requirement area | Example questions or scenarios |
|---|---|
| Finance | Can the system handle multi-entity accounting, intercompany, currencies, tax, fixed assets, allocations and close controls? |
| Procurement | Can it support requisitions, approval limits, supplier performance, purchase contracts and three-way matching? |
| Sales and order management | How are pricing, credit checks, partial shipments, returns, backorders and order changes managed? |
| Inventory and warehouse | Can users manage multiple sites, bins, replenishment, lot/serial tracking, cycle counts and warehouse execution? |
| Manufacturing | Does it support BOMs, routings, capacity planning, production orders, subcontracting, scrap and traceability? |
| Projects and services | Can it manage project budgets, time, resource utilisation, billing, service orders and contract commitments? |
| Reporting and analytics | Can business users create governed reports, drill into transactions and reconcile operational and financial measures? |
4. Technical and non-functional requirements
Ask vendors to describe the architecture and operating responsibilities, not just confirm that a feature exists. Cover hosting, identity, role-based access, audit trails, data residency, encryption, backup, recovery, availability, performance, extensibility, APIs, integration patterns, mobile access and data export.
Include expected transaction volumes, peak periods, concurrent users, data retention, recovery time objective (RTO) and recovery point objective (RPO). Ask which requirements are native, configurable, delivered through an extension or dependent on custom development.
5. Data migration and integration scope
Describe source systems, data owners, approximate record volumes, historical data requirements and known data-quality issues. Ask the respondent to explain extraction, transformation, mapping, cleansing, mock migrations, reconciliation and cutover. Require a clear decision on what will be migrated, archived or left behind.
List the systems that must integrate with the ERP, the business events exchanged, the expected frequency, direction of data flow and system of record for each data domain. Ask how failed messages, duplicate events and reconciliation exceptions will be handled. See the ERP integration architecture guide for common integration patterns.
6. Implementation methodology and team
Request the proposed delivery approach, project plan, workstream owners, named team members, customer responsibilities, dependencies, assumptions, testing strategy, training plan, cutover approach and post-go-live support. Ask which consultants will actually deliver the project and how much capacity they have reserved.
Require the partner to explain how it controls scope changes, escalates risks, manages design decisions and obtains business sign-off. A proposal that lists activities but does not identify owners or acceptance criteria is difficult to govern.
7. Commercial response and total cost of ownership
Provide a pricing template so every respondent uses the same structure. Separate software subscriptions, implementation services, data migration, integrations, customisation, third-party applications, training, travel, support, upgrades and optional services.
Request one-time and recurring costs over a consistent three-to-five-year period. State the assumptions for user counts, entities, sites, transaction volumes, environments, support coverage and annual price increases. Ask vendors to identify exclusions and conditions that could trigger a change request.
ERP RFP questions that reveal meaningful differences
Questions for the software vendor
- Which of our must-have requirements are supported in the quoted edition without custom development?
- Can you demonstrate our three highest-risk business scenarios using realistic sample transactions?
- Which requirements need configuration, an extension, a third-party application or custom code?
- How are upgrades handled when customisations or integrations are present?
- What are the limits or additional costs for entities, users, storage, environments and transaction growth?
- How can we export our data and configuration if we change platforms?
- Which security, audit, backup and recovery capabilities are included in the proposed service?
Questions for the implementation partner
- Who will lead discovery, solution architecture, data migration, integrations and testing?
- How many comparable implementations has the proposed team delivered in our industry and at our scale?
- What deliverables will we receive at the end of discovery and design?
- How many migration rehearsals and reconciliation cycles are included?
- What is excluded from the estimate, and how are scope changes priced and approved?
- What are the cutover, rollback, hypercare and support arrangements?
- Can we speak with customers whose projects had similar complexity, including one where delivery did not go to plan?
Use a weighted ERP evaluation scorecard
Agree the scoring criteria and weights before proposals arrive. The example below is a starting point; adjust it to reflect the organisation’s risk profile and strategic priorities.
| Evaluation category | Illustrative weight | Evidence to score |
|---|---|---|
| Functional fit | 25% | Demonstrated support for prioritised business scenarios |
| Implementation capability | 20% | Named team, relevant delivery evidence, plan and governance |
| Technical fit and integration | 15% | Architecture, security, APIs, performance and recovery |
| Three-to-five-year TCO | 15% | Comparable subscription, services, add-ons and operating costs |
| Data migration and reporting | 10% | Migration method, reconciliation and reporting coverage |
| Support and product roadmap | 10% | Support model, SLAs, release approach and product direction |
| References and delivery risk | 5% | Relevant customer references and credible risk controls |
Use a consistent rating scale, such as 1 (does not meet), 2 (major gaps), 3 (meets with conditions), 4 (strong fit) and 5 (exceeds requirement with evidence). Calculate weighted scores, but do not let a high overall score override a failed mandatory requirement. Record assumptions and unresolved gaps alongside the score.
Make product demonstrations evidence-based
Do not allow every vendor to run a generic scripted presentation. Give shortlisted vendors the same scenarios, sample data and time limits. Ask them to show a transaction from start to finish, including exceptions and approval steps.
Useful scenarios include a purchase order with a partial receipt, a sales order with a credit hold, an inventory transfer between sites, a production order with a material shortage, a period-end reconciliation and an integration failure. Ask the vendor to explain which steps are standard, which require configuration and which depend on another product.
Common ERP RFP mistakes
- Overloading the document: Hundreds of low-priority questions make evaluation slower without improving the decision. Prioritise requirements that change business outcomes or implementation risk.
- Combining software and partner scores: A strong product does not guarantee a capable delivery team. Evaluate both dimensions explicitly.
- Accepting yes/no answers: Require demonstrations, documentation or contractual evidence for critical capabilities.
- Comparing different scopes: Standardise user counts, locations, entities, integrations and service assumptions before comparing price.
- Ignoring internal effort: Include business-owner time, data cleansing, testing, training and change management in the plan.
- Failing to define exclusions: Ask vendors to identify what is not included and what could become a change request.
Conclusion
A useful ERP RFP is a decision framework, not a document-length contest. It describes the business context, prioritises requirements, tests real scenarios, separates software fit from partner capability and compares the full cost of ownership. Use a consistent scorecard and require evidence for the requirements that matter most. This gives the selection team a defensible shortlist and reduces the risk of choosing a platform or implementation proposal that looks attractive only on paper.
