KSeF — invoice still using the retired FA(2) schema
The most common KSeF migration failure: a perfectly well-formed invoice that still declares the FA(2) namespace, retired on 1 February 2026. Nothing looks wrong until KSeF rejects it. Note what FA(3) added and this file lacks: Podmiot2 now requires JST and GV.
FA(2) 1-0E — Invalid
The most common KSeF migration failure: a perfectly well-formed invoice that still declares the FA(2) namespace, retired on 1 February 2026. Nothing looks wrong until KSeF rejects it. Note what FA(3) added and this file lacks: Podmiot2 now requires JST and GV.
What this file shows
The most common KSeF migration failure: a perfectly well-formed invoice that still declares the FA(2) namespace, retired on 1 February 2026. Nothing looks wrong until KSeF rejects it. Note what FA(3) added and this file lacks: Podmiot2 now requires JST and GV.
The defects it carries
- FA(2)this file uses the FA(2) schema
Quoted verbatim from the validator, not paraphrased.
Every party, IBAN and amount below is fictitious. The IBANs are structurally valid — they pass the mod-97 check — but they belong to no real account.
File content
<?xml version="1.0" encoding="UTF-8"?>
<!--
DELIBERATELY OUT OF DATE. This invoice uses the retired FA(2) schema
(namespace http://crd.gov.pl/wzor/2023/06/29/12648/), which KSeF stopped
accepting on 1 February 2026 when FA(3) replaced it.
It is published as a sample because this is the single most common failure when
migrating: the file still looks fine, but the schema is the old one. Note also
what FA(3) added and this file therefore lacks — Podmiot2 now requires JST and GV.
-->
<Faktura xmlns:etd="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2022/01/05/eD/DefinicjeTypy/"
xmlns="http://crd.gov.pl/wzor/2023/06/29/12648/">
<Naglowek>
<KodFormularza kodSystemowy="FA (2)" wersjaSchemy="1-0E">FA</KodFormularza>
<WariantFormularza>2</WariantFormularza>
<DataWytworzeniaFa>2026-01-15T09:30:00Z</DataWytworzeniaFa>
<SystemInfo>Legacy ERP 4.2</SystemInfo>
</Naglowek>
<Podmiot1>
<DaneIdentyfikacyjne>
<NIP>9999999999</NIP>
<Nazwa>ABC AGD sp. z o. o.</Nazwa>
</DaneIdentyfikacyjne>
<Adres>
<KodKraju>PL</KodKraju>
<AdresL1>ul. Kwiatowa 1 m. 2</AdresL1>
<AdresL2>00-001 Warszawa</AdresL2>
</Adres>
</Podmiot1>
<Podmiot2>
<DaneIdentyfikacyjne>
<NIP>1111111111</NIP>
<Nazwa>CDE sp. j.</Nazwa>
</DaneIdentyfikacyjne>
<Adres>
<KodKraju>PL</KodKraju>
<AdresL1>ul. Sadowa 1 lok. 3</AdresL1>
<AdresL2>00-002 Kraków</AdresL2>
</Adres>
</Podmiot2>
<Fa>
<KodWaluty>PLN</KodWaluty>
<P_1>2026-01-15</P_1>
<P_2>FV/2026/01/88</P_2>
<P_13_1>1000.00</P_13_1>
<P_14_1>230.00</P_14_1>
<P_15>1230.00</P_15>
<Adnotacje>
<P_16>2</P_16>
<P_17>2</P_17>
<P_18>2</P_18>
<P_18A>2</P_18A>
<Zwolnienie>
<P_19N>1</P_19N>
</Zwolnienie>
<NoweSrodkiTransportu>
<P_22N>1</P_22N>
</NoweSrodkiTransportu>
<P_23>2</P_23>
<PMarzy>
<P_PMarzyN>1</P_PMarzyN>
</PMarzy>
</Adnotacje>
<RodzajFaktury>VAT</RodzajFaktury>
<FaWiersz>
<NrWierszaFa>1</NrWierszaFa>
<P_7>lodówka Zimnotech mk1</P_7>
<P_8A>szt.</P_8A>
<P_8B>1</P_8B>
<P_9A>1000.00</P_9A>
<P_11>1000.00</P_11>
<P_12>23</P_12>
</FaWiersz>
</Fa>
</Faktura>
How we know these results hold
Every file in this library is run through the site's own validator on each build. The expected result stated above is asserted by an automated test — if a file stopped matching what this page claims, the build would fail. Two inherited fixtures were repaired this way before publication: three IBANs failed the mod-97 check and several names used characters outside the basic SEPA character set.
KSeF invoice (Poland, FA(3))
- KSeF FA(3) — valid invoice (official MF example)
- KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)
- KSeF FA(3) — correcting invoice (faktura korygująca, KOR)
- KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)
- KSeF FA(3) — mandatory element missing (rejected by the official XSD)
- KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)