KSeF — invoice still using the retired FA(2) schema
Najczęstszy błąd migracji do KSeF: poprawnie zbudowana faktura, która wciąż deklaruje przestrzeń nazw FA(2), wycofaną 1 lutego 2026 r. Nic nie wygląda źle, dopóki KSeF jej nie odrzuci. Zwróć uwagę na to, co doszło w FA(3), a czego tu brakuje: Podmiot2 wymaga teraz JST i GV.
FA(2) 1-0E — Nieprawidłowy
Najczęstszy błąd migracji do KSeF: poprawnie zbudowana faktura, która wciąż deklaruje przestrzeń nazw FA(2), wycofaną 1 lutego 2026 r. Nic nie wygląda źle, dopóki KSeF jej nie odrzuci. Zwróć uwagę na to, co doszło w FA(3), a czego tu brakuje: Podmiot2 wymaga teraz JST i GV.
Co pokazuje ten plik
Najczęstszy błąd migracji do KSeF: poprawnie zbudowana faktura, która wciąż deklaruje przestrzeń nazw FA(2), wycofaną 1 lutego 2026 r. Nic nie wygląda źle, dopóki KSeF jej nie odrzuci. Zwróć uwagę na to, co doszło w FA(3), a czego tu brakuje: Podmiot2 wymaga teraz JST i GV.
Zawarte wady
- FA(2)this file uses the FA(2) schema
Cytowane dosłownie z walidatora, bez parafrazy.
Wszystkie strony, numery IBAN i kwoty poniżej są fikcyjne. IBAN-y są poprawne strukturalnie — przechodzą test mod-97 — ale nie należą do żadnego rzeczywistego rachunku.
Zawartość pliku
<?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>
Skąd wiemy, że te wyniki są aktualne
Każdy plik w tej bibliotece przechodzi przez walidator serwisu przy każdym buildzie. Oczekiwany wynik podany wyżej potwierdza test automatyczny: gdyby plik przestał odpowiadać temu, co głosi ta strona, build by się wywalił. Dwie odziedziczone fikstury naprawiono w ten sposób przed publikacją: trzy numery IBAN nie przechodziły mod-97, a kilka nazw używało znaków spoza podstawowego zestawu SEPA.
Faktura KSeF (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)