How to Write an ERP RFP

An ERP RFP (request for proposal) is a structured document that translates your business requirements into comparable vendor responses so you can buy on evidence instead of sales pressure. A strong ERP RFP has roughly nine sections and a weighted set of 40–100 questions spanning functional fit, implementation, pricing and total cost of ownership, security and compliance, support, and customer references — the six categories that, per ERP Research's 2026 RFP guidance, separate a real fit from a polished demo. The point of this guide is the writing of that document: how to structure it, what to put in each section, and which questions actually discriminate between vendors.

This is the RFP-authoring point of view — distinct from the broader question of how to run an end-to-end selection, which is covered in our guide to choosing the right ERP vendor for your business. If you already know you need a structured evaluation and want to author the document itself, read on.

Why a written RFP matters more than vendor demos

ERP selection is one of the most expensive, highest-stakes software decisions a business makes, and the market is genuinely confusing to navigate. ERP Focus notes that in their experience nearly half of businesses find the platforms and sales offers confusing, and only about a quarter felt confident immediately after making a decision. The antidote to that confusion is a written, scored RFP that forces every vendor to answer the same questions in the same format.

A good RFP does three things at once. It documents what you actually need before vendors can shape your thinking. It produces an apples-to-apples comparison so you are evaluating evidence rather than presentation skills. And it creates an auditable record — weighted scores, requirement-by-requirement responses, pricing breakdowns — that survives staff turnover and supports a defensible procurement decision. Without it, you are left comparing glossy proposals that are impossible to line up side by side.

The nine core sections of an ERP RFP document

There is no single canonical RFP outline, but the most effective documents converge on a predictable structure. Priority Software's breakdown of an effective ERP RFP identifies the components that consistently produce comparable, evaluable responses. Use this as your skeleton and adapt the depth of each section to your organisation.

1. Executive summary

A one-page orientation that states who you are, why you are buying an ERP, the high-level scope, and the decision you want vendors to help you make. Vendors read this first to decide whether the opportunity is worth bidding on, so be concrete about company size, industry, geography, and the scale of the project. A vague executive summary attracts low-quality bids from vendors who will say yes to anything.

2. Project overview and company background

Give vendors the operational context they need to respond accurately: number of employees, locations, current systems being replaced or integrated, revenue band, and the business problems driving the project. ERP Focus stresses that this section exists so vendors can judge fit — a vendor whose sweet spot is mid-market discrete manufacturing should self-select out of a large distribution opportunity, and the context you provide is what enables that honesty.

3. Functional and technical requirements

This is the heart of the document. List requirements organised by module or business process area — finance, procurement, manufacturing, inventory, sales, HR, CRM, reporting — and then the technical expectations: deployment model, integrations, security standards, performance, and scalability. Priority Software recommends tagging every requirement as must-have, nice-to-have, or optional, and giving vendors a structured way to respond: supported out of the box, supported through configuration, supported through customization, or not supported. That four-state vocabulary is what turns a wishlist into a scorable matrix.

4. Timeline and milestones

State your target go-live date, any immovable deadlines (fiscal year start, a regulatory compliance date, a divestiture close), the key phases you expect (requirements validation, configuration, testing, UAT, training), and your internal team's availability plus blackout periods. Ask vendors to map their implementation methodology against that timeline and flag conflicts. Be realistic here: Priority Software warns that setting overly aggressive go-live dates without internal validation is a recurring mistake that makes vendors either decline to bid or submit padded proposals.

5. Support, training, and maintenance expectations

Specify post-go-live expectations explicitly — knowledge transfer, documentation deliverables, training modalities (onsite, remote, or train-the-trainer), support tiers, and response-time targets. Vendors will not volunteer scope they can later charge for, so the RFP is where you lock it down.

6. Data migration requirements

Clarify what must be migrated — master data, historical transactions, compliance archives — and from which source systems, with volume estimates and data-quality notes. Data migration is one of the most consistently under-scoped areas in ERP projects; ERP Research identifies data migration and user adoption as the two areas buyers most often under-scope, and pinning them down in the RFP is what prevents expensive change orders later.

7. Pricing format

You do not have to reveal your budget, but you must define a pricing format so responses are comparable. Ask for line-item breakdowns by module, user type, implementation services, integrations, training, support, and annual maintenance or subscription renewal. Require vendors to state how long pricing is fixed and what the renewal and price-increase terms are. Without a standard pricing table you cannot compute a meaningful total cost of ownership.

8. Vendor qualification questions

Separate from functional requirements, ask about company history, financial stability, ownership, the specific product's install base and market position, and the product roadmap for the next 12–36 months. A thin roadmap is a red flag that the vendor is under-investing in the product you would be buying.

9. Submission guidelines and evaluation criteria

Tell vendors exactly how to respond: the response format, the submission deadline, the point of contact, and whether there will be a Q&A period, live demos, or shortlist interviews. Critically, tell them how they will be scored — which criteria matter and their relative weights. When vendors know the scoring model, their responses address what you actually care about instead of what they want to emphasise.

Executive summary — What it achieves: Frames the opportunity · The question it answers for vendors: "Is this worth bidding on?"
Project overview — What it achieves: Establishes fit context · The question it answers for vendors: "Is our product right for this buyer?"
Requirements matrix — What it achieves: Creates a scorable comparison · The question it answers for vendors: "Can we meet these needs, and how?"
Timeline & milestones — What it achieves: Exposes scheduling risk · The question it answers for vendors: "Can we deliver by their deadline?"
Support & training — What it achieves: Locks post-go-live scope · The question it answers for vendors: "What is included vs. chargeable?"
Data migration — What it achieves: Surfaces hidden cost · The question it answers for vendors: "What data work is implied?"
Pricing format — What it achieves: Enables TCO comparison · The question it answers for vendors: "What will this actually cost over 5 years?"
Vendor qualification — What it achieves: Tests viability · The question it answers for vendors: "Will this vendor exist and invest in 5 years?"
Submission & scoring — What it achieves: Aligns responses to priorities · The question it answers for vendors: "How will we be judged?"

How to write the requirements section so it is actually scorable

The requirements section is where most RFPs fail. A requirement like "system must handle manufacturing" is unscorable because every vendor will say yes. The discipline is to write requirements that are specific, tiered, and force a structured, comparable answer.

Start by documenting requirements before you send the RFP. ERP Research is emphatic on this point: you can only ask discriminating functional questions if you have first documented what you actually need across every department. If you skip the requirements-gathering step, your RFP will inevitably mirror whatever the first vendor to demo told you mattered, and you will have surrendered the evaluation frame before it begins.

Then apply three rules to every requirement line:

Be specific to your process. "Must support backflush of materials and labour at reporting-point completion for repetitive manufacturing" is scorable; "must support manufacturing" is not.
Tier the priority. Mark each line must-have, nice-to-have, or optional so the weighted score reflects how much a gap actually matters.
Force a structured response. Require every vendor to answer each requirement with one of: out of the box, via configuration, via customization, or not supported — and to attach an estimated effort or cost to any configuration or customization.

The reason the four-state response matters is that vendors will happily say "yes, we can do that," but "yes via heavy customization" is a very different commercial proposition from "yes, out of the box." ERP Research notes that integration work and upgrade-breaking customizations are among the most common causes of runaway ERP costs — so forcing vendors to expose the how in writing, before you sign, is one of the highest-leverage things your RFP can do. If you expect substantial tailoring, our ERP implementation and customization services can help you scope what is genuinely necessary versus what a vendor is upselling.

The questions that separate vendors

ERP Research organises the discriminating questions in an ERP RFP into six categories — functional fit, implementation, pricing and TCO, security and compliance, support, and customer references — plus vendor viability and integration and architecture. A thorough RFP typically contains 40 to 100 questions spread across these categories. Below are the highest-signal questions in each, drawn from that framework.

Vendor viability and product roadmap

Before you evaluate features, confirm the vendor and product are stable enough to bet on for the next decade. Ask how many businesses run this specific product (vendors sell several, and the headline number often aggregates them), what the product's market position is versus competitors, and what the roadmap looks like for the next 12–36 months. Frequent, meaningful updates signal ongoing investment; a thin roadmap signals a product on life support.

Functional fit

Ask vendors to state, against your documented requirements, which are met out of the box versus through configuration, customization, or a third-party add-on. Require them to demonstrate your top-priority processes end to end, name any requirement they cannot meet today and whether it is on the roadmap, and describe the out-of-the-box functionality for your specific sector.

Integration and architecture

ERP does not run in isolation. Ask what integration options are offered (APIs, pre-built connectors, middleware, file-based transfer), how specifically the product integrates with your existing CRM, e-commerce, WMS, payroll, and BI tools, and what the upgrade implications of customizations are. The architecture answers tell you how flexible, future-proof, and expensive the system will be to maintain.

Implementation and timeline (for partners)

Most ERP is deployed by an implementation partner or system integrator rather than the vendor directly, so ask these questions separately of the partner: how many implementations of this exact product they have completed, what methodology they use, what a realistic timeline is, and what their resourcing model is — onshore, offshore, or blended — and who specifically will be on your team.

Data migration and training

Ask how data will be migrated, cleansed, and validated, and who owns data quality. Ask what training is provided and whether it is role-based, what change-management support is included, and how testing, UAT, and go-live cutover are handled.

Pricing and total cost of ownership

Never evaluate on sticker price. Ask for license or subscription fees by user type and module; the one-time costs for implementation, data migration, integrations, and customization; the ongoing costs to budget for (support, maintenance, sandbox environments, add-ons); how long pricing is fixed and what renewal and increase terms apply; and the estimated three-to-five-year total cost of ownership. Demanding a five-year TCO on a standardised template is what makes pricing comparable.

Security and compliance

Ask how the product supports your compliance obligations (GDPR, HIPAA, SOX, or industry regulations), what certifications and audit reports the vendor holds, where data is hosted, and what the disaster-recovery and business-continuity provisions are. A security failure at your ERP vendor is a security failure for your business.

Support and SLAs

Ask what support tiers exist and what each includes, whether support comes from the vendor or the implementation partner, what the support hours are relative to your time zones, and how escalations and critical outages are handled.

Customer references

Ask for reference customers in your industry and size band — ideally ones the vendor did not hand-pick — and what went well and what they would do differently. Whether the project landed on time and on budget matters more than any feature list. A vendor unwilling to arrange candid reference calls is telling you something important.

Viability — Example high-signal question: "How many customers run this product, and what is the 24-month roadmap?" · What a weak answer reveals: Under-investment, end-of-life risk
Functional fit — Example high-signal question: "Which of our requirements need customization vs. configuration?" · What a weak answer reveals: Hidden cost and upgrade risk
Integration — Example high-signal question: "How do customizations affect upgrades?" · What a weak answer reveals: Runaway maintenance cost
Implementation — Example high-signal question: "Who specifically will be on our team, and how many like projects have they done?" · What a weak answer reveals: Staffing risk, inexperienced partner
Data & training — Example high-signal question: "Who owns data cleansing, and what is role-based training?" · What a weak answer reveals: Scope gaps, change orders
Pricing/TCO — Example high-signal question: "What is the 5-year TCO, and how long is pricing fixed?" · What a weak answer reveals: Price creep at renewal
Security — Example high-signal question: "Which certifications and hosting regions apply?" · What a weak answer reveals: Compliance exposure
Support — Example high-signal question: "Who provides support — vendor or partner — and what are the hours?" · What a weak answer reveals: Post-go-live coverage gaps
References — Example high-signal question: "Can we speak to a non-hand-picked peer customer?" · What a weak answer reveals: Overclaiming, weak delivery

How to score and evaluate responses

Once responses arrive, the goal is disciplined, weighted comparison — not impressions. ERP Focus's guidance on evaluating ERP RFP responses recommends building a structured scoring model before you read a single proposal, so the criteria are defined when you are still objective rather than retrofitted to a vendor you already like.

The standard approach is a weighted matrix. Define your evaluation categories — functional fit, technical architecture, implementation approach, vendor viability, total cost of ownership, support, and references — and assign each a weight that sums to 100%. Score each vendor in each category on a fixed scale (ERP Research and ERP Focus both suggest a 1–5 metric, with 5 as best, and note that any consistent value process is better than none). Multiply each score by its category weight and sum to a total. The weighting is what prevents the most expensive failure mode in ERP selection: letting price or a charismatic sales team dominate a decision that should be driven by fit and TCO.

Three practices keep the scoring honest. First, standardise the response format so you are scoring comparable inputs — do not allow freeform proposals, or you will spend weeks trying to align different documents and end up comparing presentation instead of substance. Second, score requirement-by-requirement, not category-by-category from memory, so a vendor's out-of-the-box coverage is captured precisely. Third, decide who evaluates deliberately. ERP Research and ERP Focus both observe that business leaders, not the IT department alone, should make the final call — IT can assess architecture and integration, but functional fit and business value are judgments for the people who will run the operation on the system.

Structuring the demo phase

After the written evaluation, the demo is where written claims get tested. Do not let vendors run their standard scripted demo — that tests their sales deck, not your business. Instead, give shortlisted vendors the same scripted scenario built from your top-priority processes, and score each demo against a demo scorecard that mirrors your requirement priorities.

A scripted demo exposes the gap between "yes, we can do that" on paper and whether the product actually does it smoothly in front of you. It also reveals usability — how many clicks a common task takes, how the interface behaves, how reporting works in practice — which no written response can convey. SAP's guidance on how to evaluate ERP software similarly emphasises tying evaluation to your real processes rather than generic capability checklists.

Common RFP mistakes that weaken your negotiating position

Most weak RFPs fail in predictable ways. Avoid these and your document will already be in the top tier.

Vague requirements. "Must support reporting" invites a yes from everyone and discriminates between no one. Specificity is the entire point of the requirements section.

No standardised response format. If you let vendors submit freeform proposals, comparison becomes nearly impossible and the evaluation collapses into impressions. Require a requirement matrix and a standard pricing table.

Arbitrary timelines. Setting a go-live date based on a fiscal target or executive preference rather than internal readiness makes vendors pad their proposals or decline. Build the timeline from your organisation's availability and the project's complexity.

Ignoring integration and data. Most organisations depend on external platforms for CRM, HR, logistics, e-commerce, and analytics. If those systems and the data they hold are not addressed in the RFP, integration becomes an expensive discovery project after the contract is signed.

Under-scoping data migration and training. These are the two areas buyers most consistently underestimate. Naming them explicitly in the RFP — with volumes, sources, and training expectations — is what keeps them out of the change-order queue.

Evaluating on price alone. Sticker price tells you almost nothing about five-year cost. A cheaper license with heavy customization, thin support, and aggressive renewal increases can cost far more over the life of the system than a higher-listed alternative that fits out of the box.

A practical RFP timeline

A well-run ERP RFP is not a weekend exercise. Expect the document-and-evaluate cycle to take roughly eight to twelve weeks for a mid-market project, longer for enterprise scope.

Requirements gathering — Typical duration: 3–4 weeks · Key output: Documented, tiered requirements across departments
RFP authoring — Typical duration: 1–2 weeks · Key output: Complete RFP document with scoring model
Vendor response period — Typical duration: 3–4 weeks · Key output: Standardised proposals from each vendor
Evaluation & shortlisting — Typical duration: 1–2 weeks · Key output: Scored matrix, 2–3 shortlisted vendors
Scripted demos — Typical duration: 1–2 weeks · Key output: Demo scorecards per vendor
Reference checks & BAFO — Typical duration: 1–2 weeks · Key output: Validated references, best-and-final offers

The requirements-gathering phase is the one most often compressed, and compressing it is the one most often regretted. Every hour spent documenting requirements before the RFP goes out saves multiples of that hour in evaluation clarity and avoided change orders later.

From RFP to decision

The RFP produces a shortlist; the decision comes from validating it. After scoring, take your top two or three vendors through scripted demos, speak to non-hand-picked reference customers, and run a best-and-final-offer round on pricing. Then make the call on fit and five-year TCO, not on the strongest sales relationship.

If you would rather not author and run this process alone, our ERP services cover selection, requirements definition, and the implementation that follows. The RFP is the document that makes the rest of that process defensible; write it carefully, weight it honestly, and the right decision becomes far easier to see.