Storing e-invoices: what the GoBD require since 2025

The GoBD, the German principles for the proper keeping and retention of books, records and documents in electronic form and for data access, are not a law but a letter from the Federal Ministry of Finance (BMF) that tax authorities apply in audits. The base version dates from 28 November 2019, a first amendment followed on 11 March 2024 (GoBD amendment of 14 July 2025). The ministry explicitly bases the second amendment on the introduction of mandatory e-invoicing between domestic businesses since 1 January 2025 (GoBD amendment of 14 July 2025). It applies without a transition period: the new version is to be applied with effect from 14 July 2025 (GoBD amendment of 14 July 2025, marg. no. 185).

Four marginal numbers decide how invoices are filed. Marginal number 119 states that the structured part of an e-invoice is sufficient. Marginal number 131 requires incoming invoices to be kept in the format received, which for e-invoices means XML. Marginal number 125 makes clear that a format conversion must not delete the XML part. And marginal number 76 allows businesses to skip an image copy of outgoing invoices if a copy with identical content can be produced at any time (GoBD amendment of 14 July 2025). What counts as an e-invoice is set by the VAT Act: an invoice that is issued, transmitted and received in a structured electronic format and allows electronic processing (VAT Act, Sec. 14(1)). A PDF without embedded data is therefore an other invoice, for which the existing rules continue to apply.

The next sentence limits the relief: the human-readable part of a hybrid e-invoice, such as the PDF part of a ZUGFeRD invoice, only has to be kept if it contains additional or deviating information that matters for taxation, for example posting notes (GoBD amendment of 14 July 2025, marg. no. 119). The table shows what that means for the most common invoice types.

Since July 2025, marginal number 131 of the GoBD reads: incoming electronic commercial or business letters and accounting records must be kept in the format in which they were received, for example invoices in XML format (GoBD amendment of 14 July 2025, marg. no. 131). For structured records received, the tax authorities only require a match in content, not a visual match (GoBD amendment of 14 July 2025, marg. no. 118). That follows from the fact that an XML file has no image against which a reproduction could be compared.

Converting to another format is still possible, but only under the conditions of marginal number 135. As a rule, when documents are converted into an in-house format, both versions have to be archived, assigned to the same record, managed under the same index, and the converted version has to be marked as such (GoBD, marg. no. 135). The converted version alone is only enough if four conditions are met at the same time (GoBD, marg. no. 135):

In practice the conclusion is simple: the file that arrived stays unchanged in the archive. Anything the business derives from it for its own work, a view, an extract for accounting, a searchable version, is added and does not replace it. Anyone who extracts text from image files by text recognition must also keep that text after verification and correction (GoBD amendment of 14 July 2025, marg. no. 131); with a genuine e-invoice this step is unnecessary because the data is already structured. How reliably text recognition works on paper and plain PDF invoices is covered in Text recognition in practice.

A hybrid format consists of a structured data part, such as an XML file, and a human-readable data part, such as a PDF document; both are combined in one file (BMF letter of 15 October 2025). One example is ZUGFeRD from version 2.0.1, excluding the MINIMUM and BASIC-WL profiles (BMF letter of 15 October 2025). For VAT the order of precedence is clear: the invoice data in the structured part is the leading part, and where the parts differ it takes precedence over the information in the image part (BMF letter of 15 October 2025).

That leads to the most important rule for any archive: the XML data must not be lost. The GoBD use ZUGFeRD as the example. What matters is not whether the recipient only uses the invoice image, but that the structured data part is present and is not deleted by a format conversion, for example to TIFF (GoBD amendment of 14 July 2025, marg. no. 125). More generally, reducing existing machine evaluability by converting the file format is not permitted; the GoBD cite the conversion of PDF/A files from the PDF/A-3 standard into an image format such as TIFF or JPEG as an example (GoBD, marg. no. 129).

When does the PDF part still have to be kept? When it contains additional or deviating information that matters for taxation; the GoBD cite posting notes and qualified electronic signatures as examples (GoBD amendment of 14 July 2025, marg. no. 131). In that case machine evaluability extends to the entire content of the PDF file (GoBD amendment of 14 July 2025, marg. no. 125). Deviations have a second side: if the image part contains different invoice details from the structured part, for example because of a manipulated description of services or a different tax amount, it may constitute a further invoice, and input tax can still only be deducted from the structured part (BMF letter of 15 October 2025).

For incoming invoices it therefore pays to look at both parts automatically. If the system reads the XML part and places invoice number, date, amounts and tax rate next to the invoice image, deviations show up on receipt rather than years later in an audit. How such a check against purchase order and goods receipt is built is shown in Automated invoice checks: the three-way match.

For your own invoicing there was already relief before the amendment: no image copy of the outgoing invoice, for example a PDF file, had to be saved if a corresponding duplicate could be produced at any time (GoBD version in the AO handbook 2025, marg. no. 76). The amendment rewords this paragraph and now expressly includes the PDF part of hybrid invoices. Marginal number 76 now reads: when invoicing software is used, no image copy of the outgoing invoice, for example a PDF file or the PDF part of a hybrid format, has to be saved from creation if a copy with identical content can be produced on request at any time (GoBD amendment of 14 July 2025, marg. no. 76). The XML file that was sent still belongs in the archive: a duplicate of every invoice issued must be kept for eight years (VAT Act, Sec. 14b(1)), and for an e-invoice at least the structured part must be kept so that it is intact in its original form (BMF letter of 15 October 2025). Only the image copy can be dropped.

The identical copy comes with conditions that the GoBD spell out directly (GoBD, marg. no. 76):

This is the question every business needs to test. Many programs can reprint an invoice, but they print it with the customer’s current address, the current letterhead and the current terms. That is not a copy with identical content. Before switching off PDF copies for outgoing invoices, run a test: reproduce an invoice from last year whose customer has since moved and compare it with the original that was sent. If both match, the versioning works. If they do not, keeping the file that was sent remains the simpler route; it needs little storage.

For hybrid outgoing invoices the same order of precedence applies as for incoming ones. Anyone who sends ZUGFeRD should generate image and data from the same source. If the image deviates from the structured part in its invoice details, it may constitute a further invoice (BMF letter of 15 October 2025). Minor deviations for technical reasons, such as rounding differences or a description shortened for display, are not objected to as long as the image keeps its character as a copy with identical content (BMF letter of 15 October 2025).

An XML file is hard for people to read. That is not a defect: the machine evaluability of a standardised file makes it possible to display it in human-readable form with a visualisation tool, and an additional human-readable version is not required for VAT (BMF letter of 15 October 2025). Anyone who keeps documents as reproductions on data carriers must, however, provide the tools needed to make them readable at their own cost and, on request, print them or provide readable reproductions (Fiscal Code, Sec. 147(5)). The GoBD add that digitised documents must be made readable on screen through the business’s own system and that a paper printout is not sufficient (GoBD, marg. no. 157).

The archive therefore needs a working viewer as well as the files, for the full period. Invoices must be kept for eight years (VAT Act, Sec. 14b(1)). Under the Fiscal Code, eight years apply to accounting records, ten years to books and annual financial statements and six years to business letters received (Fiscal Code, Sec. 147(3)). The period for invoices starts at the end of the calendar year in which the invoice was issued (VAT Act, Sec. 14b(1)), and it does not expire as long as the documents matter for taxes whose assessment period has not yet expired (Fiscal Code, Sec. 147(3)). How a business combines these periods with deletion runs is covered in Meeting retention periods digitally.

In a tax audit the authority can inspect the stored data and use the system to do so, require the data to be evaluated by machine according to its specifications, or have the data transferred in a machine-evaluable format (Fiscal Code, Sec. 147(6)). For the archive this means the XML files must be exportable in bulk with their index data, not just opened one by one.

A common stumbling block is a system change. Anyone replacing their invoice processing software or their financial accounting does not have to keep the old data running in the old system forever: after the end of the fifth calendar year following the changeover, it is sufficient to hold the data only on a machine-readable and machine-evaluable data carrier, provided no tax audit has started yet (Fiscal Code, Sec. 147(6)). Until then the authority must still be able to exercise its access rights. Data migration therefore belongs in every replacement project, see legacy system replacement and the article Migrating data from a legacy system.

Each of these decisions belongs in the process documentation. For every data processing system it must show content, structure, flow and results of the procedure completely and coherently and must be verifiable by a knowledgeable third party within a reasonable time (GoBD, marg. no. 151). As a rule it consists of four parts: a general description, user documentation, technical system documentation and operating documentation (GoBD, marg. no. 153). Changes must be traceable over time (GoBD, marg. no. 154). Switching to the new rules for e-invoices is therefore a new dated version, not an overwritten section.

For e-invoicing, these points in particular need to be added:

How to structure process documentation as a whole is shown in Writing process documentation for audits; describing the workflows is supported by process documentation. The general requirements for GoBD-compliant storage, from immutability to replacement scanning, are summarised in GoBD-compliant document storage.