Service
GoBD-compliant archiving
An e-invoice is only properly finished once it is stored correctly. I build you a storage layer that holds up to the technical requirements of the GoBD — including procedural documentation.
Immutable
Once stored, a document stays as it is. Any change would be provable.
Findable
Search across full text and structured data. An auditor finds the document in seconds.
Documented
The procedural documentation is part of it, from the start rather than as an afterthought.
What the GoBD require technically
The GoBD are not a software certificate you can buy. They describe requirements for your entire bookkeeping. Part of that can be solved technically — and that part is what this page is about.
For invoice storage it comes down to four things.
Immutability
A stored document must no longer be changeable without the change being detectable. Technically I solve that with checksums for every document, storage without overwrite rights and a log that records every access. If a file is manipulated afterwards, the checksum no longer matches — and that stands out immediately.
Completeness
No document may be missing and none may exist twice. On intake it is therefore checked whether an invoice number already exists, and gaps in the number sequence are made visible.
Machine readability
An auditor has to be able to evaluate the data, not just look at it. That is precisely why the structured original has to be preserved. A printout or a pure image PDF does not meet this requirement.
Traceability
From the invoice back to the transaction and forward again — this path has to be documented. That includes a log of when which document entered the archive and how.
The procedural documentation
This is the part that is missing most often. The GoBD require a description of how your documents are created, processed and stored. Without it, an audit can object to the orderliness even if everything runs cleanly on the technical side.
That is why the documentation is part of the project for me, not an afterthought. It contains the path a document takes through your systems, the technology used, the responsibilities and the measures that ensure immutability. Written so that an auditor understands it — not as a technical manual.
What the storage layer should do
Beyond the obligation, one point pays off particularly in daily work: search.
When a document is needed, nobody wants to click through folders. I therefore build the storage so that both can be searched:
- Structured data such as invoice number, date, amount, tax rate, customer or Leitweg-ID
- Full text, meaning everything written in the document
That turns finding a transaction into seconds rather than a quarter of an hour. During a tax audit, that is the difference between a calm day and a long one.
How this connects to the other building blocks
Archiving rarely stands alone. If you create e-invoices or send them from your ERP, storage comes up anyway — so it should be built properly right away.
The same applies to the inbound side: received e-invoices are subject to the same retention obligation as outgoing ones. In practice the inbound side is even the more critical part, because documents arrive there from many sources and get lost more easily.
One closing note: I implement the technical requirements and document them. Whether your bookkeeping as a whole complies with the GoBD also depends on your processes. That assessment belongs with your tax advisor — I provide the basis for it.
FAQ
Questions about this service
Is storing the files on our server not enough?
No. A folder on the file server satisfies neither immutability nor logging nor traceability. Anyone with access could replace a file unnoticed. That is exactly what audit-proof storage rules out.
How long do e-invoices have to be kept?
Invoices are subject to commercial and tax retention periods. What matters is that the structured data is preserved in the original — a printout or a PDF derived from it is not enough. The specific period for your case is a question for your tax advisor.
Does the XML have to be kept or is the PDF enough?
The structured original is what has to be kept. With a hybrid ZUGFeRD invoice that is the file with the embedded XML. A separately generated view PDF does not replace it, it can only complement it.
Does the archive run at our place or in the cloud?
Both are possible. I build it so that you decide the storage location: your own server, your existing cloud or storage with technical write protection. The logic stays the same.
Does that make the solution automatically GoBD-compliant?
I implement the technical requirements: immutability, logging, completeness, machine readability, procedural documentation. But the GoBD also concern your organisation and your processes. The final assessment of your individual case therefore belongs with your tax advisor, not with me.
More services
What else I build for you
Have e-invoicing software built
Custom software that creates, validates, sends and receives e-invoices — as a standalone application or a module inside your system.
Learn moreConvert invoices into e-invoices
Existing PDF, paper or legacy invoices become valid XRechnung or ZUGFeRD files — including a validation report.
Learn moreBuild converter software
Your own converter in-house: you define the source format, I build the pipeline with mapping, validation and error handling.
Learn moreGenerate e-invoices in your ERP
Your ERP cannot do e-invoicing yet? I add the capability — as an extension, an interface or a layer in between.
Learn moreCreate e-invoices from Excel and Word
Your existing Word or Excel invoice template additionally produces a valid e-invoice — same layout, same workflow, one click.
Learn moreDoes this sound like your situation?
Describe your situation in a few lines. You get an honest assessment within 24 hours.
Book a free intro call