How to run an ERP RFP
An ERP touches finance, operations, sales and IT at once, and the software is only half the decision: the other half is the team that implements it. This template asks for both in one response. The example schedule below runs about 22 weeks from kickoff to signed contracts; allow more if you have many entities, countries or plants, or if your processes aren't documented yet.
- Map your processes and set scope (weeks 1-4). Document how work flows today for each core process (record to report, procure to pay, order to cash and, if you make products, plan to produce), where it breaks, and which systems and spreadsheets are involved. Decide which entities, sites and modules are in the first go-live. Record the numbers vendors will price against: users by type, entities, countries, items, and monthly order and invoice volumes.
- Assemble the buying team. Include finance (the controller or equivalent), operations (purchasing, inventory, production or warehouse), sales and customer service, IT (integration, security and data), procurement and legal. Ask internal audit to review the access-control requirements. Appoint an executive sponsor who can settle disagreements between departments, and a project lead who will stay on through implementation.
- Decide how to involve implementation partners, and whether you need an RFI (weeks 4-6). ERP vendors sell and implement directly, through partners (systems integrators), or both. Decide whether you want joint proposals covering software and implementation, which this template assumes, or to choose the software first and run a second RFP for the partner. If your long list has more than five products, or you're unsure which products fit your industry and size, send a short RFI first about industry fit, deployment model, pricing model and who implements in your region, and use the answers to build a shortlist.
- Tailor and issue the RFP (weeks 6-10). Delete requirements that don't apply, adjust priorities, and add your process maps, volumes and integration list to Section 1. Ask each software vendor to name its proposed implementation partner and submit one joint response. Give vendors four weeks to respond, with a written question-and-answer window in the first two.
- Score the responses and shortlist (weeks 10-12). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. Check whether each 'yes' is standard functionality, configuration, custom code or a roadmap item. Compare implementation estimates assumption by assumption, not just by the total.
- Run scripted demonstrations with two or three vendors (weeks 12-18). Give every shortlisted vendor the same scripts and sample data: real items, a typical customer order, a supplier invoice with a price variance, and a month-end task. Require the proposed implementation team, not only presales staff, to attend. Interview the partner separately, and call references of similar size and industry, including one implemented by the same partner team.
- Negotiate software and services together, then award (weeks 18-22). Negotiate the subscription and the implementation statement of work at the same time, because each affects the other. Settle renewal caps, a subscription ramp during implementation, key-person terms, acceptance criteria for each milestone and exit terms before you sign, not after.
ERP RFP for manufacturers and distributors
A general ERP RFP covers finance, purchasing and sales. Manufacturers and distributors also depend on operations modules, and those need more detail than a general requirements list gives. If that's you, add requirements that describe how you make, store and ship products, and ask vendors to demonstrate them with your own items, orders and volumes.
Manufacturers should state their production mode (make-to-stock, make-to-order, engineer-to-order, or process and batch manufacturing), because a product that handles one well may handle another poorly. Distributors should describe their warehouses, order channels and trading partners. If a manufacturing execution system (MES) or warehouse management system (WMS) will sit beside the ERP, say so, and treat the integration as a requirement rather than a later project.
Lines to add to the Functional and Integration requirements:
- Manufacturing: multi-level bills of materials (BOMs) with revision and effective-date control, and routings with work centers, operations, setup and run times.
- Manufacturing: material requirements planning (MRP) that creates planned purchase and work orders from sales orders, forecasts, safety stock and lead times, with exception messages for planners.
- Manufacturing: production planning and scheduling with capacity planning by work center. State whether finite-capacity scheduling is included or an add-on.
- Manufacturing: work orders with material issue or backflushing, labor and machine reporting, scrap, completions, and actual-versus-standard cost variances.
- Manufacturing: shop-floor data collection in the ERP, or integration with our MES for work order release, labor and machine time, and production results.
- Manufacturing: quality management, including inspections at receipt and in production, nonconformance records, quality holds and corrective actions.
- Manufacturing and distribution: lot and serial number traceability from supplier receipt through production to customer shipment, with forward and backward trace reports for recalls.
- Distribution: multi-warehouse inventory with transfer orders, bin locations, replenishment rules and real-time availability across sites.
- Distribution: order management across channels (EDI, e-commerce, sales reps and customer service), with customer-specific pricing, backorders, drop shipments and allocation rules.
- Distribution: EDI with trading partners for purchase orders, acknowledgments, advance ship notices and invoices (X12 850, 855, 856 and 810, or EDIFACT ORDERS, ORDRSP, DESADV and INVOIC), built in or through a named EDI provider, with GS1-128 carton labels where partners require them.
- Distribution: landed cost allocation of freight, duty, insurance and brokerage to received items, using estimated costs at receipt and actual costs when invoiced.
- Distribution: pick, pack and ship with barcode scanning in the ERP, or integration with our WMS and shipping carriers.
ERP RFP requirements
Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.
Functional
| ID |
Requirement |
Priority |
| F1 |
General ledger with a configurable chart of accounts and reporting dimensions (such as department, location, product line and project), so we can report on any combination without adding accounts. |
Must-have |
| F2 |
Multiple legal entities and currencies in one system, with exchange-rate management, currency revaluation, and intercompany transactions that post matching entries in both entities. |
Must-have |
| F3 |
Consolidation across entities with intercompany eliminations, currency translation and consolidated financial statements. State which consolidation scenarios would need a separate tool. |
Must-have |
| F4 |
Period-end close tools: recurring, reversing and allocation journals, accruals, period locking by module and entity, and a close checklist showing task status by entity. |
Must-have |
| F5 |
Accounts payable: two- and three-way matching of supplier invoices against purchase orders and receipts, approval routing, payment runs by [check, ACH, wire, card], and supplier tax reporting where required (for example, Form 1099 in the US). |
Must-have |
| F6 |
Accounts receivable: customer invoicing, cash application with automatic matching of bank receipts to invoices, credit limits and holds, collections follow-up, customer statements and aging reports. |
Must-have |
| F7 |
Fixed assets: an asset register fed from payables, depreciation by method and by book (for example, financial and tax books), transfers and disposals, with journal entries created automatically. |
Must-have |
| F8 |
Revenue recognition for contracts with multiple performance obligations under ASC 606 or IFRS 15, with revenue schedules and deferred revenue reporting. Make this Must-have if you sell subscriptions, bundles of products and services, or long-term contracts. |
Nice-to-have |
| F9 |
Procurement: purchase requisitions, approval by amount and cost center, purchase orders and blanket orders, receiving, and supplier records with payment terms, tax details and delivery performance. |
Must-have |
| F10 |
Inventory across multiple locations, with units of measure, costing methods (standard, average or FIFO), cycle counting, reorder points, and real-time on-hand and available quantities. |
Must-have |
| F11 |
Order to cash: quotes, sales orders, customer-specific price lists and discounts, available-to-promise checks, shipment, invoicing, and returns with credit memos. |
Must-have |
| F12 |
Manufacturing: bills of materials, routings, work orders, material requirements planning (MRP) and production costing for our production mode [make-to-stock / make-to-order / engineer-to-order / process]. [Manufacturers: add the detailed lines from 'ERP RFP for manufacturers and distributors' in this template. Delete this line if you don't manufacture.] |
Must-have |
| F13 |
Distribution: multi-warehouse inventory, transfer orders, landed cost and EDI order processing. [Distributors: add the detailed lines from 'ERP RFP for manufacturers and distributors' in this template. Delete this line if it doesn't apply.] |
Must-have |
| F14 |
Project accounting: project budgets, cost capture from time, expenses and purchases, billing by time and materials, fixed fee or milestone, and project profitability reporting. |
Nice-to-have |
| F15 |
Financial statements, budget-versus-actual and operational reports with drill-down from any balance to the source transaction, reports and dashboards that finance users can build without IT, and export to spreadsheet formats. |
Must-have |
| F16 |
Configurable approval workflows for purchases, supplier invoices, journals, expenses, and new suppliers and customers, with rules by amount, entity and department, delegation during absences, and approval from mobile devices. |
Must-have |
| F17 |
Built-in automation and AI features, such as invoice data capture, transaction matching, anomaly flags or natural-language questions about our data. State which are generally available, which cost extra, and whether our data is used to train models shared with other customers. |
Nice-to-have |
Technical and architecture
| ID |
Requirement |
Priority |
| T1 |
State the deployment model: multi-tenant SaaS, single-tenant cloud, or hosted by the vendor or a partner. Identify who operates the infrastructure, and where our production data and backups are stored. [List required regions.] |
Must-have |
| T2 |
Vendor-managed updates on a published schedule, with release notes in advance and a preview of each release in a sandbox before it reaches production. State the release cadence and whether, and for how long, we can defer an update. |
Must-have |
| T3 |
Extensibility without modifying the core code: custom fields, records, forms, workflows and business logic that carry forward through updates. Describe the tools (configuration, low-code, scripting) and their limits. |
Must-have |
| T4 |
Documented REST or OData APIs covering core records and transactions, with webhooks or event notifications for changes. State API rate limits and any charge for API usage. |
Must-have |
| T5 |
Sandbox environments for configuration, testing and training, refreshable from production on request. State how many are included and the cost of additional ones. |
Must-have |
| T6 |
Backup and disaster recovery with a stated recovery point objective (RPO) and recovery time objective (RTO), and a recovery test at least once a year. Provide a summary of the latest test. |
Must-have |
| T7 |
Localization for each country where we operate [list countries]: languages, tax rules, statutory reports, and electronic invoicing where it is mandated. State which localizations the vendor maintains and which come from partners. |
Must-have |
Integration
| ID |
Requirement |
Priority |
| I1 |
Single sign-on with our identity provider via SAML 2.0 or OIDC. State whether user provisioning and deprovisioning via SCIM is supported. |
Must-have |
| I2 |
Integration with our current systems: [CRM, e-commerce, payroll/HCM, expense management, WMS, MES, BI]. For each, state whether the connector is vendor-built, partner-built or custom, and who maintains it through updates. |
Must-have |
| I3 |
Bank integration for statement import (for example, BAI2 or ISO 20022 camt.053) and payment files (for example, ACH files in NACHA format or ISO 20022 pain.001), with rules-based bank reconciliation. |
Must-have |
| I4 |
Sales tax, VAT or GST calculation, built in or through integration with a tax engine, applied on quotes, orders and invoices. |
Must-have |
| I5 |
EDI with customers and suppliers using X12 or EDIFACT, built in or through a named EDI provider, with failed transactions visible to users. Make this Must-have if your customers or suppliers require EDI. |
Nice-to-have |
| I6 |
Bulk import and export tools for master data and transactions, used for migration and ongoing updates, with validation and error reports. |
Must-have |
| I7 |
A data feed or replica for our data warehouse or BI tool, so analysts can query ERP data without affecting system performance. |
Nice-to-have |
Security and compliance
| ID |
Requirement |
Priority |
| S1 |
Role-based security down to the transaction and field level, with access restricted by entity, location or department. |
Must-have |
| S2 |
Segregation of duties (SOD) controls: configurable rules for conflicting permissions (for example, creating suppliers and approving payments), reports of users who hold conflicting roles, and periodic user access reviews. State whether any of this requires an add-on. |
Must-have |
| S3 |
An audit trail of every change to master data, transactions, configuration and security roles, showing who made it, when, and the old and new values, which users cannot edit or delete. |
Must-have |
| S4 |
Current SOC 1 Type II and SOC 2 Type II reports covering the proposed service, available under NDA, with bridge letters for gaps between report periods. Provide ISO/IEC 27001 certification if held. |
Must-have |
| S5 |
Encryption in transit and at rest, isolation of our data from other customers, and administrator access through SSO with MFA. |
Must-have |
| S6 |
A data processing agreement, a current list of sub-processors, data residency in [regions], and support for our privacy obligations (for example, GDPR). |
Must-have |
| S7 |
A contractual commitment to notify us of security incidents affecting our data within a defined time. State the time. |
Must-have |
Implementation and support
| ID |
Requirement |
Priority |
| M1 |
Identify who delivers the implementation: the vendor's own services team, a partner (systems integrator), or both. For a partner, describe its relationship with the vendor, its experience with this product in our industry, and the vendor's role if the project runs into trouble. |
Must-have |
| M2 |
A statement of work with phases, milestones, deliverables, acceptance criteria and the effort expected from our staff by role. State whether the engagement is fixed fee or time and materials, and list the assumptions it depends on. |
Must-have |
| M3 |
A named implementation team (project manager, solution architect, functional and technical consultants) with résumés and time allocation, and a commitment that key people won't be replaced without our approval. |
Must-have |
| M4 |
Data migration of master data (chart of accounts, customers, suppliers, items, bills of materials), open transactions (orders, payables, receivables, inventory balances) and [number] years of general ledger balances, with mock loads and reconciliation reports. Define who extracts, cleans, maps and loads the data. |
Must-have |
| M5 |
A test plan covering system integration testing, user acceptance testing and performance testing at our volumes, with test scripts for our key processes and a defect-tracking process. |
Must-have |
| M6 |
A cutover plan with at least one full rehearsal, go/no-go criteria, a fallback plan, and support for the first period-end close in the new system. |
Must-have |
| M7 |
Hypercare after go-live from the implementation team, through at least the first month-end close. State the length and staffing. |
Must-have |
| M8 |
Role-based training for end users and administrators, train-the-trainer materials we can reuse, and documentation of our configuration and extensions. |
Must-have |
| M9 |
A service-level agreement for production availability with service credits, and support response-time targets by severity, with 24×7 cover for critical issues. State both, and who provides first-line support after hypercare (vendor or partner). |
Must-have |
| M10 |
Optional post-go-live managed services for administration, enhancements and testing of new releases, priced as a monthly retainer or a block of hours. |
Nice-to-have |
Commercial and pricing
| ID |
Requirement |
Priority |
| C1 |
Subscription pricing by module and metric (named user, user type, entity or transaction volume), showing list price, discount and net price. Define each user type (for example, full, limited or self-service) and what it can do. |
Must-have |
| C2 |
Implementation fees broken down by phase and role, with a rate card, and a not-to-exceed amount for any time-and-materials work. State how change requests are priced. |
Must-have |
| C3 |
A cap on subscription price increases at renewal, applying to at least [two] renewal terms. State the cap. |
Must-have |
| C4 |
Prices for adding users, user types, entities, modules and sandbox environments mid-term, co-terminated with the main agreement. |
Must-have |
| C5 |
A subscription ramp that follows the implementation timeline, so we don't pay full production fees before go-live. |
Nice-to-have |
| C6 |
Every other cost over a [five]-year term: third-party add-ons, storage, API usage, EDI fees, premium support, and partner products the solution depends on. |
Must-have |
| C7 |
Exit terms covering export of all our data in a usable format, and transition assistance, at the end of the contract. |
Must-have |
Questions to ask ERP vendors
These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.
- Which modules in your proposal are part of the core product, which are separate products or acquisitions, and which come from partners? Do they share one database, one security model and one set of master data?
- Run our demonstration scripts with our sample data: a typical customer order, a supplier invoice with a price variance, and an intercompany transaction through to consolidation. What did you configure beforehand to make them work?
- Which of our requirements would you meet with standard functionality, which with configuration, which with extensions or custom code, and which not at all? Who maintains each extension through updates?
- Is your implementation estimate fixed fee or time and materials? List the assumptions behind it, what is excluded, and what most often causes change requests on projects like ours.
- Who exactly will work on our project? Give names, roles, time allocation and experience with this product in our industry, and tell us what happens if a key person leaves.
- How do product updates reach us: how often, with how much notice, and can we test them in a sandbox first? Describe a recent update that changed existing behavior and how customers were told.
- How much history do you recommend migrating (open items only, balances, or detailed transactions), which tools will you use, and how many mock loads and cutover rehearsals are in your plan?
- Show how a user with conflicting permissions is detected and reported, and what evidence our auditors can get from the system to test segregation of duties and change controls.
- How are consolidation, intercompany eliminations and currency translation handled for our entity structure, and at what point would we need a separate consolidation or planning tool?
- For manufacturers: run MRP for one of our products and show the planned orders, the exception messages and how a planner acts on them. How long does a full MRP run take at our volumes?
- For distributors: which EDI transactions and trading partners are live with customers today, who builds and maintains the maps, and what does it cost to add a trading partner?
- Which features in your proposal, including AI features, are generally available today, which are in preview or on the roadmap, and which cost extra? Give dates for the roadmap items.
- What will our total cost be over five years, including subscription increases, additional user types, sandboxes, storage, API usage, add-ons and support after go-live?
- Describe an implementation of your product that went badly: what caused it, what it cost the customer, and what you changed afterwards.
- Provide two references of similar size and industry that went live in the last two years, including one implemented by the partner team you are proposing.
Scoring rubric
Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.
| Criterion |
Weight |
What a strong response shows |
| Finance functionality (ledger, payables, receivables, multi-entity, close, reporting) |
20% |
Every finance Must-have met with standard functionality, shown with your data in a scripted demo, including intercompany transactions and consolidation. |
| Operations functionality (procurement, inventory, order to cash, manufacturing or distribution) |
20% |
Your operational scripts run end to end with your own items and orders, with little or no custom code. |
| Technology, extensibility and updates |
10% |
A clear deployment model, extensions that survive updates, a predictable release schedule and enough sandboxes. |
| Integration and data |
10% |
Proven connectors or documented APIs for each system on your list, bank and tax integration, and credible migration tools. |
| Security and controls |
5% |
Segregation-of-duties reporting, a complete audit trail, and current SOC 1 and SOC 2 reports. |
| Implementation partner, plan and team |
20% |
A named, experienced team, a realistic plan with stated assumptions, mock migrations and cutover rehearsals, and references from similar projects. |
| Commercials and five-year total cost |
15% |
Transparent subscription and services pricing, a renewal cap, a ramp during implementation, and fair add-on and exit terms. |
| Total |
100% |
|
Scoring scale
- 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
- 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
- 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
- 2 Weak: misses one or more Must-haves, or the answer is vague.
- 1 Poor: does not meet the requirement, or no answer.
Frequently asked questions
What should an ERP RFP include?
Your scope and the volumes vendors will price against; functional requirements for finance, procurement, inventory, order to cash and, where relevant, manufacturing or distribution, each marked Must-have or Nice-to-have; technical, integration and security requirements; implementation requirements covering the partner, data migration, testing, cutover and hypercare; vendor questions; a pricing table for software and services; and the rubric you'll score with. This template includes all of them.
How long does an ERP RFP take?
The example schedule in this template runs about 22 weeks from kickoff to signed contracts: four weeks to map processes, four weeks for vendor responses, and six weeks of scripted demonstrations and reference calls. Implementation starts after that and is planned separately. Allow more time if you have many entities, countries or plants, or if your processes aren't documented yet.
Should an ERP RFP include the implementation partner?
This template assumes it does. The implementation team has a large effect on cost, timeline and how well the system fits your processes, and you can't compare proposals fairly if services are priced later. Ask each software vendor to name its partner and submit a joint response, require a named team, and score the partner as its own criterion. If you'd rather choose the software first, run a second, shorter RFP for implementation services using the Implementation and support requirements.
What should an ERP RFP for manufacturers include?
Add requirements for bills of materials and routings, material requirements planning (MRP), production planning and scheduling, work orders and production costing, quality management, and lot and serial traceability. State your production mode (make-to-stock, make-to-order, engineer-to-order or process manufacturing), and say whether shop-floor data will come from the ERP or a separate manufacturing execution system (MES). Then ask vendors to demonstrate MRP and traceability with your own products.
When should you issue an ERP RFI before the RFP?
Use an RFI when your long list is too long to evaluate properly, when you don't know which products fit your industry and size, or when you haven't decided between a cloud subscription and a hosted deployment. Keep it short: industry fit, deployment model, pricing model, who implements in your region, and reference customers. Use the answers to choose three to five vendors for the RFP.
Related RFP templates
