ERP Requirements Consultant, Germany

What a German ERP specification should contain

A requirements specification is useful only if every reader can find their part and every line can be answered. I structure it in chapters that mirror how the company runs: sales and order handling, purchasing, warehouse and logistics, production or project delivery, service, finance and controlling, and the boundary with HR and payroll. Each chapter opens with a short description of the process and the entities involved, followed by numbered lines.

Every line follows the same pattern. It states one capability in a sentence a vendor can answer with a clear yes, no or partial. It names the source, whether a process owner, the tax advisor, group IT or the data protection officer. It carries a priority class and an acceptance criterion describing what a tester would need to see.

Around the process chapters sit the parts that are often missing in German tenders: a statutory chapter, non-functional requirements, an interface catalog, a migration chapter and a glossary pairing English terms with the German expressions your staff use. For subsidiaries, a separate block marks which lines come from the group template and which are local additions. The general method is described under ERP requirements gathering, and the document conventions follow my BRD consulting approach.

Writing GoBD, DATEV and e-invoice lines as tests

Statutory topics fail in German projects when they appear as a single line such as "GoBD compliant". No vendor will answer that with anything but yes, and no tester can prove it. I break the topic into statements that can be shown and checked, for example:

• Once a period is closed or a document is finalized, the system blocks edits and allows only a documented reversal, and the test shows the attempt being refused.
• Changes to customer, supplier, item and account master data are logged with old value, new value, user and timestamp, and the log can be filtered and exported.
• Data for a tax audit can be provided in a machine-readable form agreed with your advisor.
• The export to your DATEV-based advisor contains the agreed level of detail, account mapping and receipt references, and the advisor imports a sample without manual repair.
• Incoming XRechnung and ZUGFeRD invoices are validated, matched and stored with their original file; outgoing structured invoices can be produced where your obligations require it.
• Retention rules per document type are configurable as your advisor specifies.

Payroll usually stays with an external provider, so the requirement describes the journal that arrives, not the payroll itself. Every statutory line carries a flag stating that your Steuerberater has confirmed the wording. Interpreting tax law is their role; making sure the obligation is written down in testable form is mine.

Non-functional lines: hosting, access, logging and deletion

A specification can describe processes in great detail and still say almost nothing about how the system must behave. That gap tends to surface as a surprise in the contract or after go-live. I add a non-functional chapter with lines a vendor has to answer in concrete terms.

Hosting and data processing come first: where production data and backups are held, whether hosting inside Germany or the EU is required or merely preferred, which subprocessors may be used and what the data processing agreement must cover. Your data protection officer decides the position; the specification records it. Access control follows, with roles, segregation of duties between ordering, receiving and paying, and approval limits.

Logging deserves care in companies with a Betriebsrat. An ERP can record a great deal about individual users, and where a works council exists, technical systems able to monitor behavior or performance generally call for its involvement. I write lines that require logging and reporting on employees to be configurable and documented, so whatever management and the council agree can be implemented and tested. Legal questions stay with HR and counsel.

Two further lines are easy to forget. Personal data needs a deletion concept under GDPR, while tax records must be kept for the required period, and the system must handle both. Plants, depots or field staff on weaker connections need defined response times and offline behavior.

Interfaces, migration and priorities without guesswork

Interfaces cause much of the effort in German projects, yet specifications often list them as names only. I describe each one by direction, trigger, content, frequency, owner and what happens when a message fails. Typical entries include the advisor export, bank statement and payment files, EDI with key customers or suppliers, a web shop, product data or CAD sources for manufacturers, time recording, and group reporting for subsidiaries. Detail on the technical side sits on the ERP integration page.

Migration gets its own chapter. It states which master data moves, whether open items or full history are taken over, which balances start the new books, and how records from the old system remain accessible for audits once the old license ends.

Prioritization uses classes in the MoSCoW style: lines the company cannot go live without, lines that are important but could follow later, lines that are welcome if they come at little cost, and lines explicitly out of scope for this phase. Statutory lines and agreed works council requirements sit in the first class by default. Knock-out criteria for the tender are a subset of that class, written so a vendor who cannot meet them is excluded early and with a stated reason. Managers agree the classes per chapter before release, so priorities are not reopened during every demo.

From Lastenheft to Pflichtenheft, contract and acceptance

The specification earns its cost when it is used. In a tender it becomes the requirement annex: each system house answers line by line with a response code and a comment, which makes proposals comparable. The tender format itself is described on the ERP RFP consulting page, and the comparison of proposals continues on my ERP selection page for Germany.

After award, many implementers write a Pflichtenheft describing how they will meet your requirements. I check it against the specification line by line. Every requirement should map to a design statement, and anything marked as standard in the proposal should not reappear as a change request. The contract should cite the released version of both documents.

The traceability matrix then carries the work into testing: each line points to its demo scene, its UAT case and its acceptance result. Versions are controlled throughout. Each release has a number, a date, an owner and a change log, and department heads sign their chapters.

Common risks in German specifications are predictable: no retention or archive lines, a vague advisor export, missing interface error handling, no non-functional chapter and no works council lines. I check for each of them before release. Delivery is remote, with visits by arrangement, and I take no vendor commissions. More on my work in Germany.