FA(3): Polens KSeF-Rechnungsschema — Struktur, Felder, Änderungen zu FA(2)

FA(3) ist die logische XML-Struktur, die jede an das polnische KSeF gesendete strukturierte Rechnung seit dem 1. Februar 2026 verwendet, als sie FA(2) ablöste. Es ist ein nationales Schema des polnischen Finanzministeriums — keine Syntax der EN 16931 — mit acht Elementen auf oberster Ebene, von denen Naglowek, Podmiot1, Podmiot2 und Fa verpflichtend sind. Gegenüber FA(2) ergänzt es eine klarere Struktur für Zahlungsfristen, eine Mitarbeiterrolle für Dritte, längere Positionsbezeichnungen, Kennzeichen für Gebietskörperschaften und Umsatzsteuergruppen sowie einen XML-Anhang.

Was FA(3) ist und wann es gilt

FA(3) ist das „wzór faktury ustrukturyzowanej“ — die Vorlage für das elektronische Dokument —, das vom Finanzministerium definiert und im zentralen Repository der Dokumentvorlagen unter crd.gov.pl/wzor/2025/06/25/13775/ veröffentlicht ist. Eine strukturierte Rechnung ist rechtlich eine über KSeF ausgestellte Rechnung zusammen mit der Nummer, die das System ihr zugewiesen hat, und KSeF weist nur Dateien Nummern zu, die der aktuellen Vorlage entsprechen.

Die Broschüre des Ministeriums ist eindeutig: FA(2) galt vom 1. September 2023 bis zum 31. Januar 2026; FA(3) gilt für jede ab dem 1. Februar 2026 ausgestellte strukturierte Rechnung, einschließlich Korrekturen von ursprünglich in FA(2) oder FA(1) ausgestellten Rechnungen und Abrechnungsrechnungen zu älteren Anzahlungsrechnungen. Die API spiegelt das wider: Produktion und Demo akzeptieren nur FA(3) (plus die Varianten FA_PEF(3) und FA_KOR_PEF(3) für über Peppol eingehende Rechnungen aus der öffentlichen Beschaffung), während die Testumgebung noch FA(2) annimmt. Ein Client deklariert das Schema beim Öffnen einer Session, und KSeF validiert jede Datei in dieser Session dagegen.

Struktur: die acht Elemente der obersten Ebene

Das Wurzelelement Faktura enthält den Kopf, den Verkäufer, den Käufer, optionale Dritte, eine optionale bevollmächtigte Stelle, den Rechnungskörper, eine optionale Fußzeile und einen optionalen Anhang.

Die Broschüre unterscheidet obligatorische Felder (immer gefüllt, z. B. die NIP des Verkäufers), optionale Felder (gefüllt, wann immer die gesetzliche Bedingung erfüllt ist, z. B. P_11A) und fakultative Felder (nach Ermessen des Steuerpflichtigen, z. B. SystemInfo). Fakultative Knoten wegzulassen ist unproblematisch; ein optionales Feld wegzulassen, dessen Bedingung erfüllt ist, ergibt eine unrichtige Rechnung, auch wenn die XSD-Prüfung besteht.

Die Schlüsselfelder in Fa

Das meiste von dem, was ein Buchhalter als „die Rechnung“ erkennt, liegt in Fa, mit Feldnamen, die aus der Meldestruktur JPK_FA übernommen sind.

KodWaluty

ISO-4217-Währung; „PLN“ für Rechnungen in polnischer Währung. Beträge werden in der Rechnungswährung angegeben, außer den nach dem polnischen Umsatzsteuergesetz umgerechneten Steuerbeträgen, die eigene Felder (P_14_xW) neben KursWaluty haben.

P_1, P_1M

Ausstellungsdatum (verpflichtend) und Ausstellungsort (fakultativ). Bei einer Online-Rechnung ist das rechtliche Ausstellungsdatum das Übermittlungsdatum, sofern P_1 damit übereinstimmt; bei Rechnungen im Modus offline24, bei Nichtverfügbarkeit und im Notfallmodus — und bei Online-Rechnungen, die nach P_1 übermittelt werden — ist P_1 selbst das formale Ausstellungsdatum.

P_2

Die eigene fortlaufende Rechnungsnummer des Verkäufers. Sie ist nicht die KSeF-Nummer; die beiden dürfen nicht verwechselt werden.

P_6, P_6A, OkresFa

Liefer- oder Zahlungsdatum, wenn es von P_1 abweicht — auf Rechnungsebene, wenn es für alle Positionen gilt, sonst je Position in P_6A, oder als Zeitraum (P_6_Od/P_6_Do) bei Dauerleistungen.

P_13_x, P_14_x, P_15

Nettosummen und Umsatzsteuerbeträge je Satzgruppe (Regelsatz 23 % oder 22 %, ermäßigt 8 %/7 %, 5 %/4 %, 3 %, inländischer Nullsatz, innergemeinschaftliche Lieferung, Ausfuhr, steuerfrei, Reverse Charge, nicht steuerbar) sowie der Gesamtbetrag. Das Ministerium weist darauf hin, dass FA(3) auf Summenebene 22 % weiterhin nicht von 23 % trennt — der genaue Satz wird aus P_12 auf der Position gelesen.

Adnotacje

Gesetzliche Vermerke als Codes: P_16 Ist-Besteuerung, P_17 Gutschriftverfahren, P_18 Reverse Charge, P_18A Split Payment, P_19 Befreiungsgrundlage, P_22 neue Fahrzeuge, P_23 Dreiecksgeschäft-Vereinfachung, Kennzeichen der Differenzbesteuerung.

RodzajFaktury

Rechnungsart: VAT (Standard), KOR (Korrektur), ZAL (Anzahlung), ROZ (Abrechnung nach Anzahlung), UPR (vereinfacht), KOR_ZAL und KOR_ROZ (Korrekturen der beiden letztgenannten). Eine Korrektur einer vereinfachten Rechnung verwendet KOR. Bei Korrekturrechnungen zeigen alle Felder den Zustand nach der Korrektur, während die Felder für Bemessungsgrundlage, Steuer und Gesamtbetrag die Differenz tragen.

FaWiersz

Positionen: NrWierszaFa (Positionsnummer), optional UU_ID (ein fakultativer eindeutiger Positionsschlüssel von bis zu 50 Zeichen, der Korrekturpositionen mit Originalpositionen verknüpft), P_7 (Bezeichnung der Ware oder Dienstleistung, jetzt bis zu 512 Zeichen), Indeks, GTIN, PKWiU, CN, P_8A (Einheit), P_8B (Menge), P_9A (Nettoeinzelpreis), P_9B (Bruttoeinzelpreis), P_10 (Rabatte), P_11 (Nettopositionswert), P_11A (Bruttopositionswert), P_11Vat und P_12, der Satzcode.

P_12-Satzcodes

„23“, „22“, „8“, „7“, „5“, „4“, „3“, „0 KR“ (inländischer Nullsatz), „0 WDT“ (innergemeinschaftliche Lieferung), „0 EX“ (Ausfuhr), „zw“ (steuerfrei), „oo“ (inländisches Reverse Charge), „np I“ und „np II“ (außerhalb des polnischen Anwendungsbereichs, Letzteres für Dienstleistungen nach Art. 100 Abs. 1 Nr. 4). Umsätze außerhalb des Umsatzsteuergesetzes, etwa Mehrzweck-Gutscheine, sind keine Positionen; sie dürfen nur als Zusatzinformation in Rozliczenie erscheinen.

Platnosc

Zahlungsstatus und -datum, TerminPlatnosci als Datum (Termin) oder als strukturierte Beschreibung (Anzahl und Einheit, z. B. 14 Tage), Zahlungsweise, Bankkonten und Skontobedingungen.

Zamowienie

Nur für Anzahlungsrechnungen und deren Korrekturen verwendet, wo es FaWiersz ersetzt.

Feldformate: XML in UTF-8; Textfelder haben standardmäßig 256 Zeichen, mit 512 für Namen, Adresszeilen, P_7 und Anhangstext, 50 für Klassifikationscodes, Einheiten und UU_ID, 32 für IDNabywcy, 20 für GTIN. Daten sind YYYY-MM-DD; der Zeitstempel im Kopf ist ISO 8601 in UTC.

Was sich gegenüber FA(2) geändert hat

Das Ministerium führt die Änderungen auf, die es als vorteilhaft für Steuerpflichtige ansieht; keine davon ändert den steuerlichen Inhalt einer Rechnung, aber mehrere wirken sich auf das Mapping aus.

• Zahlungsfrist: TerminPlatnosci kann ein Datum oder eine strukturierte Beschreibung (Zahl plus Einheit) statt Freitext tragen, und das Feld kann eine bereits geleistete oder eine künftige Zahlung beschreiben.
• Mitarbeiterrolle: Podmiot3 erhält die Rolle 11, „pracownik“, damit eine von einem Mitarbeiter im Namen des Unternehmens getätigte Ausgabe die Identität des Mitarbeiters für die Spesenbearbeitung tragen kann.
• Längere Bezeichnungen: P_7 wächst auf 512 Zeichen.
• JST und Umsatzsteuergruppen: Neue Kennzeichen in Podmiot2 sagen einer Gebietskörperschaft oder einer Umsatzsteuergruppe, welcher nachgeordneten Einheit oder welchem Mitglied der Einkauf zuzuordnen ist; bei „1“ trägt Podmiot3 die NIP oder interne Kennung dieser Einheit.
• Anhang: das neue Element Zalacznik für umfangreiche Einheiten- und Preisdaten, vorbehaltlich einer vorherigen Anzeige in e-Urząd Skarbowy (seit dem 1. Januar 2026 möglich).
• Was sich nicht geändert hat: Es gibt weiterhin kein Feld für einen prozentualen Rabatt auf einer Position — ein Rabatt ist eine eigene Position oder wird in den Einzelpreisen abgebildet — und die Summen unterscheiden weiterhin nicht 22 % von 23 %.

Eine mit dem FA(2)-Formularcode geöffnete Session kann keine FA(3)-Dateien tragen und umgekehrt; die Software muss den zur Datei passenden Formularcode wählen.

Eine Rechnung auf FA(3) abbilden

Eine in einem EN-16931-Modell gehaltene Rechnung lässt sich Feld für Feld auf FA(3) abbilden, aber nicht verlustfrei in beide Richtungen: FA(3) hat Felder, die der EN 16931 fehlen (JST/GV-Kennzeichen, der Split-Payment-Vermerk, nationale Satzcodes), und die Umsatzsteuer-Kategoriecodes der EN 16931 werden durch die P_12-Satzliste ersetzt.

Zwei Mapping-Regeln verdienen Aufmerksamkeit. Eine Reverse-Charge-Position wird mit oo codiert, mit dem Vermerk in P_18; eine innergemeinschaftliche Lieferung ist 0 WDT, eine Ausfuhr 0 EX, ein inländischer Nullsatz 0 KR — diese auf „0 %“ zusammenzufassen verliert, was der Buchhalter des Käufers braucht. Und eine Korrekturrechnung trägt in jedem Feld den Zustand nach der Korrektur, aber die Differenzen bei Bemessungsgrundlagen, Steuer und Gesamtbetrag, anders als die Gutschrift-Konvention der EN 16931. Siehe E-Rechnungsformate und EN 16931.

Validierung: Was die XSD prüft und was KSeF prüft

Die XSD-Prüfung zu bestehen ist notwendig, aber nicht hinreichend: KSeF prüft die Vorlage und die Berechtigungen des Senders, bevor es eine Nummer vergibt; die steuerliche Richtigkeit liegt in der Verantwortung des Ausstellers.

Die XSD erzwingt Elementreihenfolge, Kardinalität, Datentypen, Feldlängen und die geschlossenen Codelisten. KSeF ergänzt die Prüfung der Schemaversion für die Session und die Berechtigungsprüfung. Es prüft nicht den Status des Käufers im Umsatzsteuerregister, lehnt keine an den falschen Kunden adressierte Rechnung ab und rechnet die Arithmetik nicht nach — laut den Fragen und Antworten des Ministeriums wird eine falsche Summe in einer angenommenen Rechnung durch eine Korrekturrechnung behoben, während eine abgelehnte Datei korrigiert und erneut eingereicht wird, weil sie nie eine Rechnung wurde. Die rund dreißig ausgearbeiteten Beispiele der Broschüre sind die praktische Referenz für Grenzfälle.

So geht KRONENWERK damit um

Mit Einschränkungen unterstützt. KRONENWERK erzeugt FA(3)-XML (Version 1-0E) für Rechnungen, Gutschriften und Anzahlungsrechnungen aus den Rechnungsdaten und der steuerlichen Beurteilung, validiert die Datei bei der Ausstellung gegen die XSD des Ministeriums und eigene Prüfungen und liest eingehende FA(3)-Dateien als Eingangsrechnungen ein. Die drei Nullsatz-Codes, Reverse Charge und Steuerbefreiung werden als eigene Kategorien geführt, und die Beträge in den Satzgruppen werden aus den Positionen berechnet statt eingetippt. Die Übermittlung an KSeF ist Noch nicht bereit: Das KSeF-2.0-Modul wurde noch nicht gegen das Produktivsystem eingesetzt, und KRONENWERK verkauft keine Abonnements an polnische Unternehmen, bis das geschehen ist — siehe die Übersichtsseite Polen und KSeF 2.0. Das Anhangselement, die FA_PEF-Varianten und die JST/Umsatzsteuergruppen-Kennzeichen werden nicht erzeugt. Entwickler können das obige Mapping mit dem KSeF-Integrationsleitfaden vergleichen; der kostenlose E-Rechnungs-Prüfer validiert Dateien gegen die Regeln eines Landes, ohne sie zu speichern.