KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)
Le NIP de l’acheteur est 1111111112 — dix chiffres, donc le schéma officiel, qui ne contraint le NIP que par un motif, l’accepte sans broncher. Sa clé mod-11 est fausse : aucun numéro fiscal polonais de ce type ne peut exister, et la facture n’est adressée à personne. ValidateFin émet un avertissement, jamais une erreur — le ministère ne publie aucune règle de validation de ce genre.
FA(3) 1-0E — Valide
Le NIP de l’acheteur est 1111111112 — dix chiffres, donc le schéma officiel, qui ne contraint le NIP que par un motif, l’accepte sans broncher. Sa clé mod-11 est fausse : aucun numéro fiscal polonais de ce type ne peut exister, et la facture n’est adressée à personne. ValidateFin émet un avertissement, jamais une erreur — le ministère ne publie aucune règle de validation de ce genre.
Ce que montre ce fichier
Le NIP de l’acheteur est 1111111112 — dix chiffres, donc le schéma officiel, qui ne contraint le NIP que par un motif, l’accepte sans broncher. Sa clé mod-11 est fausse : aucun numéro fiscal polonais de ce type ne peut exister, et la facture n’est adressée à personne. ValidateFin émet un avertissement, jamais une erreur — le ministère ne publie aucune règle de validation de ce genre.
| Transactions | 2 |
|---|---|
| Total | 5 904,00 PLN |
| Date contenue dans le fichier | 2026-07-08 |
Les défauts qu’il porte
- KSeF-NIPKSeF-NIP: the buyer's NIP (1111111112, Podmiot2) fails the mod-11 check digit.
Cité mot pour mot depuis le validateur, sans reformulation.
Toutes les parties, IBAN et montants ci-dessous sont fictifs. Les IBAN sont structurellement valides — ils passent le mod-97 — mais ne correspondent à aucun compte réel.
Contenu du fichier
<?xml version="1.0" encoding="UTF-8"?>
<!--
DELIBERATELY IMPERFECT — and yet the verdict is VALID.
The buyer's NIP is 1111111112. It has the right shape (ten digits), so the official
FA(3) schema, which constrains the NIP by a PATTERN only, accepts it without a word.
But its mod-11 check digit does not hold: with weights 6,5,7,2,3,4,5,6,7 over the
first nine digits the remainder is 1, so the tenth digit would have to be 1, not 2.
No such Polish tax number can exist — the invoice is going to the wrong taxpayer.
ValidateFin reports this as a WARNING, never an error. No official KSeF source states
the NIP checksum as a validation rule, and the tool refuses to reject a file on a rule
the Ministry does not publish. Everything else here is clean: P_15 = Σ P_13_* + Σ P_14_*
to the grosz, and the invoice lines add up to the net total.
-->
<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-12T09:20:00Z</DataWytworzeniaFa>
<SystemInfo>ValidateFin</SystemInfo>
</Naglowek>
<Podmiot1>
<DaneIdentyfikacyjne>
<NIP>9999999999</NIP>
<Nazwa>Bryza Serwis sp. z o.o.</Nazwa>
</DaneIdentyfikacyjne>
<Adres>
<KodKraju>PL</KodKraju>
<AdresL1>ul. Bukowa 5</AdresL1>
<AdresL2>60-004 Poznań</AdresL2>
</Adres>
</Podmiot1>
<Podmiot2>
<DaneIdentyfikacyjne>
<NIP>1111111112</NIP>
<Nazwa>Hurtownia Zielona Dolina sp. j.</Nazwa>
</DaneIdentyfikacyjne>
<Adres>
<KodKraju>PL</KodKraju>
<AdresL1>ul. Polna 12</AdresL1>
<AdresL2>30-001 Kraków</AdresL2>
</Adres>
<JST>2</JST>
<GV>2</GV>
</Podmiot2>
<Fa>
<KodWaluty>PLN</KodWaluty>
<P_1>2026-07-08</P_1>
<P_1M>Poznań</P_1M>
<P_2>FV/2026/07/128</P_2>
<P_6>2026-07-08</P_6>
<P_13_1>4800.00</P_13_1>
<P_14_1>1104.00</P_14_1>
<P_15>5904.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>serwis instalacji chłodniczej</P_7>
<P_8A>godz.</P_8A>
<P_8B>24</P_8B>
<P_9A>150.00</P_9A>
<P_11>3600.00</P_11>
<P_12>23</P_12>
</FaWiersz>
<FaWiersz>
<NrWierszaFa>2</NrWierszaFa>
<P_7>części zamienne — sprężarka</P_7>
<P_8A>szt.</P_8A>
<P_8B>2</P_8B>
<P_9A>600.00</P_9A>
<P_11>1200.00</P_11>
<P_12>23</P_12>
</FaWiersz>
<Platnosc>
<TerminPlatnosci>
<Termin>2026-08-07</Termin>
</TerminPlatnosci>
<FormaPlatnosci>6</FormaPlatnosci>
</Platnosc>
</Fa>
</Faktura>
Comment nous savons que ces résultats tiennent
Chaque fichier de cette bibliothèque passe dans le validateur du site à chaque build. Le résultat attendu annoncé ci-dessus est vérifié par un test automatisé : si un fichier cessait de correspondre à ce que cette page affirme, le build échouerait. Deux fixtures héritées ont été réparées ainsi avant publication : trois IBAN échouaient au mod-97 et plusieurs libellés utilisaient des caractères hors du jeu SEPA de base.
Facture KSeF (Pologne, 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) — mandatory element missing (rejected by the official XSD)