ValidateFin

KSeF FA(3) — correcting invoice (faktura korygująca, KOR)

Eine Korrekturrechnung (RodzajFaktury = KOR) — der meistgesuchte und am häufigsten falsch gebaute FA(3)-Fall. Die Summen tragen die DIFFERENZ, nicht die berichtigte Rechnung: P_13_1, P_14_1 und P_15 sind negativ. Hinzu kommen PrzyczynaKorekty, TypKorekty und DaneFaKorygowanej mit dem Verweis auf die korrigierte Rechnung. Die Positionen stehen paarweise: die mit StanPrzed ist der Zustand davor.

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

Eine Korrekturrechnung (RodzajFaktury = KOR) — der meistgesuchte und am häufigsten falsch gebaute FA(3)-Fall. Die Summen tragen die DIFFERENZ, nicht die berichtigte Rechnung: P_13_1, P_14_1 und P_15 sind negativ. Hinzu kommen PrzyczynaKorekty, TypKorekty und DaneFaKorygowanej mit dem Verweis auf die korrigierte Rechnung. Die Positionen stehen paarweise: die mit StanPrzed ist der Zustand davor.

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

Was diese Datei zeigt

Eine Korrekturrechnung (RodzajFaktury = KOR) — der meistgesuchte und am häufigsten falsch gebaute FA(3)-Fall. Die Summen tragen die DIFFERENZ, nicht die berichtigte Rechnung: P_13_1, P_14_1 und P_15 sind negativ. Hinzu kommen PrzyczynaKorekty, TypKorekty und DaneFaKorygowanej mit dem Verweis auf die korrigierte Rechnung. Die Positionen stehen paarweise: die mit StanPrzed ist der Zustand davor.

Transaktionen2
Summe-369,00 PLN
Datum in der Datei2026-07-10
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"?>
<!--
  KSeF FA(3) — CORRECTING INVOICE (faktura korygująca, RodzajFaktury = KOR).

  This is the shape a correction takes in FA(3), and it surprises people:

    · the totals carry the DELTA, not the restated invoice — P_13_1 (-300.00),
      P_14_1 (-69.00) and P_15 (-369.00) are all negative, because the correction
      lowers what was already invoiced;
    · <PrzyczynaKorekty> (the reason) and <TypKorekty> are mandatory here and appear
      nowhere on a plain VAT invoice;
    · <DaneFaKorygowanej> points back at the invoice being corrected — its date, its
      number and, when it went through KSeF, its KSeF number;
    · the lines come in PAIRS: the one carrying <StanPrzed>1</StanPrzed> is the state
      BEFORE the correction, the one without it is the state after.

  ValidateFin's line-total check (Σ P_11 vs P_13_*) deliberately does NOT run on KOR —
  the lines restate values while the totals carry the delta, so they cannot agree.
-->
<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-12T10:15: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>
		<DaneKontaktowe>
			<Email>[email protected]</Email>
			<Telefon>221234567</Telefon>
		</DaneKontaktowe>
	</Podmiot1>
	<Podmiot2>
		<DaneIdentyfikacyjne>
			<NIP>1111111111</NIP>
			<Nazwa>F.H.U. Jan Kowalski</Nazwa>
		</DaneIdentyfikacyjne>
		<Adres>
			<KodKraju>PL</KodKraju>
			<AdresL1>ul. Polna 7</AdresL1>
			<AdresL2>30-001 Kraków</AdresL2>
		</Adres>
		<JST>2</JST>
		<GV>2</GV>
	</Podmiot2>
	<Fa>
		<KodWaluty>PLN</KodWaluty>
		<P_1>2026-07-10</P_1>
		<P_1M>Warszawa</P_1M>
		<P_2>FK/2026/07/031</P_2>
		<P_6>2026-06-18</P_6>
		<P_13_1>-300.00</P_13_1>
		<P_14_1>-69.00</P_14_1>
		<P_15>-369.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>KOR</RodzajFaktury>
		<PrzyczynaKorekty>obniżka ceny o 300 zł netto z uwagi na uszkodzenia estetyczne obudowy</PrzyczynaKorekty>
		<TypKorekty>3</TypKorekty>
		<DaneFaKorygowanej>
			<DataWystFaKorygowanej>2026-06-18</DataWystFaKorygowanej>
			<NrFaKorygowanej>FV/2026/06/214</NrFaKorygowanej>
			<NrKSeF>1</NrKSeF>
			<NrKSeFFaKorygowanej>9999999999-20260618-8BEF280C8D35-4D</NrKSeFFaKorygowanej>
		</DaneFaKorygowanej>
		<FaWiersz>
			<NrWierszaFa>1</NrWierszaFa>
			<UU_ID>aaaa111133337770</UU_ID>
			<P_7>lodówka Zimnotech mk3</P_7>
			<P_8A>szt.</P_8A>
			<P_8B>1</P_8B>
			<P_9A>2600.00</P_9A>
			<P_11>2600.00</P_11>
			<P_12>23</P_12>
			<StanPrzed>1</StanPrzed>
		</FaWiersz>
		<FaWiersz>
			<NrWierszaFa>1</NrWierszaFa>
			<UU_ID>aaaa111133337770</UU_ID>
			<P_7>lodówka Zimnotech mk3</P_7>
			<P_8A>szt.</P_8A>
			<P_8B>1</P_8B>
			<P_9A>2300.00</P_9A>
			<P_11>2300.00</P_11>
			<P_12>23</P_12>
		</FaWiersz>
	</Fa>
	<Stopka>
		<Informacje>
			<StopkaFaktury>Kapitał zakładowy 500 000 zł</StopkaFaktury>
		</Informacje>
		<Rejestry>
			<KRS>0000099999</KRS>
			<REGON>999999999</REGON>
		</Rejestry>
	</Stopka>
</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-korekta.xml