Writing an ERP RFP without a proven template is like navigating without a map. You will eventually arrive somewhere, but probably not where you intended. Most RFPs either ask too many irrelevant questions or miss the critical ones entirely.
I have reviewed over 50 ERP RFPs from companies of all sizes. The best ones share a common structure: they are specific enough to get meaningful responses but flexible enough to let vendors showcase their strengths. The worst ones are 80-page documents that no vendor reads carefully.
This guide gives you a practical RFP template along with a weighted scoring framework for evaluating responses. Whether you are comparing SAP Business One against NetSuite, evaluating Odoo versus Dynamics 365, or considering ERPNext and Acumatica, this framework produces clear, defensible vendor rankings.
Keep your RFP under 25 pages. Anything longer and vendors will assign junior staff to fill in checkboxes rather than providing thoughtful responses. Quality over quantity - always.
Section 1: Company and Project Overview
Start your RFP with context that helps vendors assess fit before they invest time responding. Include your industry, employee count, annual revenue range, number of locations, and current systems. Be specific. Saying you are a mid-size manufacturer tells vendors nothing useful. Saying you are a $15M discrete manufacturer with 85 employees across two plants running QuickBooks and Excel gives them everything they need.
Define your project timeline and budget range. Yes, sharing budget feels uncomfortable. But it saves everyone time. If your budget is $100K and a vendor requires $300K minimum, both parties benefit from knowing that upfront. Provide a range rather than a single number to maintain negotiating leverage.
List your must-have modules: financials, inventory, manufacturing, CRM, HR, whatever your scope requires. Then list your future-phase modules - features you want in year two or three. This distinction helps vendors propose appropriate licensing and phased implementation plans.
Include your technical requirements: cloud versus on-premise preference, integration needs with existing systems, data migration volume (number of records across key tables), and any regulatory or compliance requirements. For manufacturing companies, specify whether you need MRP, MES, or both. For distribution, clarify warehouse management complexity.
Section 2: Functional Requirements That Matter
Organize functional requirements by module, not by department. Use a three-tier rating: mandatory (deal-breaker if missing), important (strong preference), and desirable (nice to have). For each requirement, ask vendors to respond with one of four options: standard functionality, configuration required, customization required, or not available.
Financial management requirements should cover general ledger structure, multi-company consolidation, bank reconciliation automation, tax compliance for your jurisdictions, fixed asset management, and financial reporting capabilities. Ask specifically about your close process: can the system support a five-day month-end close with automated intercompany eliminations?
Supply chain and inventory requirements need detail. Ask about lot and serial number tracking, multiple warehouse support, cycle counting methods, demand planning algorithms, and landed cost calculations. If you run manufacturing, include bill of materials management, work order processing, capacity planning, and shop floor data collection. These operational details separate ERPs that handle your workflow from those that merely claim to.
Do not list 200 requirements. Focus on 40-60 across all modules. Every additional requirement dilutes vendor attention from the critical items. If a requirement is not important enough to evaluate during demos, it should not be in the RFP.
Section 3: Technical and Integration Questions
Ask about architecture specifics. Is the system true multi-tenant cloud or hosted single-tenant? What is the guaranteed uptime SLA? How often are updates released, and can you control update timing? What happens to customizations during updates? These questions reveal whether the vendor's technology aligns with your IT strategy.
Integration capabilities deserve a dedicated section. List every system the ERP must connect to: e-commerce platform, CRM (if separate), shipping carriers, payment processors, banking systems, and industry-specific tools. Ask vendors to describe their approach for each integration: native connector, marketplace add-on, middleware, or custom API development. Request estimated costs for each.
Data migration is where implementation budgets blow up. Ask vendors how they handle migration from your current systems. How many data loads are included? What is their approach to data validation? Can they migrate transaction history, and if so, how many years? A vendor who answers vaguely here will surprise you with change orders later.
Security and compliance questions should cover data encryption standards, role-based access control granularity, audit trail capabilities, backup and disaster recovery procedures, and compliance certifications relevant to your industry (SOC 2, HIPAA, GDPR, or industry-specific regulations).
Section 4: Vendor Qualification and References
Request specific implementation experience in your industry and company size range. A vendor with 500 enterprise installations but zero small business implementations is a risk for a 50-person company. Ask for the number of active customers in your industry, their average implementation timeline, and their go-live success rate.
Demand detailed resourcing plans. Who will be assigned to your project? What are their certifications and years of experience? What is their availability during your implementation window? Request resumes for the project manager and lead consultant. The difference between a senior consultant with 10 years of experience and a junior with 18 months is enormous, even though the vendor charges similar rates.
References should be specific: provide three clients in our industry with fewer than 100 employees who went live in the past 24 months. Call every reference and ask these five questions: Did the project finish on time? Did it finish on budget? What would you do differently? Would you choose this vendor again? What surprised you most about the implementation?
Financial stability matters for a partner you will depend on for years. Ask for revenue growth rates, total employee count, R&D investment as a percentage of revenue, and customer retention rates. For smaller vendors and implementation partners, review their Glassdoor ratings - high employee turnover correlates with inconsistent service quality.
Scoring Framework and Final Selection
Use a weighted scoring matrix with five categories: functional fit (35%), total cost of ownership (25%), technical capabilities (15%), vendor viability (15%), and implementation approach (10%). These weights work for most mid-market selections. Adjust if your priorities differ - a company with complex integration needs might weight technical capabilities at 25%.
Score each category on a 1-5 scale with clear definitions. A 5 means the vendor exceeds requirements with standard functionality. A 3 means the vendor meets requirements with acceptable configuration or customization. A 1 means the vendor cannot meet the requirement or requires excessive workaround. Apply weights and calculate composite scores.
Require scripted demos for your top two or three vendors. Provide a detailed scenario based on your actual business processes and ask each vendor to demonstrate the same workflow. This eliminates the advantage of polished demo environments and reveals how the system actually handles your operations. Allow 4 hours per demo with specific time blocks for each process area.
Make your final decision within two weeks of completing demos. Longer evaluation cycles lead to analysis paralysis and decision fatigue. Present the scoring matrix to stakeholders, discuss any areas where subjective judgment should override scores, and commit. The difference between your top two vendors is almost always smaller than the difference between implementing now and delaying another quarter.