Functional Specification (Pflichtenheft)

A functional specification, in German Pflichtenheft, is the document that describes in detail how a system or project will be implemented to meet the customer's stated needs. In the German engineering tradition it is the supplier's structured answer to the customer's requirements document (Lastenheft): the Lastenheft states what is wanted, the Pflichtenheft commits to how it will be delivered. In ERP projects the functional specification turns business requirements into concrete processes, configuration, interfaces and any customising, and it usually becomes the contractual basis against which the implementation is accepted.

Lastenheft versus Pflichtenheft

The pairing is central to how DACH projects are scoped and is easy to confuse:

• Lastenheft (requirements document) — written by the customer; describes the problem and the required outcomes from the user's point of view.
• Pflichtenheft (functional specification) — written by the supplier or implementation partner; describes the proposed solution and how each requirement will be met.

The Lastenheft asks the questions; the Pflichtenheft answers them. Acceptance of the delivered system is then measured against the Pflichtenheft, which is why precision matters.

What it contains

A functional specification for an ERP implementation typically documents the target business processes, the standard system configuration, required interfaces to other systems, data-migration scope, reports and roles, and any gaps that need customising or development. It distinguishes what the standard software covers from what must be built, since that boundary drives cost and risk. Good specifications also define acceptance criteria — measurable conditions under which each function is considered delivered — and reference the relevant compliance constraints, such as auditability under GoBD for finance processes.

Role in the project lifecycle

The functional specification sits between requirements gathering and build. It is produced after the requirements document and the system selection, and before configuration begins, often as part of an ERP migration or new implementation. It feeds directly into project planning and into the test cases used for acceptance. In agile or iterative implementations the document may be lighter and evolve in increments, but even there a baseline of agreed scope and acceptance criteria serves the same purpose: aligning customer expectations with supplier commitments before significant effort is spent.

Why it matters for SMEs

For a mid-sized company an ERP project is a rare, high-stakes investment, and the functional specification is the main lever for controlling its scope and cost. A vague specification invites scope creep, disputed change requests and an acceptance that cannot be objectively judged. A precise one makes the supplier's commitments testable and gives both sides a shared reference if disagreements arise. The practical advice is to keep the customer's requirements and the supplier's solution as distinct documents, to insist on measurable acceptance criteria, and to treat the specification as a living contractual artefact rather than a formality signed and forgotten.

Related Topics

• Requirements document (Requirements Document)
• ERP selection
• Customising