ValidateFin

KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)

Il NIP dell’acquirente è 1111111112: dieci cifre, quindi lo schema ufficiale, che lo vincola solo con un pattern, lo accetta senza obiezioni. La cifra di controllo mod-11 non torna: un simile codice fiscale polacco non può esistere e la fattura non è indirizzata a nessuno. ValidateFin segnala un avviso, mai un errore — il Ministero non pubblica una regola di validazione del genere.

FA(3) 1-0E — Valido

Il NIP dell’acquirente è 1111111112: dieci cifre, quindi lo schema ufficiale, che lo vincola solo con un pattern, lo accetta senza obiezioni. La cifra di controllo mod-11 non torna: un simile codice fiscale polacco non può esistere e la fattura non è indirizzata a nessuno. ValidateFin segnala un avviso, mai un errore — il Ministero non pubblica una regola di validazione del genere.

Fattura KSeF (Polonia, FA(3)) FA(3) 1-0E KSeF — Polish Ministry of FinanceRisultato atteso: Valido — 1 avvisi

Cosa mostra questo file

Il NIP dell’acquirente è 1111111112: dieci cifre, quindi lo schema ufficiale, che lo vincola solo con un pattern, lo accetta senza obiezioni. La cifra di controllo mod-11 non torna: un simile codice fiscale polacco non può esistere e la fattura non è indirizzata a nessuno. ValidateFin segnala un avviso, mai un errore — il Ministero non pubblica una regola di validazione del genere.

Transazioni2
Totale5904,00 PLN
Data nel file2026-07-08

I difetti che contiene

  • KSeF-NIPKSeF-NIP: the buyer's NIP (1111111112, Podmiot2) fails the mod-11 check digit.

Citato alla lettera dal validatore, non parafrasato.

Ultima verifica: Licenza: CC-BY-4.0
Scarica il file Apri il validatore corrispondente

Tutte le parti, gli IBAN e gli importi qui sotto sono fittizi. Gli IBAN sono strutturalmente validi — superano il mod-97 — ma non corrispondono ad alcun conto reale.

Contenuto del file

<?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>

Come sappiamo che questi risultati reggono

Ogni file di questa libreria passa nel validatore del sito a ogni build. Il risultato atteso indicato sopra è verificato da un test automatico: se un file smettesse di corrispondere a quanto afferma questa pagina, la build fallirebbe. Due fixture ereditate sono state riparate così prima della pubblicazione: tre IBAN non superavano il mod-97 e diversi nomi usavano caratteri fuori dal set SEPA di base.

Fattura KSeF (Polonia, FA(3))

Tutti i file di esempiohttps://validatefin.com/samples/ksef-fa3-nip-checksum.xml