ERP Requirements Document Template — Structured for DACH Buyers

An ERP requirements document — the document the deutsche market calls Requirements Document — is the foundation of any structured ERP selection. Done well, it tightens the longlist, sharpens vendor responses and produces a defensible audit trail for the eventual choice. Done badly, it produces hundred-page checklists that vendors answer with optimistic colour-coding and no one reads after signature. The difference is not length but discipline: a tight, MoSCoW-prioritised, business-process-anchored document outperforms a sprawling feature checklist by a wide margin.

This template covers a twelve-chapter structure used across DACH Mid-Market selections, including the Excel-based requirements catalogue that vendors fill in during the RFP phase. It draws on patterns from successful Mid-Market selections (50–3,000 staff) but the structure generalises to SMB selections (with section pruning) and enterprise selections (with deeper integration and architecture chapters). The template is editorial and platform-agnostic — vendor preferences should not appear in a requirements document, and a well-written document should be answerable by at least five candidate vendors without favouritism.

The twelve-chapter structure

A well-structured ERP requirements document covers twelve chapters. The chapters are ordered to support a vendor reading them in sequence:

Company profile (3–5 pages). Headcount, revenue, locations, ownership, brief history, industry vertical, sub-vertical positioning, growth ambition over the next five years. Frames vendors' understanding of fit.
Business processes (10–25 pages). End-to-end business processes by functional area: order-to-cash, procure-to-pay, plan-to-produce, hire-to-retire, record-to-report. Process maps where helpful. Process volumes (transactions per day, peak periods).
Functional requirements (Excel catalogue, 200–600 line items). The detailed requirements catalogue, separated by module, with MoSCoW priority and brief description. Excel is the standard format; Word and Confluence work but are harder to score.
Non-functional requirements (3–6 pages). Performance (response times, batch windows), availability (SLA expectations), scalability (user growth, transaction growth), accessibility, multi-language.
Architecture and integration (5–10 pages). Current system landscape, integrations to retain, deployment-model preferences (cloud, hybrid, on-premises), data-residency requirements.
Compliance and regulatory (3–5 pages). Deutsche compliance specifics: GoBD, DATEV, ZUGFeRD, XRechnung, Umsatzsteuer (VAT). Industry-specific obligations. GDPR and BDSG considerations. Works-council requirements.
Data migration (2–4 pages). Master-data volumes, transactional history retention requirements, legacy systems to migrate from, data-quality known issues.
Implementation approach (2–4 pages). Big-bang or phased preference, target go-live timeframe, internal resource availability, training expectations.
Support and operations (2–3 pages). AMS expectations, response-time SLAs, language coverage for support, named-account-manager preferences.
Commercial framework (2–3 pages). Pricing model preferences (subscription vs perpetual), licence-model preferences (named user vs concurrent), indexation expectations, exit clauses.
Selection process and timeline (1–2 pages). Selection process steps, decision criteria weighting, target decision date, contact information.
Evaluation criteria and scoring (1–2 pages). The scoring methodology that will be applied to vendor responses. Transparency here improves vendor response quality materially.

Total document length runs 40 to 80 pages for typical mid-market selections, plus the Excel requirements catalogue. Documents above 120 pages usually contain repetition and noise; documents below 30 pages usually lack the specificity needed for honest vendor responses.

MoSCoW prioritisation

Every requirement should carry a MoSCoW priority. The four levels:

Must have. The system cannot be selected without this. Roughly 20 to 30 per cent of total requirements. Vendors who cannot meet a Must-have requirement out of the standard or via committed roadmap are eliminated.
Should have. Important but not selection-killing. Workarounds are acceptable, but Should-have gaps reduce the vendor's score materially. Roughly 30 to 40 per cent of total requirements.
Could have. Nice to have, no impact if missing. Roughly 25 to 35 per cent of total requirements.
Won't have (this time). Explicitly out of scope. Documenting these prevents vendors from padding their response with irrelevant capabilities.

The discipline matters. Selection teams who classify 80 per cent of requirements as Must-have produce documents no vendor can fully answer, and end up with arbitrary disqualifications. Selection teams who classify 10 per cent as Must-have produce documents that fail to distinguish among candidates. The target distribution — roughly 25 / 35 / 30 / 10 across Must / Should / Could / Won't — is reached only by walking through each requirement and asking “Would I really walk away from an otherwise-perfect vendor that lacks this?”

Sample requirements catalogue entries

The Excel requirements catalogue holds the bulk of the functional detail. Sample entries from a Mid-Market machinery-manufacturer requirements document:

ID	Module	Requirement	Priority
FIN-001	Financials	Native DATEV interface for chart-of-accounts and journal export, certified by DATEV	Must
FIN-002	Financials	GoBD-compliant audit trail with immutable journal records and time-stamped change history	Must
FIN-008	Financials	ZUGFeRD 2.x and XRechnung receivable and payable handling	Must
SAL-014	Sales	Variant configurator for machine product line with up to 80 configurable attributes per item	Must
SAL-022	Sales	Quote-to-cash workflow with multi-level approval based on margin and discount thresholds	Should
PROD-003	Production	Project-based costing with monthly cost-to-complete tracking	Must
PROD-019	Production	MES integration via OPC-UA for shop-floor data collection	Should
INV-007	Inventory	Multi-warehouse stock with serial-number tracking for end products	Must
INV-012	Inventory	Cycle-counting support with mobile barcode scanning	Should
SVC-001	After-sales service	Installed-base management with equipment history and warranty tracking	Must

Each entry should be specific enough to be answerable yes/no/workaround/no-roadmap. Vague entries (“Good user interface”, “Easy to use”) produce vague answers; specific entries produce useful comparison data. A typical Mid-Market requirements catalogue runs 200 to 600 line items across all modules.

What does not belong in a requirements document

Six categories regularly appear in requirements documents but should not:

Vendor names. A requirements document should be answerable by any candidate vendor. Naming specific vendors in functional requirements (“like SAP's S/4HANA Cloud”) signals bias and produces defensive responses from non-favoured vendors.

Implementation methodology preferences. Selecting the software and selecting the methodology are separate decisions. Mixing them constrains vendors' ability to propose what works best for their platform.

Excessive duplication across modules. “The system must have a user interface” appearing in every module section is noise. Cross-cutting requirements belong in the non-functional chapter.

Technical implementation details for the standard cases. “Order entry screen must have a field for customer name” is implicit in “Order entry is supported”. The technical detail belongs in the functional spec, after selection.

Aspirational requirements with no clear business case. AI-powered demand forecasting, blockchain-based supplier verification, voice-controlled warehouse picking — if these are not driven by a current business need, they belong in the Could-have or Won't-have category, or not at all.

Vendor evaluation criteria as requirements. “Vendor must have at least 50 reference customers in DACH” is a vendor criterion, not a requirement. It belongs in the selection-criteria chapter, not the requirements catalogue.

Distributing the document to vendors

The requirements document is the primary input to the RFP phase. Distribution typically follows this rhythm:

Pre-RFI screening (week 0). A brief one-page summary of the selection (company, segment, headcount, target go-live) is shared with the longlist of 8 to 15 vendors. Vendors confirm interest and basic fit within one week.
RFI distribution (week 1–3). A condensed version of the requirements document (15–25 pages) plus the Excel requirements catalogue. Vendors respond in writing within two to three weeks.
Shortlist selection (week 4). Based on RFI responses, 3 to 5 vendors are shortlisted for the full RFP.
Full RFP distribution (week 5–9). Full requirements document plus catalogue plus commercial framework. Vendors respond within four to six weeks, with a Q&A window of two weeks.
Demo and POC phase (week 10–16). The requirements document anchors the demo agenda — vendors demonstrate against the buyer's own scenarios drawn from the document.

Treating the requirements document as a living artefact — updated as the selection process refines the buyer's understanding — produces better outcomes than treating it as a one-shot document fixed at the start. The final version of the document, after demos and POC, becomes the basis for the implementation contract's scope-of-work appendix.

Frequently Asked Questions

How long should an ERP requirements document be?

Mid-market documents run 40 to 80 pages for the narrative sections plus 200 to 600 line items in the Excel requirements catalogue. SMB documents run 15 to 35 pages plus 80 to 200 catalogue entries. Enterprise documents run 100 to 200 pages plus 600 to 1,500 catalogue entries. Documents materially longer than this usually contain repetition, vendor-favouring detail or aspirational requirements that should be in scope cuts.

Should we hire a consultant to write the requirements document?

For first-time selections, often yes. Specialist selection advisors bring template patterns from comparable selections and force discipline on MoSCoW prioritisation. Day rates are typically 1,000 to 1,800 EUR; total cost for a Mittelstand requirements document is 20,000 to 60,000 EUR depending on internal capacity. The investment usually returns more than that in tighter vendor shortlists and avoided false starts. Internal teams who have led one or two prior selections can produce credible documents without external help.

What format should the requirements catalogue use?

Excel is the standard format because it allows vendors to fill in their responses inline, and the data can be exported for scoring. Word is harder to score; Confluence and similar collaborative tools are workable but require export to Excel before vendors respond. Specialist RFP tools (Lou, Loopio, Rocketdocs) are gaining adoption in enterprise selections but rarely appear in DACH Mittelstand selections.

Should we publish the scoring weights in the document?

Yes. Publishing the scoring weights (e.g. functional fit 40 per cent, total cost of ownership 25 per cent, vendor stability 15 per cent, implementation partner 20 per cent) signals seriousness, helps vendors prioritise their response effort and produces better proposals. The risk that vendors game the weights is real but small; the gain in response quality outweighs it.

How does a requirements document differ from a functional spec?

The requirements document (Lastenheft) is written by the buyer and describes what the business needs. The functional specification (Pflichtenheft) is written by the implementation partner after selection and describes how those requirements will be implemented on the chosen platform. The requirements document is platform-agnostic; the functional specification is platform-specific. See our requirements document vs functional spec guide for the full comparison.