GoBD and evidence

What German law actually requires

Business emails are commercial correspondence and, where they relate to a booking, accounting records. Under German law that means:

Retention periods: 6 years for commercial correspondence (§ 257 HGB, § 147 AO) or 8 years for accounting records, 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, with procedural documentation and a log of any changes. Records must be kept in their original format: an email stays an email, not a printout.
“Unalterable” specifically means: once captured, nobody, including an administrator, can change or delete the content before the retention period ends; deletions after the period ends are themselves logged.
“Timely and complete” means the copy has to be made before a user can change or delete the original. That is why the archive design uses journaling, not a periodic mailbox sync: a sync only sees what is still there when it runs.
GDPR, alongside GoBD: a deletion concept once retention ends, the ability to search by person for a data-subject access request, access restrictions, and a legal hold used only for a documented reason.

How the archive design targets this (once it ships)

Capture: Exchange Online journaling receives a copy of every journaled message before a user can act on it, as the primary path; Graph sync and IMAP sync are supplements, explicitly marked as “captured after the fact” where journaling could not have seen the item first. Mail imported from files can optionally be archived too; it counts as captured at the import, and its retention starts then.
Immutability: a running hash chain over every archived item, anchored daily, so alteration is designed to be detectable when the chain is checked against those anchors. Anyone with database write access could otherwise recompute the chain itself, which is why the anchors matter. The default storage target is planned to be S3-compatible object storage with hardware object-lock (Compliance mode), enforcing immutability at the storage layer too; a filesystem target is planned to remain usable only after an explicit, audited opt-out, and Restow says so in the interface (“storage target without hardware WORM”) rather than implying a guarantee the storage cannot back up.
Retention and legal hold: a policy per tenant (6, 8, 10 years, or unlimited), a legal hold that blocks deletion until explicitly lifted, and a daily deletion run that only removes expired, non-held items and writes what it deleted into the same hash chain.
Evidence: search across message and attachment content, export as EML with a checksummed manifest (readable by any mail client, without Restow running), and a signed evidence report per tenant covering the retention policy, chain integrity, storage’s object-lock status, and deletion history.
Procedural documentation (Verfahrensdokumentation): a per-tenant template pre-filled from the actual configuration (capture path, storage location, encryption, access rights, retention, deletion procedure, controls) which the organization completes; 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, and will not claim once archiving ships

Not “GoBD-certified”. There is no such 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. Restow will say the archive is built for German GoBD requirements and name the specific measures, not “certified” or “compliant” as an unqualified claim.
Not “revisionssicher” (a marketing term with no legal definition) without immediately explaining what it means in the same sentence: change-detecting (hash chain) and, on object-lock storage, unalterable.
Not a substitute for review by your tax advisor or data protection officer.
No completeness guarantee for IMAP archiving without journaling. It is documented as the best available approximation for providers that do not support journaling, not as equivalent to it.

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: how journaling, the hash chain, WORM, retention and legal hold are designed to work together.
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 full design and current (in-development) status.