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.
Realistically 30–80 pages depending on company size. Under 20 pages is usually too unspecific for meaningful quotes, over 100 pages often over-regulated. In practice, the exact configuration varies depending on the industry, company size class and customising depth of the specific ERP setup.
Requirements document in Excel or Word?
Both in parallel: Word for the prose (objectives, current situation, interfaces), Excel for the requirements table with fulfilment columns. In practice, the exact configuration varies depending on the industry, company size class and customising depth of the specific ERP setup. A well-founded answer always requires looking at the company's individual business processes and strategic IT roadmap.
Who writes the requirements document?
The client (that is, you) — either yourself, with an internal project team, or with an ERP consultant as co-author. Never the vendor itself. In practice, the exact configuration varies depending on the industry, company size class and customising depth of the specific ERP setup.
Is there a requirements document example available as a PDF download?
Generic PDF templates are often too general. A more sensible option is an individually structured requirements document tailored to your industry and company size. You can adopt the structure documented here directly.
What distinguishes a good requirements document example from a bad one?
A good requirements document: measurable objectives, MoSCoW-prioritised requirements, a complete interface list, a quantified volume framework. A bad requirements document: vague wording, missing volumes, no prioritisation. In practice, the exact configuration varies depending on the industry, company size class and customising depth of the specific ERP setup.
