5 Common Reasons for E-Invoice Rejection in Germany

German e-invoices are most often rejected because the file is not a valid structured invoice, mandatory data is missing, totals or tax logic do not validate, the submission channel is used incorrectly, or routing and technical rules are not met. 

Key Takeaways

• A PDF is not an e-invoice if it is not a structured, machine-readable format. 
• Federal B2G invoices must include routing data such as the buyer reference, or they cannot be delivered correctly. 
• Portals reject formal and calculation errors, while recipients can reject factual or content errors. 
• Submission rules matter: one invoice per email, permitted file limits, and embedded supporting documents all affect acceptance. 

Germany’s E-Invoicing Obligation

• According to BMF's latest guidelines on E-Invoicing, since January 1, 2025, domestic B2B transactions in Germany are expected to use electronic invoices, although transition periods for invoice issuance continue through 2026 and, in certain cases, 2027. 
• For German tax purposes, an e-invoice must be a structured electronic format that allows automated processing. A simple PDF does not qualify as an e-invoice and is treated only as another electronic invoice format.
• For federal B2G transactions, electronic invoicing has been mandatory since November 27, 2020. These invoices are generally submitted through the federal e-invoicing infrastructure, mainly the OZG-RE platform.
• Germany accepts EN 16931-compliant formats such as XRechnung and ZUGFeRD 2.0.1+ for domestic B2B (excluding MINIMUM and BASIC-WL profiles), with XRechnung as the default for federal B2G and ZUGFeRD 2.2.0 in the XRechnung profile as an alternative.

What does it mean by E-Invoice Rejection in Germany?

In Germany, an e-invoice is rejected when it fails the checks needed for delivery, validation, or acceptance. For B2G invoices, this can happen at the submission portal. For B2B invoices, it can happen in the buyer’s system or during the recipient’s internal review.

The issue may come from the invoice file itself, such as an invalid XML structure, missing mandatory data fields, incorrect tax calculations, or use of the wrong format. It may also come from the way the invoice was submitted, including an incorrect portal route, missing routing details, or failure to follow channel-specific rules.

Rejection does not always mean the same type of error. A portal may reject the invoice because the file does not pass formal or calculation checks. A recipient may reject it later because the commercial details are wrong, the content does not match the order, or the invoice does not meet agreed business requirements.

• Portal-level rejection: Usually caused by formal validation failures or calculation errors. 
• Recipient-level rejection: Usually caused by incorrect commercial details, content issues, or business-specific discrepancies. 
• Practical implication: Correcting the XML file alone may not resolve the issue if the rejection came from the recipient rather than the portal.

The submission portal may reject an invoice during formal validation if the structure, schema, or calculations fail required checks. Even after portal acceptance, the recipient may still reject the invoice for factual, content-related, or business-context issues.

5 Common Reasons for E-Invoice Rejection at a Glance

Here are the error patterns that most often stop invoice acceptance in Germany.

1. Noncompliant Format or Structure

A German e-invoice must be structured and machine-readable. This is one of the most common rejection points because an invoice can look complete to a human reviewer and still fail system validation.

• A plain PDF or scanned image does not qualify as a valid e-invoice. 
• The invoice must meet EN 16931 requirements and, where relevant, federal portal requirements. 
• For federal invoicing, XRechnung is generally the expected standard, with only limited compatible alternatives. 
• In domestic B2B invoicing, the legally relevant part is the structured data, not the visual document. 

Format errors are not minor technical defects. If the XML structure, syntax, or profile is wrong, the invoice may be rejected even when the PDF version appears correct. Businesses that still treat the PDF as the primary invoice often run into this issue first.

2. Missing or Invalid Mandatory Data Fields

Germany’s e-invoice controls rely heavily on data completeness. Even when the format is correct, missing required fields can trigger immediate rejection.

The federal framework requires key invoice data to be present in the structured invoice itself. This includes both VAT-law mandatory fields and certain public-sector fields required under Section 5 E-RechV.

• Buyer reference 
• Terms of payment 
• Payment recipient bank details 
• Invoice issuer’s postal or De-Mail address 
• Standard VAT-law invoice fields such as invoice number, invoice date, tax data, amounts, and service description 

The buyer reference, or Leitweg-ID, is especially important in federal invoicing because it acts as the routing key. If it is missing or incorrect, the invoice may not reach the intended recipient system.

Another common mistake is placing required information in a PDF attachment or free-text note. That does not solve the issue. Mandatory data must appear in the structured invoice data itself. In public-sector invoices, missing BT-10 buyer reference data is one of the fastest ways to cause rejection.

3. Calculation and Business Rule Errors

A technically correct invoice can still fail if the numbers do not align. Germany’s e-invoicing model is built for automated validation, so the invoice must be mathematically and logically consistent.

Common triggers include:

• Totals that do not reconcile 
• Tax amounts that do not match the tax logic used at line level 
• Conflicts between subtotals and grand totals 
• Missing or illogical data that breaks EN 16931 business rules 

These errors matter because the system does not interpret intent. Even if a human reviewer can guess what the issuer meant, the invoice may still fail validation if the logic is inconsistent. In practice, any mismatch between line values, tax calculations, and summary amounts can undermine trust in the invoice and lead to rejection.

4. Submission or Transmission Errors

Some rejections happen even when the invoice content is correct. The issue is not the file itself, but how it was submitted.

Federal portals apply strict transmission rules, and those rules are enforced automatically.

• Only one e-invoice may be sent per email 
• If multiple invoices are attached, the full email submission can be rejected 
• Attachments that are not valid structured e-invoices can also cause rejection 
• No-reply sender addresses may create delivery or processing issues 

Federal issuers must also use a valid submission route through OZG-RE, such as email, upload, web entry, or Peppol. The portal checks the invoice before routing it onward. This means a business can generate a technically correct XML file and still fail because it used the wrong operational process around that file.

5. Technical Constraints and Metadata Errors

Technical limits create another rejection layer that businesses often overlook during implementation. These are not content errors, but they can still stop an invoice from being accepted.

Important technical controls include:

• Maximum file size depends on the submission channel 
• Email attachments may be limited to 10 MB 
• Web entry submissions may be limited to 11 MB 
• Embedded supporting documents may be capped at 200 
• Only permitted embedded file types can be used 
• Attachments must not contain active content such as macros 

Supporting documents must also be handled correctly. In standard submissions, invoice-related documents are generally expected to be embedded within the invoice data record, not sent separately as loose email attachments.

Routing metadata is just as important. In federal invoicing, an invalid Leitweg-ID can block delivery even when the invoice content itself is accurate. That makes metadata errors especially difficult, because the invoice may appear correct but still fail at the routing stage.

How to Reduce E-Invoice Rejections Before Submission

A reliable control process usually prevents more rejections than any post-failure correction effort.

• Validate the structure before sending: Check the XML against EN 16931 and the applicable XRechnung or agreed format rules before transmission. The BMF explicitly recommends validation as a practical way to catch missing or illogical mandatory data early. 
• Check mandatory fields in the structured data: Make sure VAT-law elements and, where relevant, federal fields such as buyer reference, payment terms, bank details, and issuer address are populated in the structured invoice itself. 
• Reconcile tax and totals automatically: Portal rejection can result from calculation errors, so tax amounts, line totals, and invoice totals should be matched before dispatch. 
• Match the transmission rule to the channel: If using email, send one invoice per email only. If using OZG-RE, ensure the correct method is selected and registration is complete. 
• Control routing and attachment handling: Confirm the Leitweg-ID for public recipients and keep attachments within allowed technical limits and embedding rules. 

Conclusion

In Germany, e-invoice rejection is rarely a single “IT issue.” It usually reflects a deeper compliance gap between legal invoice requirements, machine-readable data quality, and the operational rules of the submission channel. Businesses that treat e-invoicing as a tax, data, and process discipline, rather than just an output format, reduce rejection risk materially and make later automation, audit readiness, and accounts receivable control far more reliable.