XRechnung Fehlercodes: BR-DE, BR-CO und KoSIT-Fehler beheben

XRechnung Fehlercodes beheben: BR-DE, BR-CO und KoSIT-Fehler verständlich erklärt

Eine XRechnung kann inhaltlich richtig aussehen und trotzdem technisch abgelehnt werden. Der Grund liegt fast immer in den Prüfregeln hinter der E-Rechnung: EN 16931, XRechnung, UBL, CII, Peppol-Regeln und die deutschen BR-DE-Geschäftsregeln prüfen nicht das Layout Ihrer Rechnung, sondern die strukturierten XML-Daten.

Typische Meldungen lauten zum Beispiel:

• BR-DE-15: Buyer reference fehlt
• BR-CO-17: Steuerbetrag passt rechnerisch nicht zur Bemessungsgrundlage
• BR-DE-16: Verkäufer-Steuerkennung fehlt oder ist falsch
• BR-DE-18: Skonto oder Zahlungsbedingungen sind formal falsch aufgebaut
• BR-DE-19: IBAN bei SEPA-Zahlung ist ungültig
• BR-DE-21: falscher Specification Identifier, also falsches XRechnung-Profil

Dieser Guide zeigt, was diese XRechnung Fehlercodes bedeuten, wie Sie die Ursache finden und wie Sie Ihre Rechnung vor dem Versand sauber validieren. Wenn Sie direkt prüfen möchten, laden Sie Ihre Datei im E-Rechnung Validator hoch.

Kurz erklärt: Warum XRechnung Fehlercodes entstehen

Eine klassische PDF-Rechnung kann ein Mensch lesen. Eine XRechnung muss zusätzlich maschinell eindeutig sein. Deshalb reicht es nicht, dass Rechnungsnummer, Betrag, Steuer und IBAN irgendwo sichtbar sind. Die Daten müssen im richtigen Feld, im richtigen Format und in der richtigen fachlichen Logik stehen.

XRechnung basiert auf der europäischen Norm EN 16931. Für die technische XML-Umsetzung werden vor allem UBL und UN/CEFACT CII genutzt. Die deutsche XRechnung ist eine sogenannte CIUS, also eine nationale Konkretisierung der europäischen E-Rechnungsnorm. Die Prüfregeln werden unter anderem über Schematron-Regeln und Validator-Konfigurationen umgesetzt.

Offizielle Grundlagen finden Sie unter anderem hier:

• Bundesfinanzministerium: FAQ zur verpflichtenden E-Rechnung
• E-Rechnung Bund: E-Rechnung zwischen Unternehmen B2B
• XStandards Einkauf: Standard XRechnung und technische Komponenten
• Peppol: Peppol BIS Billing 3.0

Wichtig: Seit dem 1. Januar 2025 ist eine einfache PDF-Rechnung im B2B-Kontext keine strukturierte E-Rechnung mehr, sondern eine sonstige Rechnung. Eine echte E-Rechnung muss in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen werden und elektronische Verarbeitung ermöglichen.

Was bedeuten BR-DE, BR-CO, BR-CL und Peppol-Fehler?

Bei einer KoSIT-Validierung oder einer Prüfung gegen XRechnung-Regeln tauchen verschiedene Fehlerpräfixe auf. Die wichtigsten Gruppen sind:

Ein fatal oder error bedeutet in der Praxis: Die E-Rechnung ist technisch nicht valide und wird oft nicht angenommen. Eine Warnung kann je nach Empfänger trotzdem durchgehen, sollte aber nicht ignoriert werden. Viele Rechnungseingangsportale und Empfänger verschärfen Prüfungen mit der Zeit.

Schnellübersicht: Häufige XRechnung Fehlercodes und Lösungen

1. BR-DE-15: Buyer reference, Leitweg-ID oder Empfängerreferenz fehlt

BR-DE-15 ist einer der häufigsten XRechnung Fehlercodes. Die Meldung bedeutet, dass das Feld Buyer reference fehlt. In der XRechnung ist das der Business Term BT-10.

Bei Rechnungen an öffentliche Auftraggeber ist dort häufig die Leitweg-ID einzutragen. Die Leitweg-ID sorgt dafür, dass eine XRechnung beim Bund, bei Ländern, Kommunen oder anderen öffentlichen Stellen richtig zugeordnet werden kann. Ohne diese Referenz kann die Rechnung über ZRE, OZG-RE oder andere Portale abgelehnt werden.

Bei B2B-Rechnungen kann der Empfänger an dieser Stelle ebenfalls eine Referenz erwarten, zum Beispiel eine Bestellnummer, Projektnummer, Kostenstelle oder interne Freigabereferenz.

Typische Ursachen

• Leitweg-ID wurde beim Kunden nicht gepflegt
• BT-10 ist leer
• Bestellnummer wurde nur im PDF-Layout angezeigt, aber nicht in XML übertragen
• ERP-System exportiert die Referenz in das falsche Feld
• PDF-zu-XML-Konverter hat die Referenz nicht erkannt
• mehrere Kundenstandorte nutzen unterschiedliche Leitweg-IDs

So beheben Sie BR-DE-15

1. Prüfen Sie, ob der Empfänger eine Leitweg-ID oder andere Buyer Reference verlangt.
2. Tragen Sie diese Referenz in das Feld BT-10 ein.
3. Speichern Sie die Referenz dauerhaft im Kundenstamm.
4. Validieren Sie die XML-Datei erneut vor dem Versand.
5. Bei öffentlichen Auftraggebern: Stimmen Sie die Leitweg-ID mit der Vergabestelle oder Rechnungsstelle ab.

Wenn Sie die XRechnung manuell erstellen, können Sie die Referenz im XRechnung Generator eintragen. Wenn Sie bestehende PDFs oder ERP-Ausgaben verarbeiten, nutzen Sie den PDF zu XRechnung Konverter oder richten Sie bei wiederkehrenden Fällen ein Enterprise-Mapping ein.

Mehr Hintergrund finden Sie im Beitrag zur Leitweg-ID Beschaffung und Modulo-97.

2. BR-CO-17: Steuerbetrag passt rechnerisch nicht

BR-CO-17 ist ein Kernfehler aus den europäischen Geschäftsregeln. Die Regel prüft, ob der Steuerbetrag einer Steuerkategorie rechnerisch zur steuerpflichtigen Bemessungsgrundlage und zum Steuersatz passt.

Vereinfacht gesagt:

text
Steuerbetrag = steuerpflichtiger Betrag × Steuersatz / 100

Das Ergebnis muss sauber auf zwei Dezimalstellen gerundet werden. Schon ein Cent Differenz kann zur Ablehnung führen.

Typische Ursachen

* ERP-System rundet erst auf Belegebene statt positionsweise
* Rabatte oder Zuschläge werden im PDF anders gerechnet als im XML
* Excel-Importe enthalten mehr Nachkommastellen als sichtbar
* Netto- und Bruttowerte wurden gemischt
* verschiedene Steuersätze wurden nicht sauber getrennt
* Skonto oder Anzahlungen beeinflussen falsche Summenfelder
* manuelle Nachbearbeitung hat nur das PDF geändert, nicht die XML-Daten

So beheben Sie BR-CO-17

Prüfen Sie zuerst die Steueraufteilung nach Steuersatz. Eine Rechnung mit 19 % und 7 % Umsatzsteuer braucht getrennte Steuerbasen und Steuerbeträge. Danach vergleichen Sie Positionsnetto, Rabatte, Zuschläge, Steuerbasis, Steuerbetrag und Gesamtsumme.

Wenn die Rechnung aus einem ERP-System kommt, sollte nicht nur das sichtbare PDF korrekt sein. Die exportierten XML-Felder müssen dieselbe Rundungslogik verwenden. Gerade bei E-Rechnungen aus ERP-Systemen, Excel-Konvertierungen oder individuellen APIs lohnt sich eine vorgelagerte Validierung.

Für individuelle Datenflüsse, eigene Rundungslogiken, gemischte Steuersätze oder automatische Konvertierung können Sie ein Enterprise-Mapping einrichten lassen. Details finden Sie in unserem Beitrag zur XRechnung API-Anbindung, Architektur, Felder und Validierung.

3. BR-DE-16: Verkäufer-Steuerkennung fehlt

BR-DE-16 betrifft die steuerliche Identifikation des Verkäufers. Je nach Fall muss mindestens eine passende steuerliche Kennung vorhanden sein, zum Beispiel:

* BT-31: Seller VAT identifier, also Umsatzsteuer-Identifikationsnummer
* BT-32: Seller tax registration identifier, also steuerliche Registrierungsnummer
* BG-11: Seller tax representative party, falls ein Steuervertreter relevant ist

Typische Ursachen

* USt-IdNr. fehlt in den Unternehmensstammdaten
* Steuernummer ist nur im PDF-Footer sichtbar, aber nicht im XML
* falsches Format oder Platzhalterwert wurde exportiert
* mehrere Firmenprofile wurden im ERP vermischt
* Reverse-Charge-Fall ohne saubere Steuerkennungen
* ausländischer Verkäufer oder Steuervertreter wurde nicht korrekt modelliert

So beheben Sie BR-DE-16

Prüfen Sie zuerst die Verkäufer-Stammdaten in Ihrer Rechnungssoftware, zum Beispiel in Lexware, SAP, sevDesk, lexoffice, DATEV-nahen Systemen oder Ihrem ERP. Die Steuerkennung muss nicht nur im Rechnungsdesign stehen, sondern im richtigen XML-Feld landen.

Achten Sie besonders auf diese Punkte:

* keine Platzhalter wie VAT, DE000000000 oder 123
* keine reine Freitextangabe außerhalb der strukturierten Felder
* USt-IdNr. mit korrektem Länderkürzel, falls genutzt
* Steuernummer im zulässigen Format des Systems
* bei Reverse Charge zusätzlich Käufer-USt-IdNr. und korrekte Steuerkategorie prüfen

Hilfreiche Vertiefungen finden Sie in unseren Guides zu SAP XRechnung Setup, Pflichtfeldern und Fehlern sowie sevDesk XRechnung Erstellung, Export und Validierung.

4. BR-DE-18: Skonto und Zahlungsbedingungen sind falsch formatiert

BR-DE-18 ist besonders tückisch, weil die Zahlungsbedingung für Menschen oft verständlich aussieht, aber maschinell nicht regelkonform ist. Viele Systeme schreiben zum Beispiel:

text
2 % Skonto bei Zahlung innerhalb von 10 Tagen, sonst 30 Tage netto

Für XRechnung reicht so ein Freitext je nach Regelwerk und Empfänger nicht aus. Skontoangaben müssen in der strukturierten Logik korrekt und eindeutig maschinenlesbar angegeben werden.

Typische Ursachen

* Skonto steht als beliebiger Freitext in BT-20
* Skonto und Verzugszinsen werden vermischt
* Prozentzeichen, Leerzeichen oder Textbausteine passen nicht zur erwarteten Syntax
* ERP-System nutzt eigene Zahlungsbedingungs-Codes
* Skonto wird im PDF gezeigt, aber im XML unvollständig abgebildet
* mehrere Zahlungsziele werden in einem unsauberen Satz kombiniert

So beheben Sie BR-DE-18

Trennen Sie normale Zahlungsbedingungen von strukturierten Skontoangaben. Prüfen Sie, ob Ihr System Skonto nach den Vorgaben des Zielprofils ausgibt. Wenn nicht, sollten Sie die Zahlungsbedingungen vereinfachen oder das Mapping anpassen.

Bei wiederkehrenden Rechnungen mit Skonto, Teilzahlungen, Anzahlungen, Schlussrechnungen oder komplexer Zahlungslogik ist eine manuelle Korrektur oft keine stabile Lösung. Hier ist Enterprise sinnvoll: RechneX kann individuelle Regeln für Zahlungsbedingungen, Fälligkeiten, Skonto, Abschläge, Schlussbeträge und Empfängeranforderungen in einem geprüften Prozess abbilden.

5. BR-DE-19 und BR-DE-20: IBAN oder Zahlungsdaten sind ungültig

Bei SEPA-Zahlungen prüft XRechnung die Zahlungsdaten streng. BR-DE-19 betrifft typischerweise die Zahlungskonto-Kennung BT-84, wenn ein SEPA-Überweisungs-Code genutzt wird. BR-DE-20 betrifft Lastschriftfälle und das belastete Konto.

Typische Ursachen

* IBAN enthält Leerzeichen, Sonderzeichen oder Tippfehler
* Payment Means Code passt nicht zur Zahlungsart
* IBAN steht nur im PDF, aber nicht in BT-84
* Kontoinhaber und Zahlungsempfänger passen nicht zum Prozess
* Factoring oder Forderungsabtretung wurde nicht sauber modelliert
* bei Lastschrift fehlen Mandats- oder Kontoangaben

So beheben Sie Zahlungsdaten-Fehler

Prüfen Sie zuerst die Zahlungsart. Für Überweisung, SEPA-Überweisung, Kreditkarte, Lastschrift oder bereits bezahlte Rechnungen gelten unterschiedliche Felder und Codes. Danach prüfen Sie IBAN, Kontoname, Zahlungsempfänger und Zahlungsbedingungen.

Besonders wichtig ist das bei Factoring und Forderungsabtretung: Wenn die Zahlung nicht an den Rechnungsteller, sondern an einen Factor oder abgetretenen Zahlungsempfänger gehen soll, müssen sichtbarer Rechnungstext, IBAN, Kontoname und XML-Felder zusammenpassen. Solche Fälle sollten nicht über Freitext gelöst werden.

Für wiederkehrende Factoring-Fälle, individuelle Zahlungsempfänger, Empfängerlogik oder Forderungsabtretung ist der Enterprise-Workflow geeignet. Dort können Zahlungsregeln, IBAN-Match-Prüfungen, Abtretungshinweise und Ausgabeformate abgestimmt werden.

6. BR-DE-21: Falscher Specification Identifier

BR-DE-21 bedeutet, dass die Profilkennung in BT-24 nicht zur erwarteten XRechnung passt. Das Feld sagt dem Empfänger, nach welchem Regelwerk die Datei erstellt wurde.

Typische Ursachen

* ZUGFeRD-Profil statt XRechnung exportiert
* falsche XRechnung-Version im ERP eingestellt
* Peppol BIS statt XRechnung-Profil verwendet
* alte Software erzeugt noch veraltete Profilkennungen
* XML wurde nachträglich verändert
* UBL/CII-Datei ist formal XML, aber nicht XRechnung-konform

So beheben Sie BR-DE-21

Stellen Sie im Exportdialog Ihrer Rechnungssoftware das korrekte Zielprofil ein. Wenn der Empfänger XRechnung verlangt, reicht ein beliebiges EN-16931-XML nicht immer aus. Der Specification Identifier muss zur XRechnung-Konfiguration passen.

Wenn Sie stattdessen ein hybrides PDF mit eingebetteter XML benötigen, kann ZUGFeRD passend sein. Für reine XRechnung-Anforderungen, vor allem im B2G-Umfeld, ist jedoch meistens eine XRechnung XML-Datei erforderlich. Mehr zu Profilen finden Sie im Glossar zu Peppol, KoSIT, EN 16931 und CIUS.

7. BR-DE-5 bis BR-DE-7: Verkäuferkontakt fehlt

Viele Ablehnungen entstehen nicht bei Beträgen oder Steuern, sondern bei einfachen Kontaktdaten. In XRechnung müssen Verkäuferinformationen strukturiert vorhanden sein. Dazu gehören je nach Regel unter anderem Kontaktname, Telefonnummer und E-Mail-Adresse.

Typische Ursachen

* Buchhaltungs-E-Mail fehlt im Firmenprofil
* Telefonnummer steht nur im PDF-Briefkopf
* Kontaktperson ist leer
* ERP exportiert nur den Firmennamen
* mehrere Mandanten nutzen unvollständige Stammdaten
* Pflichtfelder wurden bei der Umstellung auf XRechnung nicht ergänzt

So beheben Sie Kontaktfehler

Ergänzen Sie die Verkäufer-Stammdaten vollständig und prüfen Sie anschließend die XML-Datei. Es reicht nicht, wenn die Daten im PDF-Layout sichtbar sind. Die XRechnung muss die Informationen im strukturierten Verkäuferkontakt enthalten.

Ein sauberer Mindeststandard ist:

* Kontaktname oder Abteilung
* E-Mail-Adresse für Rückfragen
* Telefonnummer
* vollständige Verkäuferadresse
* steuerliche Kennung
* elektronische Adresse, falls vom Profil verlangt

8. BR-CL-Fehler: Freitext statt erlaubter Code

BR-CL-Fehler entstehen, wenn ein Feld nur bestimmte Codes akzeptiert, aber ein Freitextwert geliefert wird. Das passiert häufig bei Währungen, Steuerarten, Einheiten, Zahlungsarten oder Ländercodes.

Beispiele

So beheben Sie Code-Listen-Fehler

Nutzen Sie keine frei erfundenen Werte in XML-Codefeldern. Jedes Codefeld hat eine definierte Codeliste. Das gilt besonders bei:

* Währungscode
* Ländercode
* Steuerkategorie
* Einheitencode
* Payment Means Code
* VATEX-Code bei Steuerbefreiungen
* Invoice Type Code bei Rechnung, Gutschrift oder Korrektur

Wenn Sie einzelne Rechnungen erstellen, führt Sie der XRechnung Generator durch viele dieser Felder. Für bestehende PDFs nutzen Sie den Konverter. Für komplexe ERP-Daten ist ein individuelles Mapping sinnvoll.

Warum eine valide XRechnung mehr ist als „XML erzeugen“

Viele Unternehmen denken bei der E-Rechnung zuerst an den Exportknopf im ERP. In der Praxis entstehen Fehler aber oft an der Schnittstelle zwischen Fachlogik und XML:

* PDF sieht korrekt aus, XML enthält andere Werte
* Rechnungsrabatte werden visuell gezeigt, aber nicht strukturiert gemappt
* Zahlungsbedingungen sind im ERP historisch gewachsen
* unterschiedliche Empfänger verlangen unterschiedliche Referenzen
* öffentliche Auftraggeber benötigen Leitweg-ID und Portalregeln
* B2B-Kunden prüfen automatisiert über Peppol oder eigene Gateways
* Gutschriften, Korrekturen, Anzahlungen und Schlussrechnungen brauchen eigene Beleglogik

Deshalb sollte der Prozess nicht lauten: „Exportieren und hoffen“. Besser ist ein Validierungsworkflow vor dem Versand.

Empfohlener Workflow: XRechnung Fehler vermeiden

1. Belegquelle prüfen

Kommt die Rechnung aus ERP, PDF, Word, Excel, Shop, CRM oder manuellem Formular?

1. Zielformat festlegen

Benötigt der Empfänger XRechnung XML, ZUGFeRD PDF/A-3 mit XML, Factur-X, UBL, CII oder Peppol?

1. Pflichtfelder ergänzen

Prüfen Sie Buyer Reference, Steuerkennungen, Verkäuferkontakt, Zahlungsdaten, elektronische Adressen und Bestellreferenzen.

1. Sonderfall erkennen

Handelt es sich um Standardrechnung, Gutschrift, Korrekturrechnung, Reverse Charge, Kleinunternehmerrechnung, Teilrechnung, Abschlag, Schlussrechnung oder Selbstfakturierung?

1. Validieren vor Versand

Laden Sie die Datei in den E-Rechnung Validator. Erst wenn keine blockierenden Fehler mehr vorhanden sind, sollte die Rechnung an den Empfänger gehen.

1. Fehler systematisch korrigieren

Ändern Sie nicht nur die einzelne XML-Datei, sondern die Ursache im ERP, Konverter, Mapping oder Stammdatensatz.

1. Automatisieren, wenn der Fall wiederkehrt

Wiederkehrende Fehler gehören nicht in manuelle Nacharbeit. Für Batch, API, ERP-Anbindung, Shopsysteme, E-Mail-Weiterleitung oder individuelle Empfängerregeln eignet sich Enterprise.

RechneX: Fehler finden, Rechnung korrigieren, E-Rechnung sauber ausgeben

RechneX unterstützt verschiedene Wege, je nachdem, wo Sie im Prozess stehen.

Wenn Sie bereits eine XML-Datei haben

Nutzen Sie den E-Rechnung Validator, um XRechnung, ZUGFeRD-XML, UBL oder CII gegen relevante Prüfregeln zu testen. So sehen Sie, ob Fehler wie BR-DE-15, BR-CO-17 oder BR-DE-16 auftreten.

Wenn Sie die XML-Datei nur lesen möchten, nutzen Sie den XRechnung Viewer. Der Viewer macht technische XML-Daten lesbar und zeigt Rechnungsnummer, Datum, Verkäufer, Käufer, Positionen, Steuern, Zahlungsdaten und Gesamtbetrag übersichtlich an.

Wenn Sie eine PDF-Rechnung haben

Nutzen Sie den PDF zu XRechnung und ZUGFeRD Konverter. Sie laden die PDF-Rechnung hoch, prüfen die erkannten Daten im Editor und erzeugen daraus eine E-Rechnung im passenden Format.

Das ist besonders hilfreich, wenn Ihre bestehende Rechnungssoftware noch keine saubere XRechnung oder ZUGFeRD-Datei ausgeben kann.

Wenn Sie eine Rechnung manuell erstellen möchten

Nutzen Sie den XRechnung Generator oder den ZUGFeRD Generator. Sie erfassen Verkäufer, Käufer, Positionen, Steuerdaten, Zahlungsdaten und Referenzen direkt im Browser und erhalten eine strukturierte E-Rechnung.

Unterstützte Sonderfälle im Generator sind unter anderem:

* Gutschrift
* Korrekturrechnung
* Reverse Charge
* Kleinunternehmerrechnung
* Teilrechnung
* Bauabschlagsrechnung
* Selbstfakturierung

Mehr dazu finden Sie auf der Seite E-Rechnung Sonderfälle.

Wenn Sie komplexe oder wiederkehrende Prozesse haben

Nutzen Sie Enterprise, wenn Standardtools nicht ausreichen. Typische Enterprise-Fälle sind:

* ERP-Anbindung
* API-Anbindung
* CRM- oder Shopsystem-Anbindung
* Batch-Verarbeitung hoher Volumen
* automatische PDF-zu-XRechnung-Konvertierung
* automatische PDF-zu-ZUGFeRD-Konvertierung
* individuelle Empfängerregeln
* Leitweg-ID-Logik je Kunde
* Factoring und Forderungsabtretung
* Abschlags- und Schlussrechnungen
* Gutschriften und Storno-Prozesse
* E-Mail-Weiterleitung für Eingang oder Ausgang
* E-Rechnungsversand
* Freigabeprozesse im Dashboard
* Fehlerlisten und strukturierte Reports
* White-Label, SSO, SLA und persönliches Onboarding

Wenn fast alles möglich sein muss, ist Enterprise der richtige Rahmen. Senden Sie Beispielbelege und Prozessanforderungen an kontakt@rechnex.de oder prüfen Sie die Optionen auf der Preise und Enterprise-Seite.

Häufige Fragen zu XRechnung Fehlercodes

Was ist der Unterschied zwischen BR-DE und BR-CO?

BR-CO sind europäische Kernregeln der EN 16931. Sie betreffen vor allem Grundlogik, Summen, Steuerberechnung und Pflichtzusammenhänge. BR-DE sind deutsche XRechnung-Regeln, die das europäische Modell für Deutschland konkretisieren.

Warum wird meine XRechnung abgelehnt, obwohl das PDF korrekt aussieht?

Weil bei XRechnung nicht das PDF entscheidet, sondern die XML-Daten. Ein Betrag, eine IBAN oder eine Leitweg-ID kann im PDF sichtbar sein und trotzdem im XML fehlen oder im falschen Feld stehen.

Kann ich einen XRechnung Fehler einfach im XML korrigieren?

Technisch ja, praktisch ist das riskant. Wenn der Fehler aus ERP-Stammdaten, Rundungslogik oder Mapping stammt, kommt er bei der nächsten Rechnung wieder. Besser ist: Ursache im Quellsystem korrigieren und danach neu validieren.

Ist ZUGFeRD dasselbe wie XRechnung?

Nein. XRechnung ist in der Regel eine reine XML-Datei. ZUGFeRD ist ein hybrides Format: ein PDF/A-3 mit eingebetteter XML-Datei. Beide können auf EN 16931 basieren, werden aber je nach Empfänger unterschiedlich verlangt.

Welche Fehler sind besonders kritisch?

Kritisch sind alle Fehler mit Status fatal oder error. Besonders häufig und relevant sind fehlende Buyer Reference, falsche Summen, fehlende Steuerkennungen, ungültige Zahlungsdaten, falsche Profilkennung und fehlerhafte Code-Listen-Werte.

Wie finde ich den richtigen Fehler schneller?

Laden Sie die Originaldatei in den E-Rechnung Validator. Arbeiten Sie nicht anhand der PDF-Ansicht, sondern anhand des konkreten Fehlercodes, Feldes und Regelhinweises.

Fazit: XRechnung Fehlercodes sind lösbar, wenn der Prozess stimmt

XRechnung Fehlercodes wirken zunächst technisch, haben aber fast immer klare fachliche Ursachen: fehlende Stammdaten, falsche Referenzen, Rundungsdifferenzen, unpassende Zahlungslogik, falsche Steuerkennungen oder ein falsches Exportprofil.

Der wichtigste Schritt ist deshalb nicht, einzelne XML-Zeilen zu erraten. Der wichtigste Schritt ist eine saubere Validierung vor dem Versand. So erkennen Sie BR-DE, BR-CO, BR-CL und Peppol-Fehler, bevor die Rechnung bei ZRE, OZG-RE, Peppol oder einem B2B-Kunden scheitert.

Mit RechneX können Sie E-Rechnungen erstellen, konvertieren, validieren und lesbar anzeigen. Für einzelne Rechnungen starten Sie kostenlos. Für regelmäßige Standardfälle lohnt sich Pro. Für ERP, API, Shopsysteme, Batch, Sonderfälle, E-Mail-Weiterleitung, E-Rechnungsversand und individuelle Regeln ist Enterprise der passende Weg.

Kostenlos registrieren und E-Rechnung erstellen

Preise und Pro-Tarif/Enterprise ansehen

Weiterführende interne Ressourcen

* E-Rechnung validieren
* PDF zu XRechnung und ZUGFeRD konvertieren
* XRechnung Generator
* XRechnung Viewer
* KoSIT Validator Anleitung
* XRechnung abgelehnt: 12-Punkte-Checkliste
* Peppol für deutsche Unternehmen
* OZG-RE XRechnung Bund hochladen
* Massenkonvertierung für Rechnungen
* Bußgeld und E-Rechnung vermeiden