FAQ zum E-Rechungs-Validator

Warum sind meine E-Rechnungen nicht valide?

Wir erhalten relativ oft Fragen, warum bestimmte Rechnungen als nicht valide erkannt werden. Z.B. eine potentielle ZUGFeRD-Rechnung wird als invalide erkannt, aber das einzeln geprüfte XML wird als valide erkannt. Das liegt an den Vorgaben für die Formate XRechnung und ZUGFeRD. Daher fassen wir hier die häufigsten Fragen zusammen

Kurze, nicht technische Erklärung zu invaliden E-Rechnungen

Viele Nutzer sind zunächst verunsichert, wenn der E-Rechnungs-Validator meldet, dass eine Rechnung „nicht valide“ ist.
Wichtig zu wissen: Das bedeutet nicht automatisch, dass Ihre Rechnung falsch oder unbrauchbar ist.

In den meisten Fällen liegt es an formalen Vorgaben, die für E-Rechnungen gelten – etwa fehlende Pflichtangaben, unvollständige Felder oder kleine Abweichungen vom vorgeschriebenen Format. Solche Fehler entstehen häufig automatisch durch Buchhaltungs- oder Rechnungstools und lassen sich meist einfach korrigieren.

Dieser Artikel erklärt:

• warum E-Rechnungen häufig als „nicht valide“ eingestuft werden,
• welche typischen Ursachen dahinterstecken,
• und was Sie konkret tun können, um solche Fehler zu vermeiden.

👉 Wenn Sie technisch nicht tief einsteigen möchten, reicht es oft schon, die im Prüfbericht genannten Hinweise zu beachten.
👉 Für alle, die es genauer wissen wollen, finden Sie im folgenden Text die detaillierten technischen Hintergründe.

XRechnung vs.ZUGFeRD – welches XML ist erlaubt

Rechnungsstandard	CII-Format erlaubt?	UBL-Format erlaubt?	Bemerkungen
ZUGFeRD	✅ Ja	❌ Nein	ZUGFeRD verwendet ausschließlich das CII-Format für die XML-Daten.
XRechnung	✅ Ja	✅ Ja	XRechnung kann sowohl im CII-Format als auch im UBL-Format vorliegen.

Warum ist meine ZUGFeRD-Rechnung ungültig, obwohl das PDF korrekt aussieht?

Bei einer ZUGFeRD-Rechnung besteht die eigentliche E-Rechnung nicht aus dem sichtbaren PDF, sondern aus dem im PDF eingebetteten XML-Datensatz.
Die Validierung prüft ausschließlich dieses XML – nicht das Layout oder den Text, den Sie im PDF sehen.

Ein korrekt aussehendes PDF garantiert keine valide ZUGFeRD-Rechnung.
Entscheidend ist allein, ob das eingebettete XML den technischen und fachlichen Anforderungen entspricht.

Warum schlägt die Validierung trotz korrekter Beträge fehl?

Auch wenn die Beträge auf der Rechnung auf den ersten Blick korrekt aussehen, kann die Validierung fehlschlagen, weil E-Rechnungen nicht visuell, sondern rechnerisch und strukturell geprüft werden.

Typische Ursachen sind:

• Rundungsdifferenzen
  Einzelpositionen, Zwischensummen und Gesamtsumme müssen rechnerisch exakt zusammenpassen. Schon Abweichungen von wenigen Cent führen zu einem Validierungsfehler.
• Falsche Dezimalstellen
  Manche Felder erlauben nur eine bestimmte Anzahl von Dezimalstellen. Werden diese überschritten oder falsch formatiert, gilt der Wert als ungültig.
• Abweichende Steuerberechnung
  Die Steuer muss sich korrekt aus Nettobetrag und Steuersatz ergeben. Manuelle Korrekturen im PDF reichen nicht aus.
• Inkonsistente Werte im XML
  Häufig stimmen sichtbare Beträge im PDF, aber die im XML hinterlegten Werte weichen davon ab oder wurden anders berechnet.

Wichtig:
Für die Validierung zählt nicht, ob eine Rechnung „vernünftig aussieht“, sondern ob alle Beträge mathematisch exakt und konsistent im XML hinterlegt sind.

Kann eine ungültige E-Rechnung nachträglich korrigiert werden?

Nein. Eine einmal ausgestellte E-Rechnung kann nicht nachträglich geändert oder „repariert“ werden.
Weder das PDF noch das XML dürfen nachträglich angepasst werden.

Stellt sich heraus, dass eine E-Rechnung ungültig ist, muss stattdessen:

• eine neue, korrigierte Rechnung erstellt werden
  oder
• eine Stornorechnung mit anschließender Neuerstellung erfolgen

Welche Variante zulässig ist, hängt vom konkreten Geschäftsvorfall und den steuerlichen Vorgaben ab.

Wichtig:
Das bloße Korrigieren einzelner Felder im XML oder PDF führt nicht zu einer gültigen E-Rechnung und kann im Prüfungsfall beanstandet werden.

Deshalb sollte jede E-Rechnung vor Versand und vor der Archivierung validiert werden, um spätere Korrekturen zu vermeiden.

Muss eine E-Rechnung vor der Archivierung validiert werden?

Nein. Es gibt keine gesetzliche Pflicht, eine E-Rechnung vor der Archivierung technisch zu validieren.

Allerdings gilt:
Eine E-Rechnung muss formell und inhaltlich korrekt sein, um als ordnungsgemäße Rechnung zu gelten.
Ist sie fehlerhaft, bleibt sie auch nach der Archivierung ungültig.

Da E-Rechnungen ausschließlich anhand ihrer strukturierten Daten beurteilt werden, ist eine technische Validierung in der Praxis der einzige verlässliche Weg, um sicherzustellen, dass die Rechnung den geltenden Anforderungen entspricht.

Wichtig:
Die Archivierung selbst macht eine fehlerhafte E-Rechnung nicht gültig.
Wer auf eine Validierung verzichtet, trägt das Risiko, erst im Prüfungsfall festzustellen, dass die archivierte Rechnung formell nicht anerkannt wird.

Warum erhalte ich das Ergebnis invalide, obwohl meine XML-Datei scheinbar korrekt ist?

Sowohl XRechnung als auch ZUGFeRD verlangen, dass die XML-Dateien in der UTF-8-Kodierung vorliegen.

✅ Kodierung: UTF-8
✅ Ohne BOM (Byte Order Mark)

⛔ Fehlerquellen:

• Die Datei darf keinen BOM (Byte Order Mark) enthalten, da dies zu Validierungsfehlern führen kann.
• Andere Zeichencodierungen wie ISO-8859-1 oder UTF-16 sind nicht erlaubt.

Sowohl XRechnung als auch ZUGFeRD erwarten, dass die XML-Dateien mit dem Unix-Zeilenende gespeichert werden:

✅ Erlaubt:

• LF (\n) → Unix/Linux-kompatible Zeilenumbrüche

⛔ Nicht empfohlen / problematisch:

• CRLF (\r\n) → Windows-typische Zeilenumbrüche können Probleme verursachen
• CR (\r) → Mac OS (ältere Versionen) ist nicht kompatibel

Hier ist eine Liste häufiger Fehler, die bei der Erstellung und Validierung von E-Rechnungen (XRechnung & ZUGFeRD) auftreten können.

1. Fehler in der XML-Struktur

❌ Falsche oder fehlende Root-Elemente

• XRechnung: Das Wurzelelement muss <rsm:CrossIndustryInvoice> sein.
• ZUGFeRD: Das XML muss ebenfalls das <rsm:CrossIndustryInvoice>-Element enthalten.
• ❗ Fehler: Verwendung von <Invoice> (UBL) in einer XRechnung (nur CII ist erlaubt!).

❌ Fehlendes oder falsches Encoding

• Erlaubt: <?xml version="1.0" encoding="UTF-8"?>
• ❗ Fehler: Andere Encodings wie ISO-8859-1 oder UTF-8 mit BOM (Byte Order Mark).

❌ Falsche oder inkonsistente XML-Namensräume

• Erlaubt (CII-XRechnung): xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
• ❗ Fehler: Ungültige oder fehlende Namensräume, die dazu führen, dass der Validator das XML nicht versteht.

❌ Fehlende oder doppelte <ram:ID> im Kontextbereich

• Erlaubt: <ram:GuidelineSpecifiedDocumentContextParameter> <ram:ID>urn:cen.eu:en16931:2017</ram:ID> </ram:GuidelineSpecifiedDocumentContextParameter>
• ❗ Fehler: urn:cen.eu:en16931:2017 fehlt oder falsch geschrieben.

2. Fehlerhafte Pflichtfelder

❌ Fehlende Rechnungsnummer

• Pflichtfeld: <ram:ID> innerhalb von <rsm:ExchangedDocument>

❌ Fehlendes Rechnungsdatum oder falsches Format

• Erlaubt: <ram:IssueDateTime> <udt:DateTimeString format="102">20250129</udt:DateTimeString> </ram:IssueDateTime>
• ❗ Fehler: Datumsformat nicht als YYYYMMDD (Format 102).

❌ Fehlende oder falsche Währungsangabe

• Pflichtfeld: <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
• ❗ Fehler: Keine oder falsche Währung (EURO statt EUR).

❌ Fehlende Beträge oder falsches Dezimaltrennzeichen

• Erlaubt: 1000.50 (Punkt als Dezimaltrennzeichen)
• ❗ Fehler: 1.000,50 (falsch, da kein Tausenderpunkt erlaubt ist!)

3. Fehler bei der Steuerangabe

❌ Fehlender oder falscher Steuersatz

• Erlaubt: <ram:ApplicableTradeTax> <ram:TypeCode>VAT</ram:TypeCode> <ram:CategoryCode>S</ram:CategoryCode> <ram:RateApplicablePercent>19.00</ram:RateApplicablePercent> </ram:ApplicableTradeTax>
• ❗ Fehler: Falsche oder fehlende <ram:RateApplicablePercent>-Angabe.

❌ Netto-/Bruttowerte stimmen nicht überein

• Der Gesamtbetrag muss mit den Einzelposten übereinstimmen.

❌ Falsche Steuerkategorie (CategoryCode)

• Erlaubt:
  • S → Standardsteuersatz (19 % in Deutschland)
  • K → Ermäßigter Steuersatz (7 % in Deutschland)
  • AE → Steuerbefreit
• ❗ Fehler: Z für Steuerbefreiung ist falsch (statt AE).

4. Fehler in der Rechnungsposition (Zeilen)

❌ Fehlende Produktbeschreibung (<ram:Description>)

• Jede Position benötigt eine Beschreibung.

❌ Menge oder Einheit fehlen oder sind falsch

• Erlaubt: <ram:BilledQuantity unitCode="C62">5</ram:BilledQuantity>
• ❗ Fehler: Fehlende oder falsche Einheit (unitCode="KG" statt "C62" für Stück).

❌ Fehlende Preisangaben (<ram:NetPriceAmount> oder <ram:ChargeAmount>)

• Jeder Posten braucht einen Nettopreis.

5. Fehler bei der Empfänger-/Lieferantenadress

❌ Fehlender Rechnungsempfänger (<ram:BuyerTradeParty>)

• Pflichtangaben:
  • <ram:Name> (Firmenname)
  • <ram:PostalTradeAddress> (Adresse)

❌ Fehlende Steuer- oder USt-IdNr. des Lieferanten

• Erlaubt: <ram:SpecifiedTaxRegistration> <ram:ID schemeID="FC">DE123456789</ram:ID> </ram:SpecifiedTaxRegistration>
• ❗ Fehler: Steuer-ID fehlt oder falsches schemeID.

6. Fehler bei der Einbettung in PDF (ZUGFeRD)

❌ Fehlende oder falsche Einbettung der XML-Datei

• ZUGFeRD benötigt eine PDF/A-3-Datei mit einer eingebetteten XML-Datei.

❌ Falscher MIME-Type für XML-Anhang

• Erlaubt: "application/xml"
• ❗ Fehler: "text/xml" oder andere MIME-Typen.

❌ XML-Datei hat einen falschen Namen

• Erlaubt: ZUGFeRD-invoice.xml oder factur-x.xml

7. Fehler bei der Signatur / Validierung

❌ Die Datei entspricht nicht den XRechnung- oder ZUGFeRD-Regeln

• Nutze einen Validator 😊

❌ XML ist nicht wohlgeformt