A clear list of requirements is one of the most useful protections a business has when it chooses ERP. It turns a sales conversation into a comparison of like with like, and it stops the project drifting towards whatever the most polished demonstration happened to show.
This ERP requirements checklist covers the groundwork: mapping processes, separating must-haves from nice-to-haves, defining reports, listing integrations, setting access rules and preparing questions for suppliers. It is written for the people who will draft the brief and sit in the room with vendors.
The list works best when the people who run the work help write it, not only the person who has been handed the project. Treat the output as a brief that can be shared, challenged and scored, rather than a wish list that grows every week.
ERP requirements start with processes, not software
A requirement describes what the business needs to happen. A product is only one way of making it happen, so the process comes first.
Map how work moves from end to end
Draw each core process from its trigger to its result, showing every handoff. Common starting points are enquiry to invoice, purchase request to payment, goods in to goods out and month-end close. Note where information is created, where it is changed, where approvals sit and where delays happen. A rough diagram on a whiteboard is enough at this stage.
Name the people in each step
For every step, record who does the work, who approves it and who needs to see the result. Role names are more useful than personal names, because people move on. Unclear ownership often shows up here first, such as two departments each assuming the other will correct an error. Where a step has no clear owner, flag it, because those gaps are usually the source of delays that a new system cannot fix on its own.
Must-haves versus nice-to-haves
Requirement lists become unmanageable when everything is marked as essential. A simple test keeps the list honest.
A simple test for a must-have
A requirement is a must-have if the business cannot run the process safely, legally or accurately without it, or if its absence would cause a failure that matters. Ask what would happen on the first day if the function were missing. If the answer is that work would stop or a serious error would follow, it belongs in the must-have list. If people would simply be less comfortable, it does not. A useful check is to ask the process owner to walk through the step without the function, out loud, and note where they would stop.
Rank the rest rather than listing it
Sort everything else into important and optional groups, and be honest about the difference. Important items shape the choice between suppliers and belong in the scoring. Optional items can wait for a later phase. A short scale keeps the discussion grounded:
- Must-have: the process cannot run safely without it
- Important: the process works, but with real friction or risk
- Optional: useful, but it can wait for a later phase
- Not needed: requested, but no current process depends on it
Agree the scale before the supplier meetings begin, so the labels cannot be changed to suit a preferred product.
Reporting requirements people will actually use
Reporting is often treated as an afterthought, yet it is frequently why the project started. It deserves the same precision as the processes it measures.
Start from the questions managers ask
List the questions managers ask every week, such as which stock is running low, which orders are late, what is owed and to whom, and where purchasing spend is building up. Each question points to a report. Any report that answers no real question should be challenged before anyone builds it. Also note who asks each question and what they do with the answer, because a report that changes no decision is a candidate for removal.
Define each report properly
A report requirement needs more than a title. For each one, record its purpose, its audience, the data it draws on, how often it is needed, the filters it must offer and the format it must come out in. A printed pack for a meeting is a different job from a data export for analysis. Use this list for every report:
- Purpose, and the decision it supports
- Who receives it and who can change its filters
- Data sources, and the date each figure should reflect
- Frequency: live, daily, weekly or month-end
- Output format, such as on screen, PDF or spreadsheet export
Integrations and data flows
An ERP rarely works alone. Every system that touches its data needs to be named, with a clear view of what moves between them and how often.
List every system that touches the data
Include accounting packages such as Xero or Sage, ecommerce platforms such as Shopify, CRM tools such as HubSpot or Salesforce, payroll, banking files, shipping tools and any spreadsheets that feed or receive records. Missing one of these at the requirements stage usually produces an unwelcome surprise later. Ask each department to name the tools it uses day to day, not only the ones on the official list, because the informal tools often carry the most important data.
Specify direction, timing and ownership
For each connection, state which system is the source of truth for each type of data, the direction of the flow, whether it runs in real time, on a schedule or by hand, and who checks that it is working. Customer contact details might flow from the CRM into the ERP, while stock levels flow the other way to the online store. Be explicit, because every ambiguity turns into a support question later. A useful integration requirement covers:
- The source of truth for customers, products, prices, stock and orders
- The direction of each flow, one way or two way
- The timing of each flow: real time, scheduled or manual
- How failures are handled, and who receives the alerts
Access, approvals and data protection
Access rules define who can see, change and approve what. They are far easier to design on paper than to repair after go-live.
Roles and approval limits
Describe roles by responsibility, such as buyer, warehouse supervisor, finance approver or sales manager. For each role, state what it can view, create, change and approve. Approval rules should say which types of transaction need a second person, so the rule is clear to staff and suppliers alike. Keep roles few and understandable, because a long list of narrow roles is harder to maintain and tends to produce exceptions.
Personal data and supplier terms
The requirements should say what personal data the system will hold, such as customer contacts, supplier contacts or staff details, and who needs access to each category. Put the data protection questions to each supplier directly: where the data is stored, who can reach it and what contract terms apply. Guidance from the Information Commissioner's Office can help frame those questions. Take professional advice on your own situation before you finalise the requirement, because obligations depend on the data and the way it is used.
An audit trail the business can actually use
Decide what the business must be able to see afterwards, such as who changed a price, who approved a purchase or when a stock adjustment was made. Write down how long that history must be kept and who is allowed to review it. A requirement without a retention rule leaves the question open until an audit or dispute forces an answer. Finance reviewers and auditors will ask for this history, so it is worth specifying before the contract is signed.
Questions to ask suppliers
Once the requirements are written, they become the basis for supplier questions. Good questions are specific, ask for examples and check whether the answer can be shown in the product itself.
Questions about the product
Ask suppliers to show, not just tell. Useful questions include:
- How would you handle this specific process, step by step, in the live system?
- How are new fields, approvals and reports added, and who can do it?
- How are updates released, tested and communicated?
- How can data be exported, in which formats and how often?
- How are integrations built, monitored and maintained?
Questions about the partner
The people who deliver the system matter as much as the software. Ask for written answers on anything that affects the contract. Useful questions include:
- Who will do the configuration, and who will be your day-to-day contact?
- What training is included, and how is it delivered?
- What documentation does the business receive at handover?
- What support hours and response expectations are included?
Turning the ERP requirements checklist into a brief
The output of this work is a brief that every supplier can answer in the same way. It should be short enough to read in one sitting and specific enough to score.
Structure the document
A practical structure begins with the business context, then the process maps, the must-have list, the important and optional lists, reporting, integrations, access and approvals and finally the supplier questions. Each section should link back to the process it supports, so that nothing floats free of the work it is meant to serve.
Keep the wording plain. Requirements written as needs, for example approving purchases above a set value, are easier to answer than requirements written as product features.
Compare like with like
Give every supplier the same scripted scenarios drawn from your own processes, such as raising a purchase order, adjusting stock after a count or running the month-end report. Score each response against the written requirement, not against how impressive the demonstration looked. Keep notes from every session so the decision can be explained afterwards. Ask each supplier to score the same scenario, and keep the scores in one shared sheet so the comparison stays honest.
FAQ
What should an ERP requirements checklist include?
It should cover the core processes, the people involved in each step, the must-have functions, reporting needs, integrations, access and approval rules and data protection requirements. Each requirement should describe what the business needs to happen, not which feature it expects a product to have. Keep the list short enough that people will actually read it.
What is the difference between a must-have and a nice-to-have ERP feature?
A must-have is something the business cannot run safely, legally or accurately without. A nice-to-have improves efficiency or convenience but can wait for a later phase. Agree the split with the people who will use the system every day, not only with the managers who sponsor the project.
How detailed should ERP requirements be?
Detailed enough that two suppliers would read the same requirement and understand it the same way. Start with the processes that cause the most friction, then add detail wherever a supplier's answer could change the decision. Avoid writing requirements that describe a particular solution rather than a need.
Should we ask ERP suppliers for a demonstration?
Yes, but use scripted scenarios based on your own processes rather than a standard demonstration. Give each supplier the same scenarios, such as raising a purchase order or running a stock report, and watch how the system handles them. Ask them to show the steps, not only the final result.
What questions should I ask an ERP supplier?
Ask how the system handles your most important processes, how changes and updates are managed, how data can be exported and how integrations are maintained. Also ask who will do the work, how training and handover are handled and what support covers. Request written answers wherever an answer affects the contract.
Who should help write the ERP requirements?
Include the people who run each process day to day, along with finance, management and whoever looks after IT. Each area should own its own requirements, because a single person writing the whole list tends to miss the handoffs between departments. Review the finished draft with the same group before it goes to suppliers.
Final thought
An ERP requirements checklist is not paperwork for its own sake. It is the point where the business decides what it needs before anyone argues about what a product can do. Processes come first, must-haves are kept to a deliberate minimum, reports are defined by the decisions they support, and every connection has a name and an owner.
Once the list is agreed, keep it under control. It becomes the reference for supplier conversations, for testing, for the migration plan and for the review that follows go-live, so it earns its place as a working document.
If you would like a second opinion on your requirements, Mirex Agency is ready to help. Our senior-led team builds ERP solutions for UK small and mid-sized businesses, and we can help turn your processes into a brief that suppliers can answer clearly. You can start that conversation at hello@mirexagency.com.
