ValidateFin

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

Die NIP des Käufers lautet 1111111112 — zehn Ziffern, also nimmt das offizielle Schema, das die NIP nur über ein Muster prüft, sie wortlos an. Die Mod-11-Prüfziffer stimmt jedoch nicht: eine solche polnische Steuernummer kann es nicht geben, die Rechnung geht an niemanden. ValidateFin meldet eine Warnung, nie einen Fehler — das Ministerium veröffentlicht keine solche Validierungsregel.

FA(3) 1-0E — Gültig

Die NIP des Käufers lautet 1111111112 — zehn Ziffern, also nimmt das offizielle Schema, das die NIP nur über ein Muster prüft, sie wortlos an. Die Mod-11-Prüfziffer stimmt jedoch nicht: eine solche polnische Steuernummer kann es nicht geben, die Rechnung geht an niemanden. ValidateFin meldet eine Warnung, nie einen Fehler — das Ministerium veröffentlicht keine solche Validierungsregel.

KSeF-Rechnung (Polen, FA(3)) FA(3) 1-0E KSeF — Polish Ministry of FinanceErwartetes Ergebnis: Gültig — 1 Warnungen

Was diese Datei zeigt

Die NIP des Käufers lautet 1111111112 — zehn Ziffern, also nimmt das offizielle Schema, das die NIP nur über ein Muster prüft, sie wortlos an. Die Mod-11-Prüfziffer stimmt jedoch nicht: eine solche polnische Steuernummer kann es nicht geben, die Rechnung geht an niemanden. ValidateFin meldet eine Warnung, nie einen Fehler — das Ministerium veröffentlicht keine solche Validierungsregel.

Transaktionen2
Summe5.904,00 PLN
Datum in der Datei2026-07-08

Die enthaltenen Fehler

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

Wörtlich aus dem Validator zitiert, nicht umformuliert.

Zuletzt geprüft: Lizenz: CC-BY-4.0
Datei herunterladen Passenden Validator öffnen

Alle Parteien, IBANs und Beträge unten sind fiktiv. Die IBANs sind strukturell gültig — sie bestehen die Mod-97-Prüfung — gehören aber zu keinem realen Konto.

Dateiinhalt

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

Woher wir wissen, dass diese Ergebnisse stimmen

Jede Datei dieser Bibliothek läuft bei jedem Build durch den eigenen Validator der Website. Das oben genannte erwartete Ergebnis wird von einem automatisierten Test geprüft: Passt eine Datei nicht mehr zu dem, was diese Seite behauptet, schlägt der Build fehl. Zwei geerbte Fixtures wurden so vor der Veröffentlichung repariert — drei IBANs scheiterten an der Mod-97-Prüfung, und mehrere Namen nutzten Zeichen außerhalb des SEPA-Basiszeichensatzes.

KSeF-Rechnung (Polen, FA(3))

Alle Beispieldateienhttps://validatefin.com/samples/ksef-fa3-nip-checksum.xml