Germany E-Invoicing FAQ: The German Tax Chamber's Official Guidance (Translated to English)

About this guide

The Bundessteuerberaterkammer (BStBK), Germany's Federal Chamber of Tax Consultants, published a comprehensive FAQ catalogue on e-invoicing (status: 3 March 2026). The original document is in German. What follows is the full English translation, preserving all legal references, footnotes, and citations exactly as they appear in the source.

For background on the German mandate itself, see our Germany country page. For the European standard underpinning all of this, the EN 16931 explainer covers the essentials.

Preamble

With the Growth Opportunities Act (BGBl. I 2024 No. 108), the electronic invoice was introduced in Germany as mandatory for domestic B2B invoices as of 1 January 2025. Since then, a statutory obligation to receive electronic invoices has applied to all companies in Germany. The issuance of e-invoices is still voluntary in 2026. As of 1 January 2027, an obligation to issue e-invoices to entrepreneurial clients will apply to companies with a total prior-year turnover of €800,000 or more, and as of 1 January 2028, with a few exceptions, for all other companies as well.

The following compilation by the Federal Chamber of Tax Consultants is a collection of frequently asked questions regarding the introduction of e-invoicing in the B2B sector in Germany. It is intended to provide a compact overview of important aspects related to e-invoicing and to help better understand legal requirements, technical basics, and practical implementation. The FAQ therefore contains, in particular, practice-relevant questions and answers on tax law aspects including the GoBD and on technical factors of the e-invoice. For further questions, the FAQ refers to already existing sources.

The list of questions and answers is not exhaustive and does not claim to be complete. If necessary, a separate examination in individual cases is required to obtain legal certainty.

The contents are based on the currently applicable legal situation. Legal changes as well as new administrative opinions or case law will be taken into account in the context of ongoing updates. Changes and additions are highlighted in yellow. This applies accordingly to the sources used.

1.1 What are the stages of introduction?

The first stage concerns the introduction of mandatory dispatch and receipt obligations using a specific format (EN 16931) between companies in Germany, but not yet with the specification of transmission routes. The second stage is to be designed as a VAT reporting system based on e-invoices via registered e-invoicing platforms and is expected to be introduced from 1 July 2030.

In the first stage,¹ the readiness to receive e-invoices must be guaranteed since 1 January 2025. As of 1 January 2027, an obligation to issue e-invoices will then follow for companies with a total prior-year turnover greater than €800,000, and from 1 January 2028, also for companies under €800,000.

1.2 Are certain companies exempt from the obligation?

The obligation applies to all companies based in Germany with domestic B2B sales that are not tax-exempt under Section 4 No. 8 to 29 UStG.² Furthermore, small entrepreneurs and small-value invoices as well as travel tickets are exempt from the obligations.³

1.3 What counts as an e-invoice?

Only invoices in a structured electronic format according to EN 16931 that can be processed automatically (e.g., XRechnung or ZUGFeRD from vers. 2.0) count as e-invoices. Other formats such as e.g., PDF, Word or scanned invoices will in future be deemed "other invoices" and do not meet the requirements.

The structured electronic format must either comply with the European standard EN 16931 or can be agreed upon between the invoice issuer and the invoice recipient.⁶ In this case, the format used must enable the correct and complete extraction of the information required under the VAT Act according to sections 14 and 14a UStG into a format that complies with or is interoperable with the EU standard EN 16931.⁷

1.4 Where can I find further information on the e-invoice?

Growth Opportunities Act, BGBl. I 2024, No. 108.

Second BMF letter on the introduction of the mandatory electronic invoice for sales between domestic entrepreneurs as of 1 January 2025 dated 15 October 2025, BStBl. I 2025, p. 1806.

First BMF letter on the introduction of the mandatory electronic invoice for sales between domestic entrepreneurs as of 1 January 2025 dated 15 October 2024, BStBl. 2024 I, p. 1320.

FAQ E-Invoice from the Federal Ministry of Finance.⁸

2.1 What aspects regarding retention arise in connection with an e-invoice?

In terms of VAT, Section 14b (1) UStG stipulates that an entrepreneur must keep a duplicate of every incoming and outgoing invoice for eight years, provided that the tax relevance of the invoice does not make a longer retention necessary (e.g., due to an input tax correction period of ten years for land and buildings).

The structured part of an e-invoice must be stored in such a way that it is present in its original form and meets the requirements for immutability. Machine evaluability on the part of the tax administration must be ensured. If an additionally sent document (e.g., image part of a hybrid invoice) contains records that are important for taxation, e.g., booking endorsements, these must also be stored in such a way that they are present in their original form and meet the requirements for immutability.

For details on this, see BMF letter dated 28 November 2019, BStBl. I 2019 p. 1269, last amended by BMF letter dated 14 July 2025, BStBl. I 2025, p. 1502, marginal no. 131 and 133.

2.2 Is the e-invoice attached to the booking still the original invoice, or must the client separately archive the e-invoice sent to him by the supplier?

If, during booking, the digital invoice is linked to the booking record and the booking is finalized, and this invoice was sent in e-invoice format from the supplier to the client and subsequently transmitted by the client to the tax advisor, the following considerations apply.

In order to achieve GoBD-compliant archiving, at least the structured data record must be kept unchanged in the case of an electronic invoice: "The structured part of an e-invoice must be stored in such a way that it is present in its original form and meets the requirements for integrity (cf. Section 14.4 para. 3 UStAE). Machine evaluability on the part of the tax administration must be ensured."⁹ If an additionally sent document (e.g., image part of a hybrid invoice) contains records that are important for taxation, e.g., booking endorsements, these must also be stored in such a way that they are present in their original form and meet the requirements for immutability.¹⁰

Accordingly, it is sufficient if the unchanged structured data record of an e-invoice is forwarded by the taxpayer to the tax firm and stored there unchanged. Additional storage with the original invoice recipient, i.e., in the company itself, is then not necessary. This regulation applied or applies analogously also to the storage of electronically received other invoices.

Note: If the unchanged structured data record is kept in an audit-proof digital archive (DMS), care should be taken to ensure that simple access to the data record is possible from both directions (accounting/DMS) through bidirectional links or unique assignment (e.g., incoming invoice number).

2.3 Should additional measures be taken to ensure that e-invoices cannot be manipulated during receipt and dispatch?

Yes. When sending and receiving e-invoices, additional measures should be taken to ensure that an e-invoice cannot be intercepted and manipulated, or that the GDPR is complied with. Platform solutions can prove to be advantageous.

The transmission method via e-mail should therefore only be viewed as an interim solution until the introduction of a transmission obligation of the e-invoice to the tax administration.

2.4 Is it additionally necessary to retain an e-mail if electronic invoices are transmitted via e-mail?

E-mails with the function of a commercial or business letter or accounting voucher must be kept in electronic form in an unalterable manner. However, if an e-mail serves exclusively as a mere means of transport (analogous to the envelope) to transmit the attached electronic invoice, this does not fundamentally need to be kept additionally. The retention obligation refers exclusively to the transported content.

However, the company can still voluntarily decide to retain the entire e-mail in order, for example, to document which sender the e-mail comes from and when it was sent and received (audit trail).¹¹

2.5 How are filing, storage, and archiving to be designed in a GoBD-compliant manner?

Filing system: During post-processing, each invoice is filed in a defined, comprehensible filing system to ensure it can be found at any time. A numeric, alphabetic or alphanumeric system can be used as an index system.

Storage system: The invoices are stored according to a clear system, which for example has the following structure: → [Financial year] [Month] [Day] [Digitization run] [Document number].

Archiving: In the case of dispatch via a portal, archiving is ensured through an interface to the original invoicing program or by downloading the sent e-invoice.

Audit-proof filing: After dispatch, the invoice is automatically or manually filed in the audit-proof archive. The control of the filing is the responsibility of the invoicing employee.

E-mail retention: E-mails that function as commercial or business letters or accounting vouchers must be stored in electronic form. E-mails that only serve as a means of transport do not need to be retained additionally (see also question 2.4).

Retention period: All incoming and outgoing invoices must be kept electronically for at least eight years. The period begins at the end of the calendar year in which the invoice was issued.

Authenticity, integrity and readability: Over the entire retention period, the requirements for the authenticity of the origin, the integrity of the content and the readability of the e-invoices must be ensured. For this purpose, IT accounting systems and electronic archive systems are used.

Ensuring the integrity of the invoices / documentation measures / backup processes / checking the stored files: Each document is provided with a timestamp and all data paths are permanently monitored. Access is only permitted to responsible employees. Regular backup processes prevent data loss and guarantee full recovery of the data in the storage system. Random tests are carried out to ensure that the stored files correspond to the backed up files in terms of number, designation, size and date.

Machine evaluability: The machine evaluability of the sent or received e-invoice is ensured by internal organisational instructions prohibiting printing in combination with exclusive retention of printouts.

Storage location: Invoices are stored domestically or in the rest of the Community territory, with full remote access guaranteed. When stored outside the Community territory, legal requirements must be met.

Immutability: The structured part of an e-invoice data record is stored in such a way that it is present in its original form and meets the requirements for immutability (e.g., PDF/A-3 and integrated XML file for ZUGFeRD).

Tax-relevant additional information: If tax-relevant information is contained in an additionally transmitted document (e.g., image part of a hybrid invoice), this must also be stored in its original form. The requirements for immutability apply equally.

2.6 What steps must be implemented when deleting digital archive records?

Checking retention periods: The deletion of digital archive records does not take place before the expiration of the specified retention periods. The special features concerning the storage of documents in connection with fixed assets are taken into account (see GoBD, margin no. 81).

Authorization and execution: The deletion must exclusively be authorized and executed by the responsible employees.

Organisational release: Before the deletion process, an organisational release is mandatory. This takes into account that the retention period according to Section 147 (3) sentence 5 AO does not expire as long as the invoice is of tax relevance and the assessment period has not yet expired.

Treatment of foreign receipts: Receipts that must be stored according to foreign regulations are stored separately and subjected to individual treatment, as the foreign requirements may also need to be taken into account here.

3.1 How are the receipt and processing of e-invoices ensured?

Regular retrieval: E-invoices are retrieved regularly, either via e-mail, a special e-mail inbox, an electronic interface, a central storage location or an Internet portal. Retrieval should take place daily or several times a day.

Documentation: The retrieval and receipt of e-invoices is documented to ensure traceability.

Transmission by e-mail: Received e-mails that only serve as a means of transport in the context of invoice receipt are deleted. In the case of tax-relevant information (for accounting, tax or legal purposes), however, the e-mail is stored electronically in an unalterable manner to document the sender and the time.

Verification of e-invoices: Each received data record is subjected to validation (syntax, semantics and data model check as well as check of conformity with national extensions). If the invoice does not meet the legal requirements regarding the legally prescribed format or content, the invoice issuer is contacted. The validation can be carried out, for example, using the KoSIT validator.

Note: Validation requirement and mandate agreement: It should be regulated between the client and the tax advisor who, in addition to the content check, assumes the technical format and business rule check, depending on whether a technical validation is already carried out by the client before transmission or whether the tax advisor assumes this, e.g., by using a firm software with an e-invoice validator.

Special treatment of final invoices: Final invoices with unstructured attachments are treated separately.

Indexing: Upon receipt into the archiving system, e-invoices are given a unique index (e.g., using bidirectional links) for administration and traceability.

Conversion and archiving: Upon conversion into a conventional (in-house) format, machine evaluability is retained by archiving both versions (original data record; data record in in-house format) and managing them under the same index. Under certain conditions, the GoBD permit that the original does not have to be kept.

Internal guidelines: It is prohibited to print out the received data record and simply keep it in paper form as a replacement for the e-invoice.

3.2 What types of errors can occur during invoice verification and what effects do these have on the input tax deduction?

The BMF letter dated 15 October 2025 distinguishes between three error categories with the format error, the business rule error and the content error.

Format errors: A format error¹² always occurs when an e-invoice does not comply with the permissible syntaxes or their technical specifications or, in the cases of Section 14 (1) sentence 6 no. 2 UStG, does not allow correct and complete extraction. A formally incorrect e-invoice does not meet the requirements of Section 14 (1) sentence 6 UStG and therefore represents another invoice in a different electronic format under the provisions of Section 14 (1) sentence 1 UStG. An input tax deduction from such an invoice is only possible for the duration of the transitional periods.¹³

Business rule error: Business rule errors¹⁴ are present when the invoice file violates the business rules valid for this e-invoice format. Business rules are technical regulations for checking the logical dependencies of the information contained in an e-invoice. They occur e.g. when the information contained in an invoice is incomplete (e.g., no entry in the mandatory field "BT-10 Buyer reference" in an XRechnung) or contradicts each other (e.g., tax amount mathematically does not match the stated tax amount) and are determined, e.g., as a critical error ("critical error") during validation. In the case of business rule errors concerning mandatory VAT information (e.g., missing performance date, missing delivery quantity), the invoice is not deemed proper and generally does not entitle the recipient to an input tax deduction. Business rule errors outside the mandatory VAT information (e.g., incorrect IBAN, missing Buyer reference), on the other hand, generally entitle to an input tax deduction.

Content errors: Content errors¹⁵ are present in the event of a violation of the mandatory VAT information in Sections 14 (4) and 14a UStG and can simultaneously constitute business rule errors. However, content errors can also be present if formally there is no violation of the business rules and, as a result, no error was determined during validation (e.g., specification of an incorrect tax rate, insufficient description of service). In the case of corresponding content errors, the invoice is not deemed proper, the input tax deduction is generally excluded.¹⁶

3.3 How is the technical and content-related invoice verification to be carried out?

Objective of the check¹⁷: E-invoices must be checked for the errors mentioned under 4. using a suitable validation application. Format errors and business rule errors can be uncovered by a suitable validation application. An entrepreneur can rely on the technical result of a validation (regarding format and business rules) by a suitable validation application, provided they observe the due diligence of a prudent businessman. As proof, it is advisable to keep the validation report.

In the case of content errors outside the format and business rule check (e.g., stating an incorrect tax rate, insufficient description of service, only country prefix DE for the VAT ID no.), a validation application currently reaches its limits in most cases. It therefore does not replace the recipient's obligation to check the invoice for completeness and correctness (cf. Section 15.2a (6) and 15.11 (3) UStAE). Here, visualization software can be used to carry out a check for content correctness, provided this cannot be sufficiently guaranteed digitally.

Audit trail: Within the framework of an internal control procedure, an audit trail is established between the service provided and the invoice. This is done by comparing the service listed on the invoice with existing business documents such as orders, contracts of sale and delivery notes. The comparison takes place at the level of the structured data record (e.g., XML file). To establish human readability, a tool is used that can visualize the XML component.

Hybrid format / handling discrepancies: In the case of invoices in a hybrid format (e.g., ZUGFeRD), the XML data is considered leading. The validation software must therefore access the XML data record contained in the PDF container (there must be no OCR readout of the PDF image part). In the event of discrepancies between the XML part and the PDF image part, the XML part is decisive for the input tax deduction. Discrepancies can optionally be determined with the help of a visualization application. Minor technical deviations, concretizing or supplementary information (e.g., shortened service description for layout reasons or rounding differences) that do not change the character of the image part as a substantively identical multiple copy are not objected to.¹⁸ In the event of serious discrepancies (e.g., contradictory mandatory VAT information), it is advisable to reject the invoice to the creator.

Check criteria: During the check, the following aspects, among others, must be observed: mandatory information according to Section 14 UStG for invoices over €250; mandatory information according to Section 33 UStDV for small-value invoices up to €250; mandatory information according to Section 34a UStDV for small entrepreneurs (e-invoices from small entrepreneurs are to be treated like small-value invoices/travel tickets)¹⁹; check of the delivered goods or other services provided; consistency of delivery note and invoice if the invoice refers to the delivery note; consistency between invoice issuer and payee (unless payment is to be made to a third party); correctness of tax rates, plausibility of tax amounts relative to one another.

Follow-up processes: Depending on the result of the check, a decision is made as to whether the invoice is forwarded for account assignment/payment instruction (see question 3.4) or complained about (see question 3.5).

Documentation: The result of the invoice verification and the release for payment are documented. A supporting tool (validation and/or visualization application) checks the mandatory VAT information according to Section 14 UStG.

3.4 What aspects must be considered in connection with account assignment and payment instructions?

Positive incoming invoice verification / account assignment / indexing: Before account assignment, the incoming invoice verification must be successfully completed. This ensures that the invoice is formally and materially correct. After the successful verification, the account assignment of the e-invoice takes place. This involves determining the relevant accounts for incoming and outgoing sales. This process can also take place electronically or as part of the "booking" and should not be confused with the previously common "pre-account assignment". The indexing of the e-invoice data record is crucial. It enables a clear connection between the e-invoice data record and the subsequent booking record. This link ensures that both parts (the invoice record and the booking record) are viewed as a logical unit, which is important for fulfilling the voucher function.

Allocation to sales / input tax apportionment: The indexed e-invoice data record must be correctly assigned to incoming or outgoing sales. This is important for proper accounting and tax treatment. If necessary, an input tax apportionment is carried out according to Section 15 (4) UStG. This refers to the apportionment of the input tax amounts contained in the invoice, provided the invoices are used for both taxable deduction sales and tax-detrimental exclusion sales and a direct assignment is either not possible or not permissible (e.g., for acquisition and production costs of land and buildings).

Payment instruction: At the earliest after the verification has taken place, the e-invoice should be authorized for payment. Here it must be ensured that the payment is made to the correct invoice issuer and the correct amounts are transferred.

3.5 How is one to proceed in the event of a complaint?

Identification of defects / written complaint: First, it is checked whether the received invoice has formal and/or material defects. If this is the case, the invoice is complained about to the issuer. This complaint should be formulated clearly and precisely.

Content of the complaint: The complaint should contain the following information: reason for the complaint; invoice date; invoice amount; invoice number; test log of the validation application with error notices; own company data (customer number if applicable).

Request for corrections: The complaint should state whether a correction invoice is considered sufficient or whether a cancellation of the original invoice with re-invoicing is requested.

Payment block: No payment should be made until the defects have been clarified and the corrected invoice has been received.

Note: The decision as to whether an e-invoice is rejected should also be made dependent on the type of defect involved. If a validation "only" provides warnings, the e-invoice can generally be accepted. What is decisive here is whether the defect makes further processing in the ERP system or tax program more difficult. In the case of a "real" error message, the e-invoice would have to be rejected, especially if Section 14 UStG is not fulfilled. All of this assumes that the validation application provides meaningful error logs.

4.1 On what basis is the content of an e-invoice created?

Data source: The content creation of the e-invoice (invoice draft) is based on data from the merchandise management system or manually entered data. From this, the invoice draft is created in the invoicing system, taking into account the current master data, in particular the business partner master data.

Compliance with specifications: Organisationally, it must be ensured that the formal and material invoice specifications are met, including: mandatory information according to Section 14 (4) UStG; special invoice details according to Section 14a UStG; mandatory information for small-value invoices according to Section 33 UStDV (if the e-invoice is used voluntarily here); mandatory information for invoices from small entrepreneurs according to Section 34a UStDV (if the e-invoice is used voluntarily here).

Comparison of details: Relevant invoice details are compared with the corresponding details in the business partner master data, orders, etc. by the creator of the invoice draft.

Authorizations and training: Only authorized persons who have been trained and instructed in accordance with the specifications may create an invoice draft.

Checking the VAT ID: In the case of invoices in connection with intra-community deliveries and other services to EU entrepreneurs, the VAT ID of the service recipient is checked. This is done through a qualified confirmation request to the BZSt. Alternatively, the EU's VIES can also be used (however, only a simple request is possible there, which may not be recognised by the tax administration).

Process control: The creation and dispatch of the e-invoice are only initiated if all checks have been completed without complaint. The verification process and the result of the VAT ID query are documented.

Proof of the VAT ID query: Proof of an executed VAT ID query is provided by archiving the query result in electronic form.

4.2 How does the syntactical creation of an e-invoice work?

Invoice draft: The creation of an e-invoice is generally preceded by an invoice draft.

Formats: The e-invoice can be created in various formats according to EN 16931 of the CEN (Comité Européen de Normalisation, European Committee for Standardization), including: ZUGFeRD format; Peppol BIS Billing; XRechnung (both B2G and B2B); Factur-X (French equivalent to the ZUGFeRD format); RO_CIUS.

Compliance with formal requirements when creating the e-invoice data record: The structured e-invoice data record is created directly in the invoicing program or on an external invoicing platform. Here, the formal requirements of Sections 14, 14a UStG are observed. This is ensured by a civil law contract agreement or software certification.

Attachments: Supplementary information to the e-invoice can be included in a data record contained in the e-invoice (e.g., a breakdown of timesheets in a PDF file). However, a link to an external destination does not meet the requirements of Section 14 (1) sentence 3 UStG, Section 31 (1) UStDV.²⁰ This is particularly problematic, however, if this information contains confidential information that must not be made accessible to a broad circle of recipients during incoming invoice processing. Individual solution approaches must currently be found here.

Connection to the invoicing system: An external software solution for creating the e-invoice data record can be connected to the invoicing system via a bidirectional interface. This allows the invoicing software to receive the data of the invoice draft and provide the structured e-invoice data record.

4.3 What are the special features regarding cash payment and permanent invoices?

Cash payments: For cash-paid services for which an e-invoicing obligation exists, an other invoice (e.g., in the form of a cash register receipt) can initially be issued, which is subsequently corrected by an e-invoice. Alternatively, an e-invoice can also be created and delivered directly on site. In doing so, however, the requirements of the Cash Register Security Ordinance may also have to be taken into account.

Permanent invoice: In the case of continuing obligations, it is clearly described in the content of the e-invoice that it is a permanent invoice. It is sufficient if an e-invoice is only issued for the first partial service period, containing all necessary mandatory invoice information in structured form and additionally mentioning the contract.

4.4 What special features must be observed for changes and corrections?

Changes to the initial permanent e-invoice must be made if the mandatory VAT information changes (e.g., in the case of rent increases).²¹ Corrections must be made in the legally prescribed structured format. The transmission of missing or incorrect information in a form other than a structured electronic form is excluded. The correction can be made by cancelling the original invoice and issuing a new invoice.

If the assessment basis according to Section 17 UStG is reduced after the invoice is issued, an invoice correction is not required. Examples of this are discounts, rebates due to notices of defects with no impact on the billed service or a reversal of a service within the meaning of Section 17 (2) No. 3 UStG (cf. Section 17.1 (8) UStAE).²²

Changes in the scope or content of the service (e.g., relevant measurement changes), on the other hand, do not represent a mere change in the assessment basis and therefore generally require an invoice correction, at least with regard to the service description. This invoice correction can, provided a prior agreement is in place, also take the form of a credit note by the service recipient (Section 14 (2) sentences 5 and 6 UStG). In this case, the credit note must refer to the original invoice in a specific and clear manner (Section 31 (5) UStDV).²³

4.5 What special features exist regarding down payments, final invoices and residual invoices?

Down payments: With the e-invoice element "Invoice type code" (BT-3), down payment invoices can generally be represented by using the code 386 (Prepayment invoice). Currently, this code is not intended for the XRechnung; using this code leads to a warning notice. It is therefore better (as with normal invoices) to use code 380 (Commercial invoice). In addition, however, a text note should then be inserted using the "Invoice note" element (BT-22), such as "Down payment invoice".

Final invoice / Residual invoice: The representation of a final invoice or closing invoice cannot be mapped with the current data fields (Business Terms). The BMF therefore recommends only issuing a residual invoice for the remaining amount after deducting installments from the total amount. Alternatively, it is suggested to embed the missing information for a final invoice into the unstructured part of the e-invoice as an attachment.²⁴ Automatic processing of the information for down payments from purely unstructured attachments is not readily possible technically and requires additional manual steps or special OCR/parsing solutions.

4.6 What special features apply when using e-invoicing in the construction industry?²⁵

Until 30 June 2030, it is regularly sufficient for the control function of the invoice if an e-invoice for a construction service only contains totals according to the individual trades in the structured part, if a detailed breakdown according to the bill of quantities (e.g., according to the GAEB standard) is apparent from a human-readable attachment to which clear reference is made in the structured part.

Although the information according to the bill of quantities can also be presented in the XRechnung extension, the regulation also allows the use of e.g. only the CIUS XRechnung. The human-readable attachment is necessary for a possible check by the tax administration. From a tax perspective, there are no concerns if the breakdown is also additionally attached in structured form (e.g., as an XML file according to the GAEB standard).

Likewise until 30 June 2030, the regulation according to Section 14.8 (8) No. 2 UStAE (partial payments and tax amounts are listed in an appendix to the final invoice, which must be referenced in the final invoice) can also be applied to an e-invoice, to which the appendix can also be attached as an unstructured attachment, if reference is made to this attachment in the structured part of the e-invoice. The regulation already contained in margin no. 48 of the BMF letter dated 15 October 2024, BStBl. I 2024 p. 1320, can thus still be applied after 31 December 2027.

4.7 What must be considered when sending the e-invoice?

Shipping routes: The created e-invoice is sent to the recipient. The intended dispatch routes are currently (probably until the introduction of the reporting stage to the tax administration) inter alia: e-mail (cf. question 2.3); platforms such as Peppol or TRAFFIQX inter alia; company-owned web portals/customer portals; interfaces between the software programs of the invoice sender and recipient.

Authenticity and integrity: To ensure the authenticity of the origin and the integrity of the content of the e-invoice, one of the following methods is recommended: Qualified electronic signature (QES); EDI procedure; internal control procedure.

Correct entry of additional information: When sending, the e-invoice and the additional information required for it (e.g., e-mail address, TRAFFIQX ID, Peppol ID, routing ID for e-invoices to authorities) are retrieved from the current master and transaction data. This ensures that this information is correctly entered into the e-invoice data record via the e-invoice solution, as it was not usually found on a conventional invoice itself. Before the e-invoice is sent to the recipient, the element (BT-10) "Buyer reference" is (automatically) filled with the TRAFFIQX ID, Peppol ID or routing ID.

Multiple transmission: It is unobjectionable if the file for an e-invoice is sent multiple times, as long as it is the same invoice and the transmission only takes place as a substantively identical multiple copy (in particular, multiple dispatch does not lead to a tax liability under Section 14c UStG).

Key takeaways

The BStBK FAQ is the most detailed official guidance available for German businesses and tax advisers on the transition to mandatory e-invoicing. The essentials:

Reception is already mandatory. Since 1 January 2025, every business in Germany must be able to receive e-invoices. No exceptions.

Issuance deadlines are approaching. Businesses with turnover above €800,000 must issue e-invoices from 1 January 2027. All others follow from 1 January 2028. See the mandate timeline.

Only EN 16931 formats qualify. PDFs, Word documents, and scans are "other invoices." Accepted formats are XRechnung and ZUGFeRD (version 2.0 onward).

GoBD compliance is non-negotiable. The structured data record must be stored in its original form for at least eight years, meeting immutability and machine evaluability requirements. Printing is not a substitute.

Validation is essential. Every received e-invoice must be validated for format, business rules, and content. Format errors and business rule errors on mandatory VAT fields can block input tax deduction. The KoSIT validator helps, but content verification remains the recipient's responsibility.

Email is an interim solution. Platform-based transmission (Peppol, TRAFFIQX, or similar) is more secure and will become standard when the VAT reporting stage begins in 2030.

If you are not sure where your organisation stands, the e-Invoice Readiness Scorecard can help identify gaps. For a broader view of the German landscape, see our Germany country page and the XRechnung 4.0 explainer.