Guides / GoBD Procedural Documentation: Contents, Structure, Template
GoBD Procedural Documentation: Contents, Structure, Template
What the German procedural documentation (Verfahrensdokumentation) is, who needs it, its four parts, a template to copy and a GoBD checklist.
The procedural documentation (Verfahrensdokumentation) is the first thing a German tax auditor asks for, and it’s missing in many small companies. It’s less work than its reputation suggests: for a business with a handful of people, ten to twenty pages are often enough. This guide explains what goes into it, how it’s structured, and gives you a template to copy.
What is procedural documentation?
It describes how tax-relevant data and documents are created, processed, stored and found again in your company. It’s written for a knowledgeable third party, such as a tax auditor who doesn’t know your company. Reading it, they should understand within a reasonable time how a receipt travels from arrival to booking and archive.
The obligation comes from the GoBD, the German Federal Ministry of Finance’s rules for electronic bookkeeping (paragraphs 151 to 155). More in What is GoBD?.
Who needs it?
Every company that keeps its books or receipts fully or partly electronically under German tax law. That’s practically everyone: if you receive invoices by email, use accounting software or scan receipts, you need one. That applies to limited companies as much as to sole traders, and to German branches of foreign companies.
The scope depends on the size and complexity of the company. A five-person workshop doesn’t need 100 pages.
Structure: the four parts
The usual structure has four parts, as in the AWV sample documentation:
- General description: the company, its organisation, responsibilities and an overview of the systems in use.
- User documentation: how people actually work: receiving, capturing, checking, filing and archiving documents.
- Technical system documentation: which software and hardware is used, interfaces, data formats, where the data is stored.
- Operating documentation: how proper operation is ensured: backups, access rights, updates, incidents.
It also covers the internal control system: which controls make sure nothing gets lost and nothing is changed unnoticed? For example the four-eyes principle for payments, or roles and rights in the archive.
Procedural documentation: a template to copy
Copy this outline and fill in your details. The examples in brackets assume a small company that archives documents with Papermerge; replace them with your own systems.
1. General description
- 1.1 Company: name, legal form, industry, number of employees
- 1.2 Responsibilities: who handles bookkeeping, document filing and IT (with deputies)
- 1.3 Tax adviser: which tasks are outsourced
- 1.4 Overview of systems: accounting, invoicing, archive (e.g. Papermerge), banking
- 1.5 Validity: version of this document, valid from, change history
2. User documentation
- 2.1 Paper mail: who opens it, when documents are scanned
- 2.2 Electronic documents: central invoice address (e.g. the email address of the Accounting cabinet), handling of invoices sent to personal mailboxes
- 2.3 E-invoices: formats (XRechnung, ZUGFeRD), how they are checked and filed
- 2.4 Capture: which categories exist and which metadata is captured per category (invoice number, supplier, date, amount)
- 2.5 Checking and approval: who checks invoices for content and amounts
- 2.6 Filing and archiving: when a document is archived; after that it can’t be changed
- 2.7 Replacement scanning: scanning instructions, quality checks, when paper is destroyed (see Replacement scanning)
- 2.8 Retention and deletion: periods per category, who approves deletions
3. Technical system documentation
- 3.1 Software used, with version or provider (cloud services with data centre location, e.g. Papermerge: Frankfurt am Main)
- 3.2 Formats of the originals (PDF, TIFF, JPG, PNG, emails as .eml)
- 3.3 Interfaces: how data flows between archive, accounting and tax adviser
- 3.4 Immutability: how the archive prevents or logs changes (versioning, checksums, audit log)
4. Operating documentation
- 4.1 Access rights: roles, groups, who may see and change what
- 4.2 Backups: what is backed up, how often and where
- 4.3 Data access for tax audits: Z1 (auditor access), Z2, Z3 (export)
- 4.4 System change: how data is migrated and kept readable
- 4.5 Incidents: what happens in case of outage, data loss or a security incident
Appendices: organisation chart, scanning instructions, list of categories with retention periods, access rights concept.
GoBD checklist for small businesses
Go through these points once a year:
- All tax-relevant documents end up in the archive, including those sent by email.
- Invoices received electronically are kept in their original format.
- Documents are captured promptly, not collected until year end.
- Archived documents can’t be changed or deleted unnoticed.
- Changes and deletions are logged (who, what, when).
- Every document type has a defined retention period.
- Nothing is deleted before its period ends; deletions are approved.
- Access rights are assigned and documented.
- A tax auditor can get read-only access without being able to change anything.
- Data is backed up regularly.
- The procedural documentation is up to date; older versions are kept.
Common mistakes
- No documentation at all, because “we’re small”.
- A template that doesn’t match reality. The auditor compares the documentation with what they see.
- Not updated: new accounting software, new scanner, new staff, but the documentation still describes the setup of three years ago.
- Old versions overwritten. You must be able to show which process applied when.
- Only the software described, not the work. The question isn’t just “which program” but “who does what, when”.
Describing the Papermerge part
If you use Papermerge as your archive, these points help with chapters 2 to 4:
- Capture: documents arrive by upload or via a cabinet’s email address in the inbox. Users choose the category; the category sets the metadata, retention period and storage location.
- Immutability: archived versions are read-only and protected with a SHA-256 checksum; corrections create a new version.
- Logging: the audit log records uploads, changes, state transitions, deletions and permission changes with time and user.
- Deletion: after the period ends, only with approval by a designated person or group.
- Data access: auditor access through the auditor role with read access to selected cabinets.
How Papermerge covers each GoBD requirement is explained in detail in GoBD-compliant archiving.
Frequently Asked Questions
Is procedural documentation mandatory?
Yes, for every company that keeps its books and records in Germany fully or partly electronically, which is practically all of them. The obligation comes from the GoBD (paragraphs 151 ff.). Small companies and freelancers need one too, but it can be short.
What happens if it's missing?
Missing or incomplete procedural documentation is a formal defect. As long as the bookkeeping is still traceable, it usually doesn't lead to the books being rejected on its own. But it weakens your position in a tax audit and, together with other defects, can contribute to estimated additions.
How long must it be kept?
Ten years, because it counts as work instructions and organisational documents under section 147 AO. Keep older versions too: the auditor must be able to see which process applied at which time.
Is there an official template?
There is no official template. A widely used model is the sample procedural documentation by AWV and the German Federal Chamber of Tax Advisers. The outline in this guide follows the same four-part structure.