FA(3): het Poolse KSeF-factuurschema — structuur, velden, wijzigingen

FA(3) is de logische XML-structuur die elke gestructureerde factuur die naar het Poolse KSeF wordt verzonden, gebruikt sinds 1 februari 2026, toen ze FA(2) verving. Het is een nationaal schema dat door het ministerie van Financiën wordt gepubliceerd — geen syntaxis van EN 16931 — met acht hoofdelementen, waarvan Naglowek, Podmiot1, Podmiot2 en Fa verplicht zijn. In vergelijking met FA(2) voegt het een duidelijkere structuur voor betalingstermijnen toe, een werknemersrol voor derden, langere artikelomschrijvingen, markeringen voor lokale overheidseenheden en btw-groepen, en een XML-bijlage.

Wat FA(3) is en wanneer het van toepassing is

FA(3) is de "wzór faktury ustrukturyzowanej" — het sjabloon voor het elektronische document — dat door het ministerie van Financiën is gedefinieerd en gepubliceerd in het centrale register van documentsjablonen op crd.gov.pl/wzor/2025/06/25/13775/. Een gestructureerde factuur is juridisch een factuur die via KSeF is uitgereikt samen met het nummer dat het systeem eraan heeft toegekend, en KSeF kent alleen nummers toe aan bestanden die aan het actuele sjabloon voldoen.

De brochure van het ministerie is ondubbelzinnig: FA(2) gold van 1 september 2023 tot 31 januari 2026; FA(3) geldt voor elke gestructureerde factuur die vanaf 1 februari 2026 wordt uitgereikt, inclusief correcties van facturen die oorspronkelijk in FA(2) of FA(1) zijn uitgereikt en afrekeningsfacturen voor oudere voorschotfacturen. De API weerspiegelt dit: productie en demo aanvaarden alleen FA(3) (plus de varianten FA_PEF(3) en FA_KOR_PEF(3) voor via Peppol ontvangen facturen bij overheidsopdrachten), terwijl de testomgeving nog FA(2) aanvaardt. Een client declareert het schema bij het openen van een sessie, en KSeF valideert elk bestand in die sessie daartegen.

Structuur: de acht hoofdelementen

Het rootelement Faktura bevat de kop, de verkoper, de koper, optionele derden, een optionele gemachtigde entiteit, de factuur zelf, een optionele voettekst en een optionele bijlage.

De brochure onderscheidt verplichte velden (altijd ingevuld, bijv. de NIP van de verkoper), optionele velden (ingevuld telkens wanneer aan de wettelijke voorwaarde is voldaan, bijv. P_11A) en facultatieve velden (naar keuze van de belastingplichtige, bijv. SystemInfo). Facultatieve knooppunten weglaten is prima; een optioneel veld weglaten terwijl aan de voorwaarde is voldaan, levert een onjuiste factuur op, ook als de XSD slaagt.

De sleutelvelden in Fa

Het meeste van wat een boekhouder als "de factuur" herkent, staat in Fa, met veldnamen die zijn overgenomen uit de JPK_FA-rapporteringsstructuur.

KodWaluty

ISO 4217-valuta; "PLN" voor facturen in Poolse valuta. Bedragen worden in de factuurvaluta vermeld, behalve belastingbedragen die volgens de btw-wet zijn omgerekend, die eigen velden hebben (P_14_xW) naast KursWaluty.

P_1, P_1M

Uitreikingsdatum (verplicht) en plaats van uitreiking (facultatief). Voor een onlinefactuur is de wettelijke uitreikingsdatum de verzenddatum, mits P_1 daaraan gelijk is; voor offline24-, onbeschikbaarheids- en noodmodusfacturen — en voor onlinefacturen die na P_1 zijn verzonden — is P_1 zelf de formele uitreikingsdatum.

P_2

Het eigen volgnummer van de factuur van de verkoper. Het is niet het KSeF-nummer; de twee mogen niet worden verward.

P_6, P_6A, OkresFa

Datum van levering of betaling als die afwijkt van P_1 — op factuurniveau wanneer gemeenschappelijk voor alle regels, anders per regel in P_6A, of als periode (P_6_Od/P_6_Do) voor doorlopende diensten.

P_13_x, P_14_x, P_15

Nettototalen en btw-bedragen per tariefgroep (standaard 23 % of 22 %, verlaagd 8 %/7 %, 5 %/4 %, 3 %, binnenlands nultarief, intracommunautaire levering, uitvoer, vrijgesteld, verlegd, buiten toepassingsgebied) en het totaal verschuldigde bedrag. Het ministerie merkt op dat FA(3) op totaalniveau nog steeds geen onderscheid maakt tussen 22 % en 23 % — het exacte tarief wordt gelezen uit P_12 op de regel.

Adnotacje

Wettelijke aantekeningen als codes: P_16 kasstelsel, P_17 self-billing, P_18 verlegging, P_18A split payment, P_19 grondslag van de vrijstelling, P_22 nieuwe vervoermiddelen, P_23 vereenvoudigde driehoekshandel, markeringen voor de margeregeling.

RodzajFaktury

Factuurtype: VAT (standaard), KOR (correctie), ZAL (voorschot), ROZ (afrekening na een voorschot), UPR (vereenvoudigd), KOR_ZAL en KOR_ROZ (correcties van de laatste twee). Een correctie van een vereenvoudigde factuur gebruikt KOR. Bij correctiefacturen tonen alle velden de toestand na correctie, terwijl de velden voor grondslag, belasting en totaal het verschil dragen.

FaWiersz

Regels: NrWierszaFa (regelnummer), optioneel UU_ID (een facultatieve unieke regelsleutel van maximaal 50 tekens die correctieregels aan oorspronkelijke regels koppelt), P_7 (naam van goederen of dienst, nu tot 512 tekens), Indeks, GTIN, PKWiU, CN, P_8A (eenheid), P_8B (hoeveelheid), P_9A (netto-eenheidsprijs), P_9B (bruto-eenheidsprijs), P_10 (kortingen), P_11 (nettoregelwaarde), P_11A (brutoregelwaarde), P_11Vat, en P_12, de tariefcode.

P_12-tariefcodes

"23", "22", "8", "7", "5", "4", "3", "0 KR" (binnenlands nultarief), "0 WDT" (intracommunautaire levering), "0 EX" (uitvoer), "zw" (vrijgesteld), "oo" (binnenlandse verlegging), "np I" en "np II" (buiten het Poolse toepassingsgebied, de laatste voor diensten volgens art. 100(1)(4)). Transacties buiten de btw-wet, zoals multipurposevouchers, zijn geen regels; ze mogen alleen als extra informatie in Rozliczenie verschijnen.

Platnosc

Betalingsstatus en -datum, TerminPlatnosci als datum (Termin) of als gestructureerde omschrijving (hoeveelheid en eenheid, bijv. 14 dagen), betaalmethode, bankrekeningen en kortingsvoorwaarden.

Zamowienie

Alleen gebruikt voor voorschotfacturen en hun correcties, waar het FaWiersz vervangt.

Veldformaten: XML in UTF-8; tekstvelden standaard 256 tekens, met 512 voor namen, adresregels, P_7 en bijlagetekst, 50 voor classificatiecodes, eenheden en UU_ID, 32 voor IDNabywcy, 20 voor GTIN. Data zijn YYYY-MM-DD; de tijdstempel in de kop is ISO 8601 in UTC.

Wat er is veranderd ten opzichte van FA(2)

Het ministerie somt de wijzigingen op die het als gunstig voor belastingplichtigen beschouwt; geen ervan wijzigt de fiscale inhoud van een factuur, maar meerdere beïnvloeden de mapping.

• Betalingstermijn: TerminPlatnosci kan een datum of een gestructureerde omschrijving (getal plus eenheid) dragen in plaats van vrije tekst, en het veld kan een reeds verrichte of een toekomstige betaling beschrijven.
• Werknemersrol: Podmiot3 krijgt rol 11, "pracownik", zodat een uitgave die een werknemer in naam van het bedrijf heeft gedaan, de identiteit van de werknemer kan dragen voor de verwerking van onkosten.
• Langere omschrijvingen: P_7 groeit naar 512 tekens.
• JST en btw-groepen: nieuwe markeringen in Podmiot2 vertellen een lokale overheidseenheid of een btw-groep aan welke ondergeschikte eenheid of welk lid de aankoop toebehoort; bij "1" draagt Podmiot3 de NIP of interne identificatie van die eenheid.
• Bijlage: het nieuwe element Zalacznik voor grote volumes eenheids- en prijsgegevens, onderworpen aan voorafgaande melding in e-Urząd Skarbowy (open sinds 1 januari 2026).
• Wat niet is veranderd: er is nog steeds geen veld voor procentuele korting op een regel — een korting is een afzonderlijke regel of wordt in de eenheidsprijzen verwerkt — en de totalen maken nog steeds geen onderscheid tussen 22 % en 23 %.

Een sessie die met de formuliercode van FA(2) is geopend, kan geen FA(3)-bestanden dragen en omgekeerd; software moet de formuliercode kiezen die bij het bestand past.

Een factuur op FA(3) mappen

Een factuur in een EN 16931-model wordt veld voor veld op FA(3) gemapt, maar niet verliesvrij in beide richtingen: FA(3) heeft velden die EN 16931 niet kent (JST/GV-markeringen, de split-payment-aantekening, nationale tariefcodes) en de btw-categoriecodes van EN 16931 worden vervangen door de tarieflijst van P_12.

Twee mappingregels verdienen aandacht. Een verlegde regel wordt gecodeerd als oo met de aantekening in P_18; een intracommunautaire levering is 0 WDT, een uitvoer 0 EX, een binnenlands nultarief 0 KR — deze samenvoegen tot "0 %" verliest wat de boekhouder van de koper nodig heeft. En een correctiefactuur draagt in elk veld de toestand na correctie, maar de verschillen in grondslagen, belasting en totaal, anders dan de creditnotaconventie van EN 16931. Zie e-factuurformaten en EN 16931.

Validatie: wat de XSD controleert en wat KSeF controleert

De XSD halen is noodzakelijk maar niet voldoende: KSeF controleert het sjabloon en de rechten van de verzender voordat het een nummer toekent; fiscale juistheid is de verantwoordelijkheid van de uitreiker.

De XSD dwingt elementvolgorde, kardinaliteit, gegevenstypen, veldlengtes en de gesloten codelijsten af. KSeF voegt de controle van de schemaversie voor de sessie en de rechtencontrole toe. Het controleert niet de status van de koper in het register van btw-plichtigen, wijst een aan de verkeerde klant gerichte factuur niet af en herberekent geen rekenkunde — de Q&A van het ministerie zegt dat een verkeerd totaal in een aanvaarde factuur wordt hersteld met een correctiefactuur, terwijl een afgewezen bestand wordt hersteld en opnieuw ingediend omdat het nooit een factuur is geworden. De ruim dertig uitgewerkte voorbeelden in de brochure zijn de praktische referentie voor randgevallen.

Hoe KRONENWERK hiermee omgaat

Ondersteund met beperkingen. KRONENWERK genereert FA(3)-XML (versie 1-0E) voor facturen, creditnota's en voorschotfacturen op basis van de factuurgegevens en het btw-oordeel, valideert het bestand bij uitreiking tegen de XSD van het ministerie en zijn eigen controles, en leest inkomende FA(3)-bestanden in als inkoopfacturen. De drie nultariefcodes, verlegging en vrijstelling worden als afzonderlijke categorieën gedragen, en de bedragen in de tariefgroepen worden berekend uit de regels in plaats van ingetypt. Verzending naar KSeF is Nog niet gereed: de KSeF 2.0-module is niet gebruikt tegen het productiesysteem, en KRONENWERK verkoopt geen abonnementen aan Poolse bedrijven totdat dat is gebeurd — zie de Polen-hub en KSeF 2.0. Het bijlage-element, de FA_PEF-varianten en de JST/btw-groepmarkeringen worden niet gegenereerd. Ontwikkelaars kunnen de mapping hierboven vergelijken met de KSeF-integratiegids; de gratis e-factuurchecker valideert bestanden tegen de regels van een land zonder ze op te slaan.