What is a functional specification (Pflichtenheft)? — Definition and distinction from the Lastenheft
In short: The Pflichtenheft defines the technical solution; the Lastenheft describes the business problem. In the Mittelstand the two are often conflated — at considerable cost.
A Pflichtenheft (literally "duties booklet") is the binding implementation specification for an ERP or standard-software project — written from the vendor's perspective. According to VDI 2519, the authoritative DACH guideline for Lasten- and Pflichtenhefte in ERP projects, the Pflichtenheft is the implementation specification for the customer's requirements. It describes how the system will be built — not what it should do.
The Lastenheft, by contrast, is the customer's requirements document. It states: "We need an ERP process for orders, inventory, and invoicing." The Pflichtenheft answers: "We will implement SAP S/4HANA with customising in the MM, SD, and FI modules, an EDI interface, and a four-week test phase before go-live."
In the DACH Mittelstand these boundaries blur — usually for budget reasons. Large corporates maintain four separate documents (Lastenheft, functional specification, technical design, implementation plan); the Mittelstand often combines all four into one. That is pragmatic — but only if you consciously distinguish what is functional (features) from what is non-functional (compliance, security, performance, support).
Why the Pflichtenheft matters more than ever in the DACH Mittelstand
In short: VDI 2519, GoBD, NIS-2, and the EU AI Act 2026 have changed what belongs in a Pflichtenheft in 2026. Standard templates are no longer enough.
The Pflichtenheft has always been the legal anchor between customer and ERP vendor. But three new forces are reshaping it in 2026.
1. Regulatory weight — GoBD, NIS-2, GDPR. According to the Bitkom study "Digitalisierung der Wirtschaft 2025", 53% of German Mittelstand companies report difficulty with digitalisation, and 41% actively use AI features. The implication: your Pflichtenheft must explicitly cover GoBD compliance (documentation and immutability of transaction data), NIS-2 obligations (IT security for critical infrastructure), and GDPR provisions (data protection, retention periods, audit logs). Standard Pflichtenheft templates rarely contain any of this.
2. AI-generated Pflichtenhefte — a new risk zone. Companies are increasingly using generative AI to draft Pflichtenhefte. It is fast — and dangerous. LLM hallucinations produce requirements that the system literally cannot implement, or omit requirements that cost months later. Pattern recognition across many similar projects is a consultant capability — it does not fall into the "standardised AI answer" category.
3. Hybrid-cloud reality. Modern ERP runs hybrid — cloud standard modules plus on-premise customising plus API integration. The Pflichtenheft must clearly separate what is standard, what is configured, and what is custom-coded. Skip that distinction and you will pay later for customising you assumed was "standard".
Pflichtenheft contents: what actually belongs inside
In short: A robust Mittelstand Pflichtenheft has four blocks: functional requirements, non-functional requirements, interface specifications, and acceptance criteria. Not fewer.
Aligned with VDI 2519 and internationally established specification standards (IEEE/ISO/IEC 29148, formerly IEEE 830), a Pflichtenheft has four core blocks.
A. Functional requirements. What must the system do? Concrete use cases or user stories with acceptance criteria. Example: "The clerk records a material request in the WMS. The system checks availability, reserves stock, and issues the picking order to the warehouse location."
B. Non-functional requirements. Performance (≤ 2 seconds response time for inventory queries), security (SSL/TLS, role-based access), data protection (GDPR audit log, retention rules), and availability (≥ 99.5% uptime for critical modules). In our experience this is the block that gets underestimated most often — and produces the expensive surprises at go-live.
C. Interfaces and integrations. Which third-party systems talk to the ERP? EDI links to suppliers, APIs to shipping providers, integration of master data (Stammdaten) sources. Every interface needs a documented target design.
D. Implementation and go-live criteria. When is the system live? Test coverage (unit, integration, UAT), data-migration validation, training, rollback plan, support escalation. Clearly named process owners are the critical component — without them, even the best document collapses.
Practical example: an anonymised Pflichtenheft from 1,200+ projects
In short: A southern German engineering firm (320 employees, €45m revenue) chose a cloud ERP and forgot to write non-functional requirements into the Pflichtenheft. The damage: 8 weeks of delay, €120,000 of rework, a legal dispute.
The project ran four months. At UAT, three critical gaps surfaced:
- The system stored passwords in cleartext — the Pflichtenheft contained no password-hashing requirement.
- Audit logs were not enabled — the GoBD requirement had simply been forgotten.
- Response time for real-time inventory bookings exceeded 5 seconds — no non-functional performance requirement had ever been defined.
Result: eight weeks of delay, €120,000 in customising rework, and a legal dispute over who bore the additional cost. The court ruled in the vendor's favour — because the Pflichtenheft did not contain the non-functional requirements, the vendor could not be held to deliver what was never specified.
Our take: The Pflichtenheft is your legal safeguard. If it is incomplete, you lose — in court and in the project.
Common mistakes in the Pflichtenheft
In short: Four central mistakes arise from missing measurability, unclear scope, underestimated non-functional requirements, and unclear responsibilities.
Mistake 1: Vague acceptance criteria — "the system must be fast." A weak Pflichtenheft says: "Order management must perform well." A strong Pflichtenheft says: "An order query must search and filter 5,000 records within two seconds; measurement via JMeter." Measurability is not optional.
Mistake 2: Scope creep from missing "Out-of-Scope" sections. The Pflichtenheft should state not only what will be implemented, but also what deliberately will not. "Out-of-Scope: an interface to the competing EDI format XYZ is not included. Mitigation: we provide an open API through which you can map XYZ yourself." That clarity prevents later disputes.
Mistake 3: Underestimating non-functional requirements. Roughly 90% of legal disputes in ERP projects arise not over missing features, but over "the system was too slow" or "the data was not secure". Every critical requirement needs a non-functional counterpart.
Mistake 4: No separation of vendor and customer responsibility. The best Pflichtenheft fails when it is unclear who is accountable for what. "The system must scale to 100 users" — is that the vendor's infrastructure obligation, or does the customer need to buy hardware? Ambiguity equals dispute.
How we approach Pflichtenhefte methodically
In short: Four phases: requirements workshops, regulatory compliance mapping, vendor feedback loops, and an acceptance-criteria matrix.
Phase 1: Requirements workshops. We think in a Brownfield approach: not "what would be ideal?" but "what runs today, and why?". A Mittelstand procurement department works with an Excel solution and 200 rules. Ideally everything would be in the ERP. Realistically, we document which 80% of the rules belong in the ERP and which 20% can be solved through workflow or approval routing. That makes the Pflichtenheft achievable.
Phase 2: Regulatory compliance mapping. We ask explicitly: which laws and standards apply to you? GoBD, NIS-2, GDPR, Supply Chain Act, data-protection impact assessment. The output is a dedicated "non-functional requirements" chapter in the Pflichtenheft.
Phase 3: Vendor feedback loops. The vendor does not say "we can do that". The vendor says: "We can do that, with the following constraints …". Both are documented. No surprises after contract signature.
Phase 4: Acceptance-criteria matrix. For every requirement — functional or non-functional — we define: who tests it? What is the success criterion? In which phase (unit, integration, UAT, production)? This is not theoretical QA — it is go-live realism.
This methodology is not a marketing construct. It comes from more than 1,200 projects, in which we have learned one thing repeatedly: the best ERP selection fails if the Pflichtenheft is not precise, complete, and enforceable. For companies that want a structured maturity assessment we apply our own model, SCOReX®.
Next steps
A quick check: does your current or planned ERP project have a formal Pflichtenheft? If yes — does it cover non-functional requirements (GoBD, NIS-2, GDPR, performance, security)? Are the customising scope, milestones, and acceptance criteria documented? If the answer to all three is "no", you are in the majority of Mittelstand projects — and at elevated risk.
We help you write a precise, regulatorily complete, and enforceable Pflichtenheft. That is not theoretical documentation — it is the safeguard that prevents your ERP project from becoming an expensive surprise. For more on our methodology, see our ERP consulting and specifications service, our independent ERP consulting, and the overview of our Digitalisation Services. Further reading: Brownfield vs. Greenfield, CAD systems, and master data (Stammdaten) in ERP selection.
