Wie prüfen Sie den Status einer Rechnung in KSeF nach dem Versand?

Der Rechnungsstatus in KSeF zeigt, ob ein Dokument noch verarbeitet wird, erfolgreich abgeschlossen wurde oder eine Fehlerdiagnose benötigt. Die Information, dass eine Rechnung gesendet wurde, reicht nicht aus, um sie als angenommen zu behandeln.

Status 100 und 150 sind vorläufige Zustände, 200 bedeutet Erfolg der Rechnung, und Fehlerstatus erfordern das Lesen der Details vor jeder erneuten Sendung. Verwechseln Sie eine technisch erfolgreiche HTTP-Antwort nicht mit dem Rechnungsstatus im Dokumentstatus.

Sitzungsstatus, Rechnungsreferenznummer, KSeF-Nummer und UPO sind verschiedene Elemente desselben Prozesses. Erst zusammen zeigen sie, ob Sie warten, eine Bestätigung abrufen oder eine Ablehnung diagnostizieren sollten.

Nach dem Senden der XML-Datei prüfen Sie den Status derselben Rechnung oder Sitzung, senden Sie nicht automatisch eine zweite Version, speichern Sie bei Status 200 die KSeF-Nummer und UPO, und lesen Sie bei einem Fehler Code, Beschreibung und Antwortdetails, bevor Sie die nächste Entscheidung treffen.

Die Rechnung wurde an KSeF gesendet, aber Sie wissen nicht, ob sie bereits angenommen ist, noch verarbeitet wird oder abgelehnt wurde. Dieser Leitfaden führt Sie durch die Entscheidungen nach dem Versand: vom vorläufigen Status bis zur KSeF-Nummer, UPO oder Fehlerdiagnose.

Nach dem Versand sollte eine technische und geschäftliche Spur vorhanden sein. Wenn Sie nur eine allgemeine Sendemeldung haben, haben Sie den Prozess noch nicht vollständig unter Kontrolle.

Der Mindestdatensatz umfasst Sitzungsreferenznummer, Rechnungsreferenznummer, eigene Rechnungsnummer aus dem Rechnungsnummernfeld, NIP des Verkäufers, Versanddatum, Status, mögliche KSeF-Nummer und UPO-Information. Diese Elemente erlauben die Rückkehr zu demselben Vorgang, statt zu raten, ob das Dokument erneut gesendet werden muss.

Der Sitzungsstatus beschreibt den Zustand des Versandcontainers. Der Rechnungsstatus beschreibt ein konkretes Dokument in dieser Sitzung. Die Referenznummer führt zurück zum technischen Vorgang, ist aber keine KSeF-Nummer.

In einer interaktiven Sitzung können Sie ein einzelnes Dokument innerhalb der Sitzung verfolgen. In einer Batch-Sitzung oder bei mehreren Rechnungen müssen Sie zusätzlich prüfen, wie viele Dokumente korrekt verarbeitet wurden, wie viele abgelehnt wurden und welchen Status einzelne Rechnungen haben.

Die KSeF-Nummer erscheint erst nach Annahme der Rechnung. Wenn Sie nur eine Referenznummer sehen, befinden Sie sich noch in der Verfolgung des Vorgangs, nicht bei der bestätigten Annahme des Dokuments.

Die wichtigste Regel nach dem Versand lautet: vorläufigen Status überwachen, Erfolg archivieren, Fehler diagnostizieren. Es gibt weder eine einzelne Schaltfläche noch einen einzelnen Code, der die Prüfung des Rechnungsstatus ersetzt.

Die folgende Tabelle ist eine praktische Entscheidungshilfe. Sie ersetzt nicht die vollständige API-Dokumentation, hilft aber, die häufigsten Fehler nach dem Senden der XML-Datei zu vermeiden.

Wenn der Rechnungsstatus 100 oder 150 ist, besteht die richtige Reaktion darin, denselben Versand weiter zu überwachen. Kommunizieren Sie intern noch nicht, dass die Rechnung angenommen wurde, behandeln Sie sie aber auch nicht automatisch als abgelehnt.

Wenn der Rechnungsstatus 200 ist, gehen Sie zu KSeF-Nummer, Annahmedatum und UPO über. Das ist die Phase der Bestätigungsablage, nicht der Fehlersuche.

Wenn der Status auf einen Fehler hinweist, suchen Sie keine UPO. Sie lesen Code, Beschreibung, Details und mögliche Duplikatdaten. Erst danach entscheiden Sie, ob Daten korrigiert, Berechtigungen repariert, der ursprüngliche Versand gesucht oder ein technischer Vorgang wiederholt werden muss.

Behandeln Sie den Sitzungsstatus nicht als automatische Bestätigung für jedes Dokument. Sitzung und Rechnungen haben getrennte Kontrollebenen. Besonders bei Paketen müssen die Zähler korrekt und fehlerhaft verarbeiteter Rechnungen sowie die Dokumentliste der Sitzung geprüft werden.

In der Praxis reicht es nicht zu prüfen, ob die Sitzung verarbeitet wurde. Sie müssen feststellen, welche Rechnungen in dieser Sitzung erfolgreich waren, welche Fehler haben und welche Kennungen gespeichert werden müssen. Das schützt vor einer Situation, in der ein Paket als bearbeitet wirkt, aber eine einzelne Rechnung korrigiert werden muss.

Eine fehlende UPO ist keine eigenständige Diagnose. Bei Status 100 und 150 ist UPO noch nicht das Ziel, weil die Rechnung noch kein Endergebnis hat.

Bei Status 200 prüfen Sie KSeF-Nummer, generierten UPO-Link, Gültigkeit des Links und das Werkzeug, über das das Dokument gesendet wurde. Der Download-Link zur UPO ist Teil der Statusantwort und kann eine erneute Statusabfrage erfordern, wenn der Link abgelaufen ist.

Wenn das Problem eine nicht sichtbare Bestätigung ist, lesen Sie den Leitfaden Fehlende UPO in KSeF. Dieser Artikel konzentriert sich auf den Status nach dem Versand, nicht auf das vollständige Verfahren zur Wiederbeschaffung der UPO.

Ein erneuter Versand ist erst sinnvoll, wenn klar ist, was mit dem vorherigen Vorgang passiert ist. Wenn Sie nicht wissen, ob das Dokument bereits eine KSeF-Nummer erhalten hat oder ob die API ein Duplikat gemeldet hat, kann eine zweite Sendung die Nachvollziehbarkeit verschlechtern.

Bei Code 440 suchen Sie zuerst die ursprüngliche Sitzung und die ursprüngliche KSeF-Nummer, falls sie zurückgegeben wurden. Bei XML-, Semantik- oder Berechtigungsfehlern korrigieren Sie die Ursache, nicht nur die finale Datei.

Das detaillierte Diagnoseverfahren finden Sie im Leitfaden Rechnung von KSeF abgelehnt.

Im Benutzerprozess beginnen Sie mit dem richtigen Unternehmen. Wählen Sie den korrekten NIP des Verkäufers oder Firmenkontext, weil ein Status aus einem falschen Unternehmen den tatsächlichen Versand nicht erklärt.

Suchen Sie danach die Rechnung anhand eigener Rechnungsnummer, Datum, Geschäftspartner, Referenznummer oder KSeF-Nummer, falls sie bereits vergeben wurde. Prüfen Sie den Dokumentstatus, nicht nur den Status der letzten Aktion in der Oberfläche.

Wenn die Rechnung erfolgreich ist, speichern Sie die KSeF-Nummer und laden Sie UPO in dem Werkzeug herunter, das den Versand abgewickelt hat. Wenn der Status einen Fehler zeigt, lesen Sie die Details. Ich nenne hier keine Schaltflächennamen als verbindlich, weil sich Oberflächen und Handbücher ändern können.

In einer API-Integration wird der Status schrittweise geprüft. Zuerst bestimmen Sie die Sitzung, dann die Dokumente in der Sitzung, und erst nach Erfolg einer konkreten Rechnung gehen Sie zu UPO über. UPO ersetzt den Status nicht, sondern ist der nächste Schritt nach bestätigtem Erfolg.

Typische Kontrollpfade umfassen die Sitzungsliste, Details einer bestimmten Sitzung, die Rechnungsliste in der Sitzung, Details einer bestimmten Rechnung und die Liste abgelehnter Rechnungen.

Die Integration sollte mindestens Sitzungsreferenznummer, Rechnungsreferenznummer, Status, KSeF-Nummer, Annahmedatum, Fehler und UPO-Informationen speichern. Ohne diese Daten werden spätere Bearbeitung von Reklamationen, Duplikaten oder fehlenden Bestätigungen manuell.

In KSeFGPT soll der Status nach dem Versand für Personen lesbar sein, die keine rohe API-Antwort analysieren möchten. Nach dem Versand hilft die Anwendung zu sehen, ob das Dokument an KSeF übergeben wurde, welchen Status es hat, ob eine KSeF-Nummer erschienen ist und ob für das bearbeitete Dokument UPO verfügbar ist.

Diese Unterscheidung ist wichtig: KSeFGPT ordnet Status und Bestätigungen für Rechnungen, die über diese Anwendung gesendet wurden. Sie sollten nicht annehmen, dass das Werkzeug UPO für jede Rechnung abruft, die irgendwann über ein anderes ERP oder eine andere Integration gesendet wurde. In diesem Fall suchen Sie die Bestätigung im sendenden System, in der KSeF-Steuerzahleranwendung oder in Ihrer eigenen API-Integration.

Praktisch bedeutet das eine zusammenhängende Arbeitsspur: Rechnung, Status, KSeF-Nummer und Bestätigung sind im selben Kontext verbunden. Dadurch lässt sich ein verarbeitetes Dokument leichter von einem angenommenen unterscheiden und ein Fehler von einer nur nicht sichtbaren UPO.

Die häufigsten Fehler entstehen nicht durch einen einzelnen schwierigen Code, sondern durch das Vermischen von Ebenen: HTTP, Sitzung, Rechnung, Referenznummer, KSeF-Nummer und UPO.

Arbeiten Sie nach dem Senden einer Rechnung an KSeF immer in derselben Reihenfolge: Status prüfen, Kennungen prüfen, entscheiden, ob Sie warten, UPO abrufen oder einen Fehler diagnostizieren. Beginnen Sie nicht mit erneutem Versand und archivieren Sie nicht nur die Referenznummer als Annahmenachweis.

Wenn Sie den vollständigen Prozess benötigen, beginnen Sie mit Rechnungen an KSeF senden. Nach einem Erfolgsstatus gehen Sie zu UPO in KSeF. Wenn die Bestätigung nicht sichtbar ist, nutzen Sie den Leitfaden Fehlende UPO in KSeF. Bei einem Dokumentfehler lesen Sie Rechnung von KSeF abgelehnt.