Wie liest man XML aus KSeF?

XML aus KSeF ist eine Datendatei, kein Dokument, das wie ein gewöhnliches PDF gelesen wird. Sie können sie in einem Texteditor öffnen, doch ohne Kenntnis der FA(3)-Struktur lassen sich Rechnungsnummer, KSeF-Nummer, Parteidaten und technische Metadaten leicht verwechseln.

Die sicherste Reihenfolge lautet: Herkunft der Datei bestätigen, FA(3)-Version prüfen, Verkäufer- und Käuferdaten lesen, Positionen und Beträge vergleichen und anschließend validieren. Erst danach hilft eine lesbare PDF-Visualisierung bei der menschlichen Prüfung.

Die Umwandlung von XML in PDF ersetzt keine Validierung und bestätigt nicht, dass die Rechnung von KSeF angenommen wurde. Das PDF ist eine Vorschau. Maßgeblich sind FA(3)-XML, Systemstatus, KSeF-Nummer und UPO.

Die folgende Tabelle zeigt, was geklärt sein sollte, bevor eine KSeF-XML als bereit für Buchhaltung oder Weitergabe gilt.

Eine KSeF-XML-Datei enthält eine strukturierte Rechnung, also ein Dokument nach einem bestimmten Datenschema. Verkäufername, Steuer-ID, Rechnungsnummer, Datum, Positionen, Mehrwertsteuersätze und Beträge stehen in konkreten Elementen, die Buchhaltungssoftware lesen kann.

Für Menschen muss eine solche Datei nicht freundlich aussehen. Sie sehen Tags, spitze Klammern und technische Feldnamen. Für KSeF ist genau diese Struktur entscheidend: Das System bewertet Daten im Format XML FA(3), nicht die grafische Darstellung.

Wenn Sie die Grundlagen des Formats verstehen möchten, lesen Sie XML und das FA(3)-Format in KSeF. Dieser Beitrag konzentriert sich auf das praktische Lesen einer Datei, die bereits auf Ihrem Rechner liegt oder aus Buchhaltungssoftware stammt.

Klären Sie zuerst, woher die XML stammt. Eine direkt aus KSeF geladene Datei, ein Export aus Buchhaltungssoftware und ein E-Mail-Anhang sollten unterschiedlich behandelt werden. Ist die Quelle unbekannt, starten Sie keine Makros, Skripte oder Konverter von beliebigen Websites.

Für den ersten Blick reicht ein normaler Texteditor. Bearbeiten Sie die Datei aber nicht, wenn sie als Nachweis, Teil eines Buchhaltungsprozesses oder Material zur Fehlerdiagnose dienen kann. Speichern Sie das Original unverändert und arbeiten Sie mit einer Kopie.

Soll die Datei für Buchhaltung oder Klärung von Abweichungen verwendet werden, speichern Sie auch den Kontext: wer sie übergeben hat, wann sie geladen wurde, ob sie eine KSeF-Nummer hat, ob UPO vorhanden ist und aus welchem System der Export stammt.

Dass sich eine Datei öffnen lässt, bedeutet noch nicht, dass die Rechnung geprüft wurde. Praktisch müssen vier Tätigkeiten getrennt werden: Text lesen, visualisieren, validieren und in KSeF bestätigen.

Diese Unterscheidung schützt vor einem häufigen Fehler: Jemand sieht ein lesbares PDF oder eine korrekt geöffnete XML-Datei und nimmt an, das Dokument sei automatisch korrekt. Jede Ebene beantwortet eine andere Frage.

Geht das Dokument in die Buchhaltung, bleiben Sie nicht auf der ersten Ebene stehen. Geöffnete XML zeigt Daten, aber erst Validierung, KSeF-Nummer, Metadaten und UPO ergeben ein sinnvolles Bild des Rechnungsstatus.

Sie müssen nicht das gesamte XSD-Schema kennen, um eine erste Kontrolle durchzuführen. Es reicht zu wissen, welche Bereiche den wichtigsten Teilen der Rechnung entsprechen. Knotennamen wirken technisch, haben aber buchhalterische Bedeutung.

Naglowek identifiziert Formular, Strukturvariante und technische Daten. Podmiot1 ist der Verkäufer, Podmiot2 der Käufer. Fa enthält Rechnungsdaten wie Nummer, Daten, Währung und Rechnungsart. FaWiersz beschreibt Positionen. Zusammenfassende Felder in Fa zeigen Netto-, MwSt.- und Bruttowerte nach Steuersätzen.

Praktisches Beispiel: Suchen Sie die Steuer-ID des Verkäufers, beginnen Sie bei Podmiot1. Suchen Sie die eigene Rechnungsnummer, gehen Sie zum Bereich Fa. Prüfen Sie Beträge und Sätze, vergleichen Sie FaWiersz mit den zusammenfassenden Feldern in Fa, statt das ganze Dokument von oben zu lesen.

Diese Karte ist keine vollständige Liste der Pflichtfelder. Anforderungen hängen vom Rechnungstyp und den FA(3)-Regeln ab. Die Karte dient der Orientierung und ersetzt keine Validierung.

Die erste Kontrolle bedeutet nicht, die gesamte Datei von oben bis unten zu lesen. Beginnen Sie mit Feldern, die meist über Identifikation und weitere Buchhaltungsarbeit entscheiden.

Vergleichen Sie die Rechnungsnummer mit dem Quelldokument oder Buchhaltungssystem. Prüfen Sie danach Steuer-ID von Verkäufer und Käufer, Ausstellungsdatum, Leistungsdatum, sofern vorhanden, Währung, Positionen, MwSt.-Sätze und Summen. Hat die Rechnung eine KSeF-Nummer, speichern Sie sie zusammen mit Annahmedatum und Status.

Sehen Sie eine Abweichung zwischen XML und erwartetem Dokument, bearbeiten Sie die finale Datei nicht manuell, bevor die Ursache verstanden ist. Meist werden Daten im Quellsystem korrigiert und anschließend eine neue XML erzeugt.

Eine häufige Fehlerquelle ist die Verwechslung von Rechnungsnummer und KSeF-Nummer. Die Rechnungsnummer vergibt der Verkäufer in seinem System. Die KSeF-Nummer vergibt das zentrale System nach Annahme des Dokuments und sie hat eine eigene technische Struktur.

Die KSeF-Nummer hat 35 Zeichen und besteht aus der Steuer-ID des Verkäufers, dem Annahmedatum, einem 12-stelligen technischen Teil und einer 2-stelligen CRC-8-Prüfsumme. Sie ersetzt nicht die Rechnungsnummer aus dem Verkaufssystem und sollte nicht manuell erfunden oder korrigiert werden.

Beim Empfangen von Rechnungen über KSeF können sowohl die XML-Rechnung als auch Metadaten auftreten. Metadaten helfen beim Suchen, Prüfen von Kennungen und Status, sind aber nicht der vollständige Rechnungsinhalt. Wenn Sie Kennungen genauer trennen möchten, lesen Sie KSeF-Nummer auf der Rechnung. Für Audits sollten XML, Metadaten, KSeF-Nummer, Status und UPO in KSeF zusammen aufbewahrt werden, sofern verfügbar.

Ein lesbares PDF hilft schnell zu sehen, was auf der Rechnung steht. Zuerst sollte jedoch klar sein, ob die XML technisch sinnvoll ist. Ein Validator erkennt Probleme, die im Preview nicht sichtbar sind, zum Beispiel ein falsches Datumsformat, ein fehlendes Pflichtelement oder eine Schemaabweichung.

Technische Validierung garantiert keine steuerliche Richtigkeit. Sie hilft, Strukturprobleme und einige Inkonsistenzen zu finden, entscheidet aber nicht, ob die Transaktion korrekt besteuert ist, ob der MwSt.-Satz fachlich richtig ist oder ob die Rechnung zum Vertrag passt.

Wenn Sie die Datei vor weiterer Arbeit prüfen möchten, nutzen Sie den KSeF XML-Validator. Es ist ein öffentliches Tool mit Limit in einem 24-Stunden-Fenster; aktuelle Nutzungsbedingungen prüfen Sie am besten direkt auf der Tool-Seite.

XML ist ein Format für Systeme, PDF ein bequemer Blick für Menschen. Eine Umwandlung in PDF ist sinnvoll, wenn Daten schnell mit einer Bestellung verglichen, einer nicht-technischen Person gezeigt, zur Freigabe weitergegeben oder ohne Scrollen durch rohe XML geprüft werden sollen.

Behandeln Sie das PDF jedoch nicht als neue Version der Rechnung. Entsteht es aus XML, ist es nur eine Visualisierung der Daten. Enthalten die Quelldaten einen Fehler, zeigt das PDF denselben Fehler nur schöner an.

KSeFGPT stellt einen KSeF XML-zu-PDF-Konverter bereit. Es ist ein öffentliches Tool mit Limit in einem 24-Stunden-Fenster; aktuelle Bedingungen prüfen Sie direkt auf der Konverterseite.

Die folgenden Signale bedeuten nicht immer eine Ablehnung der Rechnung, sollten den Prozess aber stoppen und eine Prüfung der Datenquelle auslösen. Besondere Vorsicht gilt Dateien, die gebucht werden oder Grundlage eines Streits mit einem Vertragspartner sind.

Wenn etwas verdächtig wirkt, beschränken Sie sich nicht auf die PDF-Visualisierung. Bewahren Sie die ursprüngliche XML auf, starten Sie die Validierung, prüfen Sie Metadaten und vergleichen Sie das Dokument mit dem System, das es erzeugt hat.

Laden Sie sensible XML nicht in zufällige Konverter aus Suchergebnissen hoch. Eine Rechnung kann Vertragspartnerdaten, Adressen, Kontonummern, Beträge und Handelsinformationen enthalten. Nutzen Sie nur Tools, deren Datenschutz und Verarbeitungsumfang Sie verstehen.

Ein praktischer Prozess sollte drei Ebenen haben. Zuerst werden die originale XML und Download-Metadaten aufbewahrt. Danach wird die Datei technisch geprüft. Am Ende entsteht eine lesbare PDF-Vorschau oder die Daten gehen ins Buchhaltungssystem.

So verlieren Sie den Quellnachweis nicht. Tritt unterwegs ein Fehler auf, können Sie zum Original zurückkehren, KSeF-Status prüfen, Rechnungsnummer mit KSeF-Nummer vergleichen und nachvollziehen, wer wann mit der Datei gearbeitet hat.

Bei größeren Dokumentenmengen wird manuelles Öffnen von XML schnell riskant. Dann lohnt sich ein Tool, das Import, Validierung, Vorschau, Vertragspartnersuche und Archivierung der Ergebnisse verbindet.

Wenn Sie die Dokumentstruktur verstehen möchten, beginnen Sie mit XML und das FA(3)-Format in KSeF. Wenn Sie eine Rechnung als PDF erhalten haben und zuerst XML benötigen, lesen Sie Kostenloser PDF-zu-XML-KSeF-Konverter.

Für die technische Kontrolle von Dateien hilft XML-Validierung und Verarbeitung in KSeF. Wurde die XML vom System abgelehnt, lesen Sie Rechnung von KSeF abgelehnt.

Wie öffne ich eine XML-Datei aus KSeF? - Eine XML-Datei kann in einem Texteditor geöffnet werden. Für die praktische Arbeit ist jedoch ein Validator oder ein XML-zu-PDF-Konverter besser. Der Editor zeigt rohe Tags, ein Tool zeigt Rechnungsdaten lesbar an und hilft, technische Probleme zu erkennen.

Ist ein PDF aus XML die offizielle KSeF-Rechnung? - Nein. Das PDF ist nur eine lesbare Visualisierung. In KSeF ist das relevante Dokument die strukturierte FA(3)-XML zusammen mit Systemmetadaten, KSeF-Nummer und Annahmestatus.

Wo finde ich die KSeF-Nummer bei der Arbeit mit XML? - Die KSeF-Nummer wird nach Annahme der Rechnung durch das System vergeben; sie ist nicht die normale vom Verkäufer eingetragene Rechnungsnummer. Sie ist kein Feld derselben FA(3)-Rechnung, daher sollte sie in UPO, Metadaten, API-/Statusantworten oder im KSeF-System bestätigt werden.

Reicht manuelles Lesen von XML zur Prüfung einer Rechnung? - Nein. Manuell können Parteien, Rechnungsnummer, Daten, Positionen und Beträge geprüft werden. Die FA(3)-Struktur, Datentypen und technische Regeln sollte jedoch ein Validator prüfen.

Beginnen Sie nicht damit, Daten aus XML in eine Tabelle abzuschreiben. Bewahren Sie zuerst das Original auf, bestätigen Sie die Quelle, prüfen Sie KSeF-Nummer oder Status und starten Sie die Validierung. Erst danach PDF erzeugen, Daten an die Buchhaltung übergeben oder Abweichungen mit dem Vertragspartner klären.

Für einzelne Dateien reicht die Kombination aus Validator und XML-zu-PDF-Konverter. Bei größeren Mengen braucht es einen Prozess, der Quelle, Version, Validierungsergebnis und Archiv des Dokuments nachverfolgt.

Empfohlene Beiträge: XML und FA(3) in KSeF, KSeF-Nummer auf der Rechnung, Rechnungsstatus in KSeF und UPO in KSeF fehlt.