Blog
Issuing and receiving invoices

Corrective invoice in KSeF: how to issue one

6 min read

An invoice sent to KSeF (Krajowy System e-Faktur, Poland's National e-Invoicing System) can't be edited or deleted, so you fix a mistake with a corrective invoice: a separate FA(3) file with RodzajFaktury = KOR that points to the original. The amounts on it are the difference from the original, not the new value.

The rules come from Art. 106j of the Polish VAT Act and are the same as before KSeF; only the format changed. Invoicing software (Fakturownia, inFakt, wFirma and others) fills in most fields when you choose "issue correction". Below we show what it does on your behalf.

Art. 106j Polish VAT Act (corrective invoices)

What you can and can't correct

A correction can fix almost anything: net, VAT and gross amounts, quantity, price, VAT rate, description of goods or services, date of supply, the buyer's name and address. The exception is the buyer's NIP (tax identification number). If you entered the wrong company's NIP, you need a zero-value correction and a new invoice (see below).

Correcting an amount step by step

Example: Ania, a freelance graphic designer running a JDG (sole proprietorship), issued invoice FV/001/04/2026 on 1 April 2026 for 5,000 zł net (23% VAT) for a visual identity project. It should have been 4,500 zł, so the difference is −500 zł net.

Step 1: invoice type KOR

In the XML, RodzajFaktury is KOR instead of VAT.

Step 2: reason for correction

PrzyczynaKorekty is a short description, for example "Błędna cena usługi" (wrong service price). The schema doesn't require it, but the tax office may ask for an explanation and your client sees at once what changed.

Step 3: correction period TypKorekty

This field decides which VAT return the correction goes into, so it has real tax consequences:

  • 1: the correction takes effect on the date the original invoice was recorded (backwards),
  • 2: it takes effect on the date the correction is issued (current period),
  • 3: it takes effect on another date, including when dates differ between line items.

For a simple amount correction 2 is the usual choice. Most invoicing software picks the value itself; if yours doesn't, agree it with your accountant.

Step 4: reference to the original DaneFaKorygowanej

You give the original's issue date (DataWystFaKorygowanej), its number (NrFaKorygowanej) and its KSeF number information, in exactly one of two variants:

SituationWhat to set
Original went through KSeFNrKSeF = 1 + field NrKSeFFaKorygowanej with the original KSeF number
Original issued before KSeFNrKSeFN = 1 (no NrKSeFFaKorygowanej)

Setting both fields at once gets the invoice rejected. A KSeF number looks like NIP-DATE-XXXXXXXXXXXX-ZZ; copy it rather than retyping, because a typo stops the system linking the correction to the original. In the example the original went through KSeF, so we set NrKSeF = 1 and give its number.

Step 5: amounts as a difference

This is the most common mistake. Amounts on a correction are the difference between what was and what should be:

  • original: 5,000 zł net, 1,150 zł VAT, 6,150 zł gross,
  • should be: 4,500 zł net, 1,035 zł VAT, 5,535 zł gross,
  • on the correction you enter: −500.00 zł net, −115.00 zł VAT, −615.00 zł gross.

A difference-method correction is added to the original in both parties' books. Enter 4,500 instead of −500 and the invoice effectively totals 9,500 zł.

The same applies to line items (FaWiersz): P_11 is the difference, while descriptive fields such as P_7 (name of goods or services) show the state after correction. There is also a "before/after" method using the StanPrzed field (two rows: original and corrected data). We describe the simpler difference method here.

Step 6: check the file before sending

A correction has more required fields than a regular invoice, so it's easier to miss something. If your software doesn't validate corrections and you have the XML file, upload it to ksefuj.to to check it against MF requirements, including the consistency of the reference fields to the original.

Zero-value correction when the buyer's NIP is wrong

The FA(3) structure doesn't let you swap the buyer's NIP in an ordinary correction. You issue two documents:

  1. A zeroing correction: every amount negated and equal to the original, so original plus correction comes to 0 zł.
  2. A new invoice with the right NIP and amount.

This is the only scenario that needs two documents, and no software does it in one click. A zeroing correction doesn't cancel the invoice: both documents stay in KSeF permanently and their sum is zero. If you received such an invoice from someone else, see what to do about a fake invoice in KSeF.

Correcting an invoice issued before KSeF

If you're correcting an invoice from before 1 April 2026, set NrKSeFN = 1 in DaneFaKorygowanej, because the original has no KSeF number. The correction itself must be in FA(3): the FA(2) schema expired on 31 January 2026 and KSeF won't accept it in any form, even for an invoice from the FA(2) era. We compare the schemas in FA(2) vs FA(3).

XML example

Ania Kowalska's correction (FV/001/04/2026, −500 zł net, 23% VAT):

<?xml version="1.0" encoding="UTF-8"?>
<Faktura 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-04-02T10:00:00Z</DataWytworzeniaFa>
  </Naglowek>
  <Podmiot1>
    <DaneIdentyfikacyjne>
      <NIP>5214567890</NIP>
      <Nazwa>Ania Kowalska Grafika</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>
      <KodKraju>PL</KodKraju>
      <AdresL1>ul. Kwiatowa 12</AdresL1>
      <AdresL2>00-123 Warszawa</AdresL2>
    </Adres>
  </Podmiot1>
  <Podmiot2>
    <DaneIdentyfikacyjne>
      <NIP>7891234560</NIP>
      <Nazwa>Klient Sp. z o.o.</Nazwa>
    </DaneIdentyfikacyjne>
    <Adres>
      <KodKraju>PL</KodKraju>
      <AdresL1>ul. Handlowa 5</AdresL1>
      <AdresL2>30-002 Kraków</AdresL2>
    </Adres>
    <JST>2</JST>
    <GV>2</GV>
  </Podmiot2>
  <Fa>
    <KodWaluty>PLN</KodWaluty>
    <P_1>2026-04-02</P_1>
    <P_2>FV/001K/04/2026</P_2>
    <P_13_1>-500.00</P_13_1>
    <P_14_1>-115.00</P_14_1>
    <P_15>-615.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>Błędna cena usługi</PrzyczynaKorekty>
    <TypKorekty>2</TypKorekty>
    <DaneFaKorygowanej>
      <DataWystFaKorygowanej>2026-04-01</DataWystFaKorygowanej>
      <NrFaKorygowanej>FV/001/04/2026</NrFaKorygowanej>
      <NrKSeF>1</NrKSeF>
      <NrKSeFFaKorygowanej>5214567890-20260401-000001000001-49</NrKSeFFaKorygowanej>
    </DaneFaKorygowanej>
    <FaWiersz>
      <NrWierszaFa>1</NrWierszaFa>
      <P_7>Projekt graficzny — identyfikacja wizualna</P_7>
      <P_8B>1</P_8B>
      <P_9A>-500.00</P_9A>
      <P_11>-500.00</P_11>
      <P_12>23</P_12>
    </FaWiersz>
  </Fa>
</Faktura>

Four places matter in this file: RodzajFaktury = KOR, the DaneFaKorygowanej block pointing to the original, the negative P_13_1, P_14_1 and P_15 (a difference, not a new value), and FaWiersz with a negative P_11.

FA(3) XSD Schema — CRD FAQ MF — KSeF 2.0

If a correction comes back with an error, check the most common FA(3) validation errors.