Rechnung von KSeF abgelehnt? Häufige Fehler und Lösungen

Eine technisch erfolgreiche Antwort auf die Übermittlungsanfrage bedeutet noch nicht, dass KSeF die Rechnung angenommen hat. Status 100 steht für die Annahme zur weiteren Verarbeitung, Status 150 für eine laufende Verarbeitung und erst Status 200 für den Erfolg.

Ein abgelehntes Dokument erhält weder KSeF-Nummer noch UPO und gilt in KSeF nicht als ausgestellt. Lesen Sie zuerst Fehlercode, Beschreibung und Details. Korrigieren Sie danach P_1, FA(3)-XML, Berechtigungen, Verschlüsselung oder die andere angegebene Ursache.

Das sichere Kurzverfahren lautet: Status prüfen, Antwort und XML sichern, einen früheren Erfolg ausschließen, Fehlerquelle korrigieren, neue Datei validieren, erneut senden und bis zur KSeF-Nummer und zum UPO überwachen.

Nach der Übermittlung sehen Sie eine Meldung, aber keine KSeF-Nummer und kein UPO. Senden Sie die Rechnung nicht sofort erneut. Der Endpunkt kann Anfrage, verschlüsselte Datei und Metadaten annehmen, bevor die Verarbeitung abgeschlossen ist.

Status 100 und 150 bedeuten weder Ablehnung noch endgültigen Erfolg. Prüfen Sie weiterhin dieselbe Rechnung, statt eine neue Übermittlung anzulegen.

Fehlercodes sind zusammen mit description, details und extensions auszuwerten. Der Code benennt die Kategorie, die Details führen zur konkreten Ursache.

Übermitteln Sie das Dokument nicht nur deshalb erneut, weil UPO noch nicht sichtbar ist. Prüfen Sie zuerst Status und KSeF-Nummer.

Eine Sitzungs- oder Rechnungsreferenz dient der technischen Nachverfolgung und ist keine KSeF-Nummer. Die KSeF-Nummer identifiziert eine angenommene Rechnung, UPO ist die amtliche Bestätigung nach positiver Verarbeitung.

Der Rechnungsstatus kann KSeF-Nummer, Vergabedatum und UPO-Downloadadresse enthalten. Diese Angaben entstehen durch den Erfolg der Rechnung, nicht allein durch den Start der Übermittlung.

Bei negativer Prüfung vergibt KSeF keine Nummer. Das Dokument wurde nicht in KSeF ausgestellt und kann nach Korrektur erneut als ursprüngliche Rechnung übermittelt werden.

P_1 enthält das vom Aussteller angegebene Ausstellungsdatum. Vergleichen Sie es mit dem tatsächlichen Übermittlungsdatum. Drei Beziehungen führen zu drei unterschiedlichen Ergebnissen.

Ablehnung: Die Datei wird am 2. Juni 2026 gesendet, P_1 enthält jedoch den 3. Juni 2026. Das zukünftige Datum führt zur Ablehnung am Gateway.

Offline24: P_1 enthält den 2. Juni 2026, die Rechnung wird am 3. Juni gesendet. Das frühere P_1 führt nicht automatisch zur Ablehnung, sondern zum Modus offline24.

Seit dem 1. Februar 2026 gilt FA(3) als Format für strukturierte Rechnungen. KSeF vergleicht die XML-Datei mit der angegebenen XSD-Struktur. Fehlende Pflichtfelder, ungültige Werteformate, falsche Datentypen, eine falsche Elementreihenfolge oder ein unpassendes Schema können zur Ablehnung führen.

Code 430 bezeichnet einen Fehler bei der Dateiprüfung, Code 450 einen Fehler bei der semantischen Prüfung. Lesen Sie die Details, korrigieren Sie die Quelldaten und erzeugen Sie die XML-Datei neu.

Die KSeF-Prüfung hat Grenzen. Das polnische Finanzministerium weist darauf hin, dass mathematische Berechnungen nicht geprüft werden. Eine Annahme bestätigt daher nicht die vollständige rechnerische, steuerliche oder geschäftliche Richtigkeit.

Eine erfolgreiche Authentifizierung bedeutet nicht automatisch, dass Sie in jedem Kontext Rechnungen ausstellen dürfen. Geschützte API-Ressourcen benötigen ein Zugriffstoken, die Übermittlung einer normalen Rechnung die Berechtigung InvoiceWrite.

Code 410 bezeichnet einen ungültigen Berechtigungsumfang. Prüfen Sie den Steuerpflichtigenkontext, die Gültigkeit von Token und Sitzung, den tatsächlichen Absender und dessen Ausstellungsrecht.

Eine XML-Änderung löst kein Zugriffsproblem. Korrigieren Sie zuerst Authentifizierung oder Berechtigungen und senden Sie danach das inhaltlich unveränderte Dokument erneut.

Code 440 bedeutet, dass KSeF ein Rechnungsduplikat erkannt hat. Die Antwort kann originalSessionReferenceNumber und originalKsefNumber enthalten und damit zur ursprünglichen Sitzung und KSeF-Nummer führen.

Suchen Sie die genannte Rechnung, prüfen Sie ihren Status und rufen Sie UPO ab. Erzeugen Sie kein neues Dokument und ändern Sie die Rechnungsnummer nicht nur zur Umgehung der Duplikatprüfung.

Offizielle Quellen bestätigen Code 440 und die API-Daten, beschreiben jedoch keinen vollständigen Erkennungsalgorithmus. Entscheiden Sie anhand des API-Ergebnisses und des Nachweises des früheren Erfolgs.

1. Sichern Sie Sitzungsreferenz, Rechnungsreferenz, genaue Uhrzeit und gesendete XML-Datei.

2. Rufen Sie den Status der konkreten Rechnung ab. Verlassen Sie sich nicht nur auf die Annahme der Anfrage durch den Endpunkt.

3. Lesen und speichern Sie code, description, details und extensions.

4. Ordnen Sie den Fehler einer Kategorie zu: P_1, FA(3) oder XSD, Semantik, Berechtigungen, Verschlüsselung, Anhang, Duplikat oder Technik.

5. Prüfen Sie vor jeder erneuten Übermittlung, ob bereits eine KSeF-Nummer vorliegt.

6. Korrigieren Sie die Quelldaten und nicht nur den finalen XML-Text.

Hat die Rechnung keine KSeF-Nummer erhalten, korrigieren Sie Quelldaten oder Zugriff. Erzeugen Sie eine neue FA(3)-XML-Datei, prüfen Sie die Struktur, öffnen Sie eine gültige Sitzung und senden Sie das Dokument erneut.

Überwachen Sie die Rechnung bis zum Endstatus. Bei 100 und 150 warten Sie weiter. Einen Fehler diagnostizieren Sie erneut. Der Prozess ist erst mit Status 200, KSeF-Nummer und UPO abgeschlossen.

Hat das Dokument bereits eine KSeF-Nummer, bearbeiten Sie es nicht und senden keine korrigierte Version als dieselbe Rechnung. Fehler werden mit einer Korrekturrechnung berichtigt.

Gehen Sie vor einer neuen Übermittlung die vollständige Kontrollliste durch. Schließen Sie insbesondere aus, dass die frühere Operation erfolgreich war, obwohl Ihre Anwendung UPO noch nicht angezeigt hat.

Ein lokaler Validator erkennt technische XML-Probleme, ersetzt aber nicht die KSeF-Prüfung, bestätigt keine Annahme und garantiert keine vollständige steuerliche Richtigkeit.

Dieser Leitfaden diagnostiziert eine konkrete Ablehnung. Den Gesamtprozess beschreibt Rechnungen an KSeF senden, die Bestätigung nach Erfolg erklärt UPO in KSeF.

Den Dokumentaufbau erläutert XML und FA(3) in KSeF. Hat die Rechnung bereits eine KSeF-Nummer, folgen Sie Korrekturrechnung in KSeF.

Bearbeiten Sie nach einem Fehler nicht wahllos Felder. Ermitteln Sie den Endstatus, sichern Sie die vollständige API-Antwort, schließen Sie einen früheren Erfolg aus und korrigieren Sie das Quellsystem.

Prüfen Sie Struktur, Berechtigungen und P_1, senden Sie die neue XML-Datei in einer gültigen Sitzung und überwachen Sie sie bis Status 200, KSeF-Nummer und UPO. Liegt die KSeF-Nummer bereits vor, erstellen Sie eine Korrektur.

Empfohlene Leitfäden: Rechnungen an KSeF senden, UPO in KSeF, XML und FA(3) und Korrekturrechnung in KSeF.