Procedural documentation for email archiving under the GoBD: contents, structure and a template
A procedural documentation (Verfahrensdokumentation) describes how a data-processing system works in organisational and technical terms, here the email archive: how emails are captured, stored, protected, found, kept and deleted. The GoBD require one for every data-processing system (Rz. 151). As a rule it consists of a general description, a user documentation, a technical system documentation and an operating documentation (Rz. 153), and the description of the internal control system belongs to it (Rz. 102). For email archiving it should cover, among other things, the capture path, the scope, storage, encryption, access rights, retention and deletion, legal hold, the checks and the change history. A template to download is below. This page is not legal or tax advice.
By Lucas Flores, IT Systeme Flores UG. Last updated
What is a procedural documentation, and why does an email archive need one?
The word does not appear in § 147 AO or § 257 HGB. Both norms do require that, besides the books and records, you keep the working instructions and other organisational documents needed to understand them (paragraph 1 no. 1 of each). The term Verfahrensdokumentation and its requirements come from the GoBD, the principles for the proper keeping and retention of books, records and documents in electronic form. They are a letter of the Federal Ministry of Finance (BMF) to the supreme finance authorities of the German states, not a statute, but they are applied in tax audits.
Under Rz. 151, every data-processing system needs a clearly structured procedural documentation from which the content, structure, flow and results of the process can be seen completely and coherently. It must be understandable, and an expert third party must be able to verify it within a reasonable time. Its scope is set by what is needed to understand the process, the books and records and the documents that are kept. It describes the process as it is meant to run organisationally and technically, for electronic documents from the creation of the information through indexing, processing and storage, unambiguous retrieval and machine evaluability to protection against loss and falsification and to reproduction (Rz. 152).
For an email archive that means: emails are treated by their function. An email that works as a commercial letter or as an accounting voucher has to be kept in electronic form; an email that is only a transport vehicle, for example for an attached invoice, does not (Rz. 121). Incoming records have to be kept in the form in which they arrived and must not be deleted before the retention period ends, whether they are kept in the production system or in another data-processing system (Rz. 119 and 131). An archive that holds such emails is therefore a system whose process you should describe. Two margin numbers name parts of the procedural documentation outright: the description of the internal control system (Rz. 102) and the description of the data backup (Rz. 106).
If the documentation is missing or insufficient, Rz. 155 says there is no formal defect of material weight that could lead to the books being rejected, as long as traceability and verifiability are not impaired. That is not an all-clear: the tax authority judges in each case whether they are intact, and a missing description makes it harder to show that.
What parts does a procedural documentation have?
The GoBD name four parts as the rule (Rz. 153) and count the description of the internal control system as part of it (Rz. 102). They do not prescribe a fixed form.
| Part | Answers the question | Examples for an email archive |
|---|---|---|
| General description | What is the process for, and who is responsible for what? | Purpose and scope, systems involved, which emails are archived, retention classes, roles and people responsible. |
| User documentation | How do users work with it? | Who may search, read and export, how a retrieval runs, what users cannot change, whom they tell about faults. |
| Technical system documentation | How is the system built, and what does it do? | Capture path, data formats, storage location, encryption, protection against alteration, index and search, interfaces, program versions. |
| Operating documentation | How is it run and maintained? | Permissions, backup of the archive, retention and deletion, legal hold, monitoring, updates, system changes, service providers. |
| Internal control system | How do you make sure it runs as described, and how do you show that? | Completeness check, integrity check, retrieval and restore tests, review of access rights, evidence that the checks were done (Rz. 100: set up, carry out and log controls). |
What exactly belongs in it for email archiving?
The GoBD give no schema for email. The table arranges the topics that follow from the margin numbers and from how an email archive works, and names the reference where there is one. It is a working basis, not a complete list for your case.
| Topic | What the documentation should record | Reference |
|---|---|---|
| Capture path | How an email gets into the archive and from when, for each kind of mailbox: journaling or a copy that the mail provider forwards (made in transport, before a user can change the mail), a capture from the mailbox shortly after delivery (Microsoft Graph, IMAP sync), or an import from files; which ways are combined, and how the same mail captured twice is kept once. Which gaps each chosen path leaves, for example a mail moved or deleted between delivery and capture, BCC recipients that a forwarded copy does not show, mail from before the set-up (taken over once and marked as captured later), drafts and mail that was never sent. | Rz. 66, 67, 117 |
| Scope | What is archived and what is not, by which criterion, who decided and where the decision is recorded. What counts is the function of an email, not its label; the invoice attached to a pure transport email stays subject to retention. How private messages, newsletters and spam are handled. | Rz. 121 |
| Formats and conversion | The format in which emails and attachments are kept; whether anything is converted and how the original is kept, linked to the same record and the converted version marked; how the structured part of an e-invoice is preserved. | Rz. 119, 131, 135 |
| Storage | Where and on what medium the archive lives, who runs the storage, how it is protected against loss (for example a copy in a second location) and what happens on a system change or migration. | Rz. 103, 106, 142 |
| Encryption | What is encrypted, with which method, who manages the keys and how they are protected. How the records stay available in decrypted form for the whole retention period, also after a lost key or a change of people or providers. | Rz. 134 |
| Protection against alteration | By which measures an archived email cannot be changed or deleted unnoticed, and what each measure does and does not achieve: technical (for example append-only storage, a hash chain, locks enforced by the storage), software (logging, versioning) and organisational (an authorisation concept). How later changes and deletions are logged. | Rz. 107 to 112, in particular 110 |
| Access rights | Who may read, search, export, delete and change settings; how rights are granted, reviewed and withdrawn; how administrators are supervised. | Rz. 103, 110 |
| Retention and deletion | Which classes exist and how long they apply, how the end of the period is calculated, how the extension for an open tax assessment is handled, who triggers and approves a deletion, how it is carried out and how it is logged. The periods are on the page Email retention periods in Germany. | Rz. 59, 119; § 147 (3) AO |
| Legal hold | Who may suspend deletion for certain emails, on what occasions (for example a legal dispute or an audit in progress), with what reason, and how suspension and release are documented. | Not a term of the GoBD; related to § 147 (3) sentence 5 AO |
| Checks | Which controls run at what rhythm, who carries them out and where the results are kept: an integrity check of the archive (for example verifying a hash chain), a retrieval and restore test, a completeness sample against the mailbox, a review of access rights, a check triggered by a system change. | Rz. 60, 100, 101, 102 |
| Data access and evaluability | How you give a tax audit access (inspection, indirect access, data transfer), in which formats data is exported, whether the export can be read without the archive system, and which parts of the documentation you hand over. | Rz. 125 to 129, 158 to 160; § 147 (6) AO |
| Responsibilities | Who is responsible for the business side, the technology, data protection and approval of the documentation, who stands in, which tasks lie with a service provider and how it is bound by contract. | Rz. 151 (design depends on the organisation) |
| Change history | Version, date, change, reason and approval of every version of the documentation; which program versions were in use when. | Rz. 154 |
Who writes it, and how does it stay current?
The procedural documentation is your company's own document. A vendor can supply technical facts, but it can only describe its software, not your process: who grants rights in your company, which emails you archive, for how long, who carries out the controls. Under Rz. 154, it has to be ensured and shown for the whole retention period that the documented process matches the process in use, in particular as to the versions of the programs. Changes of the documentation must be traceable over time, which is met if they are versioned and a traceable change history is kept. And the retention period of the documentation does not run out while the period of the records it is needed to understand is running: old versions do not belong in the bin.
In practice: write what actually applies, not what would be desirable. Decide who maintains the documentation. Review it whenever the process changes, for example with a new capture path, a new storage, a change of provider, changed periods or an update that changes a function; Rz. 101 names a system change as an occasion to check whether the system in use matches the documented one. Also schedule a regular review without an occasion.
Template to download
Template: procedural documentation for email archiving (Markdown, English)
The template is a skeleton with headings, fill-in prompts and neutral placeholders such as [Company name]. It follows the parts above, contains the topics of the table and keeps a change history. It is not a filled-in example, makes no legal statements about your case and does not replace advice. It is a Markdown file that opens in any text editor; you can paste the content into Word or LibreOffice. There is no Word file. A German version is available on the German page.
- Download the template and work through the parts in order.
- Replace every placeholder with your actual entries and strike what does not apply.
- Have your tax advisor review it and, where personal data is involved, your data protection officer.
- File the approved version with a version number, keep earlier versions and set a date for the next review.
How Restow handles this
Restow does not write your procedural documentation. Your organisation, your decisions and your controls stay with your company. What Restow contributes are the technical facts about the archive, and they are in the documentation that serves as source material for your description: Archive and journaling (capture paths, hash chain, storage targets, retention and legal hold) and GoBD and evidence (what the archive aims at and what Restow does not claim).
What Restow records
- Hash chain. The archive is append-only, and every item gets a chained SHA-256 hash. The archive check ("Kette prüfen" in the German interface) has three parts: every link, the comparison with the daily anchors that the worker seals every night, and on request a sample of the stored messages. Each check is written to the audit log. The chain makes a change detectable, not impossible, and so far the anchors stay inside Restow.
- Audit log. It is hash-chained and records every read and restore in every edition; for the archive, searches, items read and downloads are included. The viewer and the export (CSV, JSON with hashes) belong to Business and Service Provider.
- Deletion runs. In Business and Service Provider, a daily deletion run removes only expired items that are not under a legal hold and writes each deletion, with the item's hashes, to the audit log. Without that capability Restow deletes nothing from the archive.
-
Evidence report as an API. The integration API returns a report as JSON in every edition
(
GET /api/v1/archive/report): tenant, period, number and size of the items, items per capture path, the daily anchors of the period, the stored retention policies and the legal holds. Reading the report is logged. It does not run the chain check itself, and a PDF report and a screen for it do not exist yet.
What is planned
A generator for the procedural documentation is planned for an upcoming release (roadmap: "Procedural documentation generator"): a document per tenant, generated from the actual configuration and a template, as Markdown and PDF, versioned and dated. The released version does not generate it. Even then, the complete document with its organisational processes remains your company's task.
Limits you should describe
- Only mail that a chosen capture way took, or that mail import with archiving took over, reaches the archive. Since 0.4.4, in Business and Service Provider, a mail job chooses per kind of mailbox: Microsoft Graph or Exchange journaling for Microsoft 365, IMAP sync or forwarded copies for IMAP and Google Workspace. Journaling and forwarded copies capture in transport and need a TLS certificate of your own; Graph and IMAP sync capture shortly after delivery, are labelled near-time and are not complete (a mail moved or deleted in between can be missed, and Restow cannot see whether a Microsoft 365 tenant keeps deleted mail: an administrator confirms it). Jobs that archived before 0.4.4 keep journaling only until a way is switched on. The new ways were tested against simulated services only. Describe the ways you chose and the gaps they leave.
- The archive period is fixed at 8 years (see Email retention periods in Germany). The deletion run does not check whether a record has to be kept longer under § 147 (3) AO; that is your decision, for example with a legal hold.
- What the storage itself enforces depends on the target. On a local disk and NFS, immutability applies at application level only; S3 Object Lock is a setting per repository and off until an administrator turns it on. See Backup vs. archive.
Restow is designed for GoBD-compliant use. There is no certificate, and under the GoBD there cannot be one (Rz. 180 and 181). See also Email archiving under the GoBD.
Frequently asked questions
Is a procedural documentation mandatory?
The GoBD require a clearly structured procedural documentation (Verfahrensdokumentation) for every data-processing system (Rz. 151). If it is missing or insufficient, Rz. 155 says there is no formal defect of material weight as long as traceability and verifiability are not impaired. The tax authority judges that in each case, so do not rely on it: agree with your tax advisor how detailed your documentation should be.
How detailed does it have to be?
As detailed as is needed to understand the process and the records that are kept. It must be verifiable by an expert third party within a reasonable time, and its design depends on the complexity of the business, the organisation and the system in use (Rz. 151). For a small company with a single archive system it can be short, but it has to be complete and accurate.
Can the vendor of my email archive write it for me?
The vendor can supply technical facts about the software, for example how the hash chain works or what a deletion run does. It can only describe its product, not your process: who grants rights in your company, which emails you archive, for how long, who carries out the controls. Under Rz. 154 the documented process has to match the process actually in use. The procedural documentation remains your company's own document.
How long must I keep the procedural documentation?
Its retention period does not run out while the retention period of the records it is needed to understand is still running (Rz. 154). Earlier versions therefore belong in the archive too: changes must be traceable over time, which is met if they are versioned and a traceable change history is kept.
Do I have to hand it to a tax audit?
In a data access, the parts of the procedural documentation that give a complete overview of the system and are needed to understand it have to be available on request (Rz. 160). The right of data access itself is set out in § 147 (6) AO.
Is the template on this page enough?
No. The template is a skeleton with headings and fill-in prompts, not a filled-in example and not legal advice. It becomes a procedural documentation only through your own entries, and your tax advisor should review the finished version.
Is there an official certificate for an email archive or a procedural documentation?
No. The GoBD state that the tax authorities issue no positive attestations on the correctness of bookkeeping, neither in a tax audit nor in a binding ruling, and that certificates or attestations from third parties do not bind the tax authority (Rz. 180 and 181). They can help when choosing software, but they do not replace your own documentation.
Sources
Read on 22 October 2026.
- Federal Ministry of Finance (BMF): GoBD as of 14 July 2025, Amtliches AO-Handbuch 2026, Anhang 33 (German original). Margin numbers 59, 60, 66, 67, 100 to 112, 117, 119, 121, 131, 134, 135, 142, 151 to 155, 158 to 160 and 179 to 181
- Federal Ministry of Finance (BMF): letter of 14 July 2025, second amendment of the GoBD (German original). Amends, among others, margin numbers 119 and 131 for e-invoices; margin numbers 100 to 112 and 151 to 155 are unchanged
- § 147 Abgabenordnung (AO) (German original). Paragraph 1 no. 1: the working instructions and organisational documents needed to understand the books; paragraph 6: data access
- § 257 Handelsgesetzbuch (HGB) (German original). Paragraph 1 no. 1: the same working instructions and organisational documents under commercial law
- Restow documentation: Archive and journaling. Capture paths, hash chain, storage targets, retention and legal hold, search, export and the evidence report
- Restow documentation: GoBD and evidence. What the archive aims at, what Restow does not claim, and the planned procedural documentation generator