KSeF-Fehlercodes: Was das System wirklich ablehnt und wie Sie es beheben

Eine abgelehnte Rechnung existiert nicht. Rechtlich hat sie nie stattgefunden. Sie können sie weder korrigieren noch stornieren noch in der JPK_V7-Meldung referenzieren. Sie beheben den Fehler und senden erneut. Dieser Unterschied klingt trivial, bis Sie an einem Freitag um 16:55 Uhr auf den Fehlercode 21401 starren und ein Kunde auf sein Geld wartet.

Eine Umfrage von Grant Thornton vom April 2026 ergab, dass 74 Prozent der Unternehmen im ersten Monat des KSeF-Zwangs auf Fehler bei der E-Rechnung stießen. Zwanzig Prozent gaben an, dass diese Fehler den Tagesbetrieb gestört haben. Das Problem ist nicht theoretisch. Es ist die häufigste Erfahrung nach dem Start im polnischen Rechnungsumfeld.

Dieser Artikel ordnet jeden Ablehnungscode der KSeF-2.0-Taxonomie seiner Ursache, dem fehlerhaften Feld und der genauen Lösung zu. Er benennt außerdem die erfundenen Codes, die in Artikeln von Content-Farmen kursieren, denn wer nach einer falschen Taxonomie handelt, verliert Zeit und verzögert die erneute Übermittlung.

KSeF lehnt nur aus zwei Gründen ab

Das Finanzministerium bestätigte im Mai 2026 öffentlich, dass KSeF nur zwei Dinge validiert: die Einhaltung des FA(3)-Schemas und die Berechtigung des Absenders. Das System prüft keine Umsatzsteuerberechnung. Es gleicht Käuferdaten nicht mit dem Steuerregister ab. Es validiert nicht den Wechselkurswert. Es referenziert Rechnungsbeträge nicht gegen externe Datenbanken.

Eine schemakonforme Rechnung mit falschem Steuersatz, falscher NIP des Käufers und erfundenem Wechselkurs besteht die KSeF-Validierung und erhält eine KSeF-Nummer. Der Staat vergibt die Nummer, stellt das UPO (potwierdzenie przyjęcia, die Empfangsbestätigung) aus, und die Rechnung tritt in den Rechtsverkehr ein. Der inhaltliche Fehler taucht Wochen später auf: beim Abgleich, bei einer Prüfung oder wenn der Käufer feststellt, dass er keine Vorsteuer abziehen kann, weil die Rechnung die NIP eines anderen trägt.

Das ist kein Designfehler. Es ist die Architektur. KSeF ist ein Clearance-System, kein Validierungssystem. Die inhaltliche Prüfung ist Aufgabe des Steuerpflichtigen, also entweder eine manuelle Checkliste oder eine Produktfunktion. Plandesk prüft vor dem Versand, was KSeF nicht prüft: NIP-Prüfziffer und Registerabfrage, Steuerberechnung, doppelte Rechnungsnummern, NBP-Kursabgleich und die Konsistenz der GTU-Codes.

Sitzungsstatus: Wann Ihre Rechnung wirklich existiert

Bevor Sie Ablehnungscodes entschlüsseln, müssen Sie die Sitzungsstatus verstehen. Der schädlichste Fehler nach dem Start ist keine Ablehnung. Es ist ein Duplikat, das durch erneutes Senden während der Verarbeitung entsteht.

Die Status 100 und 150 sind keine Fehler. Sie bedeuten, dass KSeF die Rechnung erhalten hat und verarbeitet. Die Verarbeitungszeit des Ministeriums schwankt unter Last zwischen Sekunden und Stunden. Wer in diesem Fenster erneut sendet, erzeugt ein Rechnungsduplikat mit anderer KSeF-Nummer, die häufigste Ursache für Ablehnungen mit Code 440.

Wenn Ihr Werkzeug den Status automatisch abfragt, lassen Sie es arbeiten. Wenn Sie die Aplikacja Podatnika manuell nutzen, aktualisieren Sie die Statusseite der Sitzung. Klicken Sie nicht noch einmal auf "Senden".

Die echte Fehlertaxonomie

KSeF 2.0 liefert einen HTTP-Status plus einen exceptionCode im Antwortkörper. Die folgenden Codes stammen aus der offiziellen OpenAPI-Dokumentation des Finanzministeriums. Es sind die Codes, denen Praktiker tatsächlich begegnen.

Code 21401: Verstoß gegen das FA(3)-Schema

Bedeutung: Das übermittelte XML entspricht nicht dem FA(3)-Schema.

Typische Ursachen:

• Veraltete FA(2)-Vorlage noch im Einsatz (FA(2) wurde am 1. Februar 2026 endgültig deaktiviert)
• BOM-Bytes (Byte Order Mark) am Anfang der XML-Datei
• Falsche Reihenfolge der Elemente oder fehlende Pflichtelemente
• Falsche Namespace-Deklaration

Lösung: Erzeugen Sie die Rechnung aus einer aktuellen FA(3)-Vorlage neu. Wenn Sie eine Rechnungssoftware nutzen, aktualisieren Sie sie auf die neueste Version. Bearbeiten Sie XML niemals von Hand. Das Schema ist so streng, dass manuelle Eingriffe mehr Fehler erzeugen als sie beheben.

Beispiel: Die Rechnung einer Freiberuflerin wird mit 21401 abgelehnt, weil ihr Rechnungswerkzeug zuletzt im Januar 2026 aktualisiert wurde und noch FA(2)-XML erzeugt. Die Lösung ist ein Softwareupdate, kein XML-Eingriff.

Code 21405: Fehler bei der Eingabevalidierung

Bedeutung: Eine Validierung auf Feldebene ist fehlgeschlagen. Das XML ist strukturell gültig, aber ein bestimmtes Feld enthält Daten im falschen Format.

Typische Ursachen:

• NIP mit Bindestrichen, Leerzeichen oder "PL"-Präfix (FA(3) erwartet 10 Ziffern ohne Trennzeichen)
• Datum im falschen Format (FA(3) verlangt YYYY-MM-DD)
• Zahlenfeld mit Komma statt Punkt als Dezimaltrennzeichen
• KursWaluty mit weniger als 6 Dezimalstellen

Lösung: Korrigieren Sie die Quelldaten in der Kundenkarte oder im Rechnungsformular und senden Sie erneut. Die Fehlerantwort enthält den Feldpfad, der genau zeigt, welches Element betroffen ist.

Beispiel: Die Rechnung eines Einzelunternehmers wird mit 21405 abgelehnt, weil die Kundenkarte die NIP des Käufers als "PL-123-456-78-90" speichert. FA(3) erwartet "1234567890". Kundenkarte korrigieren, neu erzeugen, erneut senden.

Code 21301: Autorisierungsfehler

Bedeutung: Der Absender hat keine Berechtigung, Rechnungen für die NIP im Rechnungskopf auszustellen.

Typische Ursachen:

• Token abgelaufen (die Gültigkeitsdauer von KSeF-Tokens hängt von der Art der Erteilung ab)
• Token für eine andere NIP ausgestellt als die in der Rechnung
• Der Administrator hat Ausstellungsrechte erteilt, aber die Berechtigung ist noch nicht wirksam
• Persönliche Anmeldung (Profil Zaufany) statt Token oder Zertifikat

Lösung: Erzeugen Sie das Token mit den korrekten Berechtigungen für die ausstellende NIP neu. Wenn Sie eine persönliche Anmeldung nutzen, wechseln Sie zur Token-basierten Authentifizierung. Diese war schon vor dem Start die empfohlene Methode und wurde nach dem Zusammenbruch von Profil Zaufany am 2. und 3. Februar 2026 der De-facto-Standard.

Beispiel: Ein Buchhaltungsbüro versucht, eine Rechnung für einen neuen Mandanten auszustellen, und erhält 21301. Das Token des Büros wurde ausgestellt, bevor der Mandant in den KSeF-Berechtigungen ergänzt wurde. Die Lösung: Ausstellungsrecht für die NIP des Mandanten erteilen, dann das Token neu erzeugen.

Code 440: Rechnungsduplikat

Bedeutung: Eine Rechnung mit derselben Nummer desselben Ausstellers existiert bereits in KSeF.

Typische Ursachen:

• Blindes erneutes Senden nach einem Timeout (die häufigste Ursache)
• Parallele Ausstellung über Rechnungs-App und Aplikacja Podatnika
• Sitzungsstatus vor dem erneuten Senden nicht geprüft

Lösung: Fragen Sie KSeF vor dem erneuten Senden mit Ihrer eigenen Rechnungsnummer ab. Wenn die erste Übermittlung erfolgreich war (Status 200), übernehmen Sie die vorhandene Rechnung. Erzeugen Sie kein Duplikat. Wenn die erste Übermittlung wirklich fehlgeschlagen ist, beheben Sie den Fehler und senden Sie mit derselben Rechnungsnummer erneut.

Beispiel: Eine Nutzerin sendet eine Rechnung, erhält einen Timeout und sendet erneut. Die erste Übermittlung war tatsächlich erfolgreich, nur die Antwort kam verzögert. Die zweite Übermittlung läuft auf 440. Die richtige Maßnahme: Status der ersten Sitzung prüfen, den Status 200 finden und diese KSeF-Nummer verwenden.

HTTP 500, 503, 429: Serverseitige Fehler

Bedeutung: Die KSeF-Plattform ist überlastet oder begrenzt die Anfragerate.

Typische Ursachen:

• Verkehrswellen in der Startphase (Februar und April 2026)
• Rate-Limiting nach zu vielen Anfragen in kurzer Zeit
• Vorübergehende Infrastrukturprobleme

Lösung: Wiederholungsversuche mit Backoff implementieren. Wenn der Fehler anhält, in den Offline24-Modus wechseln: Rechnung lokal ausstellen und bis zum nächsten Werktag übermitteln. Das Ausstellungsdatum P_1 bleibt im Offline-Modus erhalten, das Rechtsdatum der Rechnung verschiebt sich also nicht.

Geisterrechnungen: Angenommen, aber unsichtbar

Ein Muster, das keinen Ablehnungscode erzeugt, aber genauso schmerzt: Die Rechnung wird angenommen (Status 200, KSeF-Nummer vergeben, UPO ausgestellt), doch der Käufer sieht sie nicht in seinem KSeF-Posteingang. Sein Vorsteuerabzug ist blockiert. Experten führen das auf Integrationsfehler zwischen ERP und KSeF sowie auf unklare Statuslogik für gesendet, angenommen und abgelehnt zurück.

Die Rechnung existiert. Sie ist im Rechtsverkehr. Nur der Buchhalter des Käufers kommt nicht heran. Der Workaround: Der Verkäufer teilt KSeF-Nummer und UPO direkt mit dem Käufer, der KSeF dann manuell abfragen kann. Die strukturelle Lösung ist eine bessere Statussynchronisation zwischen KSeF und den Buchhaltungssystemen, eines der Probleme, die das angekündigte Paket "7 Verbesserungen" des Ministeriums zum 1. Januar 2027 angehen soll.

Erfundene Fehlercodes, die Sie ignorieren können

Content-Farmen haben Fehlercodes erfunden, die in der KSeF-API-Dokumentation nicht existieren. Wer nach KSeF-Fehlercodes sucht, findet Artikel mit Codes wie "TOTAL_MISMATCH", "NIP_REGISTRY_REJECTION" oder "VAT_RATE_INVALID". Diese Codes sind erfunden. Sie entsprechen keinem exceptionCode in der offiziellen OpenAPI-Spezifikation.

Das Finanzministerium hat öffentlich erklärt, dass KSeF weder Rechenergebnisse noch Käuferdaten noch Steuersätze validiert. Jeder Artikel, der behauptet, KSeF lehne Rechnungen wegen falscher Steuerbeträge oder nicht registrierter Käufer-NIP ab, liegt falsch. Diese Fehler passieren KSeF. Sie tauchen später auf: als Korrektur, als Prüfung oder als verlorener Vorsteuerabzug.

Wenn Ihnen ein Fehlercode begegnet, der nicht in der offiziellen Dokumentation steht, prüfen Sie die Quelle. Maßgeblich ist die OpenAPI-Spezifikation des Finanzministeriums, gespiegelt im Dokumentationsrepository der KSeF-API.

Sieben Prüfungen vor jeder Übermittlung

Führen Sie diese Prüfungen aus, bevor Sie eine Rechnung an KSeF senden. Sie fangen die Fehler ab, die KSeF nicht abfängt.

1. NIP-Format: 10 Ziffern, keine Bindestriche, keine Leerzeichen, kein "PL"-Präfix.
2. NIP-Prüfziffer: Kontrollziffer validieren. KSeF prüft das nicht.
3. NIP-Registerabfrage: Prüfen, ob der Käufer auf der biała lista podatników VAT (Weißen Liste der USt-Pflichtigen) steht.
4. Steuerberechnung: Netto mal Satz ergibt Steuer. Netto plus Steuer ergibt Brutto. Jede Position prüfen.
5. Eindeutigkeit der Rechnungsnummer: KSeF vor dem Versand mit Ihrer eigenen Rechnungsnummer abfragen.
6. Datumskonsistenz: Ausstellungsdatum (P_1) ist heute oder liegt im Offline24-Fenster. Keine Rückdatierung.
7. Währungsfelder: KodWaluty ist ein gültiger ISO-4217-Code. KursWaluty hat 6 Dezimalstellen. Der Kurs entspricht der NBP-Tabelle des richtigen Tages.

Diese Prüfungen dauern in Software Sekunden und beseitigen die Mehrheit der Fehler nach dem Start. Manuell sind sie möglich, aber fehleranfällig. Deshalb ist die Prüfung vor dem Versand eine Produktfunktion und keine Dokumentationsübung.

Dieser Text dient der allgemeinen Information und stellt keine Rechts- oder Steuerberatung dar. Prüfen Sie im Einzelfall die aktuellen Regeln oder wenden Sie sich an einen Steuerberater.