E-Rechnung abgelehnt Gründe sind fast immer technische oder regelbasierte Abweichungen: Der Empfaenger (z. B. Portal, Peppol-Zugangspunkt oder Validator) akzeptiert die Rechnung nicht, weil Format oder Pflichtangaben nicht zu den Vorgaben passen.

Was bedeutet „E-Rechnung abgelehnt“ konkret?

Im Alltag heißt „E-Rechnung abgelehnt“: Die Rechnung ist nicht erfolgreich angenommen worden, weil entweder die technische Prüfung (z. B. Datei/Struktur/Schema) oder fachliche Prüfregeln (Pflichtfelder, Rechenlogik, IDs) fehlschlagen. Das passiert je nach Prozess vor der Zustellung (z. B. Routing/Empfänger-ID), bei der Annahme im Portal/Zugangspunkt oder bei der Validierung im Zielsystem. Wichtig ist: Eine Ablehnung ist fast immer mit einer Fehler-/Statusmeldung verbunden – die liefert den schnellsten Hinweis, ob es ein Formatproblem oder ein Inhaltsproblem ist.

E-Rechnung abgelehnt Gründe: Welche 12 Ursachen sind am häufigsten?

Wenn eine E-Rechnung abgelehnt wird, steckt fast immer einer dieser 12 Klassiker dahinter: Entweder stimmt das Format (XRechnung/ZUGFeRD) nicht, Pflichtangaben fehlen, Summen oder Steuerlogik passen nicht, oder Routing-Daten wie Leitweg-ID/Peppol-ID sind falsch. Die Liste unten ist als schnelle Diagnose gedacht, damit du zuerst die häufigsten Fehler prüfst, bevor du dich in Details verlierst.

1. Falsches Format oder falsches Profil (XRechnung vs. ZUGFeRD, Profil-Mismatch)
2. Falsche Version oder nicht zulaessige Spezifikation (z. B. Vorgabe des Empfaengers)
3. Pflichtfelder fehlen (Rechnungsnummer, Datum, Liefer-/Leistungsdatum, Zahlungsziel)
4. Stammdaten widerspruechlich (Name/Adresse, Debitor/Kreditor, Ansprechpartner)
5. USt-ID oder Steuernummer fehlt oder ist formal ungueltig
6. Steuerlogik fehlerhaft (Steuersatz, Steuerkategorie, Steuerbetrag)
7. Summen stimmen nicht (Positionssumme, Zwischensummen, Rundung, Gesamtbetrag)
8. Falsche oder fehlende Leitweg-ID (oeffentliche Auftraggeber)
9. Falsche Peppol-ID oder falsches Empfaenger-Routing
10. Unzulaessige Zeichen/Kodierung (UTF-8, Sonderzeichen, zu lange Felder)
11. Datei technisch fehlerhaft (kaputtes XML, beschaedigter Anhang, falsche MIME)
12. Business Rules verletzt (Schematron-Fehler, z. B. Pflicht-Beziehungen zwischen Feldern)

Pflichtfelder und Stammdaten: Wenn Rechnungsangaben fehlen oder widersprüchlich sind

Viele Ablehnungen entstehen nicht durch „komplizierte“ Regeln, sondern durch fehlende oder uneindeutige Basisdaten. Typische Auslöser sind eine fehlende Rechnungsnummer, ein unplausibles Leistungsdatum, unvollständige Adressen oder abweichende Schreibweisen zwischen Debitor und Empfänger. Auch Referenzen wie Bestellnummer, Auftragsnummer oder Leitweg-ID (falls gefordert) sind häufig der Knackpunkt. Der schnellste Fix ist, die Pflichtangaben einmal systematisch gegen die Empfängervorgaben zu prüfen und Stammdaten konsequent zu vereinheitlichen.

• Rechnungsnummer vorhanden und eindeutig (keine Dubletten)

• Rechnungsdatum und Liefer- oder Leistungsdatum gefüllt und plausibel

• Verkäuferdaten komplett (Name, Adresse, Land, Ansprechpartner)

• Käuferdaten komplett und exakt wie vom Empfänger erwartet (Name, Adresse, ggf. Abteilung)

• Referenzen gesetzt, wenn verlangt (Bestellnummer, Auftragsnummer, Projektnummer)

• Zahlungsbedingungen klar (Fälligkeitsdatum oder Zahlungsziel, Skonto nur wenn korrekt abbildbar)

Beträge, Steuer und Rundung: Wenn Summen nicht aufgehen

Wenn Summen oder Steuerbeträge nicht exakt zusammenpassen, wird eine E-Rechnung oft sofort abgelehnt. Häufig sind es Rundungsdifferenzen zwischen Positions- und Gesamtsumme, falsch berechnete Steuerbeträge, oder inkonsistente Angaben zu Netto und Brutto. Auch Skonto, Zuschläge oder Versandkosten können Probleme machen, wenn sie im XML anders abgebildet werden als in der internen Berechnung. Der schnellste Weg ist, die Rechenlogik einmal von der Position bis zur Gesamtsumme durchzuprüfen und jede Summe aus den gelieferten Werten nachvollziehbar zu machen.

• Positionssumme = Menge x Einzelpreis minus Rabatt (falls genutzt)

• Zwischensummen stimmen (Netto-Summe der Positionen, Zuschlaege, Nebenkosten)

• Steuer je Steuerkategorie korrekt (Steuersatz, Bemessungsgrundlage, Steuerbetrag)

• Gesamtsteuer = Summe aller Steuerbetraege (keine Mischungen ohne Kennzeichnung)

• Brutto = Netto plus Steuer (und zwar exakt nach Rundungsregel)

• Rundung einheitlich (z. B. immer auf 2 Nachkommastellen, keine versteckten Drittstellen)

• Skonto sauber abgebildet (als Bedingung, nicht als ungepruefter Abzug in der Summe)

XRechnung und ZUGFeRD: Wenn Format, Profil oder Version nicht akzeptiert werden

Viele Ablehnungen passieren, weil der Empfänger ein bestimmtes Format erwartet, die Rechnung aber in einem anderen Format, Profil oder einer anderen Version ankommt. Typisch ist auch: Die Datei sieht „formal“ wie eine E-Rechnung aus, besteht aber die Schema- oder Profilprüfung nicht, zum Beispiel wegen falscher Struktur, falschem Profil, oder weil Pflichtinhalte im gewählten Profil nicht enthalten sind. Der Fix ist, zuerst die Empfängervorgabe eindeutig zu klären und dann die Rechnung genau dagegen zu validieren, bevor du erneut einreichst.

• Empfängeranforderung checken: XRechnung oder ZUGFeRD (und welches Profil)

• Version passt zur Vorgabe (nicht „irgendeine“ Version senden)

• XML ist technisch valide (Schema-Validierung ohne Fehler)

• Profil passt zum Inhalt: Pflichtangaben sind im Profil vorhanden und belegt

• Keine unzulässigen Felder oder Strukturen (z. B. freie Texte in falschen Elementen)

• Datei wirklich im richtigen Container: bei ZUGFeRD ist das PDF mit eingebettetem XML korrekt erstellt, bei XRechnung ist es eine XML-Datei

Leitweg-ID, Peppol und Routing: Wenn die Zustellung scheitert

Manchmal ist die Rechnung inhaltlich korrekt, kommt aber beim richtigen Empfänger nicht an oder wird direkt beim Eingang abgewiesen. Ursache sind dann fast immer falsche Routing-Daten: eine fehlende oder falsche Leitweg-ID (bei vielen öffentlichen Auftraggebern Pflicht), eine nicht passende Peppol-ID, oder ein Empfängerprofil, das nicht zu Absender, Prozess oder Format passt. Der Fix ist, die Empfänger-IDs exakt so zu verwenden, wie sie vom Empfänger genannt werden, und das Routing vor dem erneuten Versand einmal hart zu pruefen.

• Leitweg-ID vorhanden, falls gefordert, und exakt ohne Tippfehler

• Leitweg-ID dem richtigen Rechnungsempfaenger zugeordnet (nicht nur „Konzern“, sondern die richtige Stelle)

• Peppol-ID korrekt (Format, Laendercode, Identifier) und zum Empfaenger passend

• Empfaengerkanal stimmt: Portal, Peppol, E-Mail, Upload (nicht am falschen Eingang einreichen)

• Format und Profil passen zum Kanal (manche Portale nehmen nur bestimmte Profile)

• Testversand oder Validator-Pruefung vor dem echten Versand dokumentieren (damit du den Fix nachweisen kannst)

Dateianhänge, Signaturen und Dateiqualität: Wenn PDF oder XML technisch fehlerhaft ist

Auch wenn Inhalt und Format grundsätzlich passen, kann eine E-Rechnung abgelehnt werden, weil die Datei technisch nicht sauber ist. Häufige Ursachen sind ein beschädigtes XML, falsche Zeichenkodierung, unzulässige Sonderzeichen, oder bei ZUGFeRD ein PDF, in dem das XML nicht korrekt eingebettet ist. Manche Empfänger lehnen auch ab, wenn Anhänge falsch eingebunden sind oder die Datei nicht den erwarteten Dateityp-Merkmalen entspricht. Der schnellste Fix ist, die Datei einmal neu zu exportieren, anschließend zu validieren und erst dann erneut einzureichen.

• Datei lässt sich öffnen und ist nicht beschädigt (XML lesbar, PDF öffnet ohne Fehler)

• Zeichenkodierung passt, idealerweise UTF-8, keine „komischen“ Steuerzeichen

• XML ist wohlgeformt (keine abgeschnittenen Tags, keine kaputten Sonderzeichen)

• Dateityp stimmt: XRechnung als XML, ZUGFeRD als PDF mit eingebettetem XML

• Bei ZUGFeRD: eingebettetes XML ist wirklich enthalten und entspricht dem gewählten Profil

• Dateiname und Endung sind konsistent (kein .pdf mit XML-Inhalt)

• Anhänge nur, wenn erlaubt, und dann korrekt referenziert (keine exotischen Formate, keine riesigen Dateien)

Validierung und Business Rules: Wenn der Validator rot meldet

Wenn der Validator rot meldet, ist das fast immer entweder ein Schema-Fehler (die Struktur der Datei passt nicht) oder ein Business-Rule-Fehler (Pflichtlogik im Inhalt wird verletzt). Entscheidend ist, die Fehlermeldung nicht nur zu lesen, sondern zuzuordnen: Was ist die betroffene Stelle, welches Feld wird erwartet, und ist es ein Formatproblem oder ein Inhaltsproblem. In der Praxis lohnt sich eine feste Reihenfolge: erst die Datei technisch validieren, dann Pflichtfelder und Beziehungen prüfen, und erst danach Detailregeln wie Steuerkennzeichen oder Referenzen. So findest du die Ursache schneller und vermeidest, dass du am Symptom statt am Auslöser korrigierst.

• Fehlermeldung 1:1 kopieren und die betroffene Stelle notieren (Pfad, Feldname, Position)

• Einordnen: Schema-Fehler (Struktur) oder Business-Rule-Fehler (Inhalt/Logik)

• Erst technisch prüfen: XML wohlgeformt, dann Schema-Validierung ohne Fehler

• Dann Pflichtfelder prüfen: Rechnungsnummer, Datum, Liefer-/Leistungsdatum, Parteien, Steuerangaben

• Beziehungen prüfen: Summen zu Positionen, Steuer zu Bemessungsgrundlage, Referenzen zu Vorgängen

• Sonderzeichen und Feldlängen checken (Umlaute, Steuerzeichen, zu lange Texte)

• Nach jedem Fix erneut validieren und nur 1 bis 2 Fehlergruppen pro Durchlauf ändern

• Final: Test-Validierung speichern (Screenshot oder Report), dann erst neu einreichen

Fix-Checkliste: In 10 Minuten zur erneuten Einreichung

Wenn eine E-Rechnung abgelehnt wurde, hilft eine feste Reihenfolge. So vermeidest du, dass du mehrfach sendest und immer wieder an einer anderen Stelle scheiterst. Die Checkliste unten ist bewusst pragmatisch: erst Eingang und Fehlermeldung sichern, dann Format und Validierung, dann Pflichtfelder und Summen, am Ende ein kurzer Gegencheck. Danach kannst du erneut einreichen, ohne zu raten.

1. Ablehnungsnachricht sichern: Status, Fehlcode, Text, Zeitpunkt, Kanal (Portal, Peppol, Upload)
2. Einordnen: Zustellung gescheitert (ID/Routing) oder Validierung gescheitert (Schema/Business Rules)
3. Datei neu exportieren oder sauber neu erzeugen (keine „zusammenkopierten“ XMLs)
4. Technische Validierung: XML wohlgeformt und Schema ohne Fehler
5. Format und Profil pruefen: XRechnung oder ZUGFeRD, Profil und Version wie vom Empfaenger gefordert
6. Pflichtangaben pruefen: Rechnungsnummer, Datum, Liefer-/Leistungsdatum, Kaeufer/Verkaeufer, Referenzen, Zahlungsbedingungen
7. Summen und Steuer pruefen: Positionen, Rundung, Steuerkategorien, Gesamtbetraege
8. IDs und Routing pruefen: Leitweg-ID oder Peppol-ID exakt, Empfaengerkanal korrekt
9. Erneut validieren und Ergebnis speichern (Report oder Screenshot)
10. Erst dann erneut einreichen und intern kurz dokumentieren, was geaendert wurde

Typische Fehler beim zweiten Versuch

• Du korrigierst den Inhalt, exportierst aber die alte Datei erneut (immer neu erzeugen, nicht nur umbenennen)

• Du fixt einen Fehler und erzeugst dabei einen neuen (nach jedem Fix erneut validieren)

• Du änderst zu viel auf einmal (pro Durchlauf nur 1 bis 2 Fehlergruppen)

• Du übernimmst Empfänger-IDs aus einer alten Mail oder einem alten Projekt (IDs immer aktuell gegenprüfen)

• Du passt Werte im PDF an, aber das XML bleibt unverändert (entscheidend ist das XML)

• Du nutzt ein anderes Profil oder eine andere Version als gefordert (Vorgabe strikt einhalten)

Fazit: So vermeidest du die nächste Ablehnung

Wenn du die Reihenfolge aus der Fix-Checkliste einhältst, findest du die Ursache einer abgelehnten E-Rechnung meist schnell: erst Routing und Empfängeranforderung klären, dann technisch validieren, danach Pflichtfelder, Summen und Steuerlogik prüfen. Wichtig ist, jeden Fix direkt mit einer erneuten Validierung abzusichern, damit du nicht im Kreis korrigierst. So wird aus der Ablehnung ein klarer, dokumentierter Korrekturlauf.

Wenn E-Rechnungen abgelehnt werden, hilft es, den Prozess für Erzeugung, Versand und Eingang strukturiert aufzusetzen. Mit AMADEUS.X kannst Du E-Rechnungen versenden und empfangen. Mehr dazu: AMADEUS.X E-Rechnungen.

FAQ: E-Rechnung abgelehnt

Warum wird eine E-Rechnung trotz „korrektem PDF“ abgelehnt?

Ein PDF kann gut aussehen und trotzdem technisch nicht konform sein, weil bei einer E-Rechnung die strukturierten Daten (z. B. XML) zaehlen. Wenn Format, Profil oder Pflichtfelder im strukturierten Teil nicht passen, wird die Rechnung abgewiesen, auch wenn die Darstellung im PDF plausibel ist.

Was bedeutet die Fehlermeldung „Leitweg-ID ist nicht valide“?

Diese Meldung bedeutet, dass die angegebene Leitweg-ID von der Plattform nicht akzeptiert wird. Hauefige Ursachen sind Tippfehler, Leerzeichen oder falsch gesetzte Bindestriche. Der naechste Schritt ist: Eingabe exakt pruefen und bei Bedarf die Leitweg-ID beim Auftraggeber gegenchecken.

Wo steht die Leitweg-ID in der XRechnung?

In der XRechnung wird die Leitweg-ID im Feld „Kaeuferreferenz“ (BT-10) uebermittelt und ist bei Rechnungen an die Bundesverwaltung als Pflichtangabe vorgesehen. Wenn BT-10 leer oder falsch gefuellt ist, kommt es schnell zur Ablehnung.

Warum meldet der Validator „invalide“, obwohl das XML optisch richtig aussieht?

Oft liegt es an technischen Details wie Zeichenkodierung. Bei XRechnung und ZUGFeRD ist UTF-8 erforderlich, und zusaetzliche Steuerzeichen wie ein BOM koennen Validierungsfehler ausloesen. Ein erneuter Export mit sauberer UTF-8 Kodierung behebt das haeufig.

Was ist der Unterschied zwischen Schema-Fehler und Business-Rule-Fehler?

Schema-Fehler bedeuten: Die Struktur passt nicht zum erwarteten Format, also ein technisches Problem in Aufbau oder Datentypen. Business-Rule-Fehler bedeuten: Die Datei ist strukturell ok, aber fachliche Regeln sind verletzt, z. B. Pflichtbeziehungen oder Summenlogik. In der Praxis behebst du erst Schema, dann Business Rules, weil viele Business-Fehler sonst Folgefehler bleiben.

Kann ich eine normale PDF-Rechnung in eine E-Rechnung umwandeln?

Ja, technisch gibt es Tools und Workflows, die PDF Inhalte in strukturierte Formate wie XRechnung umsetzen, das wird auch in der Praxis diskutiert. Entscheidend ist danach immer die Validierung, weil aus einer Umwandlung noch keine automatisch konforme E-Rechnung wird.

Warum scheitert die Zustellung ueber Peppol oder Portal, obwohl der Inhalt stimmt?

Dann ist oft das Routing falsch, zum Beispiel weil die Empfaenger-ID nicht exakt passt oder der falsche Eingangskanal genutzt wird. Viele Stellen akzeptieren nur bestimmte Kanaele oder Profile, und eine korrekt aufgebaute Rechnung kann trotzdem am Eingang abgewiesen werden.

Wo finde ich den konkreten Ablehnungsgrund?

In der Regel steht er in der Rueckmeldung des Empfaengers, oft als E-Mail Text plus Anhang oder Protokoll (z. B. Laufzettel). Ohne diese Meldung ist es schwer, zwischen Routing-, Format- und Inhaltsfehler zu unterscheiden.

Teilen