KSeF FA(3) — mandatory element missing (rejected by the official XSD)
Een FA(3)-factuur waarin één verplicht element ontbreekt: P_2, het factuurnummer. Op het oog mankeert er niets — correct gevormde XML, juiste namespace, plausibele btw-uitsplitsing — en alleen de officiële XSD van het ministerie van Financiën ziet het: “Element P_6: this element is not expected. Expected is P_2.” KSeF weigert zo’n bestand zonder meer.
FA(3) 1-0E — Ongeldig
Een FA(3)-factuur waarin één verplicht element ontbreekt: P_2, het factuurnummer. Op het oog mankeert er niets — correct gevormde XML, juiste namespace, plausibele btw-uitsplitsing — en alleen de officiële XSD van het ministerie van Financiën ziet het: “Element P_6: this element is not expected. Expected is P_2.” KSeF weigert zo’n bestand zonder meer.
Wat dit bestand laat zien
Een FA(3)-factuur waarin één verplicht element ontbreekt: P_2, het factuurnummer. Op het oog mankeert er niets — correct gevormde XML, juiste namespace, plausibele btw-uitsplitsing — en alleen de officiële XSD van het ministerie van Financiën ziet het: “Element P_6: this element is not expected. Expected is P_2.” KSeF weigert zo’n bestand zonder meer.
| Transacties | 1 |
|---|---|
| Totaal | PLN 1.230,00 |
| Datum in het bestand | 2026-07-12 |
Alle partijen, IBAN's en bedragen hieronder zijn fictief. De IBAN's zijn structureel geldig — ze doorstaan de mod-97-controle — maar horen bij geen enkele echte rekening.
Bestandsinhoud
<?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>
Hoe we weten dat deze resultaten kloppen
Elk bestand in deze bibliotheek gaat bij elke build door de eigen validator van de site. Het hierboven vermelde verwachte resultaat wordt door een geautomatiseerde test bevestigd: zou een bestand niet meer overeenkomen met wat deze pagina beweert, dan faalt de build. Twee overgeërfde fixtures zijn zo vóór publicatie hersteld: drie IBAN's zakten voor de mod-97-controle en meerdere namen gebruikten tekens buiten de SEPA-basistekenset.
KSeF-factuur (Polen, 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)