BStBK E-Invoicing FAQ: The German Tax Chamber's Official Guidance, Translated

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). It is the most practical official resource available for German businesses and their tax advisers navigating the shift to mandatory structured invoicing.

The original document is in German. What follows is an English-language summary that covers every question in the BStBK catalogue, organised into four parts: basics, GoBD-compliant storage, inbound invoice handling, and outbound invoice creation. All legal references — BMF letters, UStG sections, GoBD margin numbers — are preserved 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.

1.1 What are the stages of introduction?

Germany is rolling out mandatory e-invoicing in two stages. The first stage concerns sending and receiving invoices in a structured format compliant with EN 16931, without prescribing specific transmission routes. The second stage introduces a VAT reporting system based on e-invoices submitted through registered platforms, expected from 1 July 2030.

Within the first stage, the obligation to receive e-invoices has applied since 1 January 2025. The obligation to issue them follows on 1 January 2027 for businesses with prior-year turnover exceeding €800,000, and from 1 January 2028 for all remaining businesses. Transitional provisions are set out in Section 27 (38) No. 1 to 3 UStG.

1.2 Are certain companies exempt?

The obligation covers all Germany-based businesses making domestic B2B supplies that are not tax-exempt under Section 4 No. 8 to 29 UStG. That said, several categories are exempt from the issuance obligation (though not from receiving):

Small entrepreneurs (Kleinunternehmer) do not have to issue e-invoices but must still accept them (Section 34a sentence 3 UStDV). Small-value invoices up to €250 and travel tickets are likewise excluded from the e-invoicing requirement.

1.3 What actually counts as an e-invoice?

Only invoices in a structured electronic format conforming to EN 16931 that allow automated processing qualify. In practice, this means XRechnung and ZUGFeRD (version 2.0 onward). For more on the European standard, see our EN 16931 explainer.

PDFs, Word files, and scanned documents are classified as "other invoices" (andere Rechnungen) and do not satisfy the requirement. Where issuer and recipient agree to use an alternative structured format, it must still allow the correct and complete extraction of all VAT-required data into an EN 16931-compliant or interoperable format.

1.4 Where can I find further information?

The BStBK points to several key sources: the Growth Opportunities Act (Wachstumschancengesetz, BGBl. I 2024 No. 108), the Second BMF letter on mandatory e-invoicing dated 15 October 2025 (BStBl. I 2025, p. 1806), the First BMF letter dated 15 October 2024 (BStBl. 2024 I, p. 1320), and the BMF FAQ on e-invoicing.

2.1 What retention rules apply to e-invoices?

Under Section 14b (1) UStG, entrepreneurs must keep a copy of every incoming and outgoing invoice for eight years. Longer retention may apply where invoices remain tax-relevant — for example, the ten-year input tax correction period for real property.

The structured part of an e-invoice must be stored in its original form and satisfy immutability requirements. Machine evaluability by the tax authorities must be guaranteed. If a separately transmitted document — such as the image portion of a hybrid invoice — contains tax-relevant records (e.g. booking endorsements), it too must be stored in original form with equal immutability.

2.2 Must the client separately archive the original e-invoice?

For GoBD-compliant archiving, the unchanged structured data record must be retained at minimum. It must be stored in original form, meet integrity requirements, and remain machine-evaluable by the tax authorities.

It is sufficient if the unchanged data record is forwarded to the taxpayer's tax firm and stored there. Additional storage at the original recipient's premises is then not required. The same applies to electronically received "other invoices."

Where the data record is kept in an audit-proof digital archive (DMS), bidirectional links or a unique assignment key (e.g. incoming invoice number) should connect the archive and the accounting system, so that records can be traced in both directions.

2.3 Should additional measures be taken against manipulation?

Yes. When sending and receiving e-invoices, organisations should take measures to prevent interception and manipulation and to comply with GDPR requirements. Platform solutions offer advantages here.

Email transmission should be treated as an interim solution until the introduction of mandatory platform-based reporting to the tax authorities, expected from July 2030 in the second stage. For more on network-based transmission, see our Peppol explainer.

2.4 Must emails be retained when invoices arrive by email?

Emails that function as commercial or business letters or as accounting vouchers must be retained electronically in unalterable form. However, if an email serves purely as a transport medium (analogous to an envelope) for the attached e-invoice, it does not need to be retained.

The retention obligation covers the transported content, not the container. Organisations may still choose to keep the full email — for instance, to document the sender, timing of dispatch, and timing of receipt as part of an audit trail.

2.5 How should filing, storage, and archiving be set up for GoBD compliance?

Filing system. Every invoice must be filed within a defined, comprehensible system so that it can be retrieved at any time. Numeric, alphabetic, or alphanumeric indexing systems are all acceptable.

Storage structure. Invoices should follow a clear hierarchy — for example: financial year → month → day → digitisation run → document number.

Archiving on dispatch. When invoices are sent via a portal, archiving is handled through an interface to the invoicing programme or by downloading the sent e-invoice. After dispatch, the invoice is filed (automatically or manually) in an audit-proof archive, with the invoicing employee responsible for controlling the process.

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. Throughout the retention period, the authenticity of origin, integrity of content, and readability of e-invoices must be maintained. IT accounting systems and electronic archives serve this purpose. Each document receives a timestamp, data paths are permanently monitored, and access is restricted to authorised employees. Regular backups prevent data loss and guarantee full recovery. Random checks verify that stored files match backed-up files in number, designation, size, and date.

Machine evaluability. Internal organisational instructions must prohibit printing combined with exclusive retention of printouts. The structured data must remain machine-readable.

Storage location. Invoices are stored domestically or within the EU/EEA, with full remote access guaranteed. Storage outside the Community territory requires compliance with additional legal provisions.

Immutability. The structured part of an e-invoice is stored in original form meeting immutability requirements (e.g. PDF/A-3 with integrated XML for ZUGFeRD). If tax-relevant information is contained in a separately transmitted document (such as the image part of a hybrid invoice), that document must also be stored in original form with equal immutability.

2.6 What rules apply to deleting digital archive records?

Retention periods must be observed. Deletion must not occur before statutory retention periods expire. Particular attention is needed for documents linked to fixed assets (GoBD, margin no. 81).

Authorisation and execution. Deletion must be authorised and carried out exclusively by responsible employees.

Organisational release. An organisational release is mandatory before any deletion. Under Section 147 (3) sentence 5 AO, the retention period does not expire as long as the invoice remains tax-relevant and the assessment period has not yet ended.

Foreign receipts. Documents subject to foreign storage requirements must be stored separately and handled individually, since foreign regulations may impose additional obligations.

3.1 How are receipt and processing of e-invoices handled?

Regular retrieval. E-invoices must be collected regularly — via email, a dedicated inbox, an electronic interface, a central storage location, or an internet portal. Retrieval should happen daily or several times per day.

Documentation. The retrieval and receipt of e-invoices must be documented for traceability.

Email handling. Received emails that serve only as a transport medium are deleted after the attachment is extracted. If the email itself contains tax-relevant information (for accounting, tax, or legal purposes), it must be stored electronically in unalterable form to document the sender and timing.

Validation. Every received data record must be validated — checking syntax, semantics, data model conformity, and conformity with national extensions (e.g. XRechnung business rules). If the invoice fails format or content requirements, the issuer is contacted. Validation can be performed using the KoSIT validator, among other tools.

It should be agreed between the client and their tax adviser who handles the technical format and business rule checks — whether the client validates before forwarding, or the adviser validates using firm software with an integrated e-invoice validator.

Indexing. On receipt into the archiving system, each e-invoice is assigned a unique index (e.g. through bidirectional links) for administration and traceability.

Conversion and archiving. When converting to an in-house format, machine evaluability is preserved by archiving both versions — the original data record and the converted version — under the same index. Under certain GoBD conditions, the original need not be kept separately.

No printing. It is prohibited to print a received data record and keep it in paper form as a replacement for the e-invoice.

3.2 What error types can occur and how do they affect input tax deduction?

The BMF letter dated 15 October 2025 distinguishes three error categories:

Format errors arise when an e-invoice does not comply with permissible syntaxes or their technical specifications, or does not allow correct and complete data extraction. A formally defective e-invoice fails Section 14 (1) sentence 6 UStG and is treated as an "other invoice." Input tax deduction from such an invoice is only possible during the transitional periods.

Business rule errors occur when the invoice file violates the business rules applicable to the e-invoice format. These are technical rules checking logical dependencies — for example, missing entries in mandatory fields (such as "BT-10 Buyer reference" in XRechnung) or mathematical inconsistencies in tax amounts. Business rule errors affecting mandatory VAT information (e.g. missing performance date or delivery quantity) mean the invoice is improper and generally does not entitle the recipient to input tax deduction. Business rule errors outside mandatory VAT information (e.g. incorrect IBAN, missing buyer reference) generally do still support input tax deduction.

Content errors involve violations of mandatory VAT information under Sections 14 (4) and 14a UStG. They may overlap with business rule errors but can also exist without triggering a validation error — for instance, an incorrect tax rate or an insufficient service description. Content errors mean the invoice is improper and input tax deduction is generally excluded. However, where the tax rate is incorrect, a partial deduction remains possible up to the amount of tax actually owed.

3.3 How should technical and content verification be carried out?

Validation. E-invoices must be checked for format errors and business rule errors using a suitable validation application. An entrepreneur may rely on the technical result of a validation, provided they observe the due diligence of a prudent businessman (Sorgfalt eines ordentlichen Kaufmanns). Retaining the validation report as evidence is advisable.

For content errors that fall outside the format and business rule checks (e.g. incorrect tax rate, insufficient service description, incomplete VAT ID), validation software currently reaches its limits. It does not replace the recipient's obligation to verify completeness and correctness. Visualisation software can be used for content checks where digital verification is insufficient.

Audit trail. An internal control procedure establishes an audit trail between the service provided and the invoice by comparing invoice details with existing business documents — orders, contracts, delivery notes. The comparison takes place at the structured data record level (the XML file). A visualisation tool is used to make the XML component human-readable.

Hybrid formats (e.g. ZUGFeRD). The XML data is authoritative. The validation software must access the XML data record embedded in the PDF container — there must be no OCR readout of the PDF image part. Where the XML and PDF parts diverge, the XML part is decisive for input tax deduction. Minor technical deviations such as shortened service descriptions for layout reasons or rounding differences are tolerated. Serious discrepancies (e.g. contradictory mandatory VAT information) should lead to rejection.

Check criteria include: mandatory information under Section 14 UStG (invoices over €250); mandatory information under Section 33 UStDV (small-value invoices up to €250); mandatory information under Section 34a UStDV (small entrepreneurs); verification of delivered goods or services; consistency between delivery note and invoice; consistency between invoice issuer and payee; and correctness of tax rates and plausibility of tax amounts.

Based on the verification result, the invoice is either forwarded for account assignment and payment instruction or returned to the issuer with a complaint. The verification result and the payment release must be documented.

3.4 What must be considered for account assignment and payment instructions?

Positive verification first. Before account assignment, the incoming invoice verification must be completed successfully — the invoice must be formally and materially correct.

Account assignment. After successful verification, the relevant accounts for incoming and outgoing supplies are determined. This can happen electronically or as part of the booking process. The indexing of the e-invoice data record is critical — it creates a clear link between the invoice record and the subsequent booking record, so that both are treated as a logical unit fulfilling the voucher function.

Input tax apportionment. The indexed e-invoice must be correctly assigned to incoming or outgoing supplies. Where necessary, input tax apportionment is carried out under Section 15 (4) UStG — this applies when invoices relate to both taxable (deduction-eligible) and tax-detrimental (exclusion) supplies and direct assignment is not possible or not permissible (e.g. acquisition and production costs of real property).

Payment instruction. Payment should only be authorised after verification is complete. It must be confirmed that payment is made to the correct invoice issuer and that the correct amounts are transferred.

3.5 How should complaints about defective e-invoices be handled?

Identification and complaint. First, determine whether the received invoice has formal or material defects. If it does, complain to the issuer clearly and precisely.

Content of the complaint should include: reason for the complaint, invoice date, invoice amount, invoice number, the validation application's test log with error notices, and the complainant's own company data (customer number where applicable).

Request for corrections. The complaint should state whether a correction invoice is sufficient or whether cancellation of the original invoice with re-issuance is required.

Payment block. No payment should be released until the defect is resolved and a corrected invoice has been received.

The decision on whether to reject an e-invoice depends on the type of defect. Where a validation produces only warnings, the e-invoice can generally be accepted — what matters is whether the defect impedes further processing in the ERP system or tax programme. Where a genuine error is flagged, the e-invoice should be rejected, particularly if Section 14 UStG requirements are not met. This assumes the validation application provides meaningful error logs.

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

Data source. The e-invoice content (the invoice draft) draws on data from the merchandise management system or manually entered data. The draft is created in the invoicing system using current master data — particularly business partner master data.

Mandatory specifications include: mandatory information under Section 14 (4) UStG; special invoice details under Section 14a UStG; mandatory information for small-value invoices under Section 33 UStDV (where e-invoicing is used voluntarily); and mandatory information for small entrepreneur invoices under Section 34a UStDV (where used voluntarily).

Verification process. Relevant invoice details are compared with the corresponding data in business partner master records and orders. Only authorised, trained personnel may create an invoice draft.

VAT ID verification. For invoices connected to intra-Community deliveries and services to EU entrepreneurs, the service recipient's VAT ID must be verified through a qualified confirmation request to the BZSt (Federal Central Tax Office). The EU's VIES system can alternatively be used, though only simple requests are available there, which the German tax administration may not fully recognise.

The e-invoice is only created and dispatched once all checks have been completed without issue. The verification process and the VAT ID query result must be documented, and the query result archived electronically.

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

An invoice draft normally precedes the final e-invoice. The e-invoice can be created in various EN 16931-compliant formats, including: ZUGFeRD, Peppol BIS Billing, XRechnung (B2G and B2B), Factur-X (the French equivalent of ZUGFeRD), and RO_CIUS.

The structured data record is generated either directly in the invoicing programme or on an external platform. The formal requirements of Sections 14 and 14a UStG must be observed — ensured through contractual agreement or software certification.

Attachments. Supplementary information can be included as a data record within the e-invoice (e.g. a breakdown of timesheets in a PDF file). However, a link to an external destination does not satisfy Section 14 (1) sentence 3 UStG. This creates difficulty where confidential content must not be accessible to a wide circle of recipients during incoming invoice processing. Individual solutions must currently be found for such cases.

System integration. An external software solution for creating the e-invoice data record can be connected to the invoicing system via a bidirectional interface, allowing the invoicing software to receive draft data and return the structured e-invoice.

4.3 What are the special rules for cash payments and permanent invoices?

Cash payments. Where a cash-paid service triggers an e-invoicing obligation, an "other invoice" (e.g. a cash register receipt) can initially be issued and subsequently corrected by an e-invoice. Alternatively, an e-invoice can be created and delivered on the spot — though the requirements of the Cash Register Security Ordinance (KassenSichV) may also need to be observed.

Permanent invoices (Dauerrechnungen). For continuing obligations, the e-invoice content must clearly describe that it is a permanent invoice. It is sufficient to issue an e-invoice only for the first partial service period, containing all mandatory information in structured form and additionally referencing the underlying contract.

4.4 What must be observed for changes and corrections?

Changes to a permanent e-invoice are required when mandatory VAT information changes (e.g. rent increases). Corrections must be made in the legally prescribed structured format — transmitting missing or incorrect information in a non-structured form is not permitted. The correction can take the form of cancellation of the original invoice followed by re-issuance.

Where the assessment basis under Section 17 UStG is reduced after issuance, an invoice correction is not required. Examples include discounts, rebates arising from defect notices with no impact on the billed service, or reversal of a supply within the meaning of Section 17 (2) No. 3 UStG.

Changes in the scope or content of the service (e.g. relevant measurement changes) do not constitute a mere reduction in the assessment basis and therefore generally require an invoice correction — at least to the service description. This correction can, with prior agreement, take the form of a credit note by the service recipient (Section 14 (2) sentences 5 and 6 UStG). The credit note must refer to the original invoice in a specific and unambiguous manner.

4.5 What about down payments, final invoices, and residual invoices?

Down payments. The e-invoice element "Invoice type code" (BT-3) can represent down payment invoices using code 386 (Prepayment invoice). However, this code is not currently supported in XRechnung and triggers a warning. It is therefore preferable to use code 380 (Commercial invoice) with a text note in the "Invoice note" element (BT-22) such as "Down payment invoice."

Final and residual invoices. A final or closing invoice cannot be fully mapped using the current data fields (Business Terms). The BMF therefore recommends issuing only a residual invoice for the remaining amount after deducting instalments from the total. Alternatively, the missing information for a final invoice can be embedded in the unstructured part as an attachment — though automated processing of down payment data from purely unstructured attachments is not readily feasible and requires additional manual steps or specialist parsing solutions.

4.6 What special rules apply to the construction industry?

Until 30 June 2030, it is generally sufficient for the control function if a construction services e-invoice contains only totals by individual trade in the structured part, provided a detailed breakdown according to the bill of quantities (e.g. using the GAEB standard) appears in a human-readable attachment that is clearly referenced from the structured part.

While the information can also be presented in the XRechnung extension, the regulation permits using only the CIUS XRechnung. The human-readable attachment is necessary for potential review by the tax authorities. There are no tax concerns if the breakdown is also attached in structured form (e.g. as an XML file using the GAEB standard).

Likewise until 30 June 2030, the provision allowing partial payments and tax amounts to be listed in an appendix to the final invoice can also be applied to e-invoices. The appendix may be attached as an unstructured document with a reference in the structured part.

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

Transmission routes currently available (likely until the reporting stage is introduced) include: email; platforms such as Peppol or TRAFFIQX; company-operated web portals and customer portals; and direct interfaces between the software systems of sender and recipient.

Authenticity and integrity of the e-invoice can be ensured through: a Qualified Electronic Signature (QES), an EDI procedure, or an internal control procedure.

Correct routing information. When sending, the e-invoice and any required routing data (e.g. email address, TRAFFIQX ID, Peppol ID, routing ID for invoices to public authorities) are retrieved from current master and transaction data. Before dispatch, the element BT-10 "Buyer reference" is automatically populated with the appropriate TRAFFIQX ID, Peppol ID, or routing ID.

Multiple transmission. It is permissible to send the same e-invoice file more than once, provided it is the same invoice and the transmission is a substantively identical copy. Sending a duplicate does not create 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.