Do we need a formal RFP to buy an ERP?

Not always. A formal RFP earns its cost when several vendors are genuinely in contention, when procurement rules require it, or when the internal decision needs a documented basis. For a small business with two candidates, a structured requirements list and two scripted demos usually produce a better decision faster.

What should an ERP RFP actually contain?

Enough context for a vendor to size the work honestly, requirements written as processes rather than features, and questions whose answers can be checked. That means your transaction volumes, your integrations, your data condition, your timeline, and a scripted demo scenario built from your own records.

What do buyers most often leave out of an ERP RFP?

Data condition, integration inventory, and who does the work internally. Vendors price against clean data and available client staff, and both assumptions are usually wrong, which is where overruns start rather than in the software.

How many vendors should we invite?

Three to five is usually right. Fewer than three and there is no comparison; more than five and the evaluation cost exceeds what the extra options are worth, and every vendor gets less of your attention during demos.

Should we ask for a fixed price?

Ask for a fixed price on a defined scope, plus an hourly rate and a change process for everything else. A fixed price on undefined scope is priced with a risk premium you pay whether or not the risk occurs, and it makes the vendor resist exactly the discovery that would have improved the outcome.

ERP RFP Template and Requirements Checklist

Q: Why write requirements as processes rather than features?

A feature list invites a yes-or-no grid that every vendor passes, because almost everything is technically possible in almost every system. A process description forces a demonstration, and a demonstration shows how many steps it takes and whether the answer is native or custom.

Quick answer: a good ERP RFP gives vendors enough context to size the work honestly and asks questions whose answers can be checked. Write requirements as processes rather than features, include your real volumes and data condition, and script the demo from your own records.

When an RFP Is Worth the Effort

An RFP is expensive on both sides. It earns its cost when several vendors are genuinely in contention, when procurement rules require a documented process, or when an internal decision needs a defensible basis.

For a small business with two candidates already, a structured requirements list plus two scripted demos usually produces a better decision faster than a formal document. Do not run an RFP as ceremony. A process nobody believes in produces proposals nobody reads.

The Structural Mistake Most RFPs Make

Most ERP RFPs are a feature matrix, and a feature matrix is answered “yes” by every vendor, honestly, because almost everything is technically possible in almost every system.

The matrix cannot distinguish between:

Native, working today, out of the box
Configurable, with effort
Achievable through a third-party app
Custom development
Technically possible and nobody has done it

Those are wildly different costs and every one of them appears as a tick.

The fix is to write requirements as processes and demand demonstrations. “Show us a purchase order raised against a customer order, received partially, with duty and freight applied to the receipt, invoiced against the vendor bill” cannot be answered with a tick. It gets answered by clicking, and you count the steps.

RFP Structure

1. About us

Enough for a vendor to size the work rather than guess:

What the business does, and the revenue band
Employee count, and how many will use the system
Locations, legal entities, and currencies
Industry, and any regulatory obligations
Why you are looking now, and what happens if nothing changes

2. Current systems

What runs today, by function
Which systems stay and which are being replaced
Every integration that exists now, including the ones held together by a person
The honest condition of your data. Duplicates, gaps, inconsistent naming. Vendors price against clean data and it is almost never clean.

3. Volumes

Give real numbers here. Adjectives cannot be priced against:

Transactions per month by type: sales orders, purchase orders, invoices, work orders
Active SKUs, customers, suppliers
Concurrent users at peak
Years of history to migrate, and years to keep accessible
Documents per month, if attachments matter

4. Requirements as processes

Group by function, and describe the flow end to end. For each, state whether it is mandatory, important or desirable, and be disciplined: if everything is mandatory the categories carry no information.

Include the exception paths, which is where systems actually differ. A partial shipment, a return after invoicing, a change order mid-job, a credit note against a closed period.

5. Integrations

For each: the system, direction of flow, what data, how often, and who owns it today. Ask vendors to state which are native, which need middleware, and which need building.

6. Reporting

Name the reports somebody actually needs and cannot currently produce. Ask for them to be demonstrated rather than described.

7. Implementation approach

Proposed phases and what is live at the end of each
Named roles on the vendor side, with the fraction of their time
What they need from you, by role and hours per week
Data migration approach, and who cleans the data
Training approach and who is trained
Cutover plan and the fallback if go-live fails

8. Commercials

Licensing, by user type, per year for three years
Implementation cost, itemised by phase
The hourly rate for work outside scope, and the change process
Annual support cost and what it includes
Total three-year cost, which is the number worth comparing

9. The questions that separate vendors

Include these verbatim. They are hard to answer with marketing.

How many implementations of this exact product have you completed, and how many are live today?
Name the person who will configure our chart of accounts and inventory valuation, their last three projects on this product, and what else they are on during ours.
Tell us about the last three customizations you talked a client out of, and the native mechanism you used instead.
What in this product have you been burned by? Name a version.
On your last five projects on this product, what was the estimate at signing and what was the final invoice?
For clients you implemented two or more years ago, how many are on a currently supported version, and who paid for the upgrade?
What would make you tell us this product is the wrong answer?
What is the smallest paid piece of work we can buy from you first, and what does it cost?

10. The scripted demo

Do not let vendors demo their own scenario. Send one built from your records:

One real customer order through to cash, including a partial shipment
One real purchase through to payment, including a price variance
One month-end task somebody currently does by hand
One report that is currently impossible
One exception: a return, a change order, or a credit against a closed period

Every vendor runs the same script, and you compare like with like.

Requirements Buyers Forget

Gathered from where implementations go wrong rather than from a feature taxonomy:

Who cleans the data, and when. It is always more work than anyone plans.
Document storage and retention, including how long records must be kept.
Approval workflows that mirror who actually signs things off.
Period close and lock, and who can post to a closed period.
Audit trail, and whether it survives a record being edited.
Personal information handling under PIPEDA and any provincial equivalent, including where data is stored.
Upgrade obligations. Ask what happens to customisations at the next version. Odoo, for example, documents that a database containing custom modules cannot be upgraded until a version of those modules exists for the target release. Most products have some version of this and few RFPs ask.
Exit. How you get your data out, in what format, and what it costs.
Sandbox availability for testing after go-live.

Evaluating What Comes Back

Score against your stated priorities rather than on impressions, and record why each score was given.

Three signals worth weighting heavily:

Did they ask questions before quoting? A vendor who priced a complex operation without a single clarifying question has priced a guess.
Did they say no to anything? A proposal where everything is possible and nothing is difficult has not been read properly.
Is the estimate a range with named assumptions, or a single number? A single number on an undefined scope is a negotiating position.

Then check references yourself, at companies your size in your industry, and ask them what went wrong rather than what went well.

What Is ERP? covers the category before a shortlist exists.
Software Evaluation Checklist covers the lighter-weight version of this process.
Canadian Business Software Buying Guide covers the decision before the RFP.