German SMEs looking at AI automation usually ask about GDPR first, since it’s the more familiar regulation. What often gets missed is GoBD — the Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, the German rules governing how business records, especially anything tax-relevant, must be kept, stored and made available. An AI agent that touches invoicing, order data or customer records sits at the intersection of both, and the two frameworks pull in slightly different directions: GDPR pushes toward minimising and deleting personal data, GoBD pushes toward retaining tax-relevant records unaltered for years. Getting this right isn’t complicated once you understand both sets of requirements, but treating it as “just a GDPR question” misses half the picture.
This isn’t legal advice — it’s a practical starting point. For anything customer-facing, financially relevant, or high-risk, involve your Steuerberater and, where appropriate, legal counsel.
What GoBD actually requires
GoBD applies to anything relevant for German tax and accounting purposes — invoices, receipts, booking records, and increasingly the systems and processes that generate them. The core requirements that matter for AI automation:
Immutability. Once a tax-relevant record is created, it can’t be silently altered. Any correction needs to be traceable — the original stays visible, and the correction is logged as a separate, auditable event.
Retention. Most tax-relevant records need to be kept for ten years, in a form that remains readable and exportable for the full period — not just archived somewhere that happens to still exist.
Verifiability (Nachvollziehbarkeit). A third party, typically a tax auditor, needs to be able to follow how a record came to exist — what triggered it, what data went into it, and what process produced the final version — without relying on someone’s memory of how the system worked.
Machine-readable access. For a formal audit, records need to be exportable in a structured, machine-readable format your tax authority’s systems can process — this is exactly what a DATEV export exists to provide.
None of this is new because of AI — it’s the same standard that already applies to any accounting or invoicing system. What changes is that an AI agent generating or touching these records needs to meet the same bar as the system it’s replacing or augmenting.
Where AI agents intersect with GoBD
Invoice generation. If an agent generates invoices — from Lexoffice, sevDesk or a similar system — the generated record needs to be immutable once issued, with any correction handled as a proper amendment rather than an edit to the original.
Automated categorisation. An agent that reads a receipt and assigns it to an account needs that decision logged in a way that’s reconstructible later — not just the final categorisation, but enough trail to show how it was reached, in case a tax auditor asks.
Data pipelines feeding accounting systems. If an agent moves data between a CRM, an e-commerce platform and an accounting tool, the path that data took needs to be traceable end to end. A missing link in that chain is exactly the kind of gap a GoBD audit looks for.
Change logs, not silent updates. Any system where an agent can modify a tax-relevant record needs versioning built in from the start — the original state, the change, the timestamp and, where relevant, what triggered it.
The practical implication is that “the agent got it right” isn’t the whole bar. The system also needs to be able to show how it got there, on demand, potentially years later.
Where GDPR pulls in a different direction
GDPR’s default posture on personal data is closer to the opposite of GoBD’s: collect only what’s needed, keep it only as long as necessary, and support deletion on request. That creates a real tension where records contain both tax-relevant data (which must be retained) and personal data (which GDPR wants minimised and eventually erased).
The resolution used in German accounting practice generally isn’t new because of AI — data that’s genuinely required for tax retention is exempt from a GDPR deletion request for the retention period, because GDPR itself recognises legal retention obligations as a valid basis for continued processing. The risk with AI automation is scope creep: an agent that logs more than the invoice actually requires — full conversation transcripts, browsing behaviour, unrelated customer fields — extends what’s swept up under “we have to keep this,” when in fact only the tax-relevant subset does. Scoping what an agent logs and retains, distinct from what it merely used momentarily to do its job, is where this actually gets decided in practice.
A practical checklist
For any AI agent touching invoicing, order data or other tax-relevant records:
- Separate what must be retained from what doesn’t. Tax-relevant fields fall under GoBD’s ten-year rule; everything else should follow ordinary GDPR minimisation and deletion practice.
- Log the process, not just the output. Be able to show what triggered a record, what data fed into it, and what the agent did — reconstructible after the fact, not just at the time.
- Build corrections as amendments, not edits. Any system an agent writes to should preserve the original record and log the correction separately.
- Confirm export format with your Steuerberater or DATEV-certified system before assuming an agent’s output is audit-ready — “readable” and “audit-format-compliant” aren’t the same thing.
- Scope logging deliberately. Log what’s needed for traceability and tax compliance; avoid defaulting to logging everything an agent touches, since that data inherits the more complex retention picture too.
- Keep a documented sub-processor and DPA trail for every system in the chain, the same as with any GDPR-relevant automation — see our broader GDPR compliance guide for the full framework.
Why this is manageable, not a blocker
None of this is a reason to avoid automating invoicing, receipt handling or order-to-accounting workflows — it’s a design constraint, and one German accounting software has already been built around for years. The systems most DACH businesses already use, Lexoffice, sevDesk and DATEV among them, are built with GoBD in mind. An agent working through those systems, rather than around them, inherits most of that compliance posture rather than having to invent it. The failure mode isn’t “AI can’t meet GoBD” — it’s building a shortcut that writes directly to a database without the audit trail those systems already provide.
If you’re automating invoicing, receipt capture or back-office workflows and want a second opinion on whether your setup holds up under GoBD as well as GDPR, get in touch and we’ll walk through your specific systems — or explore what a properly scoped workflow automation build looks like for a German back office.