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.
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.
What belongs in an ERP requirements document template?
A complete ERP requirements document template typically covers around a dozen standard chapters: company profile and volume data, as-is analysis, objectives, functional and non-functional requirements, interfaces, data migration, permissions and compliance, reporting, implementation and the contractual framework. The core is the prioritised requirements catalogue, in which each individual requirement is recorded with a unique ID, a module, a measurable description and an acceptance criterion. In an Excel template, evaluation columns per vendor can also be added, turning the requirements document directly into a comparison matrix. What matters is that it describes what the system is supposed to deliver, not how a specific vendor solves it technically.
How long should an ERP requirements document be and how many requirements should it contain?
In the B2B mid-market, a workable ERP requirements document usually runs between roughly 15 and 40 pages, while more complex projects can reach 40 to 80 pages. Requirements documents of well over 100 pages do occur, but in the view of many selection consultants they do not automatically contribute to a successful project, because they become hard to align and shift the focus from processes to mere feature lists. The more sensible rule of thumb is as long as necessary, as short as possible, with a focus on the genuinely differentiating requirements. As for the number of individual requirements, the ranges run from a few dozen to several hundred function points depending on industry and process depth.
What does MoSCoW prioritisation mean in a requirements document?
MoSCoW is an acronym for Must have, Should have, Could have and Won't have and serves to classify each requirement unambiguously by importance. Must-have requirements allow no alternative and decide whether a vendor is accepted or rejected, Should-have is important but not project-critical, Could-have is desirable, and Won't-have is deliberately deferred to a later roadmap. The method was developed in 1994 by Dai Clegg in the context of Rapid Application Development and spread through the agile Dynamic Systems Development Method (DSDM). Without such prioritisation, a requirements document quickly turns into a wish list, which needlessly inflates vendors' effort estimates and quotes.
What is the difference between a requirements document (Lastenheft) and a functional specification (Pflichtenheft)?
According to DIN 69901-5, the requirements document (Lastenheft) is defined as the totality of the requirements specified by the customer for the deliverables and services of a contractor, and thus describes the what and the what-for. Under the same standard, the functional specification (Pflichtenheft) comprises the implementation specifications drawn up by the contractor on the basis of the requirements document and answers the how and the with-what. In an ERP project, the selecting company therefore writes the requirements document, while the chosen vendor responds to it with a functional specification. Further details can be found in the glossary under requirements document and functional specification.
Who writes the ERP requirements document and how long does it take to create?
Responsibility classically lies with the project team of the selecting company, with input from the business departments, often supported by external selection advisors. In the mid-market, creation usually takes several weeks to months depending on complexity, available resources and coordination effort; at least three to six months are frequently allowed for, and considerably longer for large projects. During this time there are workshops for the as-is analysis, reviews with the business departments and several rounds of alignment. Experience shows it pays to plan realistic buffers from the outset, as project timetables are regularly exceeded in practice.
Is there a free ERP requirements document template as an Excel or Word download?
Yes, several vendors and specialist portals provide free ERP requirements document templates as Excel or Word files, some with extensive function catalogues covering several hundred functional areas. An Excel template is particularly well suited to the requirements catalogue, because filters, prioritisation and per-vendor scoring can be mapped directly, while a Word document serves as a contract annex. Some templates use DIN 69901-5 as their structural framework. What matters is not to adopt generic templates unchecked, but to supplement them with your own volume data, interfaces and industry-specific processes.
