FA(3): Poland's KSeF invoice schema — structure, fields, changes from FA(2)

FA(3) is the XML logical structure that every structured invoice sent to Poland's KSeF has used since 1 February 2026, when it replaced FA(2). It is a national schema published by the Ministry of Finance — not a syntax of EN 16931 — with eight top-level elements, of which Naglowek, Podmiot1, Podmiot2 and Fa are mandatory. Compared with FA(2) it adds a clearer payment-term structure, an employee role for third parties, longer item descriptions, markers for local-government units and VAT groups, and an XML attachment.

What FA(3) is and when it applies

FA(3) is the "wzór faktury ustrukturyzowanej" — the electronic document template — defined by the Ministry of Finance and published in the central repository of document templates at crd.gov.pl/wzor/2025/06/25/13775/. A structured invoice is legally an invoice issued through KSeF together with the number the system assigned to it, and KSeF only assigns numbers to files that conform to the current template.

The Ministry's brochure is unambiguous: FA(2) applied from 1 September 2023 to 31 January 2026; FA(3) applies to every structured invoice issued from 1 February 2026, including corrections of invoices originally issued in FA(2) or FA(1) and settlement invoices for older advance invoices. The API mirrors this: production and demo accept only FA(3) (plus the FA_PEF(3) and FA_KOR_PEF(3) variants for Peppol-originated public-procurement invoices), while the test environment still accepts FA(2). A client declares the schema when it opens a session, and KSeF validates every file in that session against it.

Structure: the eight top-level elements

The root element Faktura contains the header, the seller, the buyer, optional third parties, an optional authorised entity, the invoice body, an optional footer and an optional attachment.

The brochure distinguishes obligatory fields (always filled, e.g. the seller's NIP), optional fields (filled whenever the statutory condition is met, e.g. P_11A) and facultative fields (at the taxpayer's discretion, e.g. SystemInfo). Omitting facultative nodes is fine; omitting an optional field whose condition is met yields an incorrect invoice even if the XSD passes.

The key fields inside Fa

Most of what a bookkeeper recognises as "the invoice" lives in Fa, with field names inherited from the JPK_FA reporting structure.

KodWaluty

ISO 4217 currency; "PLN" for Polish-currency invoices. Amounts are stated in the invoice currency, except tax amounts converted under the VAT Act, which have their own fields (P_14_xW) alongside KursWaluty.

P_1, P_1M

Issue date (mandatory) and place of issue (facultative). For an online invoice the legal issue date is the transmission date, provided P_1 equals it; for offline24, unavailability and emergency-mode invoices — and for online invoices transmitted after P_1 — P_1 itself is the formal issue date.

P_2

The seller's own sequential invoice number. It is not the KSeF number; the two must not be confused.

P_6, P_6A, OkresFa

Date of supply or payment if it differs from P_1 — at invoice level when common to all lines, per line in P_6A otherwise, or as a period (P_6_Od/P_6_Do) for continuous services.

P_13_x, P_14_x, P_15

Net totals and VAT amounts per rate bucket (standard 23 % or 22 %, reduced 8 %/7 %, 5 %/4 %, 3 %, zero-rated domestic, intra-Community supply, export, exempt, reverse charge, outside scope), and the total amount due. The Ministry notes that FA(3) still does not separate 22 % from 23 % at total level — the exact rate is read from P_12 on the line.

Adnotacje

Statutory annotations as codes: P_16 cash accounting, P_17 self-billing, P_18 reverse charge, P_18A split payment, P_19 exemption basis, P_22 new means of transport, P_23 triangular simplification, margin-scheme markers.

RodzajFaktury

Invoice type: VAT (standard), KOR (correcting), ZAL (advance), ROZ (settlement after an advance), UPR (simplified), KOR_ZAL and KOR_ROZ (corrections of the latter two). A correction of a simplified invoice uses KOR. For correcting invoices all fields show the state after correction, while base, tax and total fields carry the difference.

FaWiersz

Line items: NrWierszaFa (line number), optional UU_ID (a facultative unique line key of up to 50 characters that ties correction lines to original lines), P_7 (name of goods or service, now up to 512 characters), Indeks, GTIN, PKWiU, CN, P_8A (unit), P_8B (quantity), P_9A (net unit price), P_9B (gross unit price), P_10 (discounts), P_11 (net line value), P_11A (gross line value), P_11Vat, and P_12, the rate code.

P_12 rate codes

"23", "22", "8", "7", "5", "4", "3", "0 KR" (domestic zero rate), "0 WDT" (intra-Community supply), "0 EX" (export), "zw" (exempt), "oo" (domestic reverse charge), "np I" and "np II" (outside Polish scope, the latter for services under art. 100(1)(4)). Transactions outside the VAT Act, such as multi-purpose vouchers, are not lines; they may only appear as extra information in Rozliczenie.

Platnosc

Payment status and date, TerminPlatnosci as a date (Termin) or a structured description (quantity and unit, e.g. 14 days), payment method, bank accounts and discount terms.

Zamowienie

Used only for advance invoices and their corrections, where it replaces FaWiersz.

Field formats: XML in UTF-8; text fields default to 256 characters, with 512 for names, address lines, P_7 and attachment text, 50 for classification codes, units and UU_ID, 32 for IDNabywcy, 20 for GTIN. Dates are YYYY-MM-DD; the header timestamp is ISO 8601 in UTC.

What changed from FA(2)

The Ministry lists the changes it regards as beneficial to taxpayers; none of them alters the fiscal content of an invoice, but several affect mapping.

• Payment term: TerminPlatnosci can carry a date or a structured description (number plus unit) instead of free text, and the field may describe an already-made or a future payment.
• Employee role: Podmiot3 gains role 11, "pracownik", so that an expense bought by an employee in the company's name can carry the employee's identity for expense processing.
• Longer descriptions: P_7 grows to 512 characters.
• JST and VAT groups: new markers in Podmiot2 tell a local-government unit or a VAT group which subordinate unit or member the purchase belongs to; when set to "1", Podmiot3 carries that unit's NIP or internal identifier.
• Attachment: the new Zalacznik element for high-volume unit and price data, subject to prior notification in e-Urząd Skarbowy (open since 1 January 2026).
• What did not change: there is still no percentage-discount field on a line — a discount is a separate line or is reflected in unit prices — and the totals still do not distinguish 22 % from 23 %.

A session opened with the FA(2) form code cannot carry FA(3) files and vice versa; software must pick the form code that matches the file.

Mapping an invoice onto FA(3)

An invoice held in an EN 16931 model maps onto FA(3) field by field, but not losslessly in both directions: FA(3) has fields EN 16931 lacks (JST/GV markers, the split-payment annotation, national rate codes) and EN 16931's VAT category codes are replaced by the P_12 rate list.

Two mapping rules deserve attention. A reverse-charge line is coded oo with the annotation in P_18; an intra-Community supply is 0 WDT, an export 0 EX, a domestic zero rate 0 KR — collapsing these to "0 %" loses what the buyer's bookkeeper needs. And a correcting invoice carries the post-correction state in every field but the differences in bases, tax and total, unlike the EN 16931 credit-note convention. See e-invoice formats and EN 16931.

Validation: what the XSD checks and what KSeF checks

Passing the XSD is necessary but not sufficient: KSeF checks the template and the sender's permissions before assigning a number; fiscal correctness is the issuer's responsibility.

The XSD enforces element order, cardinality, data types, field lengths and the closed code lists. KSeF adds the schema-version check for the session and the permission check. It does not verify the buyer's status in the VAT taxpayer register, does not reject an invoice addressed to the wrong customer, and does not recalculate arithmetic — the Ministry's Q&A says a wrong total in an accepted invoice is fixed by a correcting invoice, while a rejected file is fixed and resubmitted because it never became an invoice. The brochure's thirty-odd worked examples are the practical reference for edge cases.

How KRONENWERK handles this

SUPPORTED WITH LIMITATIONS. KRONENWERK generates FA(3) XML (version 1-0E) for invoices, credit notes and advance invoices from the invoice data and the tax verdict, validates the file against the Ministry's XSD and its own checks at issuance, and reads incoming FA(3) files back into bills. The three zero-rate codes, reverse charge and exemption are carried as distinct categories, and the amounts in the buckets are computed from the lines rather than typed. Transmission to KSeF is NOT YET READY: the KSeF 2.0 module has not been used against the production system, and KRONENWERK does not sell subscriptions to Polish companies until it has — see the Poland hub and KSeF 2.0. The attachment element, FA_PEF variants and JST/VAT-group markers are not generated. Developers can compare the mapping above with the KSeF integration guide; the free e-invoice checker validates files against a country's rules without storing them.