Skip to content

GoBD Compliance for Email Archiving#

This documentation applies to Piler enterprise edition 2.1.0+

Revision #4

Publication date: 2026-OCT-30

Deutsche Fassung

Legal notice

This documentation describes how piler enterprise supports compliance with the German GoBD requirements from a technical and organizational perspective.

It does not constitute legal advice and does not replace the organization's obligation to assess its own legal requirements, risks, and compliance measures.

Organizations remain solely responsible for:

  • determining which emails are tax-relevant or commercially relevant,
  • configuring appropriate retention periods,
  • ensuring proper access controls and audit trails,
  • maintaining overall compliance with German tax and commercial law.

piler enterprise provides technical means to support, but not substitute, regulatory and legal decision-making.

The references "Rz." are the margin numbers of the GoBD, in the version of 14 July 2025 (see References).

What is GoBD?#

GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) is an administrative regulation of the German Federal Ministry of Finance (BMF). The current version is the BMF letter of 28 November 2019, amended on 11 March 2024 and on 14 July 2025 (mainly for mandatory e-invoicing).

It defines requirements for:

  • Electronic bookkeeping and record-keeping
  • Retention of tax-relevant documents in electronic form
  • Data access rights for tax authorities during audits

GoBD applies to all businesses subject to German tax law, regardless of size. Non-compliance can result in:

  • Rejection of bookkeeping by tax authorities
  • Estimated tax assessments
  • Fines and penalties
  • Increased audit scrutiny

Two principles of the GoBD shape what an archive can and can't do for you:

  • The responsibility stays with the company, also when the archive is run by a service provider or a hosting partner (Rz. 21).
  • There is no GoBD certificate. The tax authority makes no general statements about the conformity of a software product, and certificates or attestations of third parties have no binding effect on it (Rz. 179 to 181). What counts is how the archive is configured and operated, and the procedure documentation that describes it (Rz. 151 to 155).

The GoBD requirements are derived from several German laws:

Law Requirement
§ 147 AO (Abgabenordnung) Retention of tax-relevant documents
§ 257 HGB (Handelsgesetzbuch) Retention of commercial correspondence
§ 14b UStG Retention of invoices for VAT purposes
GoBD (BMF letter) Technical implementation requirements

Retention periods#

Document type Retention period
Books and records, inventories, annual financial statements, management reports, and the work instructions and organizational documents needed to understand them 10 years
Accounting vouchers (Buchungsbelege), including invoices 8 years (10 years until 2024)
Commercial and business letters received and sent (offers, order confirmations, general business correspondence) 6 years

The retention period begins at the end of the calendar year in which the document was created or received.

The period for accounting vouchers was shortened from 10 to 8 years by the Fourth Bureaucracy Relief Act (BEG IV) from 1 January 2025 (§ 147 Abs. 3 AO, § 257 Abs. 4 HGB, § 14b UStG). Banks, insurance companies and investment firms keep 10 years for a transition period. Many tax advisers still recommend keeping vouchers for 10 years. The retention period of an email is also not always clear from its subject: ask your tax adviser which periods to configure.

Which emails must be archived?#

What matters is the content and the function of an email, not what it's called (Rz. 121). An email that serves as a business letter or an accounting voucher must be kept. An email that is only the "transport" of an attached invoice, and contains nothing else that must be kept, doesn't have to be (like a paper envelope).

Tax-relevant emails#

  • Invoices (incoming and outgoing)
  • Invoice corrections and credit notes
  • Contracts with financial implications
  • Payment confirmations and reminders
  • Tax declarations and correspondence with tax authorities
  • Financial statements and accounting documents

Commercially relevant emails#

  • Offers and quotations
  • Order confirmations
  • Delivery notes and shipping confirmations
  • General business correspondence
  • Customer and supplier communications with commercial significance

Emails that do NOT require archiving#

  • Private correspondence (if permitted by company policy)
  • Spam and advertising
  • Newsletters without business relevance
  • Internal informal communications without commercial significance
  • Drafts that were never sent (Rz. 5)

Separating these reliably by hand is rarely practical. Most companies archive every email of their domains with a journal rule and set the retention period by the longest applicable obligation, with retention rules for exceptions.

GoBD requirements and how Piler meets them#

The table maps the requirements of the GoBD that concern an email archive to what Piler does, and what remains your task. The sections below explain each one.

Requirement Rz. Piler Your task
Completeness (Vollständigkeit) 36 to 43 Archives every email the mail server sends to it, with headers and attachments Journal rule for all incoming and outgoing email
Immutability (Unveränderbarkeit) 58 to 60, 107 to 112 Stores each email unchanged as received; no function to edit an archived email; a digest verified when the email is opened; optional TSA timestamps Keep deletion disabled; optional WORM storage
Logging (Protokollierung) 59, 111, 117 Audit log of logins, searches, views, downloads, exports, removals and every configuration change Review it; optionally forward it to a SIEM
Retention in the received format 119, 129, 131 The original email (EML) with all headers and attachments, e-invoice XML and PDF included
No deletion before the end of the period 119 Deletion is disabled by default; retention rules; legal hold; the purge only removes emails after their period Retention periods; approval for removals if you enable deletion
Order and index (Ordnung) 53 to 57, 117, 122 A unique id, the Message-ID and the digest of every email; a search index that can be rebuilt from the stored emails
Annotations 123 Tags and notes are stored apart from the email, which stays unchanged
Machine evaluation (Maschinelle Auswertbarkeit) 125 to 128 Full-text search of emails and attachments, metadata search, exports
Encryption 134 Emails are stored encrypted and shown decrypted to authorized users Keep the encryption key for the whole retention period
Data security (Datensicherheit) 103 to 106 Access control, roles, two-factor authentication Backups, and their description in the procedure documentation
Internal control system (IKS) 100 to 102 Roles, access rights, approval of removals, audit log Access concept, its description in the procedure documentation
Readability (Lesbarmachung) 156, 157 Every email readable on screen in the web UI
Data access in a tax audit 158 to 170 Auditor accounts (Z1), searches and exports by the auditor's criteria (Z2), exports in EML and other formats (Z3) Decide what the auditor may see
Procedure documentation (Verfahrensdokumentation) 151 to 155 Describes its part: this page, the documentation of your Piler version Write and keep it up to date

Technical implementation#

Completeness#

GoBD requires that business transactions are recorded completely and without gaps (Rz. 36). For an email archive, this means that every email that must be kept reaches the archive.

How Piler ensures completeness:

  • A journal rule on the mail server sends a copy of every incoming and outgoing email to Piler, without relying on users or clients
  • Real-time archiving: emails are archived as they arrive
  • Headers and attachments are kept with the email, and the envelope recipients (e.g. Bcc recipients) with envelope files
  • Nothing in the email is modified during archiving

Configure your mail server to send a journal copy of all emails to the Piler SMTP daemon, see the documentation of your mail server or Microsoft 365 journaling.

Immutability and logging#

A record must not be changed in a way that its original content can no longer be determined, and changes must be logged (§ 146 Abs. 4 AO, Rz. 58 to 60 and 107 to 112). Immutability can be ensured by hardware (e.g. WORM storage), by software (e.g. locks, logging, versioning) or by organizational measures (e.g. access rights). Storing files in a plain file system is regularly not enough without additional measures (Rz. 110).

How Piler ensures immutability:

  • Emails are stored in their original format (EML), as received, immediately upon receipt
  • Piler has no function to edit an archived email: users and administrators can only read, export or (if enabled) request its removal
  • All stored emails are encrypted at rest with AES
  • A SHA-256 digest of each email is stored when it's archived, and verified when the email is opened: a changed email is shown as not verified
  • Audit logs record access and administrative actions, see below
  • Optional: TSA timestamps. The sign tool has the digests of the archived emails signed by a time stamping authority (RFC 3161, sign --tsa-url https://...), as cryptographic proof that they existed unchanged at that time. Run it regularly, e.g. daily from cron
  • Optional: WORM storage, e.g. S3 storage with Object Lock, for immutability at the storage level

What the audit log records (Rz. 111, 117):

  • Authentication: logins (successful and failed), logouts, passkeys
  • Access: which user viewed, downloaded or restored which email, when, from which IP address
  • Searches: what was searched, and by whom
  • Exports: eDiscovery exports, downloads
  • Removals: removal requests, their approval or rejection, GDPR erasure requests
  • Configuration (2.3.0+): every change made through the web UI or the API, with the new values (never a password): users, groups, domains, LDAP, profiles, tenants, quotas, retention rules, categories, legal holds, DLP and compliance rules, import jobs, branding, API tokens, Teams and Slack retention

Changes outside Piler (e.g. the .env settings or the mail server's journal rule) aren't in the audit log: record them in the change history of your procedure documentation (Rz. 154). Before 2.3.0, changes of domains, groups, LDAP, profiles and some other settings weren't logged.

Audit log protection:

  • Audit logs are stored separately from email content, and can't be changed or deleted in the web UI or the API
  • Logs can be forwarded to an external SIEM (Splunk, Sumo Logic, Syslog), see SIEM integration: a copy outside Piler that local administrators can't change

Retention in the received format#

Incoming electronic business letters and accounting vouchers must be kept in the format in which they were received (Rz. 119, 131). Converting an email to PDF loses its header, and with it the proof of how the email was received (Rz. 129).

How Piler meets it:

  • Piler keeps the original email (EML) with all headers and attachments, as received
  • Attachments are never converted: a PDF stays a PDF, an XML invoice stays XML, and a ZUGFeRD invoice keeps its embedded XML
  • The search index and the database are derived from the stored email, which remains the original

Retention and deletion#

Documents must not be deleted before the end of their retention period (Rz. 119).

How Piler supports it:

  • Deletion is disabled by default (ENABLE_DELETE=false): nobody can remove an archived email before its retention period ends
  • Retention period per tenant (the default for all emails), and retention rules for exceptions, by domain, sender, recipient, subject, body, size, attachment name or type
  • Legal hold: emails of the custodians under a legal hold are not purged, even after their retention period
  • Purge: removes emails after their retention period has ended (if enabled for the tenant)

If you enable deletion (ENABLE_DELETE=true), e.g. for GDPR erasure requests: auditors (and, with ENABLE_DELETE_FOR_USERS=true, users) can request the removal of an email. With NEED_TO_APPROVE_DELETE=true, a data officer must approve each request (four-eyes principle). Every request, approval and rejection is in the audit log. Note that the retention obligations of tax and commercial law generally take precedence over a GDPR erasure request (Art. 17 Abs. 3 lit. b GDPR).

Recommended configuration for GoBD:

  • Keep ENABLE_DELETE=false, or enable it only with NEED_TO_APPROVE_DELETE=true
  • Set the retention period of the tenant by the longest obligation that applies to your emails (e.g. 10 years, 3650 days)
  • Add a year: Piler counts the period from the date of the email, while the legal period ends at the end of the calendar year (e.g. 11 years, 4018 days, for 10 years)
  • Use retention rules only for emails you know to be shorter-lived (e.g. newsletters)

Order and index#

Documents must be kept in order, and every electronic document needs a unique index that stays linked to it for the whole retention period (Rz. 117, 122).

How Piler supports it:

  • Every email has a unique id, and the Message-ID and the digest are stored with it
  • Full-text search across email bodies, subjects and attachments
  • Metadata search by sender, recipient, date range, size, attachment type
  • Categories, tags and notes for classification; tags and notes are stored apart from the email, which stays unchanged (Rz. 123)
  • Saved searches for recurring queries
  • The search index can be rebuilt from the stored emails (reindex)

Machine evaluation#

Archived documents must be machine-evaluable to the extent of their information (Rz. 125 to 128). Full-text search counts as machine evaluation (Rz. 126). Structured data, such as the XML of an e-invoice, must stay available as such (Rz. 127, 129).

Piler export capabilities:

Format Use case
EML The original email; standard and portable
MBOX Multiple emails in one file
PDF A readable copy of an email
CSV Metadata for spreadsheet analysis
eDiscovery exports Emails with load files and hashes for review tools, see eDiscovery

Encryption and keys#

Encrypted documents must be available decrypted, and the keys must be kept as long as documents encrypted with them must be kept (Rz. 134).

  • Piler shows and exports emails decrypted to authorized users
  • Keep the encryption key (piler.key) for the whole retention period, in your backups and in a safe place apart from them. Without it, the archived emails can't be read

Data security#

The archive must be protected against loss and unauthorized changes, and the backup procedure is part of the procedure documentation (Rz. 103 to 106).

  • Access control with roles, LDAP / Active Directory, SAML or local accounts, and two-factor authentication
  • Backups are your task: follow the 3-2-1 rule and test restores regularly, see backup and disaster recovery

E-invoices#

Since 1 January 2025, businesses in Germany must be able to receive e-invoices for domestic B2B transactions, and issuing them becomes mandatory in stages until 2028. The GoBD amendment of 14 July 2025 sets how they are kept:

Requirement Rz. Piler
Incoming e-invoices are kept in the format received, e.g. XML 131 The email is kept as received, the XML attachment unchanged
For an e-invoice, keeping the structured part (the XML) is enough; for structured data, matching content is required, not a matching image 118, 119, 131 The XML is kept, and the PDF as well
The human-readable part (e.g. the PDF of a ZUGFeRD invoice) must also be kept if it has additional tax-relevant information (e.g. booking notes or qualified electronic signatures) 119, 125, 131 The whole email is kept, PDF included
The XML of a hybrid invoice must not be lost by a conversion (e.g. PDF/A-3 to TIFF) 125, 129 Attachments are never converted
E-invoices are structured data that can be evaluated mathematically and technically 127 The XML is available unchanged for evaluation and export
An email that only transports an e-invoice doesn't have to be kept 121 Piler keeps it anyway, with the invoice

Piler keeps e-invoices as the GoBD require because it archives every email as received: XML, PDF and hybrid formats (ZUGFeRD, Factur-X, XRechnung) are all preserved unchanged, and found by full-text search and by attachment type.

Finding e-invoices (2.3.0+): Piler recognizes the emails with an e-invoice attachment when it archives them: XRechnung and other UBL or CII invoices (XML), and ZUGFeRD / Factur-X invoices (PDF with an embedded XML invoice). Search for them with attachment:einvoice, or the "E-invoice" checkbox of the advanced search. For a tax audit, combine it with a date range and export the e-invoices (Z2 / Z3, see The e-invoices of a period). The emails archived before 2.3.0 are found after a reindex.

Procedural documentation (Verfahrensdokumentation)#

For every IT system there must be a clearly structured procedure documentation, from which the content, structure, process and results of the procedure are fully and conclusively apparent, and which a knowledgeable third party can review in a reasonable time (Rz. 151). For electronic documents it describes the process from their creation through indexing, processing and storage, finding them, machine evaluation, protection against loss and falsification, to their reproduction (Rz. 152).

Required elements#

It usually consists of (Rz. 153):

  1. General description

    • The purpose of the archive, which emails are archived
    • Responsibilities: who operates, administers and audits the archive

  2. User documentation

    • How users and auditors search, view and export emails
    • Roles and access rights

  3. Technical system documentation

    • Software used (Piler enterprise, its version), hardware or hosting, storage locations
    • How emails are captured (journal rule), stored, encrypted and verified
    • Retention periods and rules, deletion settings

  4. Operations documentation

    • Backups and restores, the safekeeping of the encryption key
    • Updates and their history, monitoring
    • The internal control system: access reviews, audit log reviews

The documentation must match the system actually in use, including the versions of the programs, and changes must be versioned with a traceable history (Rz. 154). It must be kept as long as the documents it explains (Rz. 154). A missing or insufficient procedure documentation is not a formal defect leading to the rejection of the bookkeeping, as long as it doesn't impair traceability and verifiability (Rz. 155).

Piler supports your procedural documentation with:

  • A template for the procedure documentation (in German), with the parts about Piler filled in

  • This page and the documentation of your Piler version, for the technical parts

  • The audit log, for the controls (logins, access, removals, rule changes)
  • The retention rules and their change history
  • The configuration report (2.3.0+), under Compliance > Configuration report in the admin UI: the settings, retention and exclusion rules, roles and users, and active legal holds of the tenant, as Markdown or JSON, in English or German, or printed. The reason of a rule is its description. What Piler can't read (e.g. S3 Object Lock, the purge schedule) stays a [placeholder] for you to fill in. The German report says where its sections go in the template. It has no passwords or keys. It shows the configuration on the day you make it, so keep each version with your documentation.

Deployment recommendations for GoBD compliance#

Minimum requirements#

  1. Archive every email

    • Configure a journal rule on the mail server for all incoming and outgoing email

  2. Configure retention

    • The retention period of the tenant by the longest obligation that applies (e.g. 10 years)
    • Retention rules only for emails you know to be shorter-lived

  3. Keep deletion disabled

    • ENABLE_DELETE=false (the default), or deletion only with NEED_TO_APPROVE_DELETE=true

  4. Protect the key and back up

    • Back up the databases, the stored emails and the encryption key; follow the 3-2-1 rule
    • Test restores regularly

  5. Use and review the audit log

    • Review it regularly, as part of your internal control system

  6. Write the procedure documentation

Enhanced compliance#

  1. TSA timestamps: run the sign tool regularly, for independent proof of when the emails were archived
  2. WORM storage: S3 Object Lock or equivalent, for immutability at the storage level
  3. External audit log storage: SIEM integration, so local administrators can't change the logs
  4. Regular reviews: check the configuration against this page and update the procedure documentation after every change

Data access in a tax audit#

In a tax audit, the tax authority may access the data in three ways, and choose which (Rz. 163, 164):

Access Rz. What it means With Piler
Z1: direct access 165 The auditor reads the data in your system, with read-only access, on site; no online remote access An auditor account for the tax auditor
Z2: indirect access 166 You (or a service provider) evaluate the data by the auditor's criteria, and hand over the results or give read-only access to them Searches by the auditor's criteria, exported for them
Z3: data handover 167 to 169 You hand over the data in a machine-readable format, e.g. on a data carrier Export of the selected emails in EML (with their metadata); the e-invoices of a period with an index (2.3.0+)

The scope: data access covers the documents that must be kept, within the scope of the audit (Rz. 158, 159). Deciding which data are tax-relevant is your task (Rz. 161).

An auditor account sees every archived email of the tenant. Piler has no auditor role limited to the tax-relevant emails. If the tax auditor shouldn't see everything, prefer Z2 or Z3: search for the relevant emails yourself and export them. Agree on the format with the auditor.

Who does it: for Z2 and Z3, no special account is needed. A regular user who receives the invoices (e.g. with rechnung@ or buchhaltung@ as an alias) finds and exports them, and sees nothing else. An auditor account can do it too, but sees all mail.

The e-invoices of a period (Z3)#

From 2.3.0:

  1. Search for attachment:einvoice (or tick "E-invoice" in the advanced search) with the dates of the audited period
  2. Click the receipt button next to the export button, then download the ZIP from the exports

The ZIP has:

File Contents
einvoices/<id>-<n>_<name> Each e-invoice (XRechnung UBL or CII XML, ZUGFeRD / Factur-X PDF) as received, byte for byte
emails/<id>.eml The email it came with
index.csv One row per e-invoice: date, sender, recipients, subject, kind (UBL, CII, PDF/A-3), file name, size, SHA-256 of the e-invoice and of the email. UTF-8, separated by semicolons
README.txt The number of emails found and checked, and whether the export is complete

Emails without an e-invoice are left out. A search is limited to MAX_EXPORT_MESSAGES emails (20000 by default) before they are left out: if a broad search hits the limit, README.txt says "INCOMPLETE". Narrow the search to attachment:einvoice and the period, and export again. Each exported email is in the audit log (download), and the export itself (export), with its counts.

An auditor account for direct access (Z1)#

  1. Create a user account with the auditor role, only for the time of the audit
  2. Keep deletion disabled: with ENABLE_DELETE=true, auditors can request removals
  3. Give the credentials to the tax auditor
  4. Follow the access in the audit log
  5. Disable the account after the audit

All auditor access is logged.

Summary: GoBD compliance checklist#

Requirement Implementation Status
Completeness Journal rule, real-time SMTP archiving ✓ Configuration required
Immutability Original EML, no edit function, encryption, SHA-256 digest verification, optional TSA and WORM ✓ Built-in
Logging Audit log of access and every configuration change (2.3.0+), SIEM forwarding ✓ Built-in
Retention in the received format Original EML with headers and attachments ✓ Built-in
No deletion before the end of the period Deletion disabled by default, retention rules, legal hold ✓ Configuration required
Order and index Unique id, full-text and metadata search, e-invoices (attachment:einvoice), categories, tags ✓ Built-in
Machine evaluation Full-text search, EML, MBOX, PDF, CSV and eDiscovery exports ✓ Built-in
Encryption key Kept for the whole retention period ○ Customer task
Data security, backups Access control, 2FA; backups ○ Customer task
Data access Auditor accounts, searches and exports ✓ Built-in
Procedural documentation Supported by this page and the audit log ○ Customer task

Legend: ✓ = Supported, ○ = Customer responsibility

References#