What does GoBD require from ERP?
Traceable documents, change history, and auditable exports: what GoBD means for ERP processes and e-invoicing, and what to watch when choosing a system.
GoBD (the German principles for proper keeping and retention of books, records, and documents in electronic form) require that digital books, records, and documents are kept in a traceable, complete, and immutable way. For ERP that means concretely: invoices, postings, and business transactions remain auditable on the transaction, including approval and change history. E-invoicing increases the pressure because structured data must be received and posted in the process, not in a tool beside it. GoBD is not a vendor product feature. It is a filter for every system decision in the finance and order environment.
What does GoBD mean in practice for ERP flows?
The principles translate into operational requirements:
- Documents belong on the business transaction (order, goods receipt, project), not in an island solution without context.
- Approvals and changes are historized and attributable to a person or role.
- Export for audits and tax advisors works without media breaks.
- Retention periods, access control, and long-term readability are clarified.
“Immutable” does not mean nobody may correct anything. It means corrections remain traceable and the original document state is not silently overwritten. When corrections run in spreadsheets or by email, the evidence chain breaks, even if the ERP stores a document somewhere.
Why is e-invoicing a GoBD topic?
Because XRechnung and ZUGFeRD deliver structured data that should land in the ERP process: receipt, validation, assignment to the transaction, approval, posting preparation, archiving. Separate mailboxes and desktop tools create exactly the media breaks that audits expose. The technical format question is only the entry point. The process decides.
More on the flow: XRechnung and ZUGFeRD in ERP. In parallel, integrations to DATEV and archive matter: ERP integrations.
Which check questions do you ask during system selection?
- Document on the transaction: Can an audit follow the path from purchase order through goods receipt to invoice without an export puzzle?
- Audit trail: Are approvals, cancellations, and changes exportable and attributable in time?
- Archive and retention: How are retention and access secured technically and organizationally?
- DATEV and tax-advisor workflow: Does export match the real handoff process, not only the demo?
- Permissions and separation: Who may see, change, and approve documents, and is that logged?
These questions belong in selection and in the contract. Retrofitting later often costs more than a deliberate architecture decision.
How do you avoid island solutions despite compliance pressure?
Many companies react to deadlines with quick tools: an e-invoice portal here, an archive there, approval by mail. Short term that feels relieving. Medium term three truths appear for the same transaction. Auditability suffers because nobody can show the full path in one system.
Better: map one critical document process in the ERP, for example inbound invoice with assignment and approval. Only when that path holds do you extend adjacent formats and volume. Individual ERP helps when approval logic and document fields do not fit standard modules, without pushing compliance into spreadsheets.
Which decisions come next?
Inventory where documents sit outside the ERP today. Clarify with tax advisors and internal audit which exports and evidence are actually required. Prioritize one end-to-end document path (receipt to archive) and check DATEV and archive integrations in parallel.
Further reading: XRechnung and ZUGFeRD and ERP integrations. GoBD does not replace specialist advice, but it makes visible whether your ERP carries the transaction or only stores files.