GoBD and evidence

What the law asks for (Germany)

Business emails are commercial letters (Handelsbriefe) or, where they relate to a booking, accounting vouchers (Buchungsbelege). Under German law that means:

Retention periods: 6 years for business letters (§ 257 HGB, § 147 AO), 8 years for accounting vouchers (since 2025) and 10 years for books and annual financial statements.
GoBD (the German finance ministry’s administrative guidance on proper bookkeeping and record-keeping): records must be complete, correct, timely, orderly, unalterable, traceable and machine-evaluable. The guidance also asks for procedural documentation, a log of changes, and keeping records in their original format: an email stays an email, not a printout.
“Unalterable” (unveränderbar) means that once a record is captured, nobody, an administrator included, can change or delete its content before the retention period ends. Deletions after the period ends are themselves logged. How far Restow meets this on each storage target is stated below and on Archive and journaling.
“Timely and complete” means the copy should be made before a user can change or delete the original. That succeeds most reliably in transport, by journaling at Exchange Online or by a copy that the mail provider forwards. A capture from the mailbox (Graph, IMAP archiving) is near-time, but not guaranteed to be gap-free, and mail that Restow takes over afterwards is marked as captured afterwards: see Journaled or near-time capture.
GDPR, alongside GoBD: a deletion concept once retention ends, the ability to find data by person for a data-subject access request, access restrictions, and a legal hold only with a documented reason.

How the archive targets this

Capture. Five ways fill the archive. Two capture at transport, before a user can act on the mail (Business and above): Exchange Online journaling, and plain copies that a mail provider forwards for IMAP accounts and Google Workspace (since 0.4.4). Two capture near-time, from the mailbox shortly after delivery (Business and above, since 0.4.4): Graph capture for Microsoft 365 and IMAP archiving for IMAP and Google Workspace. Near-time capture is not complete: a mail moved or deleted in the gap can be missed, and Restow labels such mail as what it is. Mail imported from files can be archived at the same time in every edition; it counts as captured at the import, and its retention starts then. Mail that Graph capture or IMAP archiving takes over once from the existing mailbox is marked Captured afterwards. The same mail from several ways is kept as one item with the stronger way; an earlier, weaker capture stays in the archive unchanged. Mail that was neither captured nor imported is not in the archive.
Tamper evidence. A running hash chain over every archived item, daily anchors that the worker seals every night, and an archive check in three parts: every link, the comparison with the anchors, and on request a sample of the stored messages read back and compared with their checksums from capture. Anyone with write access to the database could recompute the chain and the anchors with it, which is why external anchors are planned; in 0.4.7 the anchors stay inside Restow. On local and NFS targets the application alone enforces immutability. With Object Lock, the sealed records are locked to the end of the retention, and the packs that hold the message content are locked too where immutable backups are turned on for the repository, for that setting’s period, not until the archive’s retention date. The long form is on Archive and journaling.
Retention and legal hold. In 0.4.7 a fixed default of 8 years, ending on 31 December of the year of receipt plus 8 years (no screen or API sets another period yet). That covers the 6 years for business letters and the 8 years for accounting vouchers, but not the 10 years for books and annual financial statements. From Business, a legal hold per tenant or per mailbox blocks deletion until it is released, and a daily deletion run removes only expired, non-held items and writes each deletion to the hash-chained audit log.
Evidence. Search over subject, addresses and, for imported, captured and forwarded mail, body text (attachment content is not searched), with the capture way, the other ways that captured the same mail and “captured afterwards” named on each hit (a capture that a stronger way replaced is hidden unless you ask for it, includeSuperseded), export as EML in a ZIP with a checksummed manifest or as MBOX (readable without Restow running), and an evidence report as JSON through the integration API. An auditor export with the chain values (CHAIN.txt) and a signed PDF evidence report are planned.
Procedural documentation (Verfahrensdokumentation), planned: a per-tenant document generated from the actual configuration and a template (system description, capture ways, storage location, encryption, access rights, retention, deletion procedure, controls, responsible people, change history), as Markdown and PDF, versioned and dated. It is part of being audit-ready, not an extra. Restow 0.4.7 does not generate it. The full document, including its organizational processes, stays the taxpayer’s own responsibility under GoBD, because an archive’s defensibility rests on that document as much as on the data itself.

What Restow does not claim

No certification. There is no certificate to hold: GoBD Rz. 179-181 are explicit that tax authorities issue no positive attestations (Positivtestate), neither in a tax audit nor in a binding ruling, and that a third party’s certificate does not bind the tax authority either; responsibility stays with the taxpayer. IDW PS 880 is an audit standard for software, expensive and optional. Restow says the archive is designed for GoBD-compliant use and names the specific measures.
No marketing label in place of a statement. Terms in the style of “audit-proof” have no legal definition. Restow says “tamper-evident (hash chain)” and states what each storage target enforces.
No conclusion from a setting. Immutable backups and ransomware detection are technical measures that protect backup data. Turning them on does not show that an archive or a procedure meets GoBD; that stays an assessment for your tax advisor.
No replacement for review by your tax advisor or data protection officer.
No claim beyond the known issues of the capture ways. The ways that capture from a mailbox or at a provider’s transport (Business and above, since 0.4.4) were tested against simulated services only, holds in a Microsoft 365 tenant are not detected, and the receiver does not check the sender. See Archiving.
No completeness beyond what reached the archive. Only mail that was captured or imported is in it. For mail captured near-time (Graph, IMAP archiving) Restow gives no guarantee of completeness; such mail is labelled as what it is.
No hardware WORM guarantee without Object Lock. On local storage and NFS the immutability is enforced by the application only.

Where to read more

Backup vs. archive: why these are two different systems, and why neither one deletes anything from your mailbox.
Archive and journaling: capture ways, the hash chain, storage targets, retention and legal hold in full.
Regulations: a requirement-by-requirement table, whether WORM storage is actually required, and how GoBD compares with SEC 17a-4, FINRA, and other regimes.
Archiving: the summary and current status (available and planned), including the capture ways and their known issues.