KSeF FA(3) — mandatory element missing (rejected by the official XSD)
Faktura FA(3) bez jednego elementu obowiązkowego: P_2, czyli numeru faktury. Na oko wszystko jest w porządku — poprawny XML, właściwa przestrzeń nazw, wiarygodne rozbicie VAT — a wykrywa to dopiero oficjalny XSD Ministerstwa Finansów: „Element P_6: this element is not expected. Expected is P_2”. KSeF odrzuca taki plik od razu.
FA(3) 1-0E — Nieprawidłowy
Faktura FA(3) bez jednego elementu obowiązkowego: P_2, czyli numeru faktury. Na oko wszystko jest w porządku — poprawny XML, właściwa przestrzeń nazw, wiarygodne rozbicie VAT — a wykrywa to dopiero oficjalny XSD Ministerstwa Finansów: „Element P_6: this element is not expected. Expected is P_2”. KSeF odrzuca taki plik od razu.
Co pokazuje ten plik
Faktura FA(3) bez jednego elementu obowiązkowego: P_2, czyli numeru faktury. Na oko wszystko jest w porządku — poprawny XML, właściwa przestrzeń nazw, wiarygodne rozbicie VAT — a wykrywa to dopiero oficjalny XSD Ministerstwa Finansów: „Element P_6: this element is not expected. Expected is P_2”. KSeF odrzuca taki plik od razu.
| Transakcje | 1 |
|---|---|
| Suma | 1230,00 zł |
| Data w pliku | 2026-07-12 |
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 BROKEN — against the OFFICIAL Ministry of Finance FA(3) schema.
Everything here is well-formed XML, in the right namespace, with the right root
element. What is missing is one mandatory child of <Fa>: <P_2>, the invoice number.
It sits between <P_1M> and <P_6> on every other sample, and the XSD declares it with
no minOccurs — so it must be there.
This is the whole point of the sample: nothing about the file LOOKS wrong. Only the
schema catches it, which is why ValidateFin runs the Ministry's own XSD as layer 1
instead of re-encoding FA(3)'s cardinalities by hand. KSeF will reject the invoice
outright with a structural error; there is no "accepted with a remark" here.
-->
<Faktura xmlns:etd="http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2022/01/05/eD/DefinicjeTypy/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://crd.gov.pl/wzor/2025/06/25/13775/">
<Naglowek>
<KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
<WariantFormularza>3</WariantFormularza>
<DataWytworzeniaFa>2026-07-12T11:05:00Z</DataWytworzeniaFa>
<SystemInfo>ValidateFin</SystemInfo>
</Naglowek>
<Podmiot1>
<DaneIdentyfikacyjne>
<NIP>9999999999</NIP>
<Nazwa>Zimnotech 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>30-002 Kraków</AdresL2>
</Adres>
<JST>2</JST>
<GV>2</GV>
</Podmiot2>
<Fa>
<KodWaluty>PLN</KodWaluty>
<P_1>2026-07-12</P_1>
<P_1M>Warszawa</P_1M>
<!-- <P_2> — the invoice number — is MISSING. The schema requires it. -->
<P_6>2026-07-12</P_6>
<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>zmywarka Bryza 100</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 — invoice still using the retired FA(2) schema
- 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) — buyer NIP failing its mod-11 check digit (warning only)