Auf dieser Seite
- Zulässige Formate und Profile im Überblick
- Validierung im Eingang: drei Prüfebenen
- Referenzwerkzeug: KoSIT-Validator
- Aufbewahrung von Validierungsberichten
- Innerbetriebliches Kontrollverfahren (IKV) nach §14 UStG
- Was das IKV konkret leisten muss
- Qualifizierte Signatur: gleichwertig, aber nicht zwingend
- Empfangskanäle: E-Mail und Peppol
- Peppol
- Vorsteuerabzug absichern
Geprüft auf Basis von §14 UStG (n. F. durch das Wachstumschancengesetz), BMF-Anwendungsschreiben vom 15. Oktober 2025 (Az. III C 2 – S 7287-a/23/10001 :007) und EN 16931-1 (Stand Juni 2026). Dieser Artikel richtet sich an ERP-Verantwortliche, IT-Abteilungen und Steuerberater mit technischem Hintergrund.
Den kaufmännischen Überblick darüber, welche Unternehmen betroffen sind und was inhaltlich geprüft werden muss, bietet die Angebots-Seite E-Rechnung empfangen.
Zulässige Formate und Profile im Überblick
Nach §14 Abs. 1 Satz 3 UStG (n. F.) ist eine E-Rechnung ein strukturiertes Format, das der europäischen Norm EN 16931 entspricht und die elektronische Verarbeitung ermöglicht. Das BMF-Anwendungsschreiben vom 15. Oktober 2025 und die IHK Frankfurt benennen konkret folgende zulässige Formatvarianten:
| Format | Syntax | Profil / Variante | Status |
|---|---|---|---|
| XRechnung | UBL (ISO/IEC 19845) | (eine Version) | ✅ zulässig |
| XRechnung | UN/CEFACT CII | (eine Version) | ✅ zulässig |
| ZUGFeRD ≥ 2.0.1 / Factur-X | PDF + eingebettetes XML (CII) | BASIC | ✅ zulässig |
| ZUGFeRD ≥ 2.0.1 / Factur-X | PDF + eingebettetes XML (CII) | EN 16931 (Comfort) | ✅ zulässig |
| ZUGFeRD ≥ 2.0.1 / Factur-X | PDF + eingebettetes XML (CII) | EXTENDED | ✅ zulässig |
| ZUGFeRD ≥ 2.0.1 / Factur-X | PDF + eingebettetes XML (CII) | XRECHNUNG | ✅ zulässig |
| ZUGFeRD, Profil MINIMUM | PDF + eingebettetes XML (CII) | MINIMUM | ❌ nicht ausreichend |
| ZUGFeRD, Profil BASIC WL | PDF + eingebettetes XML (CII) | BASIC-WL | ❌ nicht ausreichend |
| PDF per E-Mail (ohne XML) | entfällt | entfällt | ❌ keine E-Rechnung |
| EDI-Formate nach § 14 Abs. 1 Satz 6 UStG | bilateral vereinbart | EN-16931-kompatibel | ✅ zulässig (bilateral) |
Warum MINIMUM und BASIC-WL ausscheiden: Beide Profile enthalten nicht alle umsatzsteuerrechtlichen Pflichtfelder strukturiert im XML. MINIMUM führt weder Positionsdetails noch Steuerkennzeichnung auf Zeilenebene. BASIC-WL enthält zwar Steuerpositionen, aber keine Zeilenpositionen; beides reicht für einen maschinell auswertbaren Vorsteuerabzug nicht aus.
Syntaxvarianten XRechnung: UBL nutzt den Namespace urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, CII nutzt urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Beide sind gleichwertig. Welche Variante ein eingehendes Dokument verwendet, erkennt ein valider Eingangs-Parser am Root-Element: <Invoice> (UBL) vs. <CrossIndustryInvoice> (CII).
ZUGFeRD als Hybrid: Bei ZUGFeRD/Factur-X ist das PDF die Träger-Datei, das XML ist als Dateianlage mit dem Attachment-Namen factur-x.xml (oder ZUGFeRD-invoice.xml bei älteren Versionen) eingebettet. Ab Version 2.0.1 ist Factur-X und ZUGFeRD technisch identisch. Der Detailartikel zu ZUGFeRD und Factur-X erklärt die Extraktion des XML-Anteils.
Validierung im Eingang: drei Prüfebenen
Eine eingehende E-Rechnung muss drei unabhängige Prüfebenen bestehen, damit sie steuerrechtlich als vollwertige E-Rechnung gilt. Das BMF-Anwendungsschreiben vom 15. Oktober 2025 klassifiziert dabei ausdrücklich drei Fehlerklassen mit unterschiedlichen steuerlichen Folgen:
| Prüfebene | Was wird geprüft | Fehlerklasse BMF 2025 | Steuerliche Folge bei Fehler |
|---|---|---|---|
| 1: Format | XML-Schema (XSD), Namespaces, Elementreihenfolge, Datumsformat | Formatfehler | Datei gilt nicht als E-Rechnung |
| 2: Geschäftslogik | EN-16931-Schematron: Berechnungsregeln, Code-Listen, Steuerlogik | Geschäftsregelfehler | Vorsteuerabzug grundsätzlich gefährdet |
| 3: Pflichtfelder USt | Vollständigkeit der umsatzsteuerlichen Pflichtangaben im XML | Inhaltsfehler | Kein Vorsteuerabzug; Zurückweisung empfohlen |
Das BMF stellt klar: Technische Validierung hilft, Fehler früh zu erkennen; sie ersetzt aber nicht die inhaltliche Prüfung (IKV, siehe nächster Abschnitt).
Referenzwerkzeug: KoSIT-Validator
Die Koordinierungsstelle für IT-Standards (KoSIT) veröffentlicht den Referenz-Validator als Open-Source-Java-Anwendung (Apache 2.0, Java 11+). Er kombiniert alle drei Prüfebenen in einem Lauf und liefert einen SVRL-Report (Schematron Validation Reporting Language):
java -jar validationtool-1.6.x-standalone.jar \
-s xrechnung-configuration-2026-01-31.xml \
-o ./reports \
eingangsrechnung.xml
Für den Dauerbetrieb eignet sich der REST-Daemon-Modus (-D -H localhost -P 8080), dann werden Dokumente per HTTP POST eingereicht und Berichte maschinell ausgewertet. Kostenlose Online-Validatoren (ohne Installation) laufen intern auf demselben KoSIT-Stack.
Aufbewahrung von Validierungsberichten
Das BMF-Anwendungsschreiben vom 15. Oktober 2025 empfiehlt, erzeugte Validierungsberichte aufzubewahren. Es handelt sich ausdrücklich um eine Empfehlung, keine harte Pflicht. In der Praxis ist die Aufbewahrung sinnvoll: Sie dokumentiert den technischen Teil des Prüfpfads (IKV) und kann bei einer Betriebsprüfung nachweisen, dass fehlerhafte Rechnungen erkannt und nicht unkritisch weiterverarbeitet wurden.
Formate, die sich für die Archivierung eignen: SVRL-XML (maschinell auswertbar), HTML-Report (KoSIT erzeugt ihn optional, menschenlesbar). Beide müssen unveränderbar abgelegt werden, zusammen mit der Originalrechnung.
Innerbetriebliches Kontrollverfahren (IKV) nach §14 UStG
Nach §14 Abs. 1 Satz 5 UStG müssen Aussteller und Empfänger einer Rechnung die Echtheit der Herkunft, die Unversehrtheit des Inhalts und die Lesbarkeit sicherstellen. Als gleichwertige Methode neben der qualifizierten elektronischen Signatur (QES) gilt das innerbetriebliche Kontrollverfahren (IKV): ein Prozess, der einen „verlässlichen Prüfpfad" zwischen der Rechnung und der zu Grunde liegenden Leistung erzeugt.
Das IKV ist kein Formular, kein Zertifikat und keine separate Dokumentationspflicht. Es ist ein nachvollziehbarer Ablauf, der bei einer Betriebsprüfung rekonstruiert werden kann.
Was das IKV konkret leisten muss
Drei-Wege-Abgleich (Purchase Order Matching): Eingehende Rechnung wird gegen Bestellung und Lieferung (Lieferschein, Auftragsbestätigung) abgeglichen. Übereinstimmung bei Lieferant, Betrag, Leistungszeitraum und Steuersatz schließt den Prüfpfad.
Mindestabgleich ohne Bestellung: Auch wenn kein formeller Bestellprozess existiert (typisch im KMU-Umfeld): mindestens Lieferant, USt-IdNr., Leistungszeitraum und Rechnungsbetrag müssen gegen interne Aufzeichnungen (Angebot, E-Mail-Korrespondenz, Leistungsnachweis) gespiegelt werden.
Formale Validierung als IKV-Bestandteil: Der dokumentierte Nachweis, dass jede eingehende Rechnung eine EN-16931-Prüfung durchlaufen hat, ist Bestandteil des Prüfpfads. Schlägt die Validierung fehl (Geschäftsregelfehler, Inhaltsfehler), sollte die Rechnung zurückgewiesen und zur Korrektur zurückgegeben werden; laut BMF-Schreiben 15. Oktober 2025 berechtigt eine fehlerhafte Rechnung in diesen Klassen grundsätzlich nicht zum Vorsteuerabzug.
XML-Führungsprinzip bei Hybridformaten: Bei ZUGFeRD/Factur-X ist der eingebettete XML-Teil maßgeblich. Abweichungen zwischen XML-Betrag und PDF-Darstellung können nach §14c UStG zur Entstehung einer unberechtigten Steuerschuld führen. Dieses Risiko wird ausschließlich über die XML-Prüfung erkannt, nicht durch bloßes Ablesen des PDFs.
Qualifizierte Signatur: gleichwertig, aber nicht zwingend
Eine QES oder ein genehmigtes EDI-Verfahren ist eine alternative Methode zur Integritätssicherung; sie ersetzt das IKV vollständig. Für die meisten KMU ohne bestehende PKI-Infrastruktur ist das IKV der praktischere Weg. Im konkreten Einzelfall entscheidet der Steuerberater.
Empfangskanäle: E-Mail und Peppol
Das Bundesfinanzministerium bestätigt: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach." (BMF FAQ, Frage 3.) Das gilt für den reinen Empfang; GoBD-konforme Archivierung und IKV-Nachweis kommen als separate Anforderungen hinzu.
Technisch empfiehlt sich eine dedizierte Rechnungseingangsadresse (z. B. rechnungseingang@firma.de), damit eingehende E-Rechnungen nicht im allgemeinen Postfach untergehen und ein eindeutiger Verarbeitungspfad entsteht. Das Postfach selbst muss in die GoBD-konforme Archivierung eingebunden sein; das bloße Belassen der E-Mail im Postfach reicht nicht.
Peppol
Peppol (Pan-European Public Procurement On-Line) ist kein Dateiformat, sondern ein Transportnetzwerk aus Identifikatoren, standardisierten Transportprotokollen (AS4) und vertraglich gebundenen Access Points. Peppol BIS 3.0 (Billing) basiert auf UBL und ist EN-16931-konform; eine darüber eingehende Rechnung ist steuerrechtlich gleichwertig mit einer E-Mail-übertragenen XRechnung.
Für deutsche KMU ist Peppol 2026 kein primärer Empfangskanal: Im B2G-Bereich (öffentliche Auftraggeber) ist Peppol über die Zentrale Rechnungseingangsplattform des Bundes relevant. Im B2B-Bereich wächst Peppol, ist aber noch nicht flächendeckend. Wer bereits heute einen Peppol-Access-Point betreibt oder plant, kann XRechnung im UBL-Format direkt über das Netzwerk empfangen; eine ergänzende E-Mail-Adresse bleibt sinnvoll, um auch Lieferanten ohne Peppol-Anbindung bedienen zu können. Details zum Netzwerk: Peppol erklärt.
Vorsteuerabzug absichern
Der Vorsteuerabzug nach §15 UStG setzt voraus, dass die Rechnung ordnungsgemäß ist, das heißt:
- Das Format entspricht EN 16931 (Formatprüfung bestanden).
- Alle umsatzsteuerlichen Pflichtangaben nach §14 Abs. 4 UStG sind im strukturierten XML-Teil vorhanden und korrekt (Inhaltsprüfung bestanden).
- Ein nachvollziehbarer Prüfpfad (IKV) verknüpft die Rechnung mit der erbrachten Leistung.
- Die Rechnung wird unveränderbar und maschinell auswertbar für mindestens acht Jahre aufbewahrt (GoBD, §14b UStG).
Fehlt eines dieser vier Elemente, ist der Vorsteuerabzug gefährdet. Das ist das eigentliche betriebliche Risiko: kein direktes Bußgeld für das Nicht-Empfangen-Können, sondern der Liquiditätsabfluss durch nachträglich versagten Vorsteuerabzug bei der Betriebsprüfung.
| Fehlerfall | Konsequenz | Rechtsgrundlage |
|---|---|---|
| Formatfehler (kein EN-16931-konformes XML) | Kein Vorsteuerabzug aus dieser Rechnung | §15 i. V. m. §14 UStG |
| XML-Pflichtfelder unvollständig | Kein Vorsteuerabzug; Zurückweisung und Neuausstellung erforderlich | §14 Abs. 4 UStG, BMF 15.10.2025 |
| Abweichung XML ↔ PDF (Hybrid) | §14c-Risiko: unberechtigte Steuer aus PDF-Betrag | §14c UStG |
| GoBD-Verstoß (nicht revisionssicher archiviert) | Versagter Vorsteuerabzug + Bußgeld bis 5.000 € | §26a Abs. 2 Nr. 2 i.V.m. Abs. 3 UStG, GoBD |
| Kein IKV-Nachweis | Echtheit und Unversehrtheit nicht belegt; Risiko bei Prüfung | §14 Abs. 1 Satz 5 UStG |
Hinweis: Die steuerrechtliche Bewertung im Einzelfall obliegt dem Steuerberater. Diese Übersicht folgt dem BMF-Anwendungsschreiben vom 15. Oktober 2025 und §26a UStG.
IKV-Nachweis automatisch, Vorsteuer belegt
Wer eingehende E-Rechnungen nicht nur empfängt, sondern alle drei Prüfebenen strukturiert durchlaufen lässt und den Prüfpfad unveränderbar speichert, hat bei jeder Betriebsprüfung alles Notwendige abrufbereit. Das schafft Glaubwürdigkeit gegenüber dem Finanzamt, die im Prüfungsfall nicht erst zusammengesucht werden muss.
Gebaut von Leuten, die denselben Engpass aus der Praxis kennen.
Welche ZUGFeRD-Version ist Mindestvoraussetzung?
ZUGFeRD ab Version **2.0.1** und mindestens Profil **BASIC**. Ältere Versionen (ZUGFeRD 1.0, 2.0) sind nicht EN-16931-konform und gelten damit nicht als E-Rechnung im Sinne von §14 UStG. Auch ZUGFeRD 2.0.1 im Profil MINIMUM oder BASIC-WL ist nicht ausreichend; diese Profile enthalten nicht alle umsatzsteuerlichen Pflichtfelder maschinenlesbar im XML.
Gilt das XML oder das PDF bei ZUGFeRD-Rechnungen?
Das eingebettete **XML ist maßgeblich**; das bestätigt das BMF-Anwendungsschreiben vom 15. Oktober 2025. Weicht der XML-Betrag vom PDF-Betrag ab, entsteht das Risiko einer unberechtigten Steuerschuld nach §14c UStG. Die Eingangsverarbeitung muss daher zwingend auf dem XML-Teil basieren, nicht auf dem visuell lesbaren PDF.
Muss das IKV dokumentiert werden?
Ein formelles Dokument ist nicht vorgeschrieben. Das IKV muss aber **nachvollziehbar** sein, das heißt: Bei einer Betriebsprüfung muss rekonstruierbar sein, wie die Rechnung geprüft wurde. Softwaregestützte Protokolle (Validierungslog, Abgleich-Ergebnis, Freigabe-Zeitstempel) erfüllen diese Anforderung. Das BMF-Anwendungsschreiben vom 15. Oktober 2025 empfiehlt, Validierungsberichte aufzubewahren.
Was passiert, wenn eine eingehende Rechnung einen EN-16931-Fehler enthält?
Die Rechnung berechtigt nach BMF-Schreiben 15. Oktober 2025 bei Geschäftsregel- oder Inhaltsfehler grundsätzlich nicht zum Vorsteuerabzug. Empfohlene Reaktion: Rechnung zurückweisen, Lieferanten über den konkreten Fehler informieren (Fehlercode aus dem Validierungsbericht), berichtigte Rechnung anfordern. Erst nach erfolgreicher Validierung der Neuausstellung wird die Rechnung freigegeben.
Ist Peppol für mein Unternehmen schon relevant?
Für die meisten deutschen KMU im B2B-Bereich ist Peppol **2026 kein verpflichtender Empfangskanal**. XRechnung per E-Mail und ZUGFeRD per E-Mail decken die gesetzliche Empfangspflicht vollständig ab. Peppol gewinnt an Relevanz, wenn Lieferanten oder Kunden Peppol-Anbindungen aufbauen oder wenn ein Unternehmen im B2G-Bereich mit öffentlichen Auftraggebern arbeitet. Details: Peppol erklärt.
Wie lange müssen E-Rechnungen aufbewahrt werden?
**Acht Jahre**: Das gilt für die strukturierte XML-Datei in unveränderter Originalform (§14b UStG, GoBD). Das Ausdrucken oder Konvertieren in ein anderes Format reicht als Archivierung nicht aus. Bei ZUGFeRD muss der PDF-Container mit eingebettetem XML aufbewahrt werden, nicht nur das extrahierte XML. Im Zweifel gilt: Das Originaldokument, so wie es eingegangen ist, revisionssicher und maschinell auswertbar ablegen.
Verwandte Seiten: E-Rechnung empfangen: kaufmännischer Überblick · XRechnung erklärt · ZUGFeRD und Factur-X · E-Rechnungspflicht 2025 bis 2028