Typische ERP-Exportprobleme bei XRechnung

Ein ERP-System kann eine fachlich richtige Rechnung anzeigen und trotzdem eine ungültige XRechnung exportieren. Der Grund liegt häufig zwischen Oberfläche und XML: Stammdaten werden nicht in die richtigen Business Terms gemappt, alte Codes werden verwendet, Pflichtfelder sind nur als Freitext vorhanden oder Summen werden anders gerundet als im Standard erwartet.

Deshalb sollte ein ERP-Export nicht nur nach dem sichtbaren Rechnungsbild geprüft werden. Entscheidend ist die strukturierte XML-Datei, die der Empfänger maschinell verarbeitet.

Die folgende Tabelle zeigt typische Fehlerquellen, die bei ERP-, Buchhaltungs- und Warenwirtschaftssystemen immer wieder auftreten. Sie ist bewusst praktisch formuliert: Wo entsteht der Fehler, wie sieht er aus und wer sollte ihn korrigieren?

Viele Systeme bieten mehrere Ausgabearten: normales PDF, ZUGFeRD, Factur-X, XRechnung, UBL, CII oder verschiedene Profile. Ein häufiger Fehler ist, dass zwar eine Datei erzeugt wird, diese aber nicht dem erwarteten Profil entspricht.

Besonders kritisch ist das bei hybriden Formaten. Ein PDF kann korrekt aussehen, während das eingebettete XML ein unpassendes Profil nutzt oder nicht alle Pflichtinformationen enthält. Für die Validierung zählt die strukturierte Rechnung, nicht das sichtbare Layout.

ERP-Oberflächen erlauben oft Notizen, Einleitungstexte oder interne Bemerkungen. Für Menschen ist das bequem, für XRechnung reicht es aber nicht. Eine Leitweg-ID, Bestellnummer oder Steuerangabe muss im richtigen strukturierten Feld stehen.

Wenn eine Information nur im Freitext erscheint, kann der Empfängerprozess sie nicht zuverlässig auslesen. Das führt zu Ablehnungen, obwohl der Wert auf dem PDF oder in der ERP-Maske sichtbar ist.

Für Papier- oder PDF-Rechnungen genügt manchmal ein lesbarer Adressblock. Eine XML-Rechnung braucht dagegen getrennte Felder: Name, Straße, Postleitzahl, Ort, Ländercode, Steuerkennzeichen und je nach Prozess elektronische Adressen.

Viele Exportfehler sind deshalb eigentlich Stammdatenfehler. Der Kunde ist im ERP angelegt, aber nicht mit den Feldern, die der XML-Export für EN 16931 und XRechnung benötigt.

Interne ERP-Steuercodes sind nicht automatisch identisch mit den Steuerkategorien einer E-Rechnung. Ein System kann intern mit eigenen Codes für 19 Prozent, steuerfrei, Reverse Charge oder innergemeinschaftliche Lieferung arbeiten. Beim Export müssen diese Codes korrekt in die strukturierten Steuerangaben übersetzt werden.

Fehler zeigen sich häufig erst im Validator: Steuerkategorie, Steuersatz, Steuerbasis, Steuerbetrag und Befreiungsgrund passen dann nicht zusammen.

ERP-Systeme zeigen Beträge oft in gerundeter Form an, rechnen intern aber mit mehr Nachkommastellen. Beim XML-Export müssen Positionssummen, Zuschläge, Abschläge, Steuerbeträge und Gesamtbeträge rechnerisch zusammenpassen.

Kleine Differenzen von einem Cent können ausreichen, damit eine Business Rule fehlschlägt. Das Problem liegt dann nicht im XML-Parser, sondern in der Rechenlogik oder im Mapping der Beträge.

XRechnung besteht nicht nur aus einer PDF-Beschreibung. Es gibt Spezifikationen, Schematron-Regeln, Validator-Konfigurationen und Codelisten. Diese Komponenten werden versioniert und müssen zur exportierten Rechnung passen.

Ein ERP-Export kann also scheitern, wenn das System noch eine alte XRechnung-Version nutzt oder Codelistenwerte exportiert, die im aktuellen Prüfstand nicht mehr passen. Bei Fehleranalysen sollte deshalb immer dokumentiert werden, welche ERP-Version, welches Profil und welche Validator-Version verwendet wurden.

XRechnung kann in unterschiedlichen XML-Syntaxen auftreten. UBL und CII bilden ähnliche fachliche Informationen ab, sehen technisch aber anders aus. Wer eigene Schnittstellen, Konverter oder Exporte baut, darf die XML-Pfade nicht einfach austauschen.

Entscheidend ist das semantische Mapping auf Business Terms. Ein Feld muss fachlich stimmen und zugleich in der gewählten Syntax korrekt platziert sein.

Bei wiederkehrenden Fehlern lohnt es sich, den Exportprozess aufzuteilen: Stammdaten, Belegdaten, Steuerlogik, Mapping, Formatprofil, XML-Erzeugung und Validierung. So lässt sich erkennen, ob die Buchhaltung eine Angabe ergänzen muss oder ob die ERP-Konfiguration korrigiert werden sollte.

Ein lesbarer Validierungsbericht hilft dabei, weil er technische Regeln in konkrete Rechnungsbereiche übersetzt. Ohne diese Übersetzung landet jeder Fehler schnell beim falschen Team.

Testen Sie nicht nur eine Standardrechnung. Ein belastbarer ERP-Test enthält typische und schwierige Fälle: normale Rechnung, Gutschrift, Rabatt, Versandkosten, mehrere Steuersätze, steuerfreie Leistung, Reverse Charge, Leitweg-ID, Bestellnummer und Rundungsfälle.

Für jeden Fall sollte festgehalten werden: ERP-Version, Exportprofil, XRechnung-Version, verwendete Syntax, Validator-Version und Ergebnisbericht. Dadurch werden spätere Updates deutlich leichter kontrollierbar.