GoBD Process Documentation: What Must Be Included and How Simple It Can Be
Demystify GoBD process documentation for German SMEs. Learn what auditors actually need, why the 50-page myth is wrong, and how to create proportional documentation in 1-3 pages.
Verfahrensdokumentation (process documentation) after GoBD is simultaneously the most feared and most misunderstood compliance requirement in German accounting. Ask 10 business owners about it, and you'll hear myths: "You need 50 pages," "It's technically impossible for SMEs," "An IT consultant costs 5,000 EUR." None of this is true. This guide cuts through the noise.
What Is GoBD Process Documentation?
GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form) is the German tax authority's guideline for compliant digital bookkeeping. Process documentation is its most nebulous requirement.
At its core, Verfahrensdokumentation is a written description of HOW your business processes financial data — from the moment a receipt enters your system until it's archived years later. It answers auditor questions like:
- Who enters invoices into your system?
- What software do you use?
- How are documents scanned and stored?
- Who has access to what?
- What backups do you have?
- What happens when an error is discovered?
Why Everyone Gets Scared (and Why They're Wrong)
The fear stems from a misreading of GoBD itself. The tax authority published a 60-page guideline. Many Steuerberater forums then suggest you need an equally massive document. In reality, the guideline is *reference material*. What you document depends on your size and complexity.
A solo freelancer with one invoice software needs vastly less documentation than a 100-person GmbH with multiple systems and departments.
The Proportionality Principle
GoBD explicitly states: "Dokumentation muss der Größe und Komplexität des Unternehmens entsprechen." (Documentation must match the size and complexity of the business.) This is your legal shield. A 3-page checklist can be fully compliant for a 5-person business.
The 4 Required Sections (Per GoBD)
GoBD defines four mandatory documentation sections. If you structure your document around these, you're GoBD-compliant by definition.
1. Allgemeine Beschreibung (General System Description)
Answer: What are you using to run accounting?
- Name and version of accounting software (e.g., "Lexoffice v2026.01")
- Hardware setup (laptop, server, cloud)
- Internet connection method (ADSL, fiber, 4G)
- All other financial systems (e.g., CRM, bank feeds, payroll software)
- Who is the software provider and where is data stored?
For a small business: 5-8 lines. *Example: "We use Lexoffice (Cloud), accessed via browser on Windows 10 laptops. Bank data imports automatically from Qonto. Invoices are scanned using a Canon multifunction printer."*
2. Anwenderdokumentation (User Documentation)
Answer: Who does what, and who has access?
- How many users have system access?
- What is each user's role (admin, data entry, view-only)?
- Which financial modules can each user access?
- Is there a change log or audit trail?
- Who approves changes to master data (customers, vendors, accounts)?
For a small business: 5-10 lines. *Example: "Owner (Admin) has full access. Bookkeeper (Employee) enters invoices and approves bank transfers up to 5,000 EUR. Accountant (External) accesses reports read-only. All changes are logged by Lexoffice with user and timestamp."*
3. Technische Systemdokumentation (Technical System Documentation)
Answer: How is data protected and preserved?
- How often are backups made? (Daily? Weekly?)
- Where are backups stored? (Off-site? Cloud?)
- Password policy (complexity, rotation frequency)
- Is the system encrypted? (SSL/TLS for transmission)
- How long are backups retained before deletion?
- What happens if the system goes down? (Disaster recovery plan)
For cloud software like Lexoffice, Sevdesk: Much of this is handled by the provider. Your documentation can reference their security guidelines (they publish them). *Example: "Data is hosted by Lexoffice GmbH in German data centers with daily automated backups and 30-day retention. Backup security is documented in their Terms of Service. We maintain an export copy on an encrypted USB drive stored off-site monthly."*
4. Betriebsdokumentation (Operational Documentation)
Answer: What are the daily procedures and what happens when things go wrong?
- Invoice entry process: how are invoices scanned, numbered, and stored?
- Bank reconciliation: how often and by whom?
- Month/year-end close procedures
- How are discrepancies or missing invoices handled?
- Who archives completed documents and how?
- Document retention periods (invoices: 10 years, bank statements: 6 years, etc.)
For a small business: 10-15 lines. *Example: "Incoming invoices are scanned with a date stamp, emailed to [email], and manually entered into Lexoffice with reference to supplier and project. Bank transactions auto-import daily. Each month, the bookkeeper reconciles bank balance to Lexoffice and investigates any mismatches. At year-end, outstanding invoices are verified against contracts."*
What Auditors Actually Look For (vs. Your Nightmares)
A Betriebsprüfer (tax auditor) reviewing your process documentation is asking one core question: Is there a clear, intentional process? They're not looking for perfection. They're looking for evidence you know what you're doing.
They want to see:
- Consistency: Same systems and processes used month after month
- Traceability: Ability to follow a transaction from receipt to archive
- Intent: Evidence you tried to comply, even if imperfectly
- Change management: Documentation updated when systems or staff change
They do NOT care about:
- Polished formatting or professional layout
- Perfect grammar (German or English is fine)
- Extensive technical jargon
- Whether you use ISO standards or technical frameworks
- Pre-printed templates (a handwritten checklist is valid!)
A Simple 3-Page Template Approach
Here's a practical template structure. Use this for each major financial process:
Page 1: Process Overview
- Process name: e.g., "Rechnungseingang" (Invoice Receipt)
- Owner: Who is responsible for this process?
- Software used: What system handles this?
- Frequency: How often does this occur? (daily, weekly, monthly)
- Key steps: 1) Receive 2) Scan 3) Enter 4) Archive
Page 2: Detailed Workflow
- Step-by-step description of how the process happens
- Who is involved at each step
- What controls are in place (e.g., "2-person approval for over 5,000 EUR")
- Where data is stored (local? cloud? both?)
- How errors are caught and corrected
Page 3: Audit Trail & Compliance
- How is this process documented? (timestamp, user, action)
- What records are kept? (email? PDF? database?)
- Retention period and archive location
- Software's role in creating audit trail (automatic vs. manual)
Repeat this 3-page structure for each major process (Rechnungseingang, Rechnungsausgang, Bankkontenabstimmung, Lohnbuchhaltung, etc.). A 5-person business with 3-4 key processes = 9-12 pages total. Fully GoBD-compliant.
Key Processes to Document
You don't need to document every detail of your business. Focus on financial transactions that create audit risk:
- Rechnungseingang (Incoming invoices) — expenses, supplier payments
- Rechnungsausgang (Outgoing invoices) — revenue recognition, sales records
- Kassenführung (Cash handling) — if you operate a physical till
- Belegarchivierung (Document archiving) — how long you keep what
- Bankkontenabstimmung (Bank reconciliation) — monthly process
- Lohnbuchhaltung (Payroll) — if you have employees
Not needed: internal memo processes, social media strategy, HR workflows (unless they affect payroll).
Common Over-Engineering Mistakes
1. Writing a 30-Page Novel
More documentation is not more compliant. A 30-page document with contradictions and unnecessary detail creates more audit risk, not less. Stick to the essential 4 sections.
2. Over-Documenting Technical Details
You don't need to explain database architecture or API endpoints. Auditors are accountants, not IT specialists. Plain language suffices: *"Data is encrypted in transit (HTTPS) and at rest (AES-256)."* Done.
3. Ignoring Cloud Provider Documentation
If you use Lexoffice, Sevdesk, or Agicap, they already provide security and backup documentation. You can reference their docs instead of rewriting. *"See Lexoffice Security Policy (published 2025) for technical details."* This counts.
4. Outdated Documentation
The worst documentation error is one that was true last year but isn't anymore. An auditor reads: *"Invoices are entered manually by John."* But John left 6 months ago. Now you look disorganized.
How Often Should You Update Documentation?
Review and update annually, or whenever:
- Software changes: New version, new system, or new tool added
- Personnel changes: Staff departure, new hire, role change
- Process changes: New approval level, new storage method, new workflow
- Legal/tax changes: New reporting requirements, new retention rules
Add a date and version number to your documentation. *Example: "Version 2.1, updated 2026-02-09."* This shows you're maintaining it.
What Happens if You Don't Have One?
During a Betriebsprüfung (tax audit), if you can't produce process documentation, the auditor has two options:
- Verwerfung: Reject your bookkeeping entirely. They assume you can't prove which entries are correct, so they disallow deductions at will.
- Closure: Simply end the audit and assess estimates. This is worse because they're not required to prove anything.
The financial impact can be severe: 20,000+ EUR in unexpected taxes if you're disallowed legitimate deductions. Documentation costs you 2-3 hours. Non-compliance can cost you 20,000+.
Real Risk
A Verwerfung (rejection of bookkeeping) is the auditor's nuclear option. It's rare but devastating. Process documentation is your primary defense.
Cloud Accounting Software: A Shortcut
One hidden advantage of cloud accounting platforms: the software provider handles much of the technical documentation for you.
When you use Lexoffice, Sevdesk, or Fastbill, the vendor publishes:
- Security policies (encryption, backups)
- Data center locations (usually Germany, EU, compliant with GDPR)
- Audit trails and logging capabilities
- Disaster recovery procedures
- Password and access controls
Your documentation becomes simpler: *"For technical details, see Lexoffice Security Whitepaper."* You still need to document your processes (who enters data, who approves, etc.), but the infrastructure part is delegated.
Cloud Advantage
Switching from on-premise software to a GoBD-certified cloud platform like Sevdesk or Buchhaltungsbutler often reduces documentation burden by 40% because the vendor handles technical compliance.
A Real-World Example: Solo Freelancer
Let's walk through a minimal example. You're a solo consultant with 80,000 EUR annual revenue:
Your Process Documentation (2 pages, simple)
Section 1: Outgoing Invoices (Rechnungsausgang)
- Software: Lexoffice
- Process: Create invoice in Lexoffice, email to client, store PDF in folder /Rechnungen/[Jahr]/
- Owner: Me (I create and track)
- Backup: Lexoffice automatic (cloud), plus monthly export to encrypted USB
- Retention: 10 years (Lexoffice keeps originals)
Section 2: Incoming Invoices (Rechnungseingang)
- Software: Lexoffice
- Process: Receive email, scan/attach to Lexoffice, categorize to expense account, pay via Qonto
- Backup: Lexoffice automatic
- Retention: 10 years
That's it. Two sections, 10 lines, GoBD-compliant. If an auditor calls, you can confidently say: "Here's my process, here's the software I use, here's the backup proof." Game over, you're fine.
Connecting to [GoBD Compliance](/blog/gobd-compliance-praktisch-erklaert)
Process documentation is one pillar of GoBD compliance. For the full picture, read our guide on practical GoBD compliance, which covers all requirements including data preservation, document retention, and audit-readiness.
Tools and Stacks That Simplify This
The simpler your software stack, the simpler your documentation. Consider:
- Lexoffice for all-in-one invoicing, expense, and basic bookkeeping
- Sevdesk for invoicing with strong process controls
- Agicap for cash flow visibility (reduces reconciliation complexity)
- Fastbill for automated invoice workflows
- Qonto or Finom for dedicated business banking with built-in documentation
Look into the GmbH starter stack or freelancer essentials for pre-vetted tool combinations.
When to Hire Help
You don't need an IT consultant to create GoBD documentation. You need clarity, not complexity. Hire help only if:
- You have multiple systems (e.g., ERP, CRM, custom software, bank connection) that interact
- You have multiple staff with different roles and approval flows
- You've had a previous audit warning about documentation
- You operate in a heavily regulated industry (finance, pharmaceuticals)
For a 5-person business with standard accounting software: DIY is fine. Spend 4-6 hours. You'll be compliant.
Your Compliance Checklist
Before you consider yourself done:
- ☐ Document covers the 4 required sections (Allgemeine, Anwender, Technisch, Betrieb)
- ☐ All major financial processes are described (invoicing, expenses, bank sync, payroll if applicable)
- ☐ Document is dated and versioned
- ☐ It's simple, plain-language, and under 15 pages
- ☐ You've referenced cloud provider docs where applicable
- ☐ You can explain your process verbally without the document
- ☐ You review and update it annually or when processes change
Final Thought: Process Documentation Is Not Evil
This requirement exists for a good reason. If your business is audited, process documentation protects you. It's proof that you organized, intentional, and compliant. It's not a bureaucratic hurdle — it's a shield.
Spend 1-2 afternoons writing it. Update it once a year. Sleep soundly knowing that if a Betriebsprüfer shows up, you have documentary evidence of your process integrity.
Signals in this article
Disclaimer: Finance Stacks is not a financial advisory service. All content is for informational purposes only and does not replace professional advice from a tax advisor, accountant, or financial consultant.