ValidateFin

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

The buyer’s NIP is 1111111112 — ten digits, so the official schema, which constrains the NIP by a pattern only, accepts it without a word. Its mod-11 check digit does not hold: no such Polish tax number can exist, and the invoice is addressed to nobody. ValidateFin reports a warning, never an error — the Ministry publishes no such validation rule.

FA(3) 1-0E — Valid

The buyer’s NIP is 1111111112 — ten digits, so the official schema, which constrains the NIP by a pattern only, accepts it without a word. Its mod-11 check digit does not hold: no such Polish tax number can exist, and the invoice is addressed to nobody. ValidateFin reports a warning, never an error — the Ministry publishes no such validation rule.

KSeF invoice (Poland, FA(3)) FA(3) 1-0E KSeF — Polish Ministry of FinanceExpected result: Valid — 1 warnings

What this file shows

The buyer’s NIP is 1111111112 — ten digits, so the official schema, which constrains the NIP by a pattern only, accepts it without a word. Its mod-11 check digit does not hold: no such Polish tax number can exist, and the invoice is addressed to nobody. ValidateFin reports a warning, never an error — the Ministry publishes no such validation rule.

Transactions2
TotalPLN 5,904.00
Date in the file2026-07-08

The defects it carries

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

Quoted verbatim from the validator, not paraphrased.

Last verified: License: CC-BY-4.0
Download the file Open the matching validator

Every party, IBAN and amount below is fictitious. The IBANs are structurally valid — they pass the mod-97 check — but they belong to no real account.

File content

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

How we know these results hold

Every file in this library is run through the site's own validator on each build. The expected result stated above is asserted by an automated test — if a file stopped matching what this page claims, the build would fail. Two inherited fixtures were repaired this way before publication: three IBANs failed the mod-97 check and several names used characters outside the basic SEPA character set.

KSeF invoice (Poland, FA(3))

All sample fileshttps://validatefin.com/samples/ksef-fa3-nip-checksum.xml