Creating an ERP Requirements Spec: Guide & Template

An ERP requirements spec is the document in which you describe all requirements for your future ERP system from the client's perspective – before you even talk to vendors. It answers the question "What should the system be able to do?", not "How will it be implemented?". A clean requirements spec makes proposals comparable, prevents costly misunderstandings, and is the most important foundation of any ERP selection. In this guide you'll learn how a requirements spec is structured, how to weight must-have and nice-to-have criteria, and how to create your own in six steps – including a structural template.

What is an ERP requirements spec?

The requirements spec describes the totality of the client's requirements for a system. It originates on your side, before a vendor enters the picture, and is sent identically to every system in the comparison. That way you receive proposals that all reference the same basis and are genuinely comparable.

A good requirements spec is written in a solution-neutral way. You describe what has to happen – for example "The system must automatically invoice partial deliveries" – but not with which module or which technology. The technical solution is the vendor's job. That keeps the competition open and stops you from prematurely committing to a particular implementation.

The effort pays off: anyone who walks into demos without a requirements spec gets led by user interfaces instead of real requirements. With one in hand, you run every ERP selection in a structured way and can prove in the end why a decision was made.

Requirements spec vs. functional spec – the difference

The two terms are often confused, but they refer to two different documents in different project phases.

• The requirements spec comes from the client (you). It gathers the requirements and formulates the "what".
• The functional spec comes from the contractor (the ERP vendor). As a response to your requirements spec, it describes how the requirements will be implemented in concrete terms – the "how".

Put simply: you write the requirements spec, the vendor answers with the functional spec. The functional spec later becomes part of the contract and is the reference for acceptance. That's exactly why your requirements spec has to be precise – it's the template all later commitments refer back to.

Structure of an ERP requirements spec: the template

A requirements spec follows no legal norm, but a proven structure helps you forget nothing and give vendors a clear framework. Use the following template as a chapter skeleton.

1. Scope and starting point

Describe your company: industry, size, locations, headcount, revenue order of magnitude and current system landscape. State the goals of the project and the rough timeframe. Vendors need this context to realistically assess effort and fit.

2. Processes and functional requirements

The heart of it. Walk through your business processes and derive concrete requirements for each area. Typical chapters:

• Purchasing & procurement: ordering, supplier evaluation, invoice verification
• Warehouse & logistics: inventory management, picking, multi-warehouse
• Sales & distribution: order processing, quotes, multichannel connectivity
• Finance & accounting: accounting export (DATEV/BMD), dunning, cost centers
• Master data & reporting: item master, dashboards, analyses

3. Technical and non-functional requirements

This is where the operating model (cloud vs. on-premise), interfaces, data migration, multi-tenancy, scalability, data protection and legal requirements belong. Name concrete integrations (shop, marketplace, shipping provider) and obligations such as GoBD compliance or e-invoicing – more on that shortly.

4. Framework conditions and formalities

Budget range, desired go-live date, contact person, response format and submission deadline. The clearer the format, the more comparable the responses.

Weighting must-have and nice-to-have criteria correctly

Not every requirement is equally important. Separating must-have from nice-to-have criteria is the core of a decision-ready requirements spec.

Must-have vs. nice-to-have criteria

• Must-have criteria (knockout criteria): without them a system is unusable. If a vendor doesn't meet a must-have, they're out – regardless of how good they are otherwise. Example: "The system must generate e-invoices in the XRechnung format."
• Nice-to-have criteria (wish criteria): desirable but dispensable. They decide between systems that all meet the must-haves.

Formulate must-haves sparingly. If you declare too many requirements a "must", you end up disqualifying every system and stalling the project. Rule of thumb: a requirement is only a must-have if your operation genuinely suffers without it.

Weighting and scoring

Give each nice-to-have criterion a weighting so you can offset proposals objectively. A simple points model is enough:

This produces a traceable total score per vendor. It doesn't replace gut feeling, but it disciplines the discussion and makes the decision documentable – important when several departments have a say.

DACH obligations that belong in the requirements spec

Certain legal requirements should be explicitly listed as must-have criteria in the DACH region rather than silently assumed.

• E-invoicing (Germany): the B2B obligation to receive e-invoices has applied since 01/01/2025. The obligation to issue them is staggered – generally from 01/01/2027 for companies with more than €800,000 in prior-year revenue, and from 01/01/2028 for everyone else. Permitted formats follow EN 16931, such as XRechnung and ZUGFeRD. Record which formats your system must generate and receive.
• GoBD: accounting and archiving-relevant processes must meet the principles for the proper keeping and retention of books (immutability, traceability, retention periods).
• Accounting connection: check the export to DATEV or BMD if your tax advisor works with them.

These points are technical, not legal advice – when in doubt, involve your tax advisor. But they absolutely belong in the requirements spec, because they decide the fundamental suitability of a system.

The finished ERP requirements spec in 6 steps

1. Define project scope and goals – describe the starting point, size, affected areas and goals.
2. Capture business processes – document as-is processes and mark potential improvements.
3. Collect and structure requirements – organize functional and technical requirements by module.
4. Separate must-have from nice-to-have criteria – flag each requirement as a must-have or nice-to-have.
5. Weight the criteria – define the points and weighting logic so proposals become comparable.
6. Finalize and send the requirements spec – review with the departments and send identically to every vendor.

If you can't handle these steps internally with your own resources, neutral ERP consulting helps with requirements capture and weighting. If you need a market overview first, you'll find it in the ERP directory and the system comparison.

Common mistakes with the requirements spec

• Too many must-have criteria: blocks the selection and rules out good systems for no reason.
• Solutions instead of requirements: prescribing modules or technologies narrows the competition and wastes better solution paths.
• Forgotten processes: edge processes like returns, drop shipping or batch management otherwise surface only during the project – and get expensive.
• Scope creep afterwards: requirements that keep growing after dispatch make proposals incomparable. Collect everything, then freeze.
• No alignment with departments: a requirements spec written by IT alone overlooks the daily reality in the warehouse and accounting.

Conclusion

An ERP requirements spec is not bureaucracy for its own sake – it's your most important steering instrument in system selection. It describes, in a solution-neutral way, what your future system has to deliver, separates must-have from nice-to-have criteria, and makes proposals objectively comparable through weighting. Use the structural template from this guide as a chapter skeleton, work through the six steps consistently, and involve the departments early. The requirements spec is the foundation the vendor later answers with their functional spec – the clearer your document, the more robust the eventual decision.