XML und das FA(3)-Schema in KSeF - ein Leitfaden fur Unternehmen

Zusammenfassung

XML ist ein strukturiertes Datenformat, kein Bild und kein PDF. KSeF verlangt es, weil Maschinen es automatisch lesen und validieren konnen.

Das Schema FA(2) war die Vorgangervorganger der Rechnungsstruktur. Ab 2026 gilt FA(3) verbindlich. Wenn Ihr System noch FA(2) verwendet, werden Rechnungen abgelehnt.

Fehlerhaftes XML bedeutet eine abgelehnte Rechnung - und eine abgelehnte Rechnung existiert rechtlich nicht. Die Validierung vor der Ubermittlung ist eine Pflicht, keine Option.

Inhaltsverzeichnis

1. Was ist XML - und warum verlangt KSeF es

2. Das FA(2)-Schema - was der Name bedeutet und woher es stammt

3. Rechnungsstruktur in FA(2) - wichtige XML-Elemente

4. FA(2) vs. FA(3) - was sich geandert hat und was jetzt gilt

5. Warum XML und das FA-Schema fur die KSeF-Integration wichtig sind

Wichtigste Erkenntnisse

Die folgende Tabelle fasst die wichtigsten Erkenntnisse des Artikels zusammen - ein Satz pro Abschnitt.

Was ist XML - und warum verlangt KSeF es

XML (eXtensible Markup Language) ist ein textbasiertes Format zur Speicherung von Daten in einer Form, die sowohl fur Menschen als auch fur Maschinen lesbar ist. Es ist weder eine Programmiersprache noch Software - es ist eine Methode zur Organisation von Informationen mithilfe von Tags. Jedes Datenelement wird durch ein offnendes und ein schliessendes Tag-Paar beschrieben; ein Firmenname, ein Rechnungsbetrag oder eine NIP-Steuernummer werden in klar bezeichneten Feldern gespeichert.

Die beste Analogie ist ein amtliches Formular. Ein Freitext-Schreiben kann dieselben Informationen enthalten wie ein ausgefulltes Formular, aber ein Sachbearbeiter muss moglicherweise lange suchen, um die Antwort auf eine bestimmte Frage zu finden. Ein Formular mit vordefinierten Feldern liefert die Antwort sofort. XML funktioniert auf genau dieselbe Weise: Anstelle von Freitext gibt es prazise beschriftete Felder, die ein System automatisch auslesen kann.

PDF funktioniert vollig anders. Eine PDF-Datei ist im Wesentlichen eine visuelle Beschreibung eines Dokuments - sie teilt Drucker und Bildschirm mit, wo Text gezeichnet werden soll, wie viele Pixel er haben soll und wie er aussehen soll. Ein Mensch sieht eine Rechnung. Ein System sieht ein Bild. Es gibt keine Daten, die ein Computer ohne zusatzliche Texterkennung (OCR) verarbeiten konnte. Genau deshalb akzeptiert KSeF keine PDFs als gultige Rechnungen.

Das Finanzministerium hat XML aus mehreren Grunden gewahlt. Erstens ist XML maschinenlesbar: Das System kann uberprufen, ob eine NIP 10 Ziffern hat, ob Betrage ubereinstimmen und ob alle Pflichtfelder ausgefullt sind - ohne menschliches Zutun. Zweitens ist XML validierbar: Ein Dokument kann noch vor der Ubermittlung gegen eine Vorlage (ein sogenanntes XSD-Schema) gepruft werden. Drittens ist XML interoperabel: Jedes ERP-System, jede Anwendung und jeder Server kann es auf dieselbe Weise lesen, unabhangig vom Softwareanbieter.

Zusammenfassend der Unterschied, den jeder Unternehmer kennen sollte: PDF ist fur Augen, XML ist fur Systeme. KSeF ist ein System, kein Mensch - daher die XML-Anforderung.

Das FA(2)-Schema - was der Name bedeutet und woher es stammt

Ein XSD-Schema ist eine Vorlage, die beschreibt, wie ein gultig XML-Dokument aussehen soll. Man kann es sich wie ein Rezept vorstellen: Das Rezept gibt an, welche Zutaten verwendet werden sollen, in welcher Reihenfolge und in welchem Verhaltnis. Das XSD-Schema teilt einem XML-Dokument mit, welche Elemente vorhanden sein mussen, welche Datentypen zulassig sind (z. B. muss ein Datum das Format JJJJ-MM-TT haben) und welche Beziehungen zwischen Feldern bestehen mussen. Eine XML-Rechnung, die nicht dem Schema entspricht, ist wie ein Gericht, das nicht nach Rezept zubereitet wurde - das Ergebnis kann ungeniessbar sein.

Die Abkurzung FA stammt vom polnischen Wort fur Rechnung. FA(1), FA(2) und FA(3) sind aufeinanderfolgende Versionen des XSD-Schemas fur strukturierte Rechnungen in KSeF, die vom Finanzministerium veroffentlicht werden. FA(1) wurde wahrend der Pilotphase des Systems verwendet. FA(2) galt wahrend des freiwilligen KSeF-Zeitraums - Unternehmen konnten, mussten aber keine Rechnungen uber das System ausstellen. FA(3) ist das Pflichtschema, das mit der stufenweisen Einfuhrung des obligatorischen KSeF eingefuhrt wurde.

Warum lohnt es sich zu wissen, was FA(2) ist, wenn es nicht mehr gilt? Dokumentationen fur ERP-Systeme, Fachartikel, Anleitungen und interne Verfahren vieler Unternehmen wurden auf der Grundlage von FA(2) erstellt. Wenn Sie auf Feldbeispiele, Beschreibungen von XML-Knoten oder Systemkonfigurationsanweisungen stossen, die auf FA(2) verweisen, mussen Sie wissen, dass Sie es mit einer veralteten Version zu tun haben. Die Folgen konnen ernst sein: Eine im Format FA(2) an KSeF ubermittelte Rechnung wird im Jahr 2026 abgelehnt.

Wichtiges Datum: Ab dem 1. Februar 2026 ist das einzige von KSeF akzeptierte Schema FA(3). Dies gilt fur Grossunternehmen (Bruttoumsatz uber 200 Mio. PLN im Jahr 2024). Ab dem 1. April 2026 gilt die Pflicht fur alle ubrigen MwSt-Steuerpflichtigen. FA(2) wird vom System nicht mehr akzeptiert - und jede in diesem Format ubermittelte Rechnung wird automatisch abgelehnt, ohne Ausnahme.

Rechnungsstruktur in FA(2) - wichtige XML-Elemente

Um FA(3) und mogliche Migrationsprobleme von FA(2) zu verstehen, lohnt es sich, die grundlegende Struktur einer XML-Rechnung in KSeF kennenzulernen. Das Dokument ist in mehrere Hauptknoten unterteilt, von denen jeder fur einen bestimmten Teil der Rechnungsdaten zustandig ist. Knoten sind nichts anderes als Abschnitte des Dokuments - wie Kapitel in einem Vertrag.

Podmiot1 ist der Abschnitt, der den Verkaufer - den Rechnungsaussteller - beschreibt. Er enthalt die Unternehmensidentifikationsdaten: NIP, Name und Adresse. Dieses Feld ist Pflicht und muss genau den in den Steuerregistern eingetragenen Daten entsprechen. Podmiot2 ist entsprechend der Abschnitt fur den Kaufer. Er enthalt ebenfalls NIP, Name und Adresse. Bei Transaktionen mit einer Privatperson, die kein Unternehmen betreibt, ist das Feld optional oder wird auf spezifische Weise ausgefullt.

Der Knoten Fa ist der Rechnungskopf - seine Metadaten. Hier befinden sich: Rechnungsnummer (P_2), Ausstellungsdatum (P_1), Verkaufsdatum (P_6), Dokumententyp (P_15), Wahrung (KodWaluty), Zahlungsbedingungen (TerminPlatnosci) und weitere wichtige Attribute. FaWiersz ist eine Rechnungsposition - eine Zeile entspricht einem Produkt oder einer Dienstleistung. Sie enthalt eine Beschreibung der Ware oder Dienstleistung, Menge, Masseinheit, Nettostueckpreis, MwSt-Satz und Werte. Eine Rechnung kann mehrere solcher Zeilen enthalten. Podsumowanie ist der Knoten, der MwSt-Summen nach Satzen zusammenfasst - Gesamtnettobetrag, MwSt und Bruttobetrag.

Welche Felder verursachen am haufigsten Validierungsfehler? Die Erfahrung aus Implementierungen zeigt, dass sich Probleme an mehreren Stellen konzentrieren. Die NIP muss genau 10 Ziffern haben und eine Prufzifferverifizierung bestehen - das Prafix PL und Leerzeichen sind in einem ausschliesslich fur Ziffern vorgesehenen Feld nicht erlaubt. Daten mussen im ISO-8601-Format (JJJJ-MM-TT) vorliegen - die Schreibweise 15.04.2026 wird abgelehnt. MwSt-Satzcodes mussen dem Finanzministerium-Worterbuch entsprechen, nicht beliebigen Beschreibungen. Betrage mussen gemas dem KSeF-Algorithmus gerundet werden - selbst eine Differenz von einem Grosz fuhrt zur Ablehnung.

FA(2) vs. FA(3) - was sich geandert hat und was jetzt gilt

Der Ubergang von FA(2) zu FA(3) ist nicht nur eine Versionsnummernaktualisierung - es ist eine Anderung der Anforderungen, die sich direkt darauf auswirkt, wie ein ERP-System oder eine Rechnungsstellungsanwendung ein XML-Dokument aufbauen muss. Wenn Ihr Softwareanbieter die Integration nicht auf FA(3) aktualisiert hat, werden Rechnungen von KSeF abgelehnt, ohne eine fur den Endbenutzer verstandliche Warnung.

Was fuhrt FA(3) neu ein? In erster Linie wurden die Moglichkeiten zur Beschreibung von Zahlungsfristen erweitert - in FA(3) konnen mehrere Zahlungsfristen fur eine einzige Rechnung prazise angegeben werden, was fur Ratenrechnungen wichtig ist. Es ist nun moglich, Anhange direkt an die XML-Rechnung anzufugen - das war zuvor nicht moglich. Das Bankkontonummernfeld wurde auf den IBAN-Standard erweitert. Neue Sonderverfahrenscodes wurden hinzugefugt, u. a. fur Transaktionen zwischen verbundenen Unternehmen (TP), den Mechanismus der geteilten Zahlung (MPP) und den Verkauf uber digitale Plattformen (IED). GTU-Codes - Kennzeichen fur Waren- und Dienstleistungsarten, die fur die JPK-Meldung und die MwSt-Erklarung relevant sind - wurden erweitert.

Wie prufen Sie, ob Ihr System auf FA(3) lauft? Nachfolgend eine Liste von Fragen, die Sie Ihrem ERP- oder Buchhaltungssoftwareanbieter stellen sollten:

Wann haben Sie zuletzt das KSeF-Modul in Ihrem System aktualisiert? Umfasst die Aktualisierung das vom Finanzministerium veroffentlichte FA(3)-Schema? Testet das System Rechnungen in der KSeF-Demo-Umgebung vor der Ubermittlung? Welche XSD-Schemaversion generiert Ihr XML-Export? Unterstutzt das System die neuen FA(3)-Felder: mehrere Zahlungsfristen, IBAN, TP- und MPP-Codes? Wie verhalt sich das System, wenn eine Rechnung von KSeF abgelehnt wird?

Warum XML und das FA-Schema fur die KSeF-Integration wichtig sind

Im KSeF-System wird eine Rechnung entweder validiert und akzeptiert oder abgelehnt. Es gibt keinen Zwischenzustand. Eine abgelehnte Rechnung existiert steuerrechtlich nicht - sie gilt nicht als ausgestellt, kann nicht als Grundlage fur den Vorsteuerabzug des Kaufers dienen und wird nicht im System des Finanzministeriums gespeichert. Sie muss korrigiert und erneut ubermittelt werden.

Der Validierungsprozess in KSeF lauft auf drei Ebenen ab. Die erste ist die XSD-Strukturvalidierung: Das System pruft, ob das XML strukturell korrekt aufgebaut ist - ob Elemente in der richtigen Reihenfolge stehen, ob Datentypen ubereinstimmen und ob Pflichtfelder vorhanden sind. Besteht die Datei diese Stufe nicht, gelangt sie nicht zu weiteren Prufungen. Die zweite ist die Geschaftsvalidierung: Das System pruft logische Regeln - ob das Verkaufsdatum nicht spater als das Ausstellungsdatum liegt, ob die MwSt-Summe mathematisch korrekt ist und ob Steueridentifikatoren das richtige Format haben. Die dritte ist die Duplikatsprufung: KSeF pruft, ob eine Rechnung mit derselben Nummer, NIP des Verkaufers und demselben Dokumententyp bereits im System registriert wurde (die Prufung reicht 10 Jahre zuruck).

Wie vermeiden Sie die Ablehnung einer Rechnung? Die wirksamste Methode ist die lokale Validierung - die Prufung des XML vor der Ubermittlung an KSeF mithilfe von Werkzeugen ausserhalb des Produktivsystems. Auf diese Weise werden Fehler in der Dokumentvorbereitungsphase erkannt, nicht erst nach einem Ubermittlungsversuch.

KSeFGPT ermoglicht den Import und die Verifizierung von XML-Rechnungen direkt aus KSeF. Die Plattform erlaubt es Ihnen, die Dokumentstruktur zu pruefen, Fehler zu identifizieren und Rechnungen zu verwalten, ohne manuell mit der API des Finanzministeriums zu arbeiten. Sie ist ein praktisches Werkzeug sowohl fur Unternehmen, die grosse Rechnungsvolumen ausstellen, als auch fur Buchhaltungskanzleien, die mehrere Mandanten betreuen.

Perspektive: Warum es sich lohnt, XML auch ohne technisches Wissen zu verstehen

Ein Unternehmer muss keinen XML-Code schreiben oder die XSD-Schemaspezifikation auswendig kennen. Aber es lohnt sich zu verstehen, was XML ist und warum es existiert - wenn nur deshalb, weil dieses Wissen vor blindem Vertrauen in Software schutzt. Wenn Sie wissen, dass eine strukturierte Rechnung eine Datendatei und kein visuelles Dokument ist, wissen Sie auch, dass das bloge Erstellen eines PDFs in Ihrem Buchhaltungsprogramm nicht gleichbedeutend mit der Ausstellung einer Rechnung in KSeF ist. Dieser Unterschied kostet echtes Geld und Zeit, wenn er zu spat entdeckt wird.

Der haufigste organisatorische Fehler bei Unternehmen, die KSeF einfuhren, ist eine Trennung der Verantwortlichkeiten: Die IT-Abteilung ist fur die technische Integration zustandig, wahrend das Rechnungswesen fur die inhaltliche Richtigkeit der Rechnungen verantwortlich ist - und diese beiden Welten kommunizieren in der Konfigurationsphase nicht miteinander. Das vorhersehbare Ergebnis ist eine XML-Datei, die technisch gegen das XSD-Schema valide ist, aber falsche MwSt-Satze, falsche GTU-Codes oder fehlende Verfahrenskennzeichnungen enthalt. Solche Rechnungen bestehen die Strukturvalidierung, verursachen aber Probleme in der Steuerrechnung.

Werkzeuge abstrahieren XML zunehmend effektiv vom Endbenutzer. Ein gutes Rechnungsstellungsprogramm oder integriertes ERP-System ermoglicht es Ihnen, eine korrekte KSeF-Rechnung auszustellen, ohne die XML-Datei manuell zu bearbeiten. Aber diese Bequemlichkeit hat ihren Preis: Wenn das System falsche Daten generiert und der Benutzer nicht versteht, wie das Dokument aufgebaut ist, kann der Fehler lange unbemerkt bleiben. Grundlegende Kenntnisse der XML-Struktur ermoglichen es Ihnen, Ihrem Softwareanbieter die richtigen Fragen zu stellen: Generieren Sie FA(3) oder FA(2)? Wo werden GTU-Codes im XML gespeichert? Wird die Validierung vor oder nach der Ubermittlung ausgelost?

Eine praktische Empfehlung: Bevor Sie die Produktivrechnungsstellung uber KSeF starten, testen Sie den vollstandigen Zyklus in der Demo-Umgebung des Finanzministeriums. Eine Rechnung ausstellen, den Validierungsstatus prufen, die KSeF-Nummer und UPO empfangen und dann verifizieren, ob die Daten im System dem entsprechen, was Sie zu senden beabsichtigt hatten - das ist das absolute Minimum vor dem Start. Die Testumgebung ist kostenlos verfugbar und hat keinerlei Auswirkungen auf tatsachliche Steuerklarungen. Jede Stunde, die Sie mit Tests verbringen, ist eine Stunde weniger, die Sie mit dem Loschen von Produktionsbrandherden verbringen.

Prufen Sie Ihre XML-Rechnungen vor der Ubermittlung an KSeF

KSeFGPT ist eine KSeF-Rechnungsverwaltungsplattform, die den Import, die Verifikation und die Verarbeitung von XML-Dokumenten direkt aus dem System des Finanzministeriums ermoglicht. Ob Sie ein Unternehmen sind, das mehrere Dutzend Rechnungen pro Monat ausstellt, oder eine Buchhaltungskanzlei, die hunderte von Mandanten betreut - die Plattform reduziert den manuellen API-Aufwand und minimiert Ablehnungen.

Haufig gestellte Fragen

Wird FA(2) noch von KSeF akzeptiert? - Nein. Ab dem 1. Februar 2026 (Grossunternehmen) und ab dem 1. April 2026 (alle ubrigen MwSt-Steuerpflichtigen) ist FA(3) das einzige akzeptierte Schema fur strukturierte Rechnungen. Eine im FA(2)-Format ubermittelte Rechnung wird vom KSeF-System automatisch abgelehnt, ohne eine KSeF-Nummer zu erhalten.

Wie prufe ich, ob meine XML-Datei FA(3) entspricht? - Die wirksamste Methode ist die lokale Validierung gegen das vom Finanzministerium veroffentlichte XSD-Schema. Sie konnen einen online verfugbaren XSD-Validator oder XML-Bearbeitungswerkzeuge verwenden. Das Finanzministerium stellt auch eine KSeF-Testumgebung (ksef-test.mf.gov.pl) zur Verfugung, in der Sie ein Testdokument ubermitteln und pruefen konnen, ob es die Validierung besteht, ohne tatsachliche Steuerklarungen zu beeinflussen.

Wie unterscheidet sich eine KSeF-XML-Datei von einer standardmaigen XML-Datei? - Jede KSeF-XML-Datei muss dem spezifischen XSD-Schema entsprechen, das vom Finanzministerium veroffentlicht wurde - derzeit FA(3). Es genugt nicht, dass die Datei technisch valides XML ist. Sie muss genau die Knoten, in genau der Reihenfolge und mit genau den Datentypen enthalten, die im FA(3)-Schema definiert sind. Daruber hinaus muss die Datei die Geschaftsregeln von KSeF erfullen - z. B. mussen MwSt-Summen mathematisch mit den Positionen ubereinstimmen.

Was bedeutet die Ablehnung einer Rechnung durch KSeF - muss ich sie erneut ausstellen? - Ja. Eine abgelehnte Rechnung wird nicht im KSeF-System registriert, was bedeutet, dass sie steuerrechtlich nicht ausgestellt wurde. Sie mussen die XML-Datei korrigieren (den vom System angegebenen Fehler beheben) und die Rechnung dann erneut ubermitteln. Die Rechnungsnummer bleibt dieselbe - Sie erstellen kein neues Dokument, sondern korrigieren und ubermitteln dasselbe erneut. Eine Ausnahme bildet die Situation, wenn dieselbe Rechnungsnummer bereits erfolgreich registriert wurde - in diesem Fall lehnt KSeF das Dokument als Duplikat ab.

Empfohlene Artikel

Lesen Sie auch: XML-Validierung und -Verarbeitung in KSeF - wie das KSeF-System ein Dokument vor der Vergabe einer KSeF-Nummer pruft. PDF-zu-KSeF-XML-Konverter - wie man eine PDF-Rechnung in eine gultige FA(3)-Datei zur Ubermittlung konvertiert. Haufigste Herausforderungen bei der KSeF-Implementierung - Fehler, Sonderfalle und Notfallverfahren, die in keinem Gesetz beschrieben sind. Kann ein PDF an KSeF gesendet werden? - eine kurze und direkte Antwort auf eine der am haufigsten gestellten Fragen zu KSeF.