An ERP request for proposal (RFP) should help your organisation distinguish between software that can demonstrate features and a solution that can support the way the business actually operates. A weak RFP invites generic responses and makes vendors difficult to compare. A useful RFP documents business outcomes, prioritised requirements, implementation responsibilities, integration constraints, commercial assumptions and a consistent evaluation method.
This checklist is intended for organisations preparing to shortlist ERP products and implementation partners. It is not a universal specification: adapt the questions to your operating model, industry, regulatory obligations and project scope.
1. Establish the decision before writing the RFP
Start by agreeing why the organisation is evaluating ERP. Common drivers include replacing unsupported legacy software, consolidating entities, improving inventory visibility, shortening financial close, reducing manual work or supporting new locations. Convert each driver into an outcome that can be assessed later.
Form a cross-functional team with an executive sponsor, finance, operations, procurement, IT, security and representatives from the business processes affected. Identify who owns requirements, who approves the shortlist and who can commit resources for workshops, demonstrations and reference calls.
2. Document the current state and project scope
Give vendors enough context to understand the environment. Include business units and legal entities, locations, currencies, languages, user groups, transaction volumes, peak periods, current applications, reporting needs and known process constraints. Describe the systems that must remain and the integrations that may be replaced.
Define what is in scope for the initial release and what may be phased. State whether the project includes data migration, process redesign, integrations, reporting, custom development, training, change management, managed services and post-go-live support. List exclusions explicitly. Unclear scope makes proposal pricing and delivery plans difficult to compare.
3. Build requirements around business processes
A long list of generic features encourages vendors to answer “yes” without explaining the depth of fit. Organise requirements around end-to-end processes and the business reason behind each one. For every requirement, record:
- Requirement: A concise statement of what the business needs to do.
- Business outcome: Why it matters and what measurable improvement is expected.
- Priority: Mandatory, important or optional, with a clear definition for each category.
- Process owner: The department accountable for validating the requirement.
- Fit expectation: Standard configuration, extension, third-party product, custom development or workaround.
- Dependencies: Data, integration, security, reporting or process prerequisites.
- Acceptance method: How the vendor will demonstrate that the requirement is met.
Separate mandatory requirements from preferences. If everything is marked critical, the RFP provides no useful prioritisation. Avoid prescribing a feature where the actual need is a business outcome; allow vendors to explain a better way to meet it.
4. ERP RFP requirements checklist
| Area | Questions and evidence to request |
|---|---|
| Finance | General ledger, payables, receivables, fixed assets, tax, multi-entity consolidation, close and audit requirements |
| Operations | Procurement, inventory, warehouse, production, planning, quality, order management and fulfilment workflows |
| Industry fit | Required industry processes, regulatory controls, traceability, costing or project accounting needs |
| Reporting | Operational reports, financial statements, analytics, data exports and self-service requirements |
| Integration | APIs, events, middleware, existing applications, data ownership, frequency and failure handling |
| Data | Migration scope, historical data, master data, cleansing, reconciliation and retention |
| Security | Role design, segregation of duties, identity, audit logs, encryption, backup and recovery expectations |
| Technology | Cloud or on-premises deployment, availability, performance, environments, extensibility and update model |
| Adoption | Usability, mobile access, training, accessibility, languages and change-management needs |
| Support | Support hours, severity definitions, escalation, service reporting, upgrades and partner responsibilities |
5. Ask vendors to explain fit—not just confirm it
Require a response against each priority requirement. Ask vendors to classify the proposed solution as standard, configuration, extension, third-party add-on, custom development or not supported. Request a short explanation, dependencies, recurring costs and delivery implications for anything beyond standard capability.
Useful questions include:
- Which requirements are not met without customisation or an additional product?
- What assumptions have you made about our data, processes, integrations and internal resources?
- Which capabilities are available in the proposed edition and licence tier?
- How are upgrades tested when extensions or third-party products are involved?
- What is the implementation partner’s role, and which responsibilities remain with the software publisher?
- What support is included after go-live, and what is priced separately?
- Can you provide references for organisations with comparable complexity and operating requirements?
6. Make demonstrations comparable
Do not rely on a generic product tour. Give each finalist the same realistic scenarios and expected outcomes. Examples might include procure-to-pay, order-to-cash, month-end close, inventory replenishment, intercompany processing or a project billing scenario. Include exceptions, approvals, corrections and reporting—not only the ideal path.
Ask vendors to identify which steps use standard functionality and which depend on configuration, custom code or manual work. Have process owners score the demonstration against the original requirements. Record unanswered questions and request evidence after the session rather than awarding points for confident presentation.
7. Evaluate the implementation approach and partner
The software and the delivery partner are separate decisions. Ask for a proposed delivery methodology, phase plan, governance structure, named roles, resource assumptions, data migration approach, integration strategy, testing plan, training approach, cutover method and support transition.
Request examples of similar projects, including scope, complexity, partner responsibilities and lessons learned. Validate references directly. Ask who will lead the project day to day, how specialist resources are allocated, and what happens if key personnel become unavailable. For a US-focused starting point, see our guide to ERP implementation companies in the USA.
8. Compare total cost of ownership
Do not compare only the first-year subscription or implementation fee. Build a common cost model over a defined period, often three to five years, and state the assumptions. Include:
- Software subscriptions, user licences, environments and usage-based charges.
- Implementation services, project management, configuration and custom development.
- Data migration, integration, reporting and third-party applications.
- Training, change management, internal project staffing and backfill.
- Support, managed services, upgrades, testing and ongoing administration.
- Hosting, storage, security, compliance and disaster recovery where applicable.
- Expected costs of process change, downtime, parallel running and future expansion.
Ask vendors to identify assumptions that could change the estimate, such as user counts, transaction volumes, entities, integrations, data quality or customisation. Our guide to ERP implementation cost and TCO covers additional budget factors.
9. Use a weighted evaluation model
Agree the scoring method before proposals arrive. A practical model can score functional fit, implementation capability, integration and data, security and compliance, usability and adoption, support, and commercial value. Weight categories according to business priorities rather than copying a generic template.
Use a consistent scale and define what each score means. For example, a high score might require demonstrated fit with standard functionality and evidence; a lower score might indicate significant customisation, an unproven workaround or a material gap. Keep mandatory requirements as pass/fail gates rather than allowing a high overall score to conceal a critical failure.
10. Complete due diligence before selection
Before final approval, validate the proposal, references, implementation team, product roadmap, security documentation, service terms, licence assumptions, data ownership, exit options and contract schedules. Reconcile every commercial figure with the proposed scope. Ask vendors to identify exclusions, dependencies, price-change mechanisms and optional services.
Do not treat a proposal as a contract-ready delivery plan. Translate the selected scope, deliverables, acceptance criteria, responsibilities and assumptions into the final statement of work and commercial agreement. Obtain appropriate legal, security and procurement review.
ERP RFP readiness checklist
- Executive sponsor and cross-functional evaluation team are appointed.
- Business objectives and current-state constraints are documented.
- Scope, phases, exclusions and dependencies are explicit.
- Requirements are process-based, prioritised and owned.
- Vendors must disclose fit gaps, add-ons and customisation.
- Demonstrations use common business scenarios and scoring.
- Implementation approach and named delivery resources are evaluated.
- Three-to-five-year TCO assumptions are documented.
- References, security, support and contract terms are checked.
- Selection criteria and decision authority are agreed before scoring.
Bottom line
A strong ERP RFP reduces ambiguity before it becomes delivery risk. Focus on business processes, evidence-based demonstrations, transparent fit gaps, partner capability and a comparable TCO model. The best proposal is not necessarily the one with the most “yes” answers or the lowest initial price; it is the one that meets the organisation’s critical needs with a delivery approach and long-term cost profile it can govern.
For a structured overview of ERP evaluation stages, see SAP’s ERP evaluation guidance. For more detailed questions to put to vendors and partners, consult ERP Research’s ERP RFP question guide.
