XRechnung Fehlercodes sind standardisierte Validierungsregeln aus Schematron- und Business-Rule-Prüfungen, die anzeigen, dass eine elektronische Rechnung nicht den definierten Anforderungen der XRechnung-Spezifikation entspricht. Sie entstehen, wenn Pflichtfelder fehlen, Inhalte inkonsistent sind, nationale Geschäftsregeln verletzt werden oder technische Anforderungen nicht erfüllt sind. Im Kontext der E-Rechnung sind sie ein zentrales Signal für Datenqualität und Prozessreife.
Diese Fehlercodes wirken direkt auf Prozesse, Datenqualität und Governance in Finanz- und Verwaltungsabläufen. Werden Rechnungen aufgrund von Validierungsfehlern abgelehnt, verzögern sich Durchlaufzeiten, Skonto geht verloren, Lieferantenbeziehungen werden belastet und der Automatisierungsgrad sinkt. Für Unternehmen, die Purchase-to-Pay- oder Order-to-Cash-Prozesse digitalisieren, ist das systematische Verständnis und die Behebung von XRechnung Fehlercodes Voraussetzung für stabile, skalierbare E-Rechnungsverarbeitung.
XRechnung Fehlercodes sind keine Systemfehlermeldungen im klassischen Sinn, sondern standardisierte Validierungsregeln, die prüfen, ob eine elektronische Rechnung den Anforderungen der XRechnung-Spezifikation entspricht. Sie entstehen bei Schematron- und Business-Rule-Prüfungen, die sowohl syntaktische als auch semantische Anforderungen abdecken.
Typische Fehlercode-Präfixe zeigen die Herkunft der Regel: BR-DE-Codes stammen aus deutschen nationalen Geschäftsregeln, BR-Codes aus der europäischen Norm EN 16931, PEPPOL-EN16931-R-Codes aus PEPPOL-Regeln und UBL-Codes aus dem UBL-Schema. Diese Unterscheidung ist wichtig, weil XRechnung auf PEPPOL-BIS basiert, jedoch zusätzliche deutsche Anforderungen stellt.
Ein Fehlercode ist immer ein Symptom. Die eigentliche Ursache liegt häufig in Stammdaten, ERP-Mapping, Rundungslogik oder Prozessvarianten. Wenn etwa BR-DE-18 meldet, dass Skonto falsch formatiert ist, liegt das meist daran, dass das rechnungserstellende System Skonto als Freitext statt im standardisierten Segmentformat überträgt.
Syntaktische Fehler betreffen die XML-Struktur selbst: fehlende Pflichtfelder, falsche Datentypen, leere Tags. Semantische Fehler beziehen sich auf die inhaltliche Konsistenz: Summen stimmen nicht, Steuersätze passen nicht zur Kategorie, Datumsfelder sind logisch widersprüchlich. Nationale Zusatzregeln ergänzen die europäische Norm um deutsche Besonderheiten wie Leitweg-ID, Skonto-Format oder IBAN-Prüfungen bei SEPA-Zahlungen.
Darüber hinaus gibt es portal- und kanalspezifische Anforderungen. Ein und dieselbe Rechnung kann gegen die XRechnung-Spezifikation valide sein, aber an Upload-Restriktionen eines öffentlichen Portals scheitern, etwa weil Anlagen zu groß sind, Dateinamen Sonderzeichen enthalten oder die Leitweg-ID nicht korrekt formatiert ist.
Nur wenn eine Rechnung die Validierung besteht, kann sie automatisiert verarbeitet werden. Fehlercodes sind damit keine technische Nebensache, sondern Qualitätssignal für die gesamte Prozesskette von der Stammdatenpflege bis zur Dunkelverarbeitung. Wer XRechnung Fehlercodes systematisch behebt, reduziert manuelle Eingriffe, verkürzt Durchlaufzeiten und schafft Skalierbarkeit in der E-Rechnungsverarbeitung.
XRechnung Fehlercodes wirken direkt auf die operative Effizienz und strategische Handlungsfähigkeit von Unternehmen. Wenn Rechnungen abgelehnt werden, entstehen Verzögerungen in Purchase-to-Pay- und Order-to-Cash-Prozessen, Skonto verfällt, Liquiditätsplanung wird erschwert und manuelle Klärungsaufwände steigen.
Für öffentliche Auftraggeber in Deutschland ist die Annahme von XRechnungen seit 2020 verpflichtend. Rechnungen, die nicht validiert werden können, werden automatisch abgelehnt. Das bedeutet: Lieferanten müssen Fehler beheben, Rechnungen erneut einreichen und tragen das Risiko verspäteter Zahlung. Im B2B-Bereich steigt die Erwartung an strukturierte E-Rechnungen ebenfalls, da Empfänger zunehmend automatisierte Verarbeitung anstreben.
Fehlercodes sind nicht nur IT-Thema, sondern zeigen strukturelle Schwächen in Stammdaten, Mapping und Prozessen. Wenn etwa BR-CO-15 meldet, dass Brutto nicht gleich Netto plus Umsatzsteuer ist, liegt das meist an Rundungslogik oder fehlerhafter Berechnung im ERP. Wenn BR-DE-1 meldet, dass Zahlungsinformationen fehlen, obwohl Zahlungsbedingungen angegeben sind, fehlt ein konsistentes Mapping zwischen Belegfeldern und XRechnung-Struktur.
Aus Governance-Sicht sind validierte Rechnungen nachvollziehbar, auditfähig und dokumentieren belastbar die Datenherkunft. Unternehmen, die E-Rechnungsprozesse ohne systematische Fehlerprävention aufbauen, riskieren hohe laufende Aufwände, Eskalationen mit Geschäftspartnern und Verzögerungen bei der Transformation.
Hohe Validierungsquoten ermöglichen Dunkelverarbeitung, verkürzen Durchlaufzeiten und senken operative Kosten. Niedrige Validierungsquoten führen zu Prozessstau, manuellem Nacharbeiten und erschweren die Anbindung weiterer Lieferanten oder Kunden. Für Unternehmen, die viele Geschäftspartner digital anbinden wollen, ist eine stabile Fehlerquote Voraussetzung für Skalierung.
XRechnung Fehlercodes lassen sich nach Herkunft und Art der Prüfung einordnen. Diese Einordnung hilft, die Ursache schneller zu identifizieren und die richtigen Korrekturmaßnahmen zu treffen.
BR-DE-Codes stammen aus der XRechnung-Spezifikation und ergänzen die europäische Norm EN 16931 um deutsche Besonderheiten. Sie decken Themen ab wie Leitweg-ID, Skonto-Format, IBAN-Prüfungen bei SEPA-Zahlungen, Verkäuferkontaktdaten, Gutschriftsverfahren und Konsistenz zwischen Zahlungsmitteln und Zahlungsgruppen.
Typische Beispiele: BR-DE-1 verlangt Zahlungsanweisungen, wenn Zahlungsbedingungen angegeben sind. BR-DE-18 fordert Skonto in einem definierten Segmentformat. BR-DE-19 prüft, ob bei SEPA-Überweisung eine korrekte IBAN angegeben ist. BR-DE-21 verlangt Telefonnummer und E-Mail-Adresse im Verkäuferkontaktpunkt.
BR-Codes ohne DE-Zusatz stammen direkt aus der EN 16931 und gelten für alle EU-konformen E-Rechnungsformate. Sie prüfen grundlegende Konsistenzen: Summenberechnungen, Datumslogiken, Pflichtfelder in Positionen, negative Preise, Steuerkategorie-Codes.
Beispiele: BR-CO-15 prüft, ob Bruttosumme gleich Netto plus Umsatzsteuer ist. BR-25 fordert eine Artikelbezeichnung in jeder Position. BR-27 verbietet negative Nettopreise. BR-30 prüft, ob Enddatum eines Lieferzeitraums nach oder gleich dem Startdatum liegt.
PEPPOL-EN16931-R-Codes stammen aus PEPPOL-BIS Billing. XRechnung basiert auf PEPPOL-BIS, erweitert diese jedoch um deutsche Regeln. PEPPOL-Codes prüfen etwa, ob Basismengen größer Null sind, ob Nettopreis aus Bruttopreis minus Rabatt korrekt berechnet wurde oder ob Mengeneinheiten nach UN/ECE Recommendation 20 codiert sind.
Beispiel: PEPPOL-EN16931-R046 prüft, ob Nettopreis gleich Bruttopreis minus Rabatt ist, wenn Bruttopreis übermittelt wird. PEPPOL-EN16931-R121 fordert, dass die Preisbasis größer Null sein muss.
UBL-Codes und Schema-Validierungsfehler betreffen die XML-Struktur selbst. Sie entstehen, wenn etwa leere Tags übermittelt werden, nicht erlaubte Elemente verwendet werden oder Subpositionen in XRechnung auftreten, die das UBL-Profil nicht zulässt. Diese Fehler sind meist Mapping- oder Template-Fehler im rechnungserstellenden System.
Die folgende Tabelle ordnet typische Fehlerklassen nach Herkunft, Ursache und Behebungsstrategie ein.
| Fehlertyp | Herkunft | Typische Ursache | Behebung |
|---|---|---|---|
| BR-DE-Codes | Deutsche nationale Regeln | Leitweg-ID, Skonto, IBAN, Kontaktdaten | Stammdaten, Mapping, Prozessvorgaben |
| BR-Codes (EN 16931) | Europäische Geschäftsregeln | Summen, Steuern, Pflichtfelder | Berechnungslogik, Mapping |
| PEPPOL-Codes | PEPPOL-BIS Billing | Mengen, Preise, Einheiten | Mapping, Einheitencodierung |
| UBL-/Schema-Fehler | XML-Struktur | Leere Tags, nicht erlaubte Elemente | Template-Anpassung, Mapping-Review |
| Portal-Restriktionen | Einreichkanal | Dateigröße, Anlagenformate, Dateinamen | Versand-Gate, technische Vorprüfung |
Diese Einordnung zeigt: Fehler entstehen auf unterschiedlichen Ebenen und erfordern unterschiedliche Korrekturstrategien. Während syntaktische Fehler meist durch Template-Anpassung behoben werden, erfordern semantische Fehler Eingriffe in Stammdaten, Berechnungslogik oder Prozessvorgaben.
Ein strukturiertes Vorgehen reduziert Aufwand, beschleunigt Fehlerkorrektur und verhindert Wiederholfehler. Die folgenden Schritte haben sich in der Praxis bewährt.
Klären Sie, über welchen Kanal die Rechnung eingereicht wird: Portal-Upload, E-Mail, PEPPOL-Netzwerk, EDI-Schnittstelle. Jeder Kanal kann eigene Zusatzanforderungen haben, etwa Dateigröße, Anlagenformate, Dateinamenkonventionen oder Registrierungsvorgaben.
Stellen Sie sicher, dass Sie den Validierungsbericht erhalten. Dieser wird meist per E-Mail zugestellt, liegt als Laufzettel bei oder wird im Portal bereitgestellt. Legen Sie Validierungsberichte zentral ab, damit Fehleranalyse nachvollziehbar ist und Wiederholfehler vermieden werden.
Priorisieren Sie Fehler nach Schwere: Zuerst Pflichtfeld-Fehler (Blocker), dann Konsistenz- und Berechnungsfehler, dann Empfehlungen. Pflichtfeld-Fehler führen immer zur Ablehnung. Konsistenzfehler können je nach Kanal toleriert oder abgelehnt werden. Empfehlungen beeinflussen Qualität und Risiko für Folgeprozesse.
Identifizieren Sie die Datenquelle: Stammdaten (Lieferant, Kunde), Bewegungsdaten (Auftrag, Position), Mapping zwischen ERP und E-Invoicing-Format, Rundungs- oder Steuerlogik. Nutzen Sie BT- und BG-Referenzen im Validierungsbericht, um das betroffene Feld im Datenmodell zu finden.
Setzen Sie die Korrektur um: Stammdaten ergänzen, Mapping anpassen, Berechnungslogik korrigieren. Testen Sie die korrigierte Rechnung gegen einen Validator, etwa den KOSIT-Validator, bevor Sie sie erneut einreichen. So vermeiden Sie erneute Ablehnungen.
Definieren Sie eine Maßnahme, die verhindert, dass der Fehler erneut auftritt: Validierungs-Gate vor Versand, Stammdatenregeln im ERP, Monitoring wiederkehrender Fehlertypen, Schulung operativer Teams.
Die folgenden Fehler treten in der Praxis besonders häufig auf. Für jeden Fehler werden Bedeutung, Ursache und Behebung konkret beschrieben.
Wenn Sie Zahlungsbedingungen (BT-20) angeben, müssen Sie auch Zahlungsanweisungen (BG-16) bereitstellen. Typische Ursache: ERP füllt Zahlungsbedingungen als Freitext, überträgt aber keine strukturierte Zahlungsgruppe. Behebung: Zahlungsmittel (BT-81) angeben und entsprechende Zahlungsgruppe (BG-17, BG-18 oder BG-19) befüllen.
Der Verkäuferkontaktpunkt (BG-6) muss einen Personennamen (BT-41) und eine E-Mail-Adresse (BT-43) enthalten. Telefonnummer (BT-42) sollte mindestens drei Ziffern haben. Typische Ursache: Stammdaten enthalten keine Kontaktdaten oder nur Firmennamen. Behebung: Stammdaten ergänzen, mindestens Abteilungsname und E-Mail-Adresse hinterlegen.
Wenn ein Zahlungsmittel (BT-81) angegeben wird, müssen Zahlungsbedingungen (BT-20) vorhanden sein. Behebung: Zahlungsbedingungen-Text einfügen, der beschreibt, wann die Zahlung fällig ist.
Wenn Lieferinformationen angegeben werden, muss der Lieferempfängername (BT-70) vorhanden sein. Behebung: Namen ergänzen oder gesamte Lieferadressgruppe entfernen, wenn nicht benötigt.
Gutschriften (Invoice type code 381) müssen auf die ursprüngliche Rechnung verweisen (BT-25). Behebung: Ursprüngliche Rechnungsnummer im Feld Preceding invoice reference eintragen.
Unter Verwendung des Standards XRechnung können Gutschriften gemäß Paragraph 14 Absatz 2 Satz 2 UStG übermittelt werden, das heißt, der Leistungsempfänger erstellt die Abrechnung. Dies ist deutlich von kaufmännischen Gutschriften und Rechnungsberichtigungen zu unterscheiden. Das semantische Datenmodell der XRechnung sieht den Invoice type code (BT-3) zur eindeutigen Identifizierung vor. Code 389 kennzeichnet eine Self-billed invoice.
Skonto muss in Payment terms (BT-20) in einem definierten Segmentformat übertragen werden. Segmente: SKONTO, TAGE=n, PROZENT=n, optional BASISBETRAG=n. Trennung über #, jeder Eintrag beginnt und endet mit #, Abschluss mit XML-konformem Zeilenumbruch. Großbuchstaben, kein Whitespace, keine anderen Zeichen. Typische Ursache: Skonto wird als Freitext angegeben. Behebung: Mapping so anpassen, dass Skonto im definierten Format geschrieben wird.
Payment account identifier (BT-84) soll korrekte IBAN enthalten, wenn Payment means type code (BT-81) Code 58 (SEPA-Überweisung) ist. Debited account identifier (BT-91) soll korrekte IBAN enthalten, wenn Code 59 (SEPA-Lastschrift) verwendet wird. Behebung: IBAN-Format prüfen, Ländercode und Prüfziffer korrekt angeben.
Das Element Specification identifier (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. Für aktuelle XRechnung-Versionen: urn:cen.eu:en16931:2017#compliant#urn:xrechnung:3.0. Behebung: Kennung korrekt setzen, keine Vermischung mit ZUGFeRD-Kennungen.
Wenn Payment means type code (BT-81) einen Schlüssel für Überweisungen enthält (30, 58), muss CREDIT TRANSFER (BG-17) übermittelt werden. PAYMENT CARD INFORMATION (BG-18) und DIRECT DEBIT (BG-19) dürfen nicht da sein. Bei Kartenzahlungen (48, 54, 55) muss genau BG-18 da sein. Bei Lastschriften (59) muss genau BG-19 da sein. Behebung: Mapping zwischen Zahlungsmittel und Zahlungsgruppen konsistent gestalten.
Wenn Invoice type code (BT-3) 384 (Corrected invoice) ist, soll PRECEDING INVOICE REFERENCE (BG-3) mindestens einmal vorhanden sein. Behebung: Referenz auf korrigierte Rechnung eintragen.
Seller contact telephone number (BT-42) soll mindestens drei Ziffern enthalten. Seller contact email address (BT-43) soll gültige E-Mail-Adresse sein. Behebung: Stammdaten prüfen, Telefonnummer und E-Mail-Adresse korrekt befüllen.
Bank assigned creditor identifier (BT-90) und Debited account identifier (BT-91) müssen übermittelt werden, wenn DIRECT DEBIT (BG-19) vorhanden ist. Behebung: Gläubiger-ID und IBAN des belasteten Kontos eintragen.
Jede Rechnungsposition (BG-25) muss eine Artikelbezeichnung (BT-153) enthalten. Typische Ursache: Position ohne Beschreibung angelegt. Behebung: Artikelbezeichnung ergänzen.
Item net price (BT-146) darf nicht negativ sein. Um negative Beträge zu erzeugen, negative Menge angeben oder Rechnungskorrektur verwenden. Behebung: Preis positiv setzen, Menge negativ oder Invoice type code 384 verwenden.
Seller VAT identifier (BT-31), Seller tax representative VAT identifier (BT-63) und Buyer VAT identifier (BT-48) müssen Länderpräfix nach ISO 3166-1 alpha-2 enthalten. Beispiel: DE123456789. Behebung: Ländercode ergänzen.
Mengeneinheit muss nach UN/ECE Recommendation 20 with Rec 21 extension codiert sein. Beispiele: kg, km. Behebung: Einheitencode aus Codeliste wählen, kein Freitext.
Invoice total amount with VAT (BT-112) muss gleich Invoice total amount without VAT (BT-109) plus Invoice total VAT amount (BT-110) sein. Typische Ursache: Rundungsfehler. Behebung: Rundungslogik prüfen, zentrale Berechnungsengine verwenden.
Wenn Start- und Enddatum des Abrechnungszeitraums einer Rechnungsposition angegeben sind, muss Enddatum (BT-135) nach oder gleich Startdatum (BT-134) sein. Behebung: Datumsfelder prüfen, Logik korrigieren.
Item net price (BT-146) muss Item gross price (BT-148) minus Item price discount (BT-147) entsprechen, wenn Bruttopreis übermittelt wird. Behebung: Berechnung korrigieren.
Item price base quantity (BT-149) muss positive Zahl größer Null sein. Behebung: Basismengenfeld prüfen, positiven Wert eintragen.
Leitweg-ID ist Routing-Identifikator für öffentliche Auftraggeber. Typische Fehler: Zahlendreher, falsche Länge, Leerzeichen, Sonderzeichen, falscher Bindestrich durch Copy/Paste ohne UTF-8. Behebung: Leitweg-ID vom Auftraggeber besorgen, exakt übernehmen, Zeichensatz UTF-8 verwenden.
Registrierung nicht abgeschlossen: alle Registrierungsschritte prüfen. Format nicht akzeptiert: XRechnung-XML oder ZUGFeRD-PDF im Profil XRechnung verwenden. Veraltete XRechnung-Fassung: führt zu Meldung unbekanntes Dateiformat. Größenbeschränkungen: maximal 20 MB Gesamtgröße inklusive Anlagen (auch Base64 eingebettet). Sehr viele Rechnungspositionen: Aufteilung in Teilrechnungen oder alternativer Einreichweg. Anlagenformate beschränkt: PDF, PNG, JPG, JPEG, CSV, XLSX, ODS, XML (nur bei Extension). Dateinamenanforderungen: keine identischen Namen zwischen beigefügten und eingebetteten Anlagen, erlaubte Zeichen (kein @), Maximallänge 25 Zeichen, eindeutige Dateinamen (nicht case-sensitiv). Verbot referenzierter Anlagen-Links: Links entfernen. E-Mail-Einreichung: Absendeadresse muss mit hinterlegter ZRE-E-Mail-Adresse übereinstimmen, No-Reply/Bounce-Problematik berücksichtigen. Digitale Signatur: nur qualifizierte elektronische Signatur (QES), eIDAS-konform, Container-Signaturen können Probleme machen.
Wenn Deliver-to-Address-Gruppe (BG-15) vorhanden ist, müssen Deliver to city (BT-77) und Deliver to post code (BT-78) übermittelt werden. BT-78 muss eine Postleitzahl sein. Typische Ursache: Lieferadresse nur teilweise befüllt. Behebung: Stadt und Postleitzahl ergänzen oder gesamte Gruppe entfernen.
Wenn Steuercodes S, Z, E, AE, K, G, L oder M verwendet werden, muss mindestens Seller VAT identifier (BT-31), Seller tax registration identifier (BT-32) oder SELLER TAX REPRESENTATIVE PARTY (BG-11) vorhanden sein. Behebung: Umsatzsteuer-Identifikationsnummer oder Steuernummer eintragen.
Mit Invoice type code (BT-3) sollen folgende Codes aus Codeliste UNTDID 1001 übermittelt werden: 326 Partial invoice, 380 Commercial invoice, 384 Corrected invoice, 389 Self-billed invoice, 381 Credit note, 875 Partial construction invoice, 876 Partial final construction invoice, 877 Final construction invoice. Behebung: Korrekten Code für Dokumenttyp wählen.
In einer eingereichten Rechnung angehängte Dokumente in ADDITIONAL SUPPORTING DOCUMENTS (BG-24) müssen im Element Attached document (BT-125) einen eindeutigen Dateinamen haben (nicht case-sensitiv). Behebung: Dateinamen eindeutig gestalten, keine Duplikate.
Nicht alle Fehler sind gleich kritisch. Die folgende Tabelle hilft, Fehler nach Priorität und Aufwand zu bewerten.
| Fehlertyp | Priorität | Aufwand | Empfohlene Maßnahme |
|---|---|---|---|
| Pflichtfeld fehlt | Hoch (Blocker) | Niedrig bis mittel | Stammdaten ergänzen, Mapping anpassen |
| Summen/Steuern inkonsistent | Hoch | Mittel | Berechnungslogik prüfen, Rundungsregeln definieren |
| Format-/Codierungsfehler | Mittel | Niedrig | Mapping korrigieren, Codelisten nutzen |
| Empfehlungen (SHOULD) | Niedrig | Niedrig | Langfristig beheben, Qualität steigern |
| Portal-spezifisch | Hoch (kanalabhängig) | Niedrig | Technische Vorprüfung, Versand-Gate |
Priorisieren Sie zuerst Blocker, die zur sofortigen Ablehnung führen. Dann Konsistenzfehler, die Automatisierung verhindern. Empfehlungen können langfristig behoben werden, sollten aber nicht ignoriert werden, da sie Risiko für Folgeprozesse bergen.
Eine gute Fehlerprävention zeichnet sich durch strukturierte Prozesse, klare Verantwortlichkeiten und proaktive Maßnahmen aus. Die folgenden Merkmale sind typisch für Unternehmen, die XRechnung Fehlercodes nachhaltig minimieren.
Stammdaten sind Grundlage valider Rechnungen. Gute Stammdaten-Governance bedeutet: Pflichtfelder im ERP definiert, Validierungsregeln aktiv, klare Verantwortlichkeiten für Datenpflege, regelmäßige Datenqualitätschecks. Wenn Umsatzsteuer-Identifikationsnummer, IBAN, Kontaktdaten und Lieferadressen sauber gepflegt sind, sinkt die Fehlerquote deutlich.
Jedes ERP-zu-XRechnung-Mapping sollte dokumentiert sein: Welches ERP-Feld befüllt welches BT-/BG-Element, welche Ableitungsregeln gelten, welche Bedingungen führen zu welcher Struktur. Testfälle pro Dokumenttyp, Steuerszenario und Prozessvariante stellen sicher, dass Änderungen keine Regressionsfehler verursachen.
Pre-Validation vor Versand verhindert, dass fehlerhafte Rechnungen überhaupt beim Empfänger ankommen. Der KOSIT-Validator kann in QS- oder CI-Pipelines integriert werden. Rechnungen, die nicht validieren, werden nicht versendet, sondern gehen zurück an den Ersteller.
Laufendes Monitoring zeigt Fehlerquoten, Fehlertypen und Trends. Wiederkehrende Fehler deuten auf strukturelle Probleme hin. Fehleranalyse sollte nicht nur einzelne Rechnungen betrachten, sondern Muster identifizieren: Welche Lieferanten, welche Belegarten, welche Steuerszenarien verursachen häufig Fehler?
XRechnung-Versionen ändern sich, nationale Geschäftsregeln werden angepasst, Portale aktualisieren Anforderungen. Gutes Release-Management bedeutet: Versionswechsel geplant, Regressionstests durchgeführt, Stakeholder informiert, Mapping rechtzeitig angepasst.
Operative Teams müssen wissen, wie sie Skonto, Lieferadressen, Zahlungsmittel und Anlagen korrekt erfassen. Schulung reduziert Eingabefehler, klare Prozessvorgaben reduzieren Prozessvarianz. Change-Management stellt sicher, dass Mapping-Änderungen koordiniert und getestet werden.
Nutzen Sie die folgende Checkliste, um systematisch zu prüfen, ob Ihre Rechnungen validierungsbereit sind.
Der KOSIT-Validator ist Deutschlands offizielles Tool zur Validierung elektronischer Rechnungen in XRechnung- und ZUGFeRD-Formaten. Er prüft, ob eine Rechnung den nationalen Geschäftsregeln und der EN 16931 entspricht. Rechnungen scheitern meist an fehlenden Pflichtfeldern, inkonsistenten Summen, falschen Formaten oder Mapping-Fehlern.
Nutzen Sie den KOSIT-Validator oder andere konforme Validatoren. Laden Sie Ihre XML-Datei hoch und prüfen Sie den Validierungsbericht. Beheben Sie zuerst Pflichtfeld-Fehler, dann Berechnungs- und Formatprobleme.
BR-DE-1 verlangt Zahlungsanweisungen (BG-16), wenn Zahlungsbedingungen (BT-20) angegeben sind. Behebung: Zahlungsmittel (BT-81) angeben und entsprechende Zahlungsgruppe (BG-17, BG-18 oder BG-19) befüllen.
Pflichtfelder umfassen: Rechnungsnummer, Ausstellungsdatum, Verkäuferdetails, Käuferdetails, Steuerinformationen (Umsatzsteuer-Identifikationsnummer oder Steuernummer), Positionen mit Artikelbezeichnung, Summen (Netto, Umsatzsteuer, Brutto) konsistent. B2G zusätzlich: Leitweg-ID.
XRechnung ist reines maschinenlesbares XML (UBL) mit deutschen Zusatzregeln. ZUGFeRD im Profil XRechnung ist PDF/A-3 mit eingebettetem XML nach XRechnung-Profil. Entscheidend ist das XML, nicht die PDF. Portale extrahieren das XML und verarbeiten nur dieses.
Nicht valide bedeutet: Rechnung verstößt gegen Spezifikation oder CIUS, wird technisch abgelehnt. Das heißt nicht zwingend ungültig im Sinne des Umsatzsteuergesetzes. Aber: Validität ist Voraussetzung für Automatisierung, Durchlaufzeit und Dunkelverarbeitung.
Portal-spezifische Restriktionen: Dateigröße, Anlagenformate, Dateinamen, Leitweg-ID-Format, veraltete XRechnung-Fassung, E-Mail-Absendeadresse stimmt nicht mit hinterlegter ZRE-E-Mail-Adresse überein, digitale Signatur nicht QES-konform.
Die Leitweg-ID ist ein Routing-Identifikator für öffentliche Auftraggeber in Deutschland. Sie erhalten sie ausschließlich von Ihrem Auftraggeber. Achten Sie auf korrektes Format, keine Leerzeichen, keine Sonderzeichen, Zeichensatz UTF-8.
Skonto muss in Payment terms (BT-20) im Segmentformat übertragen werden: #SKONTO#TAGE=n#PROZENT=n#, optional #BASISBETRAG=n#. Großbuchstaben, kein Whitespace, Abschluss mit XML-konformem Zeilenumbruch. Typische Ursache für Fehler: Freitext statt Segmentformat.
BT-Nummern sind semantische Business Terms aus EN 16931 und XRechnung. Wenn ein Validierungsbericht ein BT-Feld referenziert, identifizieren Sie im ERP-Mapping die Quelle: Stammdatum, Belegfeld oder Ableitung. Mapping-Dokumentation hilft, schnell die Datenquelle zu finden.
BR-27 verbietet negative Nettopreise (BT-146). Um negative Beträge zu erzeugen, verwenden Sie negative Menge oder eine Rechnungskorrektur (Invoice type code 384). So bleibt die Preislogik konsistent.
XRechnung Fehlercodes sind systematische Validierungsregeln, die Datenqualität, Prozessstabilität und Automatisierungsfähigkeit in der E-Rechnungsverarbeitung sicherstellen. Ein strukturiertes Vorgehen bei der Fehleranalyse, klare Verantwortlichkeiten für Stammdaten und Mapping sowie proaktive Validierungs-Gates reduzieren Ablehnungen, verkürzen Durchlaufzeiten und schaffen die Grundlage für skalierbare Purchase-to-Pay- und Order-to-Cash-Prozesse.