1.643 Regeln, 8 Fehler: woran E-Rechnungen in der Praxis wirklich scheitern

Das Regelwerk, gegen das eine deutsche E-Rechnung geprüft wird, umfasst in der aktuellen Validator-Konfiguration 1.643 Prüfregeln. 464 davon sind fatal – sie führen zur Ablehnung. 1.179 sind Warnungen.

Wer diese acht Fehler abstellt, hat den Rechnungsausgang im Griff. Wer sie nicht kennt, sucht in 1.643 Regeln. Und dann gibt es die zweite, unangenehmere Kategorie: Rechnungen, die jede Validierung bestehen und trotzdem falsch sind. Die kosten in Projekten am Ende mehr Zeit als alle Schematron-Fehler zusammen, weil sie erst in der Buchhaltung des Empfängers auffallen – oder in der Betriebsprüfung.

Teil 1 — Die acht Fehler, die 90 % der Ablehnungen ausmachen

1. Rundung und Berechnung — rund 28 % aller Ablehnungen

Regel: BR-CO-17, flankiert von BR-CO-10, BR-CO-13, BR-CO-15 · Meldung: Der Umsatzsteuerkategoriebetrag (BT-117) entspricht nicht BT-116 × BT-119 / 100.

Der mit Abstand häufigste Fehler – und der am schlechtesten verstandene. Die eigentliche Ursache ist fast nie der Rundungsalgorithmus, sondern die Preisbasis. Systeme, die aus einer Brutto-Welt kommen – Shop-Systeme, Abo-Plattformen, Portale mit Endkundenpreisen – speichern den Bruttopreis als führenden Wert. Im XML ist es genau umgekehrt: Die EN 16931 kennt nur Nettobeträge als Basis, der Bruttobetrag ist das Ergebnis.

Die Regel, die das löst: erst runden, dann summieren.

Jeden Positionsnettobetrag (BT-131) auf zwei Dezimalstellen runden.
Die Summe BT-106 aus diesen gerundeten Werten bilden, nicht aus internen Rohwerten.
Positionen nach Steuersatz gruppieren, je Gruppe den Nettobetrag summieren, dann den Steuersatz auf die Gruppensumme anwenden.
Verbleibende Differenz in BT-114 (Rundungsbetrag) – nicht in eine stille Korrektur.

Praxistipp bei hartnäckigen Rundungsdifferenzen: Statt den Bruttobetrag auf Cent-Ebene zurückzurechnen, hilft es oft, in einer größeren Einheit zu rechnen. Wer z. B. 0,005 € nicht verlustfrei auf zwei Dezimalstellen runden kann, modelliert die Position als Tausendstel der eigentlichen Einheit – also 1.000 Stück à 0,01 € statt 1 Stück à 10,00 € – und vermeidet so den problematischen Zwischenwert. Dasselbe gilt bei Prozentrabatt auf viele Positionen: die Rabattbasis auf Gruppenebene bilden, nicht auf Positionsebene runden und dann aufsummieren.

<cac:LegalMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
  <cbc:PayableRoundingAmount currencyID="EUR">0.00</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>

Wenn Ihr System brutto führt: Legen Sie die Brutto-Netto-Umrechnung einmal zentral fest. Aus einem Bruttobetrag lässt sich der Nettowert nur eindeutig zurückrechnen, wenn Steuersatz, Rabattlogik und Rundungsebene vorab geklärt sind – das ist eine Abstimmungsschleife mit Fachbereich und Steuerbereich, nicht ein Entwicklertag.

2. USt-IdNr. fehlt oder hat kein Länderpräfix — rund 22 %

Regeln: BR-CO-09, BR-DE-16

123456789 statt DE123456789. Deutsche ERP-Systeme speichern die Nummer seit Jahrzehnten ohne Länderkürzel. Im XML ist es Pflicht. Zwei Nachbarfehler, die ständig mitkommen:

Kleinunternehmer nach § 19 UStG haben keine USt-IdNr. Sie tragen ihre Steuernummer in BT-32 ein – erkennbar am TaxScheme-Code FC statt VAT. Wer die Steuernummer mit VAT auszeichnet, erzeugt zusätzlich BR-CO-09.
Griechenland verwendet EL, nicht GR. Der Klassiker in jeder Mandantenliste mit EU-Kunden.

<cac:PartyTaxScheme>
  <cbc:CompanyID>040/123/45678</cbc:CompanyID>
  <cac:TaxScheme><cbc:ID>FC</cbc:ID></cac:TaxScheme>
</cac:PartyTaxScheme>

3. Umsatzsteueraufschlüsselung fehlt oder ist inkonsistent — rund 18 %

Regeln: BR-S-01 bis BR-S-10, analog BR-Z-*, BR-E-*, BR-AE-*, BR-IC-*, dazu BR-CO-18

Für jede verwendete Steuerkategorie muss genau eine Aufschlüsselungsgruppe (BG-23) vorhanden sein. Fehlt sie, ist die Rechnung ungültig. Die teureren Varianten sind die Mischfälle:

O gemeinsam mit S in einem Beleg. Das ist nach EN 16931 unzulässig. Besonders betroffen sind Kreditinstitute: steuerfreie Finanzdienstleistungen neben steuerpflichtigen Nebenleistungen in einer Rechnung – was im PDF unauffällig nebeneinanderstand, muss im XML sauber getrennt werden, was bis in den Fakturaprozess zurückwirkt.
Befreiungsgrund fehlt bei E, AE, K, O. Kategoriecode gesetzt, aber weder Code (BT-121) noch Text (BT-120).
Befreiungsgrund gesetzt bei S oder Z. Dort ist er verboten (BR-S-10, BR-Z-10).
Reverse Charge ohne Käufer-USt-IdNr. (BR-AE-02) – ein Hinweis auf ein echtes steuerliches Risiko, nicht nur ein Formatproblem.

<cac:TaxCategory>
  <cbc:ID>AE</cbc:ID>
  <cbc:Percent>0</cbc:Percent>
  <cbc:TaxExemptionReasonCode>VATEX-EU-AE</cbc:TaxExemptionReasonCode>
  <cbc:TaxExemptionReason>Steuerschuldnerschaft des Leistungsempfängers</cbc:TaxExemptionReason>
  <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:TaxCategory>

4. ZUGFeRD ist kein PDF/A-3 — rund 14 %

Der Fehler, den kein XML-Validator meldet. Das XML ist fehlerfrei, der Empfänger lehnt trotzdem ab.

ZUGFeRD und Factur-X setzen PDF/A-3 voraus, weil nur dieser Standard eingebettete Dateien archivfest zulässt. Ein normales PDF 1.7 mit angehängtem XML ist kein ZUGFeRD – es sieht nur so aus.

Prüfpunkt	Anforderung
Konformität	PDF/A-3, XMP mit pdfaid:part=3, eingebettete Schriften, Output-Intent, keine Transparenz, kein JavaScript
Dateiname des XML	ZUGFeRD ab 2.1 / Factur-X: factur-x.xml · ZUGFeRD 2.0: zugferd-invoice.xml · ZUGFeRD 1.0: ZUGFeRD-invoice.xml
AFRelationship	Eingebettete Datei als /AFRelationship /Alternative deklariert und über /AF im Dokumentkatalog referenziert
Profil-Konsistenz	Profil-URN im XML muss zu den gelieferten Feldern und zum XMP-Block passen

MINIMUM und BASIC WL erfüllen die Anforderungen an eine strukturierte E-Rechnung nach § 14 UStG nicht, weil die Positionsdaten fehlen. Sie sind Buchungshilfen, keine Rechnungen. Mindestens BASIC, besser EN 16931.

5. Verkäufer-Kontaktgruppe unvollständig — rund 10 %

Regeln: BR-DE-2, BR-DE-5, BR-DE-6, BR-DE-7, dazu BR-DE-27 und BR-DE-28

Die XRechnung verlangt eine erreichbare Kontaktstelle beim Rechnungssteller: Name, Telefon und E-Mail – alle drei. Fehlt eines, gilt die ganze Gruppe als unvollständig. Klingt banal, ist in der ERP-Datenversorgung aber einer der zähesten Punkte.

BR-DE-27 Telefon: genau eine Nummer, mindestens drei Zeichen. -, n/a, keine oder zwei Nummern in einem Feld fallen durch.
BR-DE-28 E-Mail: genau eine Adresse, genau ein @. rechnung@example.de; buchhaltung@example.de – zwei Adressen in einem Feld sind ein fataler Fehler.

6. Falsche Spezifikationskennung BT-24 — rund 8 %

Regeln: BR-DE-21 (Warnung), BR-CL-24 (Fehler, wenn Wert nicht in Codeliste)

Der Fehler, der nach jedem Versionswechsel auftritt. Die Profil-URN ist in fast allen Systemen ein hart kodierter String. Für XRechnung 3.0 in UBL:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

Mit XRechnung 4.0 steht der nächste Bruch an – die Version ist nicht rückwärtskompatibel zu 3.x. Setzen Sie sich einen Kalendereintrag auf die Prüfung von BT-24.

7. Leitweg-ID fehlt bei B2G — rund 5 %

Regel: BR-DE-15, Feld BT-10

Bei Rechnungen an öffentliche Auftraggeber trägt BT-10 die Leitweg-ID. Format: Grobadresse-Feinadresse-Prüfziffer, etwa 04011000-12345-34.

Validiert wird nur die Anwesenheit, nicht der Inhalt. Eine falsche Leitweg-ID passiert die Validierung sauber und wird erst im Rechnungseingangsportal der Behörde abgewiesen – dort dann ohne brauchbare Fehlermeldung. Im B2B ist BT-10 in der XRechnung ebenfalls Pflichtfeld.

8. Codelisten-Verstöße, allen voran der Währungscode — rund 3 %

Regeln: BR-CL-*, PEPPOL-EN16931-CL*

Feld	Codeliste	Häufig falsch	Richtig
BT-5 Währung	ISO 4217	Euro, €, " EUR "	EUR
BT-130 Einheit	UN/ECE Rec. 20/21	Stk, Stück, Std	H87, HUR, DAY, KGM
BT-40 / BT-55 Land	ISO 3166-1 alpha-2	Deutschland, GER	DE
BT-81 Zahlungsmittel	UNTDID 4461	Freitext	58, 59, 30, 48, 68, 10
BT-125 Anhang	IANA MIME (Peppol)	application/octet-stream	application/pdf

Dazu zwei Peppol-Regeln, die beim Netzversand zusätzlich greifen und in reinen XRechnung-Prüfungen unsichtbar bleiben:

PEPPOL-EN16931-R008 – keine leeren Elemente. <cbc:Note/> ist für die EN 16931 folgenlos, Peppol lehnt ab. Leere Knoten beim Serialisieren zu unterdrücken ist ein Einzeiler.
PEPPOL-EN16931-R010/R020 – elektronische Adresse. In CII darf URIUniversalCommunication pro Partei genau einmal vorkommen – E-Mail und Leitweg-ID parallel einzutragen erzeugt einen Fehler.

Teil 2 — Die Fehler, die kein Validator meldet

Die folgenden Belege sind technisch einwandfrei. Sie validieren, sie werden zugestellt, sie werden verbucht – falsch.

381 und 389 werden verwechselt – mit sehr unterschiedlichen Folgen

381 – Credit Note (kaufmännische Gutschrift / Storno). Aussteller ist der Verkäufer – genau wie bei der Ursprungsrechnung. Die Parteien bleiben identisch, es gibt keinen Rollentausch. Zwei Fehler treten hier regelmäßig auf:

Referenz fehlt. BT-25 (BillingReference/InvoiceDocumentReference/ID) und BT-26 (Datum der Ursprungsrechnung) sind Pflicht. Ohne sie ist der Beleg fachlich wertlos – Validatoren melden teils nur eine Warnung, in Prozessen ist es ein harter Abbruch, weil der Debitor nichts zuordnen kann.
Beträge negativ. Bei 381 positiv angeben – der Typcode kehrt das Vorzeichen um. Negative Beträge plus 381 ergibt eine doppelte Umkehr: der Empfänger bucht eine zweite Forderung statt eine Aufhebung.

Sprachfalle: 381 ist keine „Gutschrift" im umsatzsteuerlichen Sinne (§ 14 Abs. 2 S. 2 UStG). Im Deutschen heißt beides „Gutschrift" – gemeint ist aber Unterschiedliches. Die steuerrechtliche Gutschrift ist Code 389.

389 – Self-billed Invoice (Gutschrift im umsatzsteuerlichen Sinn). Der Leistungsempfänger erstellt den Beleg über die vom Lieferanten erbrachte Leistung – typisch bei Provisionsabrechnungen, Kommissionsgeschäften oder Gutschriftverfahren im Einkauf. Voraussetzung: eine vorherige Vereinbarung und der Hinweis „Gutschrift" auf dem Beleg (§ 14 Abs. 2 UStG).

Die Rollen in der XML werden nicht getauscht. Das ist der zweite und häufigste Fehler bei 389. Es gilt immer: BG-4 Seller = der leistende Lieferant (mit dessen USt-IdNr. in BT-31), BG-7 Buyer = der Empfänger, der den Beleg technisch ausstellt. Was sich ändert, ist ausschließlich die Transportrolle im Peppol-Envelope: der Buyer ist dort Absender, der Seller Empfänger. Das ist Envelope-Ebene – nicht Dokumentebene.

Feld	Richtig bei 389	Häufiger Fehler
BG-4 Seller	Leistender Lieferant (mit dessen USt-IdNr.)	Aussteller der Datei trägt sich selbst ein → USt wird dem Falschen zugerechnet, Vorsteuerabzug des Empfängers kippt
BG-7 Buyer	Leistungsempfänger (technischer Aussteller)	—
Beträge	Positiv – 389 ist eine vollwertige Rechnung	Negativ als „Storno" – 389 ist kein Korrekturbeleg

Faustregel: Seller im XML = wer leistet und die Steuer schuldet. Immer. Unabhängig davon, wer die Datei erzeugt. Validatoren fangen diesen Fehler nicht ab – die XML ist formal korrekt, nur fachlich falsch.

384 (Corrected Invoice) nicht mit 381 verwechseln: 384 ersetzt die Ursprungsrechnung vollständig, 381 korrigiert nur einen Teil. Deutsche Empfänger unterstützen 384 deutlich seltener – im Zweifel lieber Storno (381) plus neue Rechnung (380) statt 384.

Wie wird eine 389 storniert?

Sauber nach UNTDID 1001 wäre Code 261 (Self-billed credit note): der Leistungsempfänger, der die Gutschrift ausgestellt hat, storniert sie auch – Rollen bleiben unverändert, Referenz auf die 389 via BT-25/BT-26, Beträge positiv. Das Problem: 261 ist in deutschen Profilen nicht zugelassen. Die XRechnung-Codeliste für BT-3 kennt im Kern 326, 380, 381, 384, 389 und 875–877. Peppol BIS lässt für CreditNote nur 381 zu. Am Validator scheitert man, obwohl der Code semantisch korrekt wäre.

Praktisch in Deutschland: Storno mit 381, aber mit der Parteienbelegung der 389 — Seller = Lieferant, Buyer = Aussteller — und BT-25 auf die Nummer der stornierten Gutschrift. Der Beleg wird wieder vom Buyer erzeugt und versendet, wie die 389 selbst. Ergänzend die Storno-Absicht in BT-22 (Freitext) und ggf. den Hinweis „Gutschrift" beibehalten, damit umsatzsteuerlich klar bleibt, worauf sich der Vorgang bezieht.

Zwei Stolperfallen beim 389-Storno:

Nicht 381 mit getauschten Parteien bauen, weil der Buyer ausstellt. Der Seller bleibt der Lieferant — sonst passiert genau der USt-IdNr.-Fehler von oben, nur in der Korrektur.
Nicht die Gutschrift „stornieren", indem der Lieferant eine normale 380 über denselben Betrag schickt. Das erzeugt zwei Belege über denselben Umsatz mit unterschiedlichen Ausstellern — der Empfänger kann das nicht auflösen, und umsatzsteuerlich stehen dann zwei Steuerausweise im Raum.

Storno, Gutschrift, Korrektur: Codevorrat 380/381/384/389 und sauberer Prozess

Skonto als Freitext

BR-DE-18 ist nur eine Warnung – und genau deshalb bleibt sie stehen. „2 % Skonto bei Zahlung binnen 14 Tagen" in BT-20 ist maschinell nicht auswertbar. Der Empfänger zieht den Betrag trotzdem, die Differenz landet in der Klärung.

Die XRechnung definiert eine strukturierte Schreibweise:

<cac:PaymentTerms>
  <cbc:Note>#SKONTO#TAGE=14#PROZENT=2.00#
#SKONTO#TAGE=30#PROZENT=0.00#</cbc:Note>
</cac:PaymentTerms>

Skonto in der E-Rechnung: richtig modellieren und auslesen

Anzahlungen als Minusposition

Die geleistete Anzahlung wird als negative Rechnungsposition abgezogen – das Modell sieht dafür BT-113 (bereits gezahlter Betrag) und die Referenz auf die Abschlagsrechnungen vor. Eine Minusposition erzeugt entweder einen Fehler oder eine Rechnung, deren Positionssumme nicht mehr zur Leistung passt.

Anzahlungsrechnung, Teilrechnung, Schlussrechnung in XRechnung und ZUGFeRD

Anhänge: falscher Weg, unsichtbarer Inhalt, fehlende Rechtsgrundlage

Leistungsnachweise, Aufmaßblätter oder andere leistungsbegründende Dokumente gehören nicht als lose E-Mail-Beilage zum Beleg. Die EN 16931 sieht dafür BG-24 (AdditionalDocumentReference) vor: der Anhang wird Base64-kodiert in BT-125 eingebettet, MIME-Typ in BT-125-0, Dateiname in BT-122. Aktuell ist Base64 der einzige Weg im reinen XML. Ab 2026 soll in einer revidierten EN-Version auch eine referenzierte XRechnung-XML als Anhang zulässig sein – nahezu kein System kann das heute auslesen.

Häufiger Fehler bei ZUGFeRD: mehrere PDF-Anhänge statt Merge

In einem ZUGFeRD-Container (PDF/A-3) darf nur eine eingebettete Datei im Sinne des Standards stehen: das factur-x.xml (bzw. zugferd-invoice.xml). Wer weitere Dokumente als separate eingebettete Dateien hinzufügt, erzeugt regelmäßig Fehler – entweder beim Validator, weil mehrere /AF-Einträge auftauchen, oder beim Empfänger, der den Container als fehlerhaft zurückweist.

Der richtige Weg für zusätzliche Seiten ist der Merge ins Haupt-PDF: Leistungsnachweis, Aufmaß oder Lieferschein werden vor der PDF/A-3-Erzeugung an das Hauptdokument angehängt – das Ergebnis ist ein einziger PDF-Strom, in den das XML eingebettet wird. Alternativ können zusätzliche Belege als separate Feldinhalte über BG-24 im XML stehen (Base64), sind aber auch dann auf Empfängerseite oft nicht sichtbar.

Wann sind Anhänge rechtlich erforderlich?

Die EN 16931, das UStG (§ 14) und die XRechnung-Spezifikation schreiben keine Pflicht-Anhänge vor. Die Anforderung kommt immer aus dem Vertrag oder der Vergabe, nicht aus dem Rechnungsformat selbst. Typische Fälle:

Bauverträge (VOB/B § 14 Abs. 1): Der Auftragnehmer hat prüffähige Unterlagen – Aufmaß, Stundenlohnzettel – vorzulegen. Ob diese in die Rechnung eingebettet oder separat übergeben werden, regelt der Auftraggeber; viele B2G-Portale verlangen die Einbettung in BG-24.
Dienstleistungsverträge: Stunden- oder Tätigkeitsnachweise sind oft vertraglich geschuldet. Fehlen sie, ist die Rechnung formell prüffähig, sachlich aber nicht freigabefähig.
Öffentliche Auftraggeber (B2G): Einzelne Auftraggeber – z. B. Bundesbehörden über OZG-RE oder Landesportale – können in den Empfangsbedingungen verlangen, dass Nachweise strukturiert mitgeführt werden. Diese Anforderung steht in der Leistungsbeschreibung oder dem Auftragsdokument, nicht im Gesetz.
Sonst: Keine gesetzliche Pflicht. Die Rechnung ist umsatzsteuerlich vollständig ohne Anhang, sofern alle Pflichtangaben nach § 14 Abs. 4 UStG vorhanden sind.

Kompatibilitätsrealität: Viele Empfangssysteme und Validatoren zeigen BG-24-Anhänge nicht an – die XML ist formal korrekt, der Anhang bleibt für den Sachbearbeiter unsichtbar. rechnungsapi.de unterstützt mehrere Anhänge je Rechnung über BG-24; ob und wie der Empfänger sie anzeigt, hängt ausschließlich am eingesetzten ERP oder Portal.

Die Rechnung ist valide — und kommt trotzdem nicht an

Im Debitorenstamm steht keine, eine veraltete oder eine private Adresse eines längst ausgeschiedenen Ansprechpartners. Oder ein Sammelpostfach, das niemand liest. In den meisten Stämmen ist die Rechnungs-E-Mail nie als eigenes Feld gepflegt worden. Drei Governance-Punkte, die dauerhaft wirken: eigenes Feld für die Rechnungs-E-Mail, Pflichtfeld bei der Neuanlage, und eine Bounce-Rückkopplung aus dem Maillog in den Stammdatenprozess.

Fehlende E-Mail-Adressen im Debitorenstamm: So bekommen Sie sie

KI-generierte Rechnungsdaten

Selbstgebaute Module, die XML von einem Sprachmodell erzeugen lassen, scheitern an Regeln, die das Modell nicht kennen kann – weil sie versionsabhängig sind und sich mehrmals jährlich ändern. Ein Sprachmodell ist eine gute Wahl für die Erklärung eines Fehlercodes. Für die Erzeugung eines normkonformen Dokuments ist es die falsche Komponente.

Teil 3 — SAP-Landschaften: wo es zusätzlich hakt

In SAP-Umgebungen laufen Ausgang und Eingang typischerweise über SAP Document and Reporting Compliance (DRC) mit dem eDocument-Framework und dem eDocument Cockpit. Die Standardregeln aus Teil 1 gelten dort unverändert – dazu kommen Muster, die spezifisch für diese Architektur sind.

Die Daten fehlen nicht im Mapping, sondern im Stamm. Das ist der Kern fast aller DRC-Fälle. BT-10 (Leitweg-ID), BT-41/42/43 (Kontaktgruppe) und BT-49 (elektronische Adresse des Käufers) haben in klassischen SAP-Stammdaten keinen natürlichen Platz. Die Konsequenz: Jede Rechnung an diesen Empfänger fällt aus – reproduzierbar, bis der Stammsatz repariert ist.

Der Fehler taucht spät auf. Im eDocument Cockpit wird der Beleg nach der Faktura erzeugt und geht in einen Fehlerstatus, statt beim Buchen zu scheitern. Ohne eine Vorprüfung vor der Fakturafreigabe wächst diese Liste schneller, als sie abgearbeitet wird.

Die Regelversion hängt am Patch-Stand. Nach einem Wechsel der XRechnung-Version passen BT-24 und der geprüfte Regelsatz auseinander, bis der passende Stand eingespielt ist. Das ist der häufigste Grund, warum dieselbe Rechnung im KoSIT-Referenzvalidator durchgeht und im System nicht.

Steuerkennzeichen-Mapping. Die Zuordnung der SAP-Steuerkennzeichen auf EN-16931-Kategorien (S, Z, E, AE, K, O) ist Konfiguration, kein Standard. Fehler dort erzeugen genau die Aufschlüsselungsprobleme aus Abschnitt 3 – und fallen erst bei selteneren Kennzeichen auf: Reverse Charge nach § 13b, innergemeinschaftliche Lieferungen, durchlaufende Posten.

Exkurs: Warum ZUGFeRD aus SAP aufwendiger ist, als es klingt

Das eDocument-Framework ist XML-zentriert. ZUGFeRD ist aber kein Format, das eine Mapping-Komponente ausgibt – es ist ein PDF/A-3 mit eingebettetem XML, und das PDF kommt aus der Formularstrecke. Zwischen „gültiges CII-XML" und „gültiges ZUGFeRD" stehen vier Schritte, die keine der Komponenten von sich aus erledigt: PDF/A-3-Konformität, Dateiname factur-x.xml, /AFRelationship /Alternative plus /AF-Referenz, und XMP-Erweiterungsschema konsistent zur Profil-URN.

Weg	Was passiert	Wann sinnvoll
XRechnung statt ZUGFeRD	Reines XML, kein Container. Vollständig im Standard abbildbar.	Wenn die Empfänger es akzeptieren – im B2G ohnehin, im B2B mit großen Partnern meist verhandelbar.
Nachgelagerte Container-Erzeugung	XML aus dem ERP, PDF aus der Formularstrecke, ein Dienst dahinter baut den PDF/A-3-Container.	Wenn ZUGFeRD gefordert ist und viele Formularvarianten existieren.
Add-on im ERP-Stack	Partnerlösung übernimmt die Einbettung im System.	Wenn alles im ERP bleiben soll und eine weitere Lizenz- und Wartungslinie akzeptabel ist.

Variante A – aus XML-Daten plus Template. Liegt ein gültiges XML vor, braucht es kein bestehendes PDF. Aus den Rechnungsdaten und einem hinterlegten Template erzeugen wir Layout und PDF/A-3-Container in einem Schritt. Das Template wird einmal eingerichtet, danach ist jedes weitere ZUGFeRD ein API-Aufruf.

Variante B – JSON plus vorhandenes PDF. Rechnungsdaten als JSON zusammen mit dem bestehenden PDF übergeben. Wir erzeugen das konforme XML, prüfen es gegen das aktuelle Regelwerk und bauen den PDF/A-3-Container – inklusive Konvertierung, wenn das PDF die Anforderungen noch nicht erfüllt. Die Faktura bleibt unangetastet.

Einschränkung: Was im Standard mitkommt, hängt am Release- und Patch-Stand. Prüfen Sie es gegen die Dokumentation Ihres Releases, bevor Sie Aufwände schätzen.

Was in der Praxis am schnellsten wirkt: eine Validierung als API-Aufruf vor der Fakturafreigabe. Dann entsteht der fehlerhafte Beleg gar nicht erst. Die 25 Minuten, die ein fehlerhafter Vorgang im Schnitt kostet, entstehen fast vollständig nach der Buchung. Auf der Eingangsseite gehört zu jeder Validierung ein Rückkanal, der den Fehlercode in einen Korrekturhinweis in der Sprache des Lieferanten übersetzt.

Die Prüfreihenfolge, die Zeit spart

Wenn eine Rechnung abgelehnt wird, arbeiten Sie diese Reihenfolge ab – sortiert nach Häufigkeit, nicht nach Regelnummer:

Summen nachrechnen – BT-106, BT-109, BT-112, BT-117. Erst runden, dann summieren.
USt-IdNr. auf Präfix prüfen – beide Seiten, bei Reverse Charge zwingend auch der Käufer.
Steueraufschlüsselung – eine BG-23-Gruppe je Steuersatz, Befreiungsgrund nur bei E/AE/K/O, nie bei S/Z.
Bei ZUGFeRD: den PDF-Container prüfen, nicht nur das XML. PDF/A-3, Dateiname, AFRelationship, Profil-URN.
Kontaktgruppe – Name, Telefon, E-Mail, jeweils syntaktisch sauber.
BT-24 gegen die Zielversion halten.
B2G: Leitweg-ID vorhanden und inhaltlich richtig.
Codelisten – Währung, Einheit, Land, Zahlungsmittel.

Danach die inhaltliche Prüfung: Ist der Typ-Code richtig? Sind die Beträge positiv? Ist Skonto strukturiert? Und: Geht die Rechnung an eine Adresse, die jemand liest?

Mit rechnungsapi.de

Die Validierung lässt sich als API-Aufruf in den Rechnungsausgang einbauen, sodass keine fehlerhafte Rechnung das Haus verlässt. Ein POST mit dem XML oder der ZUGFeRD-PDF liefert das Prüfergebnis mit allen Regel-IDs, Schweregraden und betroffenen BT-Feldern zurück – gegen EN 16931, die deutschen Sonderregeln und, auf Wunsch, den Peppol-Regelsatz. Auf der Erzeugungsseite werden Modellierungsfehler abgefangen, bevor sie zu Belegen werden: negative Preise werden abgelehnt statt serialisiert, Typ-Code 381 erzeugt in UBL eine echte CreditNote, und Summen werden nach „erst runden, dann summieren" gebildet.

XRechnung Validator ZUGFeRD Validator API-Dokumentation

FAQ

Warum melden verschiedene Validatoren unterschiedliche Fehler?

Weil sie unterschiedliche Regelwerke und Versionen laden. Ein reiner EN-16931-Validator kennt keine BR-DE-Regeln, ein Peppol-Validator prüft zusätzlich die Netzregeln, und die KoSIT-Referenzimplementierung prüft gegen genau eine XRechnung-Version. Prüfen Sie gegen das Regelwerk, das Ihr Empfänger verwendet.

Mein XML ist valide, der Empfänger lehnt trotzdem ab. Warum?

Drei typische Gründe: Die Rechnung erfüllt die EN 16931, aber nicht die XRechnung-Zusatzregeln. Oder die Leitweg-ID ist formal vorhanden, aber inhaltlich falsch – das prüft kein Validator. Oder es ist ein ZUGFeRD, dessen PDF-Container nicht PDF/A-3-konform ist.

Ist eine Warnung ein Problem?

Technisch nein. Praktisch ja, sobald ein Rechnungseingangsportal strenger prüft als die Referenzimplementierung. Bei B2G sollten Sie Warnungen auflösen. Und BR-DE-18 (Skonto) ist eine Warnung mit direkten Zahlungsfolgen.

Darf eine Gutschrift negative Beträge enthalten?

Im Regelfall nein. Die Gutschrift ist eine eigenständige Forderung mit positiven Beträgen; die Richtung ergibt sich aus dem Typ-Code 381 in BT-3.

Kann SAP DRC ZUGFeRD erzeugen?

Das CII-XML ja. Der hybride Container – ein PDF/A-3 mit eingebettetem XML – entsteht nicht im eDocument-Framework, sondern in der Ausgabesteuerung. Die vier Schritte dazwischen (PDF/A-3-Konformität, Dateiname factur-x.xml, /AFRelationship /Alternative plus /AF-Referenz, XMP-Erweiterungsschema) sind Projektarbeit. Deshalb gehen die meisten großen Landschaften im Ausgang auf reines XRechnung-XML.

Erfüllt ZUGFeRD MINIMUM die E-Rechnungspflicht?

Nein. MINIMUM und BASIC WL enthalten keine Positionsdaten und sind damit keine strukturierte Rechnung im Sinne des § 14 UStG. Mindestens BASIC, besser das Profil EN 16931.

Wie vermeide ich Rundungsfehler bei den Summenregeln?

Erst runden, dann summieren. Jeden Positionsbetrag auf zwei Dezimalstellen runden, Summen aus diesen gerundeten Werten bilden, Steuersatz auf die Gruppensumme anwenden. Verbleibende Differenzen in BT-114.

Wir arbeiten mit Bruttopreisen. Ist das ein Problem?

Ja – aber ein lösbares. Die EN 16931 kennt nur Nettobeträge als Basis. Legen Sie die Brutto-Netto-Umrechnung einmal zentral fest, statt sie in jedem Exportpfad neu zu implementieren.

Weiterlesen

Storno, Gutschrift, Korrektur in XRechnung und ZUGFeRD

BT-3 richtig setzen – 380, 381, 384, 389.

Skonto in der E-Rechnung modellieren und auslesen

Strukturiertes Format, Parser-Logik und Sonderfälle.

Anzahlungsrechnung und Schlussrechnung

BT-113, drei Modellierungswege und Fallstricke.

Fehlende E-Mail-Adressen im Debitorenstamm

Aus 30.000 Stammsätzen werden wenige hundert Arbeitsfälle.

Rechtlicher Hinweis: Dieser Beitrag gibt den Stand vom 08.09.2026 wieder und ersetzt keine steuerliche Beratung. Quellen: EN 16931-1, XRechnung 3.0.2 (BR-DE-*), KoSIT Validator 1.5.x, Peppol BIS Billing 3.0, ZUGFeRD 2.4 / Factur-X 1.08, § 14 UStG.