GoBD guide: what does “GoBD compliant” mean in practice?

GoBD (German: Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) is guidance on how electronic bookkeeping and invoice-related data should be created, processed, and retained in Germany.

If you run a small business, GoBD is mostly about one thing: can you show a clean, consistent story from “invoice created” → “invoice sent” → “invoice retained” without silent changes, missing documents, or unclear responsibilities.

This guide explains GoBD in practical terms and gives you templates and checklists you can apply today.

Note: This is general information and not legal or tax advice. For binding interpretation, consult a qualified advisor or the competent authorities.

1) GoBD in one sentence

GoBD is about traceability, completeness, and immutability of business-relevant electronic records — and about having a workflow you can explain.

2) Key takeaways (for freelancers and small teams)

  • GoBD is not “a certificate you buy” — it’s the result of software + process.
  • Most audit pain comes from archiving and process documentation, not from invoice layout.
  • If you can do a “10 random invoices from last year” drill quickly and consistently, you’re usually on the right track.

3) Who is GoBD relevant for?

In practice, GoBD matters for almost anyone in Germany who creates or processes business-relevant documents electronically, especially:

  • freelancers and sole proprietors
  • small businesses
  • companies issuing invoices digitally (PDF, ZUGFeRD, XRechnung)
  • businesses scanning/archiving receipts or keeping evidence in email

Even if you “only” create invoices, once documents are created electronically, expectations around traceability, immutability, and retention apply.

4) The key GoBD principles (plain English)

GoBD contains multiple principles. These are the ones that usually matter most in day-to-day operations:

Traceability & auditability

An auditor should be able to understand how data was produced and why it looks the way it does.

In practice:

  • clear workflows (invoice → sending → archiving)
  • documented processes (often called “process documentation”)
  • unambiguous links between documents and entries

Completeness

All relevant documents must be complete.

In practice:

  • no unexplained gaps in invoice numbering
  • no lost invoices or supporting documents

Accuracy

Data must be factually correct.

In practice:

  • correct customer data, tax rates, mandatory invoice fields
  • proper correction flows

Timely recording

Transactions should be recorded in a timely manner.

In practice:

  • defined internal timelines and responsibilities
  • predictable routines instead of ad-hoc catch-up

Orderliness

Documents must be organized and retrievable.

In practice:

  • consistent filing and naming conventions
  • searchability (by customer, date range, invoice number)

Immutability

Relevant records should not be silently overwritten.

In practice:

  • changes are visible and explainable (versioning / logs)
  • corrections happen via defined processes (cancellation, corrective invoice)

5) What this means for invoicing software

GoBD “compliance” is usually not a single feature. It’s a combination of:

  • creating invoices correctly (mandatory fields, numbering, dates)
  • clean correction workflows (cancellation, credit note, corrected invoice)
  • auditable storage (complete, easy to find, not silently changed)
  • exports / access options for review and audit situations

Important: GoBD is also about your process: who can change what, how invoices are sent, where emails/attachments are archived, and how backups work.

6) GoBD and e-invoicing (PDF, ZUGFeRD, XRechnung)

GoBD does not only apply to “classic PDFs”. Once you work with electronic formats like ZUGFeRD or XRechnung, you should treat structured data as part of the business record.

Practical rule of thumb:

  • If the structured data is used to validate/import an invoice, archive it in a way that remains linked to the invoice and retrievable.

Related guides:

7) Process documentation (often the real bottleneck)

Audits often ask: How do you work? A simple “process documentation” typically covers:

  • the systems you use (invoicing app, storage, backups)
  • roles & permissions (create / approve / send)
  • the flow from document creation to archiving
  • data-loss prevention (backup + restore)
  • correction handling

It doesn’t have to be huge. A clear, consistent description is a strong starting point.

Minimal template (copy/paste starter)

  1. Scope: Which documents are in scope? (invoices, offers, corrections, attachments, exports)
  2. Systems: Which software/storage is used? Where is the “source of truth”?
  3. Roles: Who creates, who approves, who sends, who may correct?
  4. Numbering: How are invoice numbers assigned? How are cancellations handled?
  5. Archiving: Where are documents stored? How do you ensure they are not overwritten?
  6. Backups: How often? Where? Who checks restores? When was the last restore test?
  7. Corrections: What is your standard correction flow? How are links between documents maintained?

8) Retention & archiving: what “proper” looks like

GoBD doesn’t necessarily mean you need a dedicated document management system — but your archiving should answer these questions clearly:

  • What do you retain? (invoices, cancellations/corrections, relevant emails/attachments, exports)
  • Where is it stored? (folder structure, a central location, permissions)
  • How do you find it later? (invoice number, customer, date range)
  • How is immutability ensured? (no silent overwrites, changes are traceable)
  • How do backups and restores work?

Practical tip: define one consistent place for “documents related to an invoice” (e.g., email PDF, delivery note, cancellation) so they’re linked to the invoice or retrievable together.

Retention periods depend on document type and applicable rules (often many years). If you need exact requirements for your case, consult a qualified advisor.

Example folder structure (simple but robust)

/Accounting/
	/Invoices/
		/2026/
			/2026-02/
				2026-000123__Client-Name__Invoice.pdf
				2026-000123__Client-Name__Invoice.zugferd.xml (optional)
				2026-000123__Client-Name__Email.eml (optional)
	/Corrections/
		/2026/
			2026-000123__Cancel.pdf
			2026-000124__Corrected.pdf
	/Exports/
		/2026-02-11__ExportPackage/
			invoices.csv
			clients.csv
			payments.csv

9) Immutability in practice: correct, don’t “edit”

A common misconception: GoBD doesn’t mean nothing can ever be corrected — it means corrections must stay traceable.

Good practice for invoices:

  • keep the original invoice
  • correct via cancellation and a corrected invoice (or credit note/correction documents, depending on the case)
  • document numbering and references cleanly
  • archive both documents (original + correction)

If you work with ZUGFeRD or XRechnung, also ensure the structured invoice data belonging to an invoice matches the PDF and the underlying transaction.

10) Audit data access: Z1 / Z2 / Z3 (quick overview)

In practice, “data access” describes how an audit can be supported depending on the situation:

  • Z1: direct access (review in the system)
  • Z2: indirect access (you provide analyses/lists)
  • Z3: data handover (you export data in an appropriate form)

What this usually means for day-to-day operations:

  • you should be able to export invoices/documents (at least PDFs/files; often also structured data)
  • you should be able to explain where data lives and how it’s retrieved
  • you should have a repeatable process for providing documents

A practical “audit export package” checklist

  • a list of invoices (CSV/Excel)
  • PDFs (and, if applicable, structured data such as ZUGFeRD XML)
  • a list of customers/clients
  • payment/status overview
  • your short process documentation (1–2 pages is already helpful)

11) Common pitfalls (and how to avoid them)

Pitfall 1: Overwriting invoices instead of correcting them

Better: use cancellation + corrective invoices so history stays traceable.

Pitfall 2: Documents scattered across inboxes and chats

Better: centralize archiving and define clear rules.

Pitfall 3: Backups exist, but restore is never tested

Better: document backup + run periodic restore tests.

Pitfall 4: Invoice-number gaps without explanation

Better: document technical/organizational reasons (cancellations, separate series, test documents).

Pitfall 5: Changes without logs

Better: use systems that make change history visible (audit trail/versioning) or enforce strict procedures.

12) GoBD checklist

Use this as a practical starting point:

  • consistent invoice numbering (or clearly separated series)
  • corrections happen via defined correction documents (not overwriting)
  • invoices and supporting documents are complete and quickly retrievable
  • filing structure, naming, and responsibilities are defined
  • process documentation exists (a short version is fine to start)
  • permissions are controlled (who can create/change/delete?)
  • backups are documented and restore was tested
  • retention obligations are met (including digital records)

Additionally (often where audits get painful):

  • emails/attachments that replace or supplement documents are archived consistently
  • there is a rule for handling test invoices/drafts
  • approvals are defined (who releases invoices and corrections)
  • at least yearly: a small “10 invoices from last year” drill (retrievability + completeness)

13) Preparing for an audit (simple annual routine)

Audits often focus on:

  • retrievability (can you provide documents quickly?)
  • consistency (do invoices, payments, and records match?)
  • change history (are corrections traceable?)

Practical preparation:

  • name an owner who understands the workflow.
  • keep process docs up to date.
  • do a yearly drill: “Can we provide 10 random invoices from last year in 5 minutes?”

14) How AGYNAMIX Invoicer supports GoBD-friendly workflows

At a high level, you want software that supports traceability and prevents silent changes. AGYNAMIX Invoicer is designed with a privacy-first, offline-first approach and offers several features that directly address GoBD requirements:

Immutable archiving (WORM principle)

AGYNAMIX Invoicer supports WORM-style archiving (Write Once, Read Many) for published documents:

  • File-based archive with access control: On Windows, ACL (Access Control Lists) are used; on Linux and macOS, POSIX permissions protect archived files from modification after the fact.
  • S3-compatible storage with Object Lock: As an alternative, documents can be stored in S3-compatible storage with Object Lock enabled — ensuring immutability at the infrastructure level.

Both approaches can be combined with process documentation (Verfahrensdokumentation) to achieve GoBD compliance.

Audit logging and hash chaining

  • Audit log of all changes: Every relevant action (create, modify, cancel, export) is logged.
  • File hashes: Cryptographic hashes are stored for archived documents so tampering is detectable.
  • Hash chaining: Consecutive audit log entries are cryptographically chained together. This proves that no entry was removed or altered after the fact.

Immutability: what GoBD actually requires

A common misconception is that only special hardware (e.g. WORM media) can satisfy GoBD’s immutability requirement. The official BMF guidance makes clear:

“Immutability of data, data records, electronic documents, and electronic records […] can be ensured through hardware (e.g. tamper-proof storage media), through software (e.g. backups, locks, record finalization, deletion markers, automatic logging, historization, versioning), or through organizational measures (e.g. access-control concepts). Storing data and electronic documents in a file system does not, as a rule, satisfy the immutability requirement unless additional measures are taken to ensure immutability.”

— BMF letter (GoBD), margin no. 110 (translated; original in German)

This means: immutability can be achieved through hardware (e.g. WORM storage, S3 Object Lock), software (e.g. record finalization, logging, hash verification), or organizational measures (e.g. permission concepts, process documentation) — or a combination of all three.

The second sentence is especially relevant: a plain file system alone is not sufficient — additional measures are required. AGYNAMIX Invoicer addresses exactly this: with ACL/POSIX permissions, S3 Object Lock, audit logging, and hash chaining.

AGYNAMIX Invoicer combines these layers: software-level finalization with hash verification, hardware-level options like S3 Object Lock, and organizational support through audit logs and access controls.

Your exact GoBD posture still depends on your end-to-end process: sending, filing, backups, and who has access.

15) Next steps on this site

See also: