ValidateFin

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

Faktura korygująca (RodzajFaktury = KOR) — najczęściej poszukiwany i najczęściej źle budowany przypadek FA(3). Kwoty w polach P_13_1, P_14_1 i P_15 są ujemne, bo niosą RÓŻNICĘ, a nie fakturę po korekcie. Pojawiają się PrzyczynaKorekty, TypKorekty oraz DaneFaKorygowanej ze wskazaniem faktury korygowanej. Wiersze występują parami: ten ze StanPrzed to stan sprzed korekty.

FA(3) 1-0E — Prawidłowy

Faktura korygująca (RodzajFaktury = KOR) — najczęściej poszukiwany i najczęściej źle budowany przypadek FA(3). Kwoty w polach P_13_1, P_14_1 i P_15 są ujemne, bo niosą RÓŻNICĘ, a nie fakturę po korekcie. Pojawiają się PrzyczynaKorekty, TypKorekty oraz DaneFaKorygowanej ze wskazaniem faktury korygowanej. Wiersze występują parami: ten ze StanPrzed to stan sprzed korekty.

Faktura KSeF (FA(3)) FA(3) 1-0E KSeF — Polish Ministry of FinanceOczekiwany wynik: Prawidłowy

Co pokazuje ten plik

Faktura korygująca (RodzajFaktury = KOR) — najczęściej poszukiwany i najczęściej źle budowany przypadek FA(3). Kwoty w polach P_13_1, P_14_1 i P_15 są ujemne, bo niosą RÓŻNICĘ, a nie fakturę po korekcie. Pojawiają się PrzyczynaKorekty, TypKorekty oraz DaneFaKorygowanej ze wskazaniem faktury korygowanej. Wiersze występują parami: ten ze StanPrzed to stan sprzed korekty.

Transakcje2
Suma-369,00 zł
Data w pliku2026-07-10
Ostatnia weryfikacja: Licencja: CC-BY-4.0

Wszystkie strony, numery IBAN i kwoty poniżej są fikcyjne. IBAN-y są poprawne strukturalnie — przechodzą test mod-97 — ale nie należą do żadnego rzeczywistego rachunku.

Zawartość pliku

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

Skąd wiemy, że te wyniki są aktualne

Każdy plik w tej bibliotece przechodzi przez walidator serwisu przy każdym buildzie. Oczekiwany wynik podany wyżej potwierdza test automatyczny: gdyby plik przestał odpowiadać temu, co głosi ta strona, build by się wywalił. Dwie odziedziczone fikstury naprawiono w ten sposób przed publikacją: trzy numery IBAN nie przechodziły mod-97, a kilka nazw używało znaków spoza podstawowego zestawu SEPA.

Faktura KSeF (FA(3))