Lehnt ein Kunde eine E-Rechnung ab, sollten Sie nicht sofort eine zweite Rechnung mit neuer Rechnungsnummer erstellen. Sichern Sie zuerst die übermittelte Datei, die Fehlermeldung und den Versandnachweis. Klären Sie dann, ob ein technischer XML-Fehler, eine verletzte Geschäftsregel oder eine unpassende Empfängerangabe vorliegt. In vielen Fällen muss lediglich dieselbe Rechnung technisch korrigiert und erneut exportiert werden.
Für die Fehlersuche benötigen Sie mindestens die originale XML-Datei, die genaue Rückmeldung des Kunden oder Portals, das verwendete Format einschließlich Profil und Version sowie die Empfängervorgaben. Eine Beschreibung wie „Datei ungültig“ reicht nicht aus. Bitten Sie gegebenenfalls um den vollständigen Validierungsbericht mit Fehlercode, Regelkennung und betroffenem Datenfeld.
Vier Fehlerklassen bestimmen den Lösungsweg
Eine elektronische Rechnung kann an mehreren Prüfstationen scheitern. Die Meldung des Empfängers bezeichnet nicht immer sauber, welche Station betroffen ist. Ordnen Sie die Ablehnung daher zuerst einer der folgenden Klassen zu:
- Datei- oder XML-Fehler: Das Dokument ist beschädigt, leer, nicht wohlgeformt oder enthält unzulässige Zeichen.
- Schema- oder Formatfehler: Elemente fehlen, stehen an einer unzulässigen Position oder gehören nicht zur angegebenen Formatversion.
- Verstoß gegen Geschäftsregeln: Die XML-Struktur ist lesbar, aber Pflichtfelder, Berechnungen oder inhaltliche Beziehungen erfüllen die Regeln des verwendeten Standards nicht.
- Empfänger- oder Prozessfehler: Die Rechnung ist technisch gültig, passt jedoch nicht zu Bestellbezug, Leitweg-ID, Portalvorgabe, Übertragungskanal oder erwartetem Profil.
Diese Trennung verhindert unnötige Eingriffe. Ein Schemafehler wird durch eine geänderte Leitweg-ID nicht behoben. Umgekehrt kann eine valide XRechnung weiterhin abgelehnt werden, wenn der Kunde eine Bestellnummer in einem bestimmten Feld verlangt.
Die Diagnose beginnt mit Format, Profil und Übertragungsweg
„XML-Rechnung“ ist keine hinreichende Formatangabe. Ermitteln Sie in Ihrer Rechnungssoftware, ob die Datei beispielsweise als XRechnung oder als ZUGFeRD-Rechnung erzeugt wurde. Bei ZUGFeRD ist zusätzlich das gewählte Profil maßgeblich. Bei XRechnung können die unterstützte Spezifikationsversion und die verwendete Syntax eine Rolle spielen. Die vom Kunden geforderte Variante muss mit Ihrem Export übereinstimmen.
Auch das sichtbare Dokument sagt wenig über die technische Nutzbarkeit aus. Eine ZUGFeRD-Rechnung besteht typischerweise aus einer PDF/A-3-Datei mit eingebetteter XML-Datei. Ein bloß umbenanntes PDF, ein PDF mit gewöhnlichem Dateianhang oder eine separat erzeugte XML-Datei ohne passende Einbettung wird dadurch nicht automatisch zu einer gültigen ZUGFeRD-Rechnung. XRechnungen werden dagegen häufig als eigenständige strukturierte Datei verarbeitet.
Prüfen Sie beim Kunden vier Angaben:
- akzeptiertes Rechnungsformat und benötigtes Profil,
- unterstützte Version beziehungsweise maßgebliche Formatspezifikation,
- erforderliche Empfängerkennung, Bestellnummer oder Leitweg-ID,
- zulässiger Versandweg, etwa Portal, definierte E-Mail-Adresse oder angebundener Übertragungskanal.
Für öffentliche Auftraggeber und andere XRechnung-Prozesse ist die jeweils verlangte Empfängerreferenz besonders wichtig. Die Leitweg-ID wird in der XRechnung üblicherweise als Käuferreferenz geführt. Sie darf nicht ersatzweise in ein Freitextfeld, die Anschrift oder den Dateinamen geschrieben werden, wenn das Zielsystem sie in einem strukturierten Feld erwartet.
Häufige XML-Fehler und die passende Behebung
Die XML-Datei ist nicht wohlgeformt
Ein XML-Parser kann die Datei nur lesen, wenn öffnende und schließende Elemente zusammenpassen, Verschachtelungen korrekt sind und Sonderzeichen regelgerecht codiert wurden. Typische Meldungen betreffen ein unerwartetes Dateiende, ein nicht geschlossenes Element oder ein unzulässiges Zeichen.
Bearbeiten Sie solche Fehler nicht manuell in einer produktiven Rechnungsdatei. Öffnen und speichern Sie den Beleg in der Rechnungssoftware erneut und erzeugen Sie einen frischen Export. Tritt der Fehler wieder auf, testen Sie auffällige Eingaben wie kopierte Sonderzeichen in Artikeltexten, Namen oder Freitexten. Bleibt nur eine verdächtige Eingabe als Ursache übrig, korrigieren Sie diese im Ausgangsdatensatz und exportieren erneut.
Elemente fehlen oder stehen an der falschen Stelle
Ein Schemafehler bedeutet, dass die Datei nicht zur erwarteten technischen Struktur passt. Die Fehlermeldung nennt häufig ein Element, einen Namensraum oder eine Position, an der ein anderes Element erwartet wurde. Ursache kann ein ungeeignetes Exportmodul, eine veraltete Formatvorlage oder eine nachträgliche Änderung der XML-Datei sein.
Wählen Sie in der Software das vom Empfänger verlangte Format und die unterstützte Variante neu aus. Aktualisieren Sie das Rechnungsmodul nur über den vorgesehenen Anbieterprozess und erzeugen Sie die Datei aus den Rechnungsdaten neu. Eine manuelle Verschiebung von XML-Elementen ist riskant, weil dadurch weitere Schema- und Geschäftsregeln verletzt werden können.
Pflichtfelder sind leer oder nicht richtig zugeordnet
Ein Wert kann im sichtbaren Rechnungsbild stehen und in der strukturierten Datei trotzdem fehlen. Das geschieht etwa, wenn ein individuell angelegtes Eingabefeld nur auf dem PDF ausgegeben, aber keinem semantisch passenden XML-Feld zugeordnet wird. Häufig betroffen sind Käuferreferenz, Bestellbezug, Zahlungsangaben, Steuerinformationen und Kontaktdaten.
Prüfen Sie nicht nur die Bildschirmansicht der Rechnung. Kontrollieren Sie im Stammdaten- oder Exportbereich, welchem E-Rechnungsfeld die Eingabe zugeordnet ist. Bei einer vom Kunden verlangten Bestellnummer muss außerdem geklärt werden, ob sie als Bestellreferenz, Vertragsreferenz oder anderer Prozessbezug erwartet wird. Gleich klingende Angaben sind technisch nicht beliebig austauschbar.
Datums-, Zahlen- oder Codeschreibweise ist ungültig
XML-Felder verwenden definierte Datentypen und Codelisten. Ein Datum im lesbaren Format kann technisch unzulässig sein, wenn der Export beispielsweise Text statt eines normgerechten Datumswertes liefert. Vergleichbare Probleme entstehen bei Dezimaltrennzeichen, Währungscodes, Länderkennzeichen, Einheiten oder Steuerkategorien.
Tragen Sie Werte in die dafür vorgesehenen Eingabefelder der Software ein und vermeiden Sie ergänzende Wörter in reinen Zahlen- oder Datumsfeldern. Die Darstellung für Menschen darf die Software separat erzeugen. Wenn der Fehler trotz sauberer Eingabe bestehen bleibt, liegt die Korrektur meist im Exportmodul und nicht in der Rechnungsvorlage.
Summen und Steuerwerte passen rechnerisch nicht zusammen
Viele Validierungen prüfen nicht nur einzelne Felder, sondern auch deren Beziehungen. Nettopositionen, Nachlässe, Zuschläge, Steuerbasis, Steuerbetrag und Rechnungsbetrag müssen mit den Rundungsregeln des Formats zusammenpassen. Schon eine externe Berechnung mit anderer Rundungslogik kann eine Abweichung verursachen.
Lassen Sie die Beträge vollständig durch ein System berechnen. Werden Positionen aus einem Shop, einer Tabellenkalkulation oder einem Warenwirtschaftssystem importiert, muss festgelegt sein, welches System führend rechnet und auf welcher Ebene gerundet wird. Überschreiben Sie nicht lediglich die Endsumme, weil dadurch die Abweichung zu den Positions- oder Steuerwerten bestehen bleibt.
Die eingebettete XML-Datei fehlt oder ist beschädigt
Bei einer hybriden ZUGFeRD-Rechnung kann das PDF sichtbar und lesbar sein, während die eingebettete XML-Datei fehlt, falsch bezeichnet oder nicht mehr mit dem PDF verbunden ist. Das kommt unter anderem vor, wenn das Dokument nach dem Export über einen PDF-Drucker neu erzeugt, in einer ungeeigneten Anwendung gespeichert oder durch einen nachgelagerten Prozess verändert wurde.
Senden Sie die unveränderte Originaldatei aus der Rechnungssoftware. Vermeiden Sie „Drucken als PDF“, nachträgliches Zusammenfügen und erneutes Abspeichern in einem gewöhnlichen PDF-Editor. Prüfen Sie zusätzlich, ob Ihre Versandsoftware oder Ihr Dokumentenmanagement die Datei konvertiert.
Das Dokument verwendet das falsche Profil
Ein ZUGFeRD-Profil mit reduziertem Datenumfang kann für den vorgesehenen Empfängerprozess unzureichend sein. Umgekehrt akzeptiert ein Zielsystem möglicherweise nur bestimmte Profile oder eine bestimmte Ausprägung der EN-16931-konformen Daten. Die Dateiendung allein lässt diesen Unterschied nicht erkennen.
Vergleichen Sie die Exportauswahl Ihrer Software mit der Annahmespezifikation des Kunden. Ist die Profilbezeichnung in der Oberfläche unklar, benötigen Sie vom Softwareanbieter die Dokumentation zum E-Rechnungs-Export. Dort sollten Format, Profil, Version und unterstützte Syntax genannt sein.
Empfängerkennung oder Bestellbezug ist falsch
Eine formal valide Rechnung kann im automatisierten Eingang keinem Kundenkonto, Auftrag oder Rechnungskanal zugeordnet werden. Dann wird sie häufig mit einer fachlichen Fehlermeldung zurückgewiesen. Prüfen Sie insbesondere Tippfehler, Leerzeichen, veraltete Bestellnummern und die Zuordnung zum richtigen strukturierten Feld.
Übernehmen Sie Empfängerdaten möglichst aus dem Auftrag oder aus geprüften Stammdaten, nicht aus alten Rechnungen. Bei einer unklaren Rückmeldung sollte der Kunde mitteilen, welche Kennung erwartet wird und in welchem Feld sie stehen muss. Das ist präziser als die pauschale Bitte, „die Referenz zu ergänzen“.
Eine feste Prüfreihenfolge spart doppelte Arbeit
Für kleine Unternehmen ist ein kurzer, dokumentierter Ablauf sinnvoll. Er trennt Fehlerbehebung, kaufmännische Entscheidung und Kommunikation mit dem Kunden.
- Ablehnung sichern: Speichern Sie Fehlermeldung, ursprüngliche Datei, Versandzeitpunkt, Übertragungskanal und betroffene Rechnungsnummer.
- Annahmevorgaben abgleichen: Prüfen Sie Format, Profil, Version, Empfängerkennung, Bestellbezug und Versandweg.
- Datei unverändert validieren: Nutzen Sie einen Validator, der genau zum verwendeten Format und zur betreffenden Version passt. Für XRechnung kann die KoSIT-Validierung beziehungsweise eine darauf basierende Prüfumgebung ein geeigneter Prüfpunkt sein. Für ZUGFeRD muss der Validator das verwendete Profil berücksichtigen.
- Fehlerklasse bestimmen: Unterscheiden Sie Parserfehler, Schemafehler, verletzte Geschäftsregel und empfängerbezogene Ablehnung.
- Quelldaten korrigieren: Ändern Sie Stammdaten, Rechnungsfelder oder Exporteinstellungen in der führenden Software. Vermeiden Sie direkte Eingriffe in die XML-Datei.
- Neu exportieren und erneut validieren: Prüfen Sie die neu erzeugte Datei vor dem Versand mit denselben Regeln.
- Erneute Übermittlung dokumentieren: Vermerken Sie intern, welche Datei wann über welchen Kanal gesendet wurde und welcher Fehler behoben wurde.
Besteht die Datei die allgemeine Formatvalidierung, wird vom Kunden aber weiterhin abgelehnt, liegt die Ursache eher in dessen Prozessvorgaben oder in zusätzlichen Annahmeregeln. Senden Sie dem Ansprechpartner dann den Validierungsstatus und bitten Sie um die genaue Regelkennung aus dem Eingangssystem. Ein bloßer Screenshot des sichtbaren Rechnungsbildes hilft bei einem strukturellen Fehler kaum weiter.
Korrekturdatei oder neue Rechnung?
Die technische Neuerzeugung einer noch nicht akzeptierten Datei ist nicht automatisch dasselbe wie eine kaufmännische Stornierung. Bleiben Rechnungsinhalt, Rechnungsnummer und Geschäftsvorfall unverändert und wird nur ein fehlerhafter Export ersetzt, kann je nach System eine technisch korrigierte Datei zur selben Rechnung ausreichen. Ihre Buchhaltungs- und Rechnungssoftware muss dabei verhindern, dass zwei unterschiedliche Belege unter derselben Nummer geführt werden.
Ändern sich dagegen kaufmännisch relevante Inhalte wie Betrag, Leistung, Steuerbehandlung oder Rechnungsempfänger, reicht eine rein technische Reparatur möglicherweise nicht. Dann ist zu prüfen, ob der ursprüngliche Beleg bereits als Rechnung zugegangen oder verarbeitet worden ist und ob eine Stornierung beziehungsweise Rechnungskorrektur erforderlich wird. Stimmen Sie diesen Fall mit der Buchhaltung oder steuerlichen Beratung ab, statt durch wiederholte Exporte einen unklaren Belegbestand zu erzeugen.
Vergeben Sie nicht vorschnell eine neue Rechnungsnummer, nur weil ein Portal die Datei technisch abgelehnt hat. Das kann Lücken, Doppelbelege oder widersprüchliche Forderungen verursachen. Entscheidend sind der Status im eigenen Rechnungssystem, der Zugang beim Empfänger und der Umfang der Änderung.
Was Sie dem Kunden zur Klärung mitteilen sollten
Eine kurze technische Rückfrage sollte die Identifikation des Vorgangs ermöglichen, ohne sensible Rechnungsdaten unnötig zu vervielfältigen. Sie kann folgendermaßen formuliert werden:
Übermitteln Sie die Rechnungsdatei bei dieser Rückfrage nur erneut, wenn der gewählte Kommunikationsweg dafür freigegeben ist. Manche Portale erzeugen andernfalls einen weiteren Eingangsvorgang, obwohl zunächst nur eine technische Klärung beabsichtigt war.
Die Fehlerquelle dauerhaft aus dem Prozess entfernen
Nach erfolgreicher Korrektur sollte nicht nur der einzelne Beleg, sondern auch der Entstehungsweg geprüft werden. Hinterlegen Sie verifizierte Empfängerkennungen und Bestellreferenzen in den Kundenstammdaten. Dokumentieren Sie pro Kunde das verlangte Format, Profil, den Versandkanal und besondere Eingangsregeln. Begrenzen Sie zugleich die Berechtigung, Exportprofile und E-Rechnungsstammdaten zu ändern.
Führen Sie nach Softwareupdates oder Änderungen an Schnittstellen einen Test mit einem Validator durch, bevor größere Rechnungsläufe versendet werden. Das gilt besonders, wenn Daten zwischen Shop, Warenwirtschaft, Buchhaltung und Dokumentenmanagement übertragen werden. Jede Schnittstelle kann Werte anders runden, Felder auslassen oder Zeichen verändern.
Der Vorgang ist erst abgeschlossen, wenn die korrigierte Datei die passende Validierung besteht, der Kunde den Eingang bestätigt oder sein Portal einen eindeutigen Annahmestatus zeigt und die interne Ablage nur den nachvollziehbaren Belegstand enthält. So wird aus einer technischen Ablehnung kein dauerhaftes Problem in Buchhaltung und Forderungsmanagement.
