An ERP requirements document (German: Requirements Document) is the buyer's definition of what the future system must do, written before vendor demos and shaped without reference to any specific product. This page shows what such a document actually looks like — the 12 chapters that the mature DACH mid-market template uses, the MoSCoW prioritisation discipline that prevents the requirements list from growing into wish-list theatre, and an extract from a real requirements catalogue with the kind of entries vendors can answer cleanly.
The companion template that you can copy and fill in lives at /en/erp-requirements-document/. This page is the worked example.
The 12-chapter structure
A complete requirements document for a Mid-Market ERP project covers twelve chapters. Skipping any of them creates a vendor-side opportunity to over-promise and under-deliver later.
Project context — company profile, headcount, revenue, sites, key business model facts
Project goals — the three to five outcomes the migration must achieve, with measurable success criteria
Scope and out-of-scope — the modules and processes that belong in the project, and the explicit list of those that do not
As-is process landscape — the current ERP, the surrounding systems, the major interfaces, the pain points
Target processes — the future-state process map at the level of detail the project requires
Functional requirements — the structured catalogue, organised by module
Non-functional requirements — performance, availability, security, data residency, languages, accessibility
Technical requirements — deployment model preference, integration patterns, API standards, browser support
Volumes and growth — users, transactions, master-data counts, expected growth over the contract horizon
Commercial framework — total budget envelope, licence model preference, contract term, exit clauses
Evaluation criteria — the weighted scorecard against which vendor offers will be assessed
MoSCoW prioritisation
Every functional requirement carries a priority tag: Must, Should, Could, Won't.
Must — non-negotiable, a vendor that cannot meet it is out of the running
Should — important, but a vendor with a credible workaround or roadmap commitment can stay in
Could — nice to have, contributes to the score but does not by itself eliminate
Won't — explicitly out of scope for this phase, included only to prevent re-litigation
The realistic distribution in a mature requirements document is roughly 15–25 % Must, 35–45 % Should, 25–35 % Could and 5–15 % Won't. Documents with 60 % Must are wish-lists; documents with 5 % Must lack the discipline to make a real choice. The Must threshold is the lever buyers use to widen or narrow the long-list during selection.
Extract from the requirements catalogue
The requirements catalogue itself is a structured table, usually maintained in Excel or a requirements tool, with one row per requirement. Fields per row: ID, module, sub-module, requirement statement, priority (MoSCoW), rationale, acceptance criteria, vendor response, vendor evidence.
A short extract from the financial-accounting section of a sample document:
FI-001 (Must): The system shall support the German Standard Chart of Accounts SKR03 and SKR04 out of the box, with the ability to map company-specific accounts via a customisable mapping table. Acceptance: vendor demonstrates SKR04 active in a sandbox tenant within 30 minutes.
FI-012 (Must): The system shall produce a GoBD-compliant audit trail covering every posting, with timestamp, user, source document reference and immutable audit-record storage. Acceptance: audit trail extracted for a sample period passes a check by the customer's tax advisor.
FI-024 (Should): The system shall support automated DATEV export in the current DATEV format for monthly handover to the tax advisor. Acceptance: live DATEV export demonstrated in the vendor demo.
FI-031 (Should): The system shall produce ZUGFeRD 2.x and XRechnung-compliant outbound invoices for B2G and large-customer scenarios. Acceptance: sample invoice validated against XRechnung schema validator.
FI-047 (Could): The system shall support multi-GAAP parallel ledgers for HGB and IFRS reporting in the same legal entity. Acceptance: documented in vendor reference architecture.
Each entry follows the same structure: testable statement, clear priority, explicit acceptance criterion. Requirements written as ‘the system should be user-friendly’ are unscorable and waste space.
Typical requirements-document mistakes
Three failure patterns appear in almost every weak requirements document. Vendor-feature transcription: requirements that read like a feature list from the incumbent vendor's product sheet rather than from the customer's business. The fix is to write requirements in business language and let vendors map their features to them, not the other way round.
Aspiration creep: teams add requirements that the current business does not need but that ‘might one day be useful’ — AI, blockchain, IoT, predictive analytics. Each adds shortlist-narrowing pressure and rarely buys real business value. The discipline is to demote them to Could or Won't.
Process underspecification: the chapter on target processes ends up at a level of detail that vendors cannot scope against. The result is a fixed-price implementation offer that turns into time-and-materials within three months of project start. The fix is process diagrams plus a process narrative, validated by key users from each affected department before issuing the document.
How the requirements document fits into the RFP process
The requirements document is the input to the RFP, not a substitute for it. After issuing the document, the buyer sends it (with covering RFP letter, evaluation criteria and submission instructions) to the long-list, holds an optional Q&A round, receives vendor offers, scores them and narrows to a short-list for demos. The detailed mechanics live in our ERP RFP process guide and the full template at /en/erp-requirements-document/.
The document remains a living artefact through implementation: it is the reference for fit-gap analysis, the baseline for change-request governance and the basis for hypercare acceptance. Buyers that treat the requirements document as a vendor-selection asset only and then file it after signature systematically lose change-control battles.
How many pages is a typical ERP requirements document?
For a Mittelstand mid-market project (100–500 users, three to six modules): 60–120 pages including the requirements catalogue as appendix. The catalogue itself usually contains 300–800 line items. Documents under 30 pages are almost always underspecified; documents over 200 pages tend to be wish-lists that nobody, including the vendor, will read in full.
Do we need a Lastenheft if we already have a Pflichtenheft from the vendor?
Yes — the two are different artefacts. The Lastenheft (requirements document) is written by the customer before selection and defines what is wanted. The Pflichtenheft (functional specification) is written by the selected vendor after contract award and defines how the chosen system will be configured and customised to meet the Lastenheft. A vendor-supplied document calling itself a Lastenheft is by definition not one; it is a sales-driven scoping document.
Can we reuse a competitor's requirements document?
Templates and structures can and should be reused; the actual content cannot. Two companies in the same industry have different process maturity, different system landscapes and different growth ambitions. A template plus an internal workshop series with key users from every affected function delivers a Lastenheft that actually reflects the business. Reusing a competitor's catalogue produces a document that vendors recognise on sight and discount accordingly.
Who should write the Lastenheft inside the customer?
Best practice is a small core team (typically a project manager, a process consultant and a key user per affected module) supported by a methodology coach (often an external selection advisor). The core team facilitates workshops with the business, drafts the document and runs review rounds. The whole exercise typically takes 8–14 weeks; shorter durations are usually a sign of insufficient business involvement.
