Procurement software requirements: how to build your list
Short answer
A procurement software requirements list is the set of testable statements that says what an e-procurement or source-to-pay system must do for your organisation, each with a priority, so you can compare products, write the RFP and accept the system.
Key takeaways
- A requirements list says what the system must do in your organisation, not what a vendor's product can do.
- Build it from your own process, along both lines: the purchase line (sourcing to payment) and the supplier line (registration to exit).
- Write each requirement so that a tester can check it in a demonstration or an acceptance test, and give it a priority.
- Decide early which system owns supplier, contract and catalogue data, the ERP or the procurement suite: many other requirements depend on it.
What is a procurement software requirements list?
It is a table, often a spreadsheet, with one line per requirement. Each line says who does what in the system, under which condition, and what result is expected. A good list also records the priority of each line, the person who asked for it and how it will be tested.
Requirements come in two kinds. Functional requirements describe what users and suppliers do in the system: raise a requisition, approve it, send a purchase order, match an invoice. Technical requirements (also called non-functional requirements) describe how the system must run: sign-in, security, hosting, integration with the finance system, performance, accessibility. Both kinds belong in the same list, because a product that runs your process but cannot connect to your ERP will still fail.
Here is a simple case. Today, an invoice arrives with no purchase order number, and accounts payable has to find out who ordered the goods. The requirement that follows is not “the system manages invoices”. It is: “an invoice without a valid purchase order number is returned to the supplier with the reason, and is not entered for payment”. A vendor can show this; a tester can check it.
- ID
- A short code per line (for example INV-07), so that vendors, testers and the project team speak about the same requirement.
- Area
- The module or stage it belongs to: sourcing, contracts, suppliers, requisition, order, receipt, invoice, payment, reporting, integration, security.
- Requirement
- One testable statement: actor, action, condition, expected result.
- Priority
- Must, should or could. A must is a line without which you cannot go live.
- Test
- How it will be checked: scripted demonstration, written answer with evidence, or acceptance test after configuration.
- Owner
- The person who asked for it and can say whether the result is acceptable.
When do you need a requirements list?
You need one each time you choose, change or check a system. The same list serves three moments, so it is worth building once and keeping up to date.
- Selecting software. The list becomes the core of the request for proposal (RFP) and of the demonstration scripts. Vendors answer each line, show the most important ones, and are scored on them. The procurement software guide explains the selection method around it.
- Implementing it. After the contract is signed, the list is the starting point for the configuration workshops. The same lines become the acceptance tests: the system goes live when the musts pass.
- Upgrading or re-tendering. When the software contract nears its end, or a new module is added, the list shows what the current system does, what it does not do, and what has changed in your process since.
A public buyer usually buys the software through a tender, or through a mini-competition on an existing framework agreement. In the EU, the requirements then go into the technical specifications, which are part of the procurement documents (Directive 2014/24/EU, Article 2(1)(13)). The buyer can still correct these documents before the deadline for tenders, but a significant change means giving bidders more time. In an open or restricted procedure there is no negotiation, so once tenders are in, the buyer cannot change the requirements in any way that matters, for example by dropping a must that no bidder meets. Below the EU thresholds, national rules apply. In all cases, finish the list before you publish the tender.
How do you build a requirements list, step by step?
- Scope the processes on both lines. On the purchase line: sourcing, contract, requisition, purchase order, receipt, invoice and payment. On the supplier line: registration, qualification, referencing (for example on a framework agreement or a panel), enablement (a supplier account in the ERP, verified bank details, an ordering channel), performance, risk and renewal or exit. Note which of these the new system must run in its first phase, with yearly volumes: requisitions, orders, invoices, tenders, contracts, active suppliers.
- Decide which system owns each master data. Supplier records, contracts, catalogues, cost centres and general ledger accounts each need one master: the ERP or the procurement suite. Write the decision down before writing the integration requirements; many other lines depend on it.
- Gather requirements from the people who do the work. Requesters, buyers, approvers, accounts payable, finance, IT, legal, and a few suppliers. Work from real cases, not from a blank page: an urgent order that skipped approval, a supplier paid to the wrong bank account, a contract that expired without anyone noticing.
- Write each requirement as a testable statement. One line, one behaviour: who does it, what they do, under which condition, and what result is expected. Split any line that contains “and”.
- Give each line a priority. Use must, should and could (the MoSCoW method adds “won't have this time”). Keep the musts few: each one is a reason to reject a product.
- Weight the areas. Musts are pass or fail. Shoulds and coulds are scored, and each area gets a weight that reflects your volumes and risks. Agree the weights before any vendor answers.
- Turn the key lines into scenarios. Group the most frequent and the most difficult cases into short stories for the demonstrations, and ask vendors to run them on your data where possible. Keep the same scenarios for the acceptance tests after go-live.
Supplier work starts before sourcing. A supplier registers and is qualified for a category; only then can the buyer invite it to a sourcing event. In a public open procedure, any supplier may bid, and the buyer checks the selection criteria with the tender. A referencing tender often sets up a framework agreement or a panel of several suppliers for some years. Specific needs then go to those suppliers as a request for quotation or a mini-competition. So write the supplier registration and qualification requirements first, then the sourcing requirements.
What does an e-procurement requirements list cover?
The table lists the usual areas of an e-procurement or source-to-pay requirements list, what to check in each, and one example requirement written as a testable statement. The examples are generic: adapt them to your organisation, its activities and its context. Use the table as a checklist of areas; your own lines come from your process.
| Area | What to check | Example requirement |
|---|---|---|
| Supplier registration and qualification | Self-registration, documents, qualification by category, statuses | A supplier that is not qualified for a category cannot be invited to a sourcing event in that category; the buyer sees the reason. |
| Sourcing (RFI, RFQ, RFP, e-auction) | Events, invitations, sealed bids, scoring, award | Before the deadline, no user can open a submitted bid; any attempt is recorded in the audit log. |
| Frameworks and contracts | Contract record, framework ceiling, call-offs, renewal dates | For a framework agreement, the contract record shows the maximum value and the total ordered against it, and alerts the contract owner at a threshold the owner sets. |
| Mini-competitions | Quick quotations among suppliers already on a framework | A buyer can launch a request for quotation from a framework; only the suppliers on that framework can be invited. |
| Requisition and catalogue | Catalogues, punch-out, free-text requests, approval routes | A requisition above the requester's approval limit goes to the next approver for that cost centre, and the approver sees the supplier and the price. |
| Purchase order | Sending, changes, revisions, supplier confirmation | A change to a sent purchase order creates a new revision, which is sent to the supplier again with the changes marked. |
| Receipt | Goods and services receipt, partial receipts, returns | The requester can record a partial receipt per order line; the remaining quantity stays open. |
| Invoice and matching | Capture, e-invoices, two-way and three-way match, tolerances | The matching rule follows the category: three-way match for goods, two-way match for categories without a receipt; an invoice outside the tolerance is blocked and sent to the buyer. |
| Payment controls | Bank details, payment blocks, segregation of duties | A change to a supplier's bank details needs approval by a second person, and payments to that supplier are held until it is approved. |
| Reporting | Spend by category, supplier and cost centre, process reports, export | A user with reporting rights can build a spend report by category and supplier and export it, without help from the vendor. |
| Integration with the ERP | Master data, orders, receipts, invoices, error handling | Supplier records and cost centres are updated from the ERP at least daily; a failed transfer appears in an error queue with the reason and can be sent again. |
| Security and access | Single sign-on, roles, audit trail | Users sign in through the organisation's identity provider (SAML 2.0 or OpenID Connect); the same user cannot approve a requisition and the invoice for it. |
| Hosting and data | Location of data, availability, backup, exit | At the end of the contract, the buyer can export all records and attachments in an open, documented format. |
| Accessibility and languages | Interface for users and suppliers, languages | The supplier portal meets WCAG 2.1 level AA and is available in the languages of the suppliers invited. |
| Public-sector specifics | Notices, sealed tenders, open data, e-invoicing | Contracting data is published in the Open Contracting Data Standard (OCDS); in the EU, the tender reception tool meets Annex IV of Directive 2014/24/EU and the system receives EN 16931 e-invoices. |
Write every line as something a vendor can show and a tester can check; leave out what no one will test.
Two-way or three-way match is not one setting for the whole organisation. A three-way match checks the invoice against the purchase order and the goods receipt; a two-way match checks it against the purchase order only. Which one applies depends on the category: goods delivered to a warehouse usually need a receipt, while a software subscription or a utility bill often has none. So the requirement depends on your category taxonomy, and the list should say which categories use which rule. The procure-to-pay guide explains each step and control on this line.
Public buyers add lines that private buyers rarely need. In the EU, tools that receive tenders electronically must, among other things, show the time and date of receipt and keep bids closed until the opening date (Directive 2014/24/EU, Annex IV). EU public buyers must also be able to receive and process e-invoices that follow the European standard EN 16931 (Directive 2014/55/EU). Outside the EU, national e-procurement rules set their own lines.
How do you write a requirement that can be tested?
A testable requirement names a user, an action, a condition and a result that anyone can observe. Avoid words that each reader understands differently, such as “easy”, “flexible”, “fast” or “user-friendly”. If a vendor can answer “yes” without showing anything, the line is not testable yet.
| Hard to test | Testable |
|---|---|
| The system is easy to use for requesters. | A requester with no training finds a laptop in the IT catalogue and submits a requisition for it, charged to their cost centre. |
| Flexible approval workflows. | Approval routes depend on amount, cost centre and category; the procurement administrator changes a limit without help from the vendor, and the change applies to new requisitions only. |
| Supports supplier management. | A supplier uploads an insurance certificate with an expiry date; the supplier manager is alerted before the expiry date, at a delay the manager sets. |
| Good integration with our ERP. | Each approved purchase order is created in the ERP with the same number, lines and accounts; the ERP's goods receipt is visible on the order in the procurement system. |
If the line names who, what, when and the visible result, a demonstration can prove it or disprove it.
What are the common mistakes in a requirements list?
- Copying a vendor's feature list. It describes one product, so that product meets every line. Start from your process and your cases instead.
- Untestable wording. Lines such as “the system shall be intuitive” collect a “yes” from every vendor and decide nothing.
- No priorities. Hundreds of lines with the same weight hide the few that decide the choice. Mark the musts and weight the rest.
- Ignoring master data ownership. If no one has decided whether the ERP or the suite owns supplier records, contracts and catalogues, the integration lines will contradict each other, and the problem appears during the project, not during the selection.
- Forgetting the supplier side. Suppliers register, answer tenders, receive orders and send invoices in the system. Their portal, languages and costs belong in the list.
- Leaving out exceptions. A price above the order, a partial delivery, a changed bank account, an invoice without an order: these cases cost the most time, so they deserve lines and demonstration scenarios.
To compare products once the list is ready, see how to choose source-to-pay software and procure-to-pay software. For the supplier and contract areas, the supplier management and contract management guides describe the process the lines should follow.
Is there a procurement requirements generator on this page?
Not yet. A free procurement requirements generator is being built for this page: you will choose the areas in your scope and get a starting list of testable requirements to adapt. Until it is ready, the table above gives the areas and one example line for each, and the steps show how to complete the list from your own process.
Questions
What is the difference between functional and technical requirements?
Functional requirements describe what users and suppliers do in the system, such as approving a requisition or matching an invoice. Technical requirements, also called non-functional requirements, describe how the system runs: sign-in, security, hosting, integration with the ERP, performance and accessibility. A procurement software requirements list needs both.
How many requirements should an e-procurement requirements list contain?
There is no right number. The list needs enough lines to cover the processes in scope, with every must tested. Very long lists tend to collect “yes” answers from every vendor and hide the lines that decide the choice, so it helps to keep the musts few and to turn the key lines into demonstration scenarios.
Can I use a vendor's requirements template?
You can read it to check that no area is missing, but do not use it as your list. A vendor's template follows that vendor's product, so its lines favour that product. Write your lines from your own process, cases and volumes, then check the template for areas you forgot.
Who owns the requirements list during a software project?
The project team owns the whole list, and each line has an owner from the business: a buyer, an approver, accounts payable, IT. The owner of a line decides whether the vendor's answer, and later the configured system, meets it.