FA(2) vs FA(3): what to change in your XML

Since 1 February 2026, KSeF (Krajowy System e-Faktur, Poland's national e-invoicing system) 2.0 accepts only FA(3), with no backward compatibility mode. To migrate from FA(2) you change the namespace, the KodFormularza attributes and the WariantFormularza value, and add the JST and GV fields to every Podmiot2.

Legal position as of 7 October 2026.

FA(2) ended on 1 February 2026

FA(2) applied from 1 September 2023, first voluntarily, then in the KSeF pilot, and stopped working at midnight on 31 January 2026. From 1 February, FA(3) is the only binding template for a structured e-invoice. There is no legacy mode and no transition period for the format.

Two dates are easy to confuse:

• 1 February 2026: KSeF became mandatory for taxpayers with 2024 turnover above PLN 200 million. From that day FA(3) is the only accepted format for all KSeF invoices.
• 1 April 2026: KSeF became mandatory for the remaining active VAT taxpayers.

So the format has applied since February, regardless of when KSeF became mandatory for you.

Namespace

The namespace is the xmlns attribute on the <Faktura> element. FA(3) changed its URI, and KSeF 2.0 rejects the document at this level before checking anything else. This one change causes most validation errors for developers migrating from FA(2).

<!-- ❌ FA(2) — invalid since 1 February 2026 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2023/06/29/12648/">
  ...
</Faktura>
<!-- ✅ FA(3) — required from 1 February 2026 -->
<Faktura xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
  ...
</Faktura>

It is easy to miss when the namespace is hardcoded in a generator template or comes from an example copied long ago. The date in the schema URL (https://crd.gov.pl/wzor/2025/06/25/13775/) is its publication date, not its effective date.

Header

Both attributes of <KodFormularza> change, and <WariantFormularza> goes from 2 to 3:

<!-- ❌ FA(2) -->
<KodFormularza kodSystemowy="FA (2)" wersjaSchemy="...">FA</KodFormularza>
<WariantFormularza>2</WariantFormularza>
<!-- ✅ FA(3) -->
<KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
<WariantFormularza>3</WariantFormularza>

kodSystemowy="FA (3)" has a space before the bracket, and typos here are among the most common. A complete valid header:

<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">
    FA
  </KodFormularza>
  <WariantFormularza>3</WariantFormularza>
  <DataWytworzeniaFa>2026-03-28T10:00:00Z</DataWytworzeniaFa>
</Naglowek>

New mandatory JST and GV fields in Podmiot2

FA(3) adds two mandatory fields to Podmiot2. Without them the document fails XSD validation, whatever your company's profile. The section looks the same as in FA(2), so this is the easiest change to miss.

For the vast majority of invoices, set both to 2.

<!-- ❌ FA(2) — JST and GV missing -->
<Podmiot2>
  <DaneIdentyfikacyjne>
    <NIP>9876543210</NIP>
    <Nazwa>Nabywca Sp. z o.o.</Nazwa>
  </DaneIdentyfikacyjne>
  <Adres>
    <KodKraju>PL</KodKraju>
    <AdresL1>ul. Przykładowa 1, 00-001 Warszawa</AdresL1>
  </Adres>
</Podmiot2>
<!-- ✅ FA(3) — JST and GV present -->
<Podmiot2>
  <DaneIdentyfikacyjne>
    <NIP>9876543210</NIP>
    <Nazwa>Nabywca Sp. z o.o.</Nazwa>
  </DaneIdentyfikacyjne>
  <Adres>
    <KodKraju>PL</KodKraju>
    <AdresL1>ul. Przykładowa 1, 00-001 Warszawa</AdresL1>
  </Adres>
  <JST>2</JST>
  <GV>2</GV>
</Podmiot2>

When JST = 1, a Podmiot3 entry with Rola = 8 is required. When GV = 1, an entry with Rola = 10. Details are in the FA(3) information sheet.

New elements in FA(3)

Rola = 11 in Podmiot3 (employee). For invoices covering employee expenses, where an employee buys on behalf of the employer and has no NIP of their own as a party to the transaction. The DaneIdentyfikacyjne/NIP field then does not exist: you set BrakID = 1 and give the employee's name in Nazwa.

<Zalacznik>. An optional structured attachment at the top level of the document, for invoices with extensive data on units of measure, quantities or net unit prices.

Corrections to FA(2) invoices

A correction invoice for an invoice issued in FA(2) before 1 February 2026 must be in FA(3). There is no "FA(2) correction in FA(2) format". The same goes for final invoices that settle FA(2) advance invoices (MF FA(3) information brochure, or broszura, introduction on the binding invoice template).

When correcting an invoice issued outside the current KSeF, meaning any FA(2) invoice from KSeF 1.0, use NrKSeFN = 1 in DaneFaKorygowanej. The NrKSeF field applies to invoices already issued in KSeF 2.0.

Migration checklist

Mandatory:

1. Change the namespace from http://crd.gov.pl/wzor/2023/06/29/12648/ to http://crd.gov.pl/wzor/2025/06/25/13775/.
2. Set kodSystemowy="FA (3)" and wersjaSchemy="1-0E" in KodFormularza.
3. Set <WariantFormularza>3</WariantFormularza>.
4. Add <JST>2</JST> and <GV>2</GV> to every Podmiot2 (2 means "not applicable").

Depending on your case:

• corrections to FA(2): NrKSeFN = 1 in DaneFaKorygowanej,
• employee invoices: Rola = 11 in Podmiot3 with BrakID = 1,
• complex quantity-heavy invoices: Zalacznik, after notifying e-US.

If you are building from scratch, skip FA(2): old templates found online and code from the KSeF 1.0 pilot are out of date. Download the XSD from https://crd.gov.pl/wzor/2025/06/25/13775/, generate classes or types from it (JAXB, xsd.exe, xsd-to-ts) and implement against the information sheet. There is no newer schema version as of publication.

Test environment

The KSeF 2.0 test environment is at https://ap-test.ksef.mf.gov.pl/web/. Invoices with dummy data have no legal effect there, and it accepts only FA(3). The KSeF 1.0 application at ksef.mf.gov.pl/web was switched off on 1 February 2026. The production KSeF 2.0 Aplikacja Podatnika runs at ap.ksef.mf.gov.pl.

Next step

You can check your XML file on ksefuj.to before submitting; the validator points to the exact element causing each error, and the file never leaves your browser. If you still hit errors after migrating, see the most common FA(3) validation errors for ready-to-copy fixes.