Your invoice went to KSeF with 8% VAT instead of 23%. You cannot recall the submission, edit the line, or delete the document. From the moment KSeF assigns its number, the invoice is immutable, and the incorrect version stays in the system permanently, alongside whatever correction you issue against it.
There is a second change that caught many foreign-owned companies off guard. Since 1 February 2026, the nota korygująca (correction note, a document the buyer could issue to fix formal errors) no longer exists. With Article 106k of the VAT Act repealed, the buyer cannot fix even a typo in their own company name. Every error, including purely formal ones, is corrected by the issuer.
This article covers which FA(3) fields decide whether KSeF accepts your correction, how to present the change at line level, and which settlement period the correction belongs to.
What actually changed on 1 February 2026
The substantive rules did not move. Article 106j of the VAT Act still governs when a correction is required: price change, post-transaction discount, returned goods, returned advance payment, or an error in amount or VAT rate.
Three procedural things did change:
The correction note was abolished. This applies to invoices issued before 1 February 2026 and to invoices issued outside KSeF as well. There is no scenario in which the buyer fixes a document themselves.
No more acknowledgment of receipt for downward corrections. Under Article 29a(13) of the VAT Act as in force from 1 February 2026, a structured correction invoice does not require documentation confirming the buyer agreed to the reduction. The system itself evidences delivery.
The correction must be linked to the original inside the XML structure. Not in a comment field, not in an email, but in a specific node.
One common misreading: dropping the acknowledgment requirement does not drop the requirement for a real commercial basis. A discount that exists only in the correction invoice and nowhere else is still a problem in an audit.
The three FA(3) fields a correction cannot go without
A correction invoice in KSeF is an ordinary FA(3) document with a few extra elements.
1. RodzajFaktury (invoice kind). Three values, depending on what you are correcting:
Value Corrects KOR a standard VAT invoice or a simplified one (UPR) KOR_ZAL an advance payment invoice KOR_ROZ a settlement invoice (the final one after advances)
A VAT RR invoice (flat-rate farmer, Article 116) uses a separate FA_RR schema with its own correction type, KOR_VAT_RR. It is not part of FA(3).
2. DaneFaKorygowanej (corrected invoice data). This is where you point at the original: its issue date (DataWystFaKorygowanej), your own invoice number (NrFaKorygowanej), and exactly one of two flags:
the original went through KSeF:
NrKSeF= 1 plusNrKSeFFaKorygowanejholding the full KSeF number,the original was issued outside KSeF, for example before February 2026:
NrKSeFN= 1, and you omit the other two fields.
Never both. Setting both is one of the most frequent reasons a file gets rejected.
<RodzajFaktury>KOR</RodzajFaktury>
<PrzyczynaKorekty>Post-transaction rebate 10%</PrzyczynaKorekty>
<TypKorekty>2</TypKorekty>
<DaneFaKorygowanej>
<DataWystFaKorygowanej>2026-05-12</DataWystFaKorygowanej>
<NrFaKorygowanej>FV/2026/05/118</NrFaKorygowanej>
<NrKSeF>1</NrKSeF>
<NrKSeFFaKorygowanej>5261040828-20260512-XXXXXXXXXXXX-XX</NrKSeFFaKorygowanej>
</DaneFaKorygowanej>
3. TypKorekty (correction effect type). Formally optional, in practice always worth filling in. Per the Ministry of Finance guidance to the FA(3) structure, it takes values 1, 2 or 3:
1: the correction takes effect in the period of the original invoice, so retrospectively,
2: the correction takes effect on the date the correction invoice was issued, so currently,
3: the effect falls on a different date, including cases where individual lines of one correction have different timing.
The most common misreading: TypKorekty does not say whether the correction is upward or downward. It describes the moment of recognition and nothing else.
Alongside it sits PrzyczynaKorekty, a free-text reason. Formally optional, practically mandatory, because it is the first thing the buyer's accountant and a tax inspector will read. Be specific: "quantity 40 instead of 50 units", not "correction".
Three ways to present the change at line level
In the summary section, correction amounts are shown as the delta against the original invoice. A PLN 200 net rebate is -200 in the summary, not the new transaction value. At individual line level, FA(3) allows three methods:
Difference method. One original line maps to one correction line holding only the delta. It was PLN 1,000 net, it should be PLN 800 net, so the correction shows -200. The simplest option, and a good fit for returns, rebates and value changes.
Before and after method (StanPrzed). One corrected position maps to two lines: the first, flagged StanPrzed = 1, shows the incorrect state, the second shows the correct one. This is the recommended approach when the VAT rate or the currency changes, or when several attributes of a line change at once. The FA(3) guidance treats it as required where the correction affects the value of an order or contract.
Reversal (storno). You repeat the incorrect line with negative values, then add a new line with the correct data.
All three produce the same tax outcome, but not the same clarity for the buyer. On a rate change, the difference method can produce a line nobody can interpret without opening the original.
In Biurko you enter the target values, meaning what the line should say after the correction, and the application renders the StanPrzed and StanPo pair itself, handling added and removed positions as pairs with one side zeroed. No manual delta arithmetic.
Which VAT period the correction lands in
This question affects cash flow more than the content of the correction does.
Downward correction, online mode. The seller reduces the taxable base and output VAT in the period in which the correction invoice was issued in KSeF. A structured invoice counts as issued on the day it is sent to KSeF. Legal basis: Article 29a(13) and (14) of the VAT Act.
Downward correction outside KSeF. If the correction was issued on paper or as an ordinary electronic document, the old rules return, meaning the period in which the seller receives the buyer's acknowledgment.
Buyer side. Under Article 86(19a) of the VAT Act, the buyer reduces input VAT in the period in which the correction was received. A structured invoice counts as received on the day KSeF assigns its number (Article 106na(3)), regardless of when the buyer actually downloads it. For foreign-owned entities relying on an external bookkeeper, that timing is set by the system, not by your internal document flow.
Upward correction. Timing follows the cause. An error that existed from the outset sends you back to the original period. A new circumstance, such as a price increase agreed after the sale, is recognised currently.
Individual tax rulings in this area are numerous and not always consistent. For an unusual correction, confirm the classification with your accountant before choosing TypKorekty.
Five situations where mistakes are most common
Wrong buyer NIP (Polish tax identification number). This is not fixed with an ordinary data correction. The invoice reached an entity that bought nothing from you. Per the Ministry of Finance position, you issue a correction to zero against the wrong buyer, then a fresh invoice with the correct NIP.
Correcting a correction. You do not correct a KOR. Each subsequent correction is issued against the original invoice, taking into account the values from earlier corrections. DaneFaKorygowanej always carries the original invoice data, never the previous correction. Biurko blocks an attempt to correct a correction document and points you back to the original.
Correcting an original that has no KSeF number yet. For an invoice issued in offline24 mode, the sequence is fixed: the original goes to KSeF and receives its number first, then you issue the correction. Without the original's KSeF number you cannot build a valid DaneFaKorygowanej with the NrKSeF flag.
Correcting a pre-KSeF invoice. A 2025 invoice is corrected with an FA(3) document carrying NrKSeFN = 1. There is no such thing as a correction in the FA(2) schema; the old structure stopped applying on 31 January 2026.
Collective correction. One correction can cover multiple original invoices, for example an annual rebate for a customer. The DaneFaKorygowanej node is repeatable, but each corrected invoice must be listed separately with its own KSeF number.
Checklist before you send a correction
Confirm the original invoice has a KSeF number. If it does not, send the original first.
Pick the right
RodzajFaktury: KOR, KOR_ZAL or KOR_ROZ, matching the original document type.Set exactly one reference flag:
NrKSeFplusNrKSeFFaKorygowanej, orNrKSeFN. Never both.Write
PrzyczynaKorektydescriptively, so the buyer understands the change without calling you.Set
TypKorektyby the VAT recognition moment, not by the sign of the amount.For VAT rate or currency changes, use the
StanPrzedmethod rather than the difference method.For a wrong buyer NIP: correction to zero, then a new invoice. Not a data correction.
Verify the correction uses the same currency as the original invoice.
Summary
A correction in KSeF is no harder than an ordinary invoice, but it is far less forgiving. A wrong reference flag gets the file rejected outright, and a badly chosen TypKorekty moves VAT into the wrong period and only surfaces during an audit.
Biurko is built around KSeF rather than bolted onto it. You create a correction in one click from the original invoice: the application carries over both parties' data, fills in the KSeF reference, renders the StanPrzed and StanPo lines, and enforces the rules KSeF only checks at validation time. Corrections of imported purchase invoices whose originals are not in your books get flagged for review instead of quietly skewing your registers. The interface is available in Polish, English and Ukrainian.
Create a free account at biurko.io and issue your first correction in the test environment before you do it in production. The free plan is permanent, not a trial.
FAQ
Can I cancel an invoice in KSeF? No. Once a KSeF number is assigned, the document is immutable. The only route is a correction invoice, including a correction to zero if the transaction should never have been invoiced at all. The incorrect invoice remains visible in the system next to the correction.
Who issues a correction in KSeF, the seller or the buyer? Always the seller. Since 1 February 2026, with Article 106k of the VAT Act repealed, the buyer cannot issue a correction note. Any error, including one in the buyer's own name or address, must be reported to the issuer.
How do I correct an invoice issued before KSeF became mandatory? You issue the correction in the FA(3) structure and set NrKSeFN to 1 inside the DaneFaKorygowanej node. You omit NrKSeF and NrKSeFFaKorygowanej, because the original invoice never received a KSeF number.
Do I need acknowledgment of receipt for a downward correction? Not if the correction is a structured invoice. Since 1 February 2026, KSeF itself evidences delivery. You still need a genuine commercial basis for the reduction, such as an agreed rebate or a documented return of goods.
What value goes in TypKorekty for returned goods? A return of goods is a new commercial event, so the correction is recognised currently, in the period it was issued. That corresponds to value 2. Reserve value 1 for errors that existed from the outset, such as an incorrect VAT rate.
Sources: ksef.podatki.gov.pl, podatki.gov.pl/ksef, Act of 11 March 2004 on Goods and Services Tax (Articles 29a, 86, 106j, 106na), Ministry of Finance guidance to the FA(3) logical structure.
Internal links (to replace): /blog/[fa2-vs-fa3-what-changed], /blog/[ksef-offline24-mode], /blog/[common-fa3-validation-errors], /blog/[what-is-a-ksef-number]