ERP requirements that vendors can price describe what the business must do, how often, for how many users and in which systems, in sentences that can be tested. Gather them from processes and volumes rather than feature lists, rank every item with a priority such as MoSCoW, and attach the numbers a vendor needs to size the work: users, sites, transactions, integrations and data to migrate.
When two ERP quotes differ by a factor of three, the cause is rarely that one vendor is cheap and the other greedy. More often each vendor guessed a different scope because the requirements said things like "must be flexible" and "integrates with our systems". This guide shows how to gather and write requirements so that quotes are comparable. It sits before the RFP stage: once your requirements are written, our ERP RFP template shows how to package them, and the ERP RFP scoring matrix shows how to mark the answers.
Why do ERP requirements fail to produce comparable quotes?
Four patterns account for most of the trouble.
- Features instead of outcomes. "Multi-warehouse inventory" can mean two warehouses with transfers or forty locations with bins, putaway rules and lot control. The price differs enormously.
- No volumes. A vendor who does not know whether you post 200 or 20,000 order lines a day must either assume or add a risk margin.
- Hidden integrations. "Connects to our website and bank" is two integrations of unknown size. Each needs a system name, a direction of data flow and a frequency.
- Everything is a must. If all 300 requirements are mandatory, no one can tell the vendor where to save effort, and vendors who disagree with your list will quietly drop out.
Step 1: start from processes, not from a feature list
Write down the end-to-end processes that run the business. For most organisations the list is short:
- Procure to pay: request, approval, order, receipt, supplier invoice, payment.
- Order to cash: quote, order, fulfilment, invoice, collection.
- Plan to produce or deliver: demand, planning, execution, completion.
- Record to report: transactions to ledger, close, statutory and management reporting.
- Hire to retire, where HR and payroll are in scope.
For each, run a short workshop with the people who do the work, not only the managers. Ask them to walk through last week's real transactions, including the exceptions: the short delivery, the price correction, the returned item, the customer who pays in instalments. Exceptions are where packaged software usually needs configuration or custom work, and where requirements documents are usually silent.
Capture for each process: the steps, who does each, what triggers it, what documents or data are produced, and which steps are the painful ones today. Our ERP implementation steps guide describes where this discovery fits in the wider project.
Step 2: write each requirement in a testable sentence
A good requirement has a subject, a condition, an outcome and, where useful, a measure. A simple pattern is: "When [situation], the system shall [behaviour], so that [business result]."
| Weak requirement | Testable requirement |
|---|
| The system must support approvals | A purchase order above an amount set by the finance manager must be approved by the department head, and by the finance manager above a higher limit, before it can be sent; approvers can approve from a phone |
| Good reporting | A daily stock valuation report by warehouse, ready by 07:00, that agrees to the general ledger inventory account |
| Integrates with our website | New web orders arrive in the ERP at least every 15 minutes, and stock levels are sent back to the website at least hourly; roughly 400 orders a day in the peak month |
| Flexible pricing | Customer-specific price lists with start and end dates, quantity breaks and a rule that the lowest applicable price wins unless the contract price is fixed |
| Multi-currency | Sales and purchases in three currencies, with daily exchange rates loaded from a named source and realised and unrealised differences posted automatically |
You do not have to write every sentence yourself. Many teams write the sentences for the 40 to 60 requirements that carry the most risk and cost, and describe the rest at a process level.
Step 3: prioritise with a scheme everyone understands
MoSCoW is a common scheme because it is easy to explain:
- Must: the business cannot operate or comply without it at go-live. Missing means failure.
- Should: important and expected soon after go-live; a workaround exists.
- Could: useful, but only if cost and time allow.
- Won't (this time): explicitly out of scope. Listing these protects the budget and shows vendors where not to spend effort.
Check the balance. If more than half of the list is Must, the prioritisation has not happened. A rough sense of proportion helps: a short list of true Musts, a larger group of Shoulds, and the rest Could or Won't.
Step 4: give the numbers a vendor needs to size the work
Add a sizing sheet to the requirements. These are the facts that move price and plan the most.
| Item | What to state |
|---|
| Users | Named users by role and the peak number logged in at once |
| Entities and sites | Legal entities, branches, warehouses, factories, countries |
| Currencies and languages | Which, and for which users |
| Transaction volumes | Orders, invoices, stock movements, journal lines per day or month, peak and average |
| Master data | Number of customers, suppliers, items or products, cost centres |
| Integrations | System name and version, direction, frequency, method if known, and who supplies the other side |
| Data migration | Which records, how many, how many years of history, current condition and format |
| Reports and documents | Number of statutory reports, invoices, labels and management reports, and which are must-haves |
| Hosting and security | Cloud, local servers or hybrid; access policy; audit and approval needs |
| Training | Number of people and sites to train |
Vendors that see this sheet can price with fewer assumptions. For migration specifically, our ERP data migration plan explains how to describe source data so it can be estimated.
Step 5: separate functional, non-functional and delivery requirements
Three groups are easy to confuse.
- Functional: what the system does (the examples above).
- Non-functional: how well it does it: response time under load, availability hours, backup and recovery targets, audit logging, access control by role, data retention, usability for occasional users.
- Delivery and commercial: what you want from the project and the contract: training, documentation, handover, support hours, data ownership, source code or escrow position, exit and data export.
State non-functional requirements with numbers where you can. "Fast" is not a requirement; "an order with 30 lines saves in under three seconds for 50 concurrent users" is one. If you do not know the right numbers, say so and ask vendors to propose them. That is a legitimate question in an RFP.
Step 6: say what you do not want
Experienced buyers include a short section on constraints and preferences: systems that must be kept, technology standards, a preference for configuration over custom code, an upgrade policy, or reluctance to depend on a single consultant. These statements shape the solution more than most feature lines, and they let you compare packaged, configured and custom options on one footing. The wider comparison is in our ERP versus custom development guide.
ERP requirements template in Excel or Google Sheets
A spreadsheet is the usual format for the requirement list, because vendors can answer in the same columns and you can filter by priority. Use one row per requirement and keep these columns:
| ID | Process | Requirement (testable sentence) | Priority | Volume or size | Systems involved | Owner |
|---|
| | | | | | |
A distributor's first rows might look like this (illustrative):
| ID | Process | Requirement | Priority | Volume or size | Systems involved | Owner |
|---|
| INV-01 | Inventory | Show stock by item, warehouse and bin, including stock reserved for open sales orders | Must | 9,000 active items, 3 warehouses | Barcode scanners | Warehouse manager |
| SAL-04 | Sales | Apply customer-specific price lists with start and end dates | Must | About 250 price lists | Online store | Sales manager |
| PUR-02 | Purchasing | Add freight and duty to the cost of received stock | Should | About 80 inbound shipments a month | Accounting | Finance lead |
A before and after example
Before: "The ERP must manage our warehouse and inventory, support multiple locations, and integrate with our online store. It should be easy to use and have good reports."
After, in outline:
- Three warehouses in two cities, around 9,000 active items. Transfers between warehouses need a shipped and received state. (Must)
- Lot numbers and expiry dates on about 20% of items, with first-expiry-first-out picking suggestions. (Must)
- Barcode scanning on handheld devices for receiving and picking. (Should)
- Online store orders import at least every 15 minutes; stock levels export hourly; around 400 orders a day at peak. The store is a named platform that exposes an API. (Must)
- A daily stock valuation by warehouse that agrees to the ledger. A slow-moving stock report with a configurable threshold. (Must for the first; Could for the second)
- Roughly 45 users in total, up to 20 working at once, and six of them warehouse staff using mobile devices. (Sizing)
The second version is longer, but a vendor can price it, and an evaluator can test it in a demo.
Common mistakes to avoid
- Writing requirements from the vendor's brochure, which pre-selects that vendor.
- Letting IT write the list alone. Finance and operations hold the exceptions.
- Leaving out reports. Missing reports are the most common surprise after go-live; our list of reports finance teams need from an ERP is a good checklist to start from.
- Mixing requirements with solutions, such as asking for a specific database or screen layout without a business reason.
- Freezing the list for months. A requirements baseline is useful, but allow a controlled change process.
How to validate the list before you send it
- Read ten random requirements aloud and ask whether you could test each in a demo. Rewrite any you could not.
- Ask someone outside the project to find the three most ambiguous lines.
- Walk one real transaction through the list from start to end and check that no step is missing.
- Check that every integration has a name, direction, frequency and owner.
- Check the Must count and the sizing sheet are complete.
How Timeline Digital uses requirements
Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan. For custom ERP work, the Understand and Plan steps produce a requirements and module list in this format, and we use it to choose the 2 to 3 key modules for the free pilot. The full project starts after you approve the pilot, and the scope, milestones and terms are agreed after it. If you are weighing a custom build against packaged products, our page on custom ERP development explains how we work. Timeline Digital does not publish prices for custom software, because every project is custom. We can sign an NDA before you share process detail. Support hours are Monday to Friday, 9:00 to 18:00 Pakistan time (PKT, UTC+5).
Checklist
- Processes listed and walked through with the people who do the work, including exceptions.
- Each high-risk requirement written as a testable sentence.
- Every requirement has a priority; Musts are a small, honest group.
- Sizing sheet complete: users, sites, volumes, master data, integrations, migration.
- Non-functional requirements stated with numbers or marked "vendor to propose".
- Constraints and out-of-scope items written down.
- Reviewed by finance, operations and IT before issue.