An ERP RFP (request for proposal) is a structured document that describes your business, your requirements and how responses will be judged, so that every vendor, implementation partner or development company answers the same questions in the same format. A good ERP RFP has eight sections, writes requirements as testable outcomes, and tells bidders exactly how they will be scored.
The template below works for packaged ERP vendors and their partners, and for development companies proposing a custom system. That matters: if you write requirements as outcomes rather than as a feature list from one product, both kinds of supplier can answer, and you can compare them fairly. If a system built around your processes is one of the options, our custom ERP software page explains how that is delivered; if you have already chosen a package and need a partner to put it in, see ERP implementation services.
What should an ERP RFP include?
Eight sections cover what suppliers need to respond well and what you need to compare them.
| Section | Purpose | Typical length |
|---|---|---|
| 1. Introduction and instructions | Timeline, contact, format, confidentiality | One page |
| 2. Company profile | Who you are, entities, sites, users, volumes | One to two pages |
| 3. Scope and objectives | Business goals, in-scope and out-of-scope areas | One to two pages |
| 4. Functional requirements | What the system must do, by process | The bulk of the document |
| 5. Non-functional requirements | Security, access, performance, availability, accessibility, data location | Two to three pages |
| 6. Integration and data migration | Systems to connect, data to move | One to two pages |
| 7. Response format and commercial information | How to answer, what to price, team, plan | One to two pages |
| 8. Evaluation and terms | Scoring model, contract points, ownership, exit | One page |
Keep it as short as possible while still complete. Long RFPs full of generic features attract generic answers.
How do you write ERP requirements suppliers can answer?
Write each requirement as a business outcome that can be tested, give it an ID and a priority, and ask for a specific type of answer. "The system shall have inventory management" cannot be scored. "Show available stock by item, warehouse and batch, including stock reserved for open sales orders" can.
Requirement format
| ID | Process | Requirement | Priority | Response code | Explanation |
|---|---|---|---|---|---|
| FIN-04 | Finance | Post intercompany invoices that create the matching payable in the other entity automatically | Must | ||
| INV-11 | Inventory | Track stock by batch with expiry date and block expired batches from picking | Must | ||
| SAL-07 | Sales | Apply customer-specific price lists with date-effective prices | Should | ||
| PUR-03 | Purchasing | Route purchase orders above a set amount to a second approver | Must | ||
| REP-02 | Reporting | Monthly management pack by entity and consolidated, in the group currency | Must |
Use three priority levels: Must (disqualifying if missing), Should (scored), Could (nice to have). Be strict with "Must"; if everything is a must, nothing is.
Response codes to ask for
Ask bidders to answer each requirement with one code, plus an explanation:
- S Standard: works as delivered or by configuration
- E Extension: needs a documented extension, add-on or partner app (name it)
- C Custom: needs custom development (estimate the effort)
- R Roadmap: planned but not yet available (give the expected release)
- N Not supported
For a custom development company most answers will be "C", which is expected. Ask them instead to explain how each requirement fits the proposed design and which phase delivers it.
ERP RFP template (copy and adapt)
Copy the outline below into your own document and fill in the brackets.
Section 1: Introduction and instructions
- Purpose: [Company] invites proposals for [an ERP system and its implementation / a custom ERP system] covering [areas]
- Key dates: RFP issued [date]; questions due [date]; answers published to all bidders [date]; proposals due [date]; shortlist demos [dates]; decision [date]
- Single point of contact: [name, role, email]
- Format: answer in the order of this document; complete the requirements table; keep marketing material in an appendix
- Confidentiality: [reference your NDA]
Section 2: Company profile
- Industry, products or services, business model
- Legal entities and countries; currencies; languages required (for example English and Arabic)
- Sites, warehouses, production lines
- Number of users by role (finance, sales, warehouse, managers, read-only)
- Volumes: sales orders, purchase orders, invoices and items per month
- Current systems and what each one does today
Section 3: Scope and objectives
- Three to five business goals, each measurable in your own terms (for example "close the month in fewer working days than today")
- In-scope processes and entities
- Out of scope, stated explicitly
- Phasing preference, if any
- Fixed dates and why they are fixed
Section 4: Functional requirements
Group by process: finance, procurement, inventory, sales, manufacturing, projects, HR and payroll, CRM, reporting. Use the requirement table format above. Attach your top ten reports and two or three real documents (an invoice, a delivery note) as examples. Describe approvals and permissions as a matrix; our approval workflow design guide shows a format.
If you run several companies, add a subsection on intercompany, consolidation and shared master data; our guide to multi-entity ERP governance lists the questions to cover.
Section 5: Non-functional requirements
- Access control: role-based permissions, segregation of duties, single sign-on
- Audit: who changed what and when, on financial and master data
- Security: ask how the application is tested and which standard it is verified against. The OWASP Application Security Verification Standard (ASVS), whose current stable version is 5.0.0 (checked October 2026), is a common reference for web applications
- Accessibility: for browser-based systems, ask which level of W3C's Web Content Accessibility Guidelines the interface targets; WCAG 2.2 has been a W3C Recommendation since October 2023
- Availability and recovery: expected availability, backup frequency, recovery approach and how it is tested
- Data location and privacy: where data is hosted and processed, and how the solution is designed to support your legal obligations in each country
- Performance: response times for key screens at your volumes
- Upgrades and support: upgrade process, support hours, response targets
Section 6: Integration and data migration
- List each system to connect, the data flowing in each direction, frequency and volume
- Ask how integrations are built, monitored and maintained, and who owns them
- Describe data to migrate: master data, opening balances, open transactions, history approach
- Ask for the proposed migration method, number of trial loads and reconciliation approach
Section 7: Response format and commercial information
- Company overview, relevant experience and two or three references of similar size
- Proposed solution and how it meets the requirements
- Completed requirements table with response codes
- Implementation or delivery plan by phase, with assumptions
- Named key team members and their roles
- Commercial proposal itemised: licences or build, implementation, integrations, hosting, support and any recurring fees, over a stated number of years
- What the client must provide: people, time, data, decisions
Section 8: Evaluation and terms
- Scoring model and weights (see below)
- Ownership: who owns configuration, custom code and documentation, and when
- Data: confirmation that your data remains yours and can be exported in a usable format
- Exit: how the system and data are handed over if the relationship ends
- Change control: how out-of-scope requests are assessed and agreed
How should ERP RFP responses be scored?
Publish the scoring model in the RFP. Bidders write better answers when they know what matters, and your evaluators stay consistent. A simple approach: check every "Must" first (any "N" disqualifies), then score the rest with weights.
| Area | Weight (illustrative) |
|---|---|
| Functional fit (Should and Could requirements) | 30 |
| Total cost of ownership over the stated period | 20 |
| Delivery approach, plan and team | 15 |
| Integration and migration approach | 10 |
| Non-functional requirements | 10 |
| References and relevant experience | 10 |
| Ownership, data and exit terms | 5 |
Our ERP selection criteria checklist gives a full weighted scorecard, demo scripts and reference questions for the shortlist stage.
Common ERP RFP mistakes
- Copying a feature list from one vendor's website, which favours that vendor
- Marking most requirements as "Must"
- Asking for a fixed price without giving volumes, integrations or migration scope
- Leaving out reports, which are where many gaps surface
- Not stating out-of-scope areas
- Giving bidders too little time to ask questions
- Forgetting ownership and exit terms until contract negotiation
When is a full RFP not the right tool?
For a small business choosing between two well-known packages, a formal RFP can cost more effort than it saves; a short requirements list and scripted trials may be enough. A full RFP also fits poorly when requirements are genuinely unknown. In that case a paid or free discovery phase or pilot with one or two suppliers will teach you more than a long questionnaire. Use the RFP when several suppliers are in play and the decision is large enough to justify a structured comparison.
How to start your ERP RFP
Begin with a requirements brief: goals, processes, entities, systems, reports and volumes. Our software requirements brief template gives a one-document format that converts directly into sections 2 to 4 above. Then draft the requirement tables with each process owner.
If a custom ERP is one of your options, discuss the project with us and send the draft RFP. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so you can test working software against your own requirement IDs.