KSeF FA(3) — correcting invoice (faktura korygująca, KOR)
Een correctiefactuur (RodzajFaktury = KOR), het meest gezochte en vaakst verkeerd opgebouwde FA(3)-geval. De totalen dragen het VERSCHIL, niet de herziene factuur: P_13_1, P_14_1 en P_15 zijn negatief. Daarnaast verschijnen PrzyczynaKorekty, TypKorekty en DaneFaKorygowanej, die naar de gecorrigeerde factuur verwijzen. De regels komen per paar: die met StanPrzed is de toestand vóór.
FA(3) 1-0E — Geldig
Een correctiefactuur (RodzajFaktury = KOR), het meest gezochte en vaakst verkeerd opgebouwde FA(3)-geval. De totalen dragen het VERSCHIL, niet de herziene factuur: P_13_1, P_14_1 en P_15 zijn negatief. Daarnaast verschijnen PrzyczynaKorekty, TypKorekty en DaneFaKorygowanej, die naar de gecorrigeerde factuur verwijzen. De regels komen per paar: die met StanPrzed is de toestand vóór.
Wat dit bestand laat zien
Een correctiefactuur (RodzajFaktury = KOR), het meest gezochte en vaakst verkeerd opgebouwde FA(3)-geval. De totalen dragen het VERSCHIL, niet de herziene factuur: P_13_1, P_14_1 en P_15 zijn negatief. Daarnaast verschijnen PrzyczynaKorekty, TypKorekty en DaneFaKorygowanej, die naar de gecorrigeerde factuur verwijzen. De regels komen per paar: die met StanPrzed is de toestand vóór.
| Transacties | 2 |
|---|---|
| Totaal | PLN -369,00 |
| Datum in het bestand | 2026-07-10 |
Alle partijen, IBAN's en bedragen hieronder zijn fictief. De IBAN's zijn structureel geldig — ze doorstaan de mod-97-controle — maar horen bij geen enkele echte rekening.
Bestandsinhoud
<?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>
Hoe we weten dat deze resultaten kloppen
Elk bestand in deze bibliotheek gaat bij elke build door de eigen validator van de site. Het hierboven vermelde verwachte resultaat wordt door een geautomatiseerde test bevestigd: zou een bestand niet meer overeenkomen met wat deze pagina beweert, dan faalt de build. Twee overgeërfde fixtures zijn zo vóór publicatie hersteld: drie IBAN's zakten voor de mod-97-controle en meerdere namen gebruikten tekens buiten de SEPA-basistekenset.
KSeF-factuur (Polen, FA(3))
- KSeF FA(3) — valid invoice (official MF example)
- KSeF — invoice still using the retired FA(2) schema
- KSeF FA(3) — bad NIP check digit and mismatched total (warnings only)
- KSeF FA(3) — prepayment invoice (faktura zaliczkowa, ZAL)
- KSeF FA(3) — mandatory element missing (rejected by the official XSD)
- KSeF FA(3) — buyer NIP failing its mod-11 check digit (warning only)