Skip to content

GoBD and other record-keeping rules

Restow’s archive (see Archive and journaling, available since 0.1.0) is designed for GoBD-compliant use. This page lays out what that actually means, requirement by requirement, and looks at a few other record-keeping regimes people sometimes ask about (SEC Rule 17a-4, FINRA, Switzerland, Austria) without claiming to satisfy any of them.

GoBD requirement Restow mechanism Status
Complete and correct Journaling captures a copy before a user can change or delete anything; mail imported from files is archived at the import and counted from then. Since 0.4.4, copies that a mail provider forwards are captured at transport too, and Graph capture and IMAP archiving capture from the mailbox near-time, labelled as such Available (journaling, forwarding, Graph capture and IMAP archiving from Business; import with archiving in every edition)
Timely Capture happens before the recipient’s mailbox can be altered (journaling), not on a later schedule. Forwarded copies are made in the provider’s transport. Near-time capture from a mailbox (Graph, IMAP archiving) leaves a gap in which a mail can be moved or deleted, and Restow gives no completeness guarantee for it Available (Business)
Orderly, traceable Search over subject, addresses and (for imported mail) body text, per-item metadata, EML/ZIP or MBOX export with a manifest and checksums, evidence report as JSON through the integration API Available (every edition); chain-value file (CHAIN.txt) and signed PDF evidence report planned
Unalterable Hash chain over every archived item with chain verification (tamper-evident; since 0.3.1 also against daily anchors sealed every night, with an optional sample read back from storage), and an application with no path to change or delete an item before retention ends. On S3 with Object Lock the archive item records are locked to the end of the retention, and the message content is locked with the backup data where immutable backups are turned on (for that setting’s period, not the archive’s retention date) Hash chain, verification and application-level immutability available; Object Lock for the content only through the repository’s immutable-backups setting; daily external anchors and Object Lock that follows the archive’s own retention planned
Machine-evaluable Original format retained (an email stays an email), search over subject, addresses and body text of imported mail; attachment content is not searched Available
Original format Byte-exact message/rfc822 storage of the original, not a converted or printed copy (an imported MSG file contains no email in that form and is rebuilt as EML) Available
Procedural documentation (Verfahrensdokumentation) A per-tenant template pre-filled from the actual configuration (capture way, storage, 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 Planned
Change / deletion logging Every deletion by the retention run is written, with the item’s hashes, to the hash-chained audit log Available (Business)
Defined retention period A fixed default of 8 years, ending on 31 December of the year of receipt plus 8 years. That covers the 6 years for business letters and the 8 years for accounting vouchers (since 2025), not the 10 years for books and annual financial statements; no screen or API sets another period in 0.4.7; the enforced deletion run needs Business Fixed default available (every edition); other periods not settable yet; enforced deletion run available (Business)
Legal hold (not itself a GoBD requirement, but often needed alongside retention) Per tenant or per mailbox, with a reason, audited; blocks deletion (a hold on a search result is not available) Available (Business)
Access control, audited access The archive is for tenant administrators; searches and item reads are written to the audit log. Role-scoped search (end user, provider admin with four-eyes release) is planned Audited administrator access available; role-scoped search planned

The archive-specific mechanisms in this table ship with 0.1.0 where marked available; the rest are planned; see Archive and journaling for the full design and Archiving for status. Separately from the archive, Restow encrypts and isolates each tenant’s data today; every read, restore or export is recorded in the tamper-evident (hash chain) audit log (who, when, what, on whose behalf, from which IP) in every edition. The audit log viewer (list, filter, entry detail and chain verification) ships with Business and Service Provider, and since 0.3.1 so does the audit log export (CSV, JSON with hashes). See Audit log.

A fixed retention period is also not automatically the last word: under § 147(3) AO, a record must be kept longer while it still matters for a tax assessment that is not yet final. A deletion run that always deletes at a fixed mark without checking this could delete too early. Applying that check, for example by placing a legal hold (Business), is your organization’s own decision, not something Restow automates.

Not explicitly. GoBD Rz. 110 of the BMF’s guidance gives access-authorization concepts (Zugriffsberechtigungskonzepte) as its example of an organizational measure that can support immutability, alongside hardware measures (tamper-proof media) and software measures (write locks, deletion markers, automatic logging, versioning). The same paragraph also states that storing records in an ordinary file system “regularly does not meet” the immutability requirement unless additional measures ensure it. The default archive target in Restow is the local volume, where the application enforces immutability (no path to change or delete an item before retention ends, the hash chain, access restriction, deletion logging): the kind of “additional measures” Rz. 110 refers to. Hardware WORM for archived message content that follows the archive’s own retention (S3-compatible Object Lock, COMPLIANCE mode, for the full retention period) is planned for exactly that reason. What exists today: on S3 with Object Lock the archive item records are locked to the end of the retention, and since 0.4.0 an administrator can turn on immutable backups for a repository, which locks the packs that hold the message content together with the backup data, for the period set there (1 to 3650 days, renewed while the packs are in use). That is a rolling lock, not a lock to the retention date, and it was tested against a fake S3 service, not yet against a real one. On local and NFS targets the application enforces immutability, and the interface labels such targets “No hardware WORM”; see Archive and journaling for the full statement. Whether these measures are enough for your setup is for your own tax advisor or auditor to assess, not something Restow decides for you.

Outside Germany, the picture is different in one specific case. US SEC Rule 17a-4(f) governs electronic records for broker-dealers: it requires either a WORM (“non-rewriteable, non-erasable”) storage medium, or, since amendments adopted 2022-10-12 (effective 2023-01-03, compliance date 2023-05-03), an “audit-trail alternative”: a system that can recreate an original record if it is modified or deleted. Both routes also require an undertaking to furnish records to regulators, which since the 2022 amendments can be given by a designated executive officer instead of only a designated third party. FINRA Rule 4511 incorporates the same 17a-4 electronic-storage standard by reference for its members, plus a 6-year default retention for any record without its own specified period.

This regime applies to US broker-dealers, FINRA members, and, under the same 2022 rulemaking, security-based swap dealers and major participants (Rule 18a-6). It has no bearing on a German (or other EU) business archiving ordinary mail under GoBD. If it does apply to you, meeting Rule 17a-4(f) is a separate assessment your organization would need to arrange with its own counsel and auditor, not something this product certifies.

  • Switzerland (OR Art. 958f, detailed in the GeBüV, the ordinance on keeping and retaining business records): books, accounting vouchers and business correspondence are retained 10 years from the end of the fiscal year. Books and vouchers may be kept electronically or on comparable media (OR Art. 958f(3)); the annual report and the audit report must be kept in written, signed form (OR Art. 958f(2)), so the electronic option does not cover those two. GeBüV Art. 9 sets the media rules for the electronic option: either an unalterable medium, or an alterable medium combined with integrity procedures (for example digital signatures), a verifiable storage time (for example timestamps) and documented procedures, so there is a WORM-like option, but also an alterable-plus-controls alternative, not a strict WORM mandate.
  • Austria (BAO § 132): 7 years for most records (longer periods apply to some, for example real-estate-related records, up to 22 years), extended for as long as a document remains relevant to a pending tax proceeding; the period starts at the end of the calendar year for which the entries were made or to which the documents relate.

Neither of these is a target Restow’s design has been built against specifically. The mechanisms above (journaling, hash chain, retention policy, legal hold) are broadly the same kind of measure these laws also ask for, but Restow makes no claim of meeting either regime’s specific requirements.

Restow does not claim certification, conformity or compliance with GoBD, SEC Rule 17a-4, FINRA, SOC 2, ISO, or any other standard: no software can certify that for you. GoBD Rz. 179-181 are explicit that tax authorities issue no positive attestations (Positivtestate) of conformity, neither in a tax audit nor in a binding ruling, and that a third party’s certificate does not bind the tax authority either. What Restow says instead: the archive is designed for GoBD-compliant use, with the specific measures named on this page and on Archive and journaling. Whether a given deployment actually meets your organization’s obligations, under GoBD or any other regime, is something only your own tax advisor, auditor or compliance counsel can confirm for your specific situation.