How to Write an ERP RFP (with Sample Questions and Scoring Weights)

Buying an ERP system is one of the largest and longest-lived software commitments a business makes. It touches finance, operations, and often every department, so a rushed or vague purchase is expensive to unwind. A well-written ERP RFP is how serious buyers turn a fuzzy shopping exercise into a fair, comparable competition between vendors.

This guide gives you a copy-usable RFP structure with real example questions for each section, a sample scoring model, an honest look at how the major vendors typically respond and price, and the red flags that should make you pause.

What is an ERP RFP?

An ERP RFP (request for proposal) is a structured document you send to a shortlist of vendors. It describes your organization, your goals, and your requirements, and it asks each vendor to respond with a proposal covering how their system would meet those needs, how they would implement it, and what it would cost.

The point is comparability. When every vendor answers the same questions in the same format, you can score bids side by side instead of being swayed by the slickest sales demo. A good RFP also forces your own team to agree on what you actually need before you talk to anyone.

When to use an RFP (and when not to)

An RFP is worth the effort when the stakes and complexity justify it:

• The budget is significant and the system will run core operations for years.
• Several departments or sites have competing requirements that must be reconciled.
• You operate in a regulated industry with compliance or audit obligations.
• Procurement, a board, or investors require a documented, defensible selection.

A full RFP is overkill when your needs are simple or clearly scoped. A smaller business replacing a single accounting tool, or a team that already knows its two or three finalists, is usually better served by a lighter path: a prioritized requirements checklist, targeted demos, and hands-on trials. Our guide on how to choose ERP software walks through that lighter process in detail.

One practical note before you write anything: only send the RFP to vendors whose segment actually matches yours. Sending an RFP for a 40-person distributor to SAP S/4HANA, or a 5,000-person multinational manufacturing RFP to Odoo, wastes everyone’s time and produces responses you cannot use.

Sample ERP RFP structure with example questions

The skeleton below is a working structure you can lift directly. For each section, the example questions are the kind that separate strong vendors from weak ones. Copy the ones that fit, cut the rest, and add your own specifics.

1. Introduction and instructions

Purpose of the RFP, submission format and deadline, your single point of contact, the question-and-answer window, and whether you will hold a bidders’ call. Also state clearly how you will score responses (see the weights below). Vendors write better proposals when they know the rules.

2. Company background and project context

Give vendors enough to tailor their response: industry, revenue band, headcount, number of ERP users by role, sites and legal entities, current systems (name them: QuickBooks, Sage 50, a legacy AS/400 app, spreadsheets), and the business drivers behind the project. Explain why you are buying now. A vendor who understands that your trigger is “our accounting system cannot consolidate three new entities” writes a very different proposal than one guessing.

3. Functional requirements

This is the heart of the RFP. List required capabilities by module and mark each as must-have or nice-to-have. Ask vendors to answer each line with one of four codes: standard out of the box, configurable without code, requires customization, or not available. That four-code scale matters; a plain yes/no lets everything get answered “yes.”

Example functional questions worth stealing:

• “Describe how the system handles multi-entity consolidation with intercompany eliminations. Is this standard, and in which edition or module?”
• “Walk through your month-end close process step by step, including subledger close, allocations, and consolidation. What is a realistic close timeline for a company of our profile?”
• “How does the system manage lot and serial tracking through receiving, production, and shipment? Is full backward and forward traceability standard?”
• “Show how a change to a sales order after partial fulfillment flows through inventory commitments, invoicing, and revenue recognition.”
• “Which of our listed reports are available out of the box, which require report-builder configuration, and which require developer work?”
• “What functionality on our must-have list is on your roadmap rather than shipping today? Give the committed release, not an intention.”

That last question is important. Vendors routinely answer requirements with roadmap features. Force them to separate what exists from what is promised.

4. Technical and integration requirements

Spell out deployment (cloud, on-premise, hybrid), data residency, security certifications you require (SOC 2, ISO 27001), user and transaction volumes, and every system the ERP must integrate with.

Example technical questions:

• “For each integration we listed (name your CRM, e-commerce platform, payroll, banking, EDI, WMS), state whether a prebuilt connector exists, who builds and maintains it, and what it costs annually.”
• “Describe your API: protocol, rate limits, and whether all data objects we would use are readable and writable through it.”
• “How are customizations handled through version upgrades? Who is responsible for retesting them, and at whose cost?”
• “What are your uptime SLA, your penalty for missing it, and your maintenance-window policy?”
• “If we leave, how do we get our data out? Describe format, completeness, cost, and how long you retain our data after termination.”
• “Where is our data physically hosted, and can we require a specific region?”

The upgrade question deserves emphasis. How customizations survive upgrades is one of the biggest long-term cost drivers in ERP ownership, and it differs sharply by product: NetSuite and Dynamics 365 push you toward supported extension frameworks that survive updates, while heavily customized Odoo Community deployments and older on-premise systems can turn every version upgrade into a paid project.

5. Implementation approach

Ask vendors to describe methodology, phasing, a realistic timeline for a company of your profile, the named roles they will staff, and exactly what they need from your team in hours per week. Include:

• “Provide a phase-by-phase timeline with the internal effort you expect from our finance and operations staff at each phase, in hours per week.”
• “Who performs data migration, what do you need from us, and how many mock migration runs are included before go-live?”
• “Will the consultants named in this proposal be the consultants on our project? What is your staff turnover on engagements like ours?”
• “Describe a project of similar size and industry that went over budget or over schedule, and what you changed as a result.”
• “What is your go-live approach: big bang, phased by module, or phased by site, and why for us?”

The “project that went badly” question is a strong filter. Confident implementers answer it honestly; weak ones dodge it.

6. Support and maintenance

• “Describe support tiers, hours, channels, and response times by severity, and state which tier is included in the quoted price.”
• “Is first-line support delivered by you or by the implementation partner? Who do we call when the two disagree about whose problem it is?”
• “How often do you release updates, are they mandatory, and how much notice and testing time do customers get?”
• “What does your customer success or account management model look like after go-live, and is it a paid add-on?”

7. Pricing request

Ask for a complete, itemized cost breakdown in a fixed format you supply, not the vendor’s own quote template. Require, as separate lines: software subscription or license by user type and module, implementation and configuration, data migration, integrations (per integration), training, first-year support, and years two and three of everything. Then require a single total cost of ownership figure over three and five years.

Two questions that expose the games:

• “State the renewal price cap in writing. What is the maximum percentage increase at renewal, and will you contract to it?”
• “List every assumption behind your services estimate. What happens to the price if an assumption proves wrong, and at what daily or hourly rate is out-of-scope work billed?”

First-year discounts with steep renewal increases are a standard pattern in subscription ERP; NetSuite in particular is well known among buyers for aggressive first-term pricing followed by significant renewal uplift unless a cap was negotiated up front. Get the cap in the proposal, while you still have leverage.

8. Vendor background and references

• “How many live customers do you have in our industry and within 50 percent of our revenue and user count?”
• “Provide three reference customers of similar size and industry who went live in the last two years, including at least one who used the same implementation team proposed here.”
• “What is your customer retention rate, and what share of implementations in the last two years went live within the originally quoted budget?”
• “Summarize your product roadmap for the modules we are buying, over the next 24 months.”

9. Evaluation criteria, scoring, and timeline

Tell vendors how you will judge responses and what weight each area carries, then lay out the calendar: RFP issue date, question deadline, response due date, demo window, and target decision date. Publishing your criteria signals a serious process and pushes vendors to spend their effort where you actually care.

Example scoring weights

Build the weighted scoring matrix before responses arrive, so scoring reflects your priorities rather than the mood on the day. A sensible starting point for a mid-market buyer:

Adjust to context. A manufacturer with complex shop-floor requirements might push functional fit to 35 or 40 percent. A multi-entity group burned by a past integration failure might raise technical fit. What you must not do is adjust weights after reading responses; that converts a scoring model into a rationalization engine.

Score on a simple 0 to 5 scale per criterion, have each evaluator score independently before any group discussion, and require written justification for any 0 or 5. Multiply scores by weights, then, critically, treat the result as an input to judgment rather than a verdict. A vendor that fails a genuine must-have is out regardless of a strong weighted total.

How the major vendors typically respond and price

Knowing the standard shape of each vendor’s proposal helps you normalize them into one comparison. These are structural patterns, not quotes; always confirm current packaging and pricing with the vendor.

NetSuite (Oracle) sells a cloud-only annual subscription assembled from a base platform fee plus user licenses plus module add-ons, quoted through a sales rep rather than published. Proposals often lead with the SuiteSuccess implementation methodology, a fixed-scope, industry-templated rollout that can be genuinely fast for companies willing to adapt to its defaults. Watch the term structure: first-term discounts can be steep, and renewal increases are the classic NetSuite gotcha, so score the renewal cap, not the year-one number. Implementation may come from NetSuite Professional Services or from a solution-provider partner; make the proposal say which, because accountability differs.

SAP S/4HANA proposals for the cloud typically arrive as RISE with SAP (or GROW with SAP for mid-market public cloud), a bundled subscription covering software, infrastructure, and some services, with users counted in full user equivalents (FUEs) rather than simple seats. The implementation itself is usually proposed by a system integrator (the large SIs and specialist SAP partners), and services routinely dwarf the software line. Expect the most formal, thorough RFP responses of the four, and the longest timelines. If your RFP is mid-market sized, be skeptical of any S/4HANA response that promises SMB-style speed; the product’s strength is deep, industry-grade process coverage for complex enterprises, not lightweight deployment.

Microsoft Dynamics 365 is the most transparent on software pricing: per-user per-month prices are published, with a base-and-attach model where the first app is full price and additional apps for the same user are discounted. The key clarification to force in your RFP: which product is actually being proposed, Business Central (the SMB and lower mid-market product) or Finance and Supply Chain Management (the enterprise-grade apps)? They are different systems with different cost profiles, and partners sometimes blur the line. Nearly all implementation comes from the partner channel, so you are really evaluating the partner as much as Microsoft; two Dynamics proposals for the same RFP can differ mainly in partner quality and services estimate.

Odoo publishes low per-user subscription pricing for its Enterprise edition, and the open-source Community edition is free software with no vendor support. Odoo proposals therefore look dramatically cheaper on the software line, and that part is real. The honest counterweight: functional depth in areas like complex multi-entity consolidation, advanced warehousing, and regulatory localization often depends on configuration and custom modules, so the services line and the ongoing cost of maintaining customizations through Odoo’s annual version releases carry more of the true TCO. Ask an Odoo partner specifically who upgrades custom modules each version and at what cost. For a company with straightforward processes and in-house technical comfort, Odoo’s economics can be excellent; for a complex operation expecting everything out of the box, the gap between the subscription price and the real cost is the thing to score.

The practical upshot for your RFP: demand the same fixed cost-breakdown format from all four, including years two and three, or you will end up comparing a NetSuite bundle against a Microsoft license list against an SI’s services estimate against an Odoo subscription, and none of the numbers will line up.

Red flags in vendor responses

Score the response, but also read it for warning signs. These recur across ERP selections:

• “Yes” to everything. No ERP covers every requirement as standard. A response with no “requires customization” or “not available” answers means the vendor did not read carefully or is answering aspirationally. The best responses say no somewhere.
• Roadmap answers to must-haves. “Planned for a future release” counts as not available today. Score it that way.
• A services estimate far below the pack. If three vendors quote comparable implementation effort and one is half the price, the low bidder has usually assumed away scope (your data is clean, your team does the testing, integrations are “out of scope”). Read their assumptions list; the money reappears in change orders.
• No named implementation team. Proposals staffed by “senior consultants TBD” often mean bait-and-switch staffing. Ask for names and CVs, and a substitution clause.
• Vague data migration language. “We will assist with migration” is not a commitment. You want stated responsibility, included mock-run counts, and a price.
• Silence on renewal terms. A proposal that details year one and goes quiet on years two and three is hiding the uplift. No written renewal cap, no signature.
• Generic references. References in different industries, at ten times your size, or from five years ago tell you nothing. Insist on recent, comparable, and at least one from the proposed implementation team.
• Dodging the exit question. Any hedging on data export, retention, or termination assistance is a preview of how the relationship ends.
• Pressure to skip your process. A vendor who pushes to “just do a demo” instead of answering the RFP, or who offers a discount that expires before your stated decision date, is optimizing for their quarter, not your fit.

Common ERP RFP mistakes to avoid

• Vague requirements. “Strong reporting” means nothing; specify the reports, dimensions, and data you need.
• No prioritization. If everything is a must-have, nothing is, and you disqualify good options for trivial gaps.
• Copy-paste boilerplate. Generic RFPs get generic responses. Vendors triage inbound RFPs, and a 200-line unprioritized feature list signals a buyer not worth a serious bid.
• Free-text answers where you needed structure. Require the four-code functional scale and your fixed pricing format, or responses will not be comparable.
• Ignoring total cost of ownership. The license is a fraction of the real bill; implementation, integration, and support dominate.
• Skipping the demo and references. A great written response is not proof the software works for you. Move finalists to scripted demos of your workflows, not the standard tour.
• Unrealistic timelines that push vendors to cut corners or decline to bid. Two to three weeks to respond is the workable minimum for a real ERP RFP.

Copy-ready ERP RFP section checklist

Use this as the skeleton of your document:

1. Introduction and instructions: purpose, submission format, deadlines, contact, and scoring approach.
2. Company background: industry, size, sites, entities, users by role, and current systems by name.
3. Project goals and success criteria: measurable outcomes you expect.
4. Scope: modules, departments, and locations in and out of scope.
5. Functional requirements: prioritized must-have or nice-to-have, answered on the four-code scale.
6. Technical requirements: deployment, security, compliance, volumes, and upgrade policy for customizations.
7. Integration requirements: every system the ERP must connect to, with connector, ownership, and cost per integration.
8. Implementation expectations: methodology, phased timeline, named team, migration plan, and your team’s required effort.
9. Support and maintenance: SLAs, channels, update policy, and what the quoted tier includes.
10. Pricing request: itemized costs in your fixed format, three-and-five-year TCO, renewal cap in writing.
11. Vendor questions: industry customer base, retention, references, roadmap, exit and data-ownership terms.
12. Evaluation criteria and scoring: your weighted model, published to bidders.
13. Timeline and next steps: key dates through to decision.

Getting to a shortlist faster

An ERP RFP rewards a clear process, but you do not have to start from a blank page or send it to the wrong vendors. If you want help building a credible shortlist before you issue the RFP, you can get free advice from independent SoftwareSelect advisors who match your requirements to fitting systems, no cost and no sales pressure. Their input can shortcut a full RFP entirely for simpler needs, or complement one by narrowing the field first. You can also browse ERP software to see the main contenders and start turning your requirements into a strong request for proposal.