Invoice Types in KSeF: VAT, KOR, ZAL, ROZ and UPR

In the FA(3) schema, the RodzajFaktury field determines which document type you are working with: a standard invoice, correction, advance invoice, settlement invoice, simplified invoice or a correction related to an advance payment.

VAT is the most frequently used type, but not every invoice that includes VAT should use this code. Once KSeF has accepted a document, fixing it usually requires KOR, KOR_ZAL or KOR_ROZ, depending on the type of the corrected invoice.

Before submission, check the invoice type in the XML file and in the document preview. Selecting the wrong RodzajFaktury value may cause more than a technical error: it can also misrepresent a sale, advance payment, settlement or correction process.

RodzajFaktury is an element of Poland's FA(3) XML invoice, not a description added merely for the user's convenience. In the official FA(3) schema, the field uses the TRodzajFaktury type, which permits specific values: VAT, KOR, ZAL, ROZ, UPR, KOR_ZAL and KOR_ROZ.

This matters because KSeF processes structured data rather than the document's appearance. Two invoices may look similar in a PDF, but a different code tells the system that it is dealing with a different process: an initial sale, correction, advance payment, advance settlement or simplified invoice.

If you first need an overview of the terminology, read XML and the FA(3) schema in KSeF. This article focuses on the practical decision that follows: which type to select before issuing or correcting an invoice.

The table below is a practical map rather than a complete interpretation of the Polish VAT Act. It provides a starting point for selecting the document type and links to more detailed guidance.

Start by asking whether the document records the first event or corrects a document that KSeF has already accepted. For the first regular sales invoice, VAT will usually be the starting point. When correcting an accepted document, move to the correction family.

The second question concerns advance payments. If you receive part of the payment before supplying goods or performing a service, check ZAL. If you issue a document that settles the entire transaction after an advance payment, check ROZ. When correcting either document, do not automatically select the ordinary KOR type because FA(3) provides the separate KOR_ZAL and KOR_ROZ types.

The third question concerns simplification. If the document is a simplified invoice, consider UPR, but do not treat every fiscal receipt bearing the buyer's NIP as the same case. In practice, you must distinguish between a fiscal document, simplified invoice, full invoice and transitional rules.

In the FA(3) schema, VAT identifies a standard invoice. It is the appropriate starting point for a typical sales invoice when you are not issuing an advance invoice, settlement invoice, simplified invoice or correction.

Do not think of VAT as a label for every invoice that includes value added tax. An advance invoice may also include VAT but has a different type in FA(3). Likewise, a correction of an ordinary sales invoice should not return as another VAT invoice but as a corrective invoice.

The complete process for a standard sales invoice is described in How to issue a VAT invoice in KSeF step by step. This article only helps you recognise when VAT is the correct choice and when another type is required.

KOR identifies a corrective invoice. This type applies when the original invoice has already been accepted by KSeF and its data or effects must be corrected through the prescribed correction process.

The practical dividing line is important: an invoice accepted by KSeF is not fixed by editing the old document or resubmitting the same XML file. If the document has a KSeF number and needs correction, you must determine the appropriate correction type.

For a standard sales invoice, KOR is the starting point. For an advance or settlement invoice issued after an advance payment, check KOR_ZAL and KOR_ROZ separately. The detailed process is covered in Corrective invoice in KSeF.

ZAL applies to an invoice documenting receipt of all or part of a payment before the taxable supply. In practice, this includes deposits, prepayments and similar situations in which the document is created before the goods are finally supplied or the service is performed.

ROZ applies to an invoice issued to settle a transaction after an earlier advance payment. Businesses often call it a final or settlement invoice, but the XML file must use the correct code and maintain the required links to earlier documents.

A common mistake is to reduce the whole process to a single rule: there was an advance payment, so always use ZAL. That is not enough. Use ZAL when documenting the advance itself. When settling the transaction after the advance, check ROZ. See Advance invoice in KSeF for more context.

In the FA(3) schema, UPR refers to the invoice described in Article 106e(5)(3) of the Polish VAT Act. In practical terms, remember that UPR concerns the Polish simplified invoice rules; the exact statutory scope should always be checked against the current wording of the Act.

The code cannot be assigned automatically to every fiscal receipt bearing the buyer's NIP. For KSeF purposes, you must distinguish between a B2C document, simplified invoice, full invoice and transitional cases. The issue has a separate practical context, particularly after changes affecting the smallest taxpayers and the end of selected transitional preferences from 2027.

For the distinction relevant here, see Receipt with NIP after January 1, 2027, which explains the process and risks in more detail.

KOR_ZAL and KOR_ROZ are necessary because advance payments create a separate chain of documents. Correcting an ordinary sales invoice is not the same as correcting an advance invoice or a final invoice issued after an advance payment.

KOR_ZAL applies to the correction of an invoice documenting an advance payment or payment made before the taxable supply. KOR_ROZ applies to the correction of a settlement invoice issued after an advance payment. In both cases, check the link to the corrected document, the amounts after correction and any line items before and after the change.

These types are defined here so that all corrections are not treated as one category. Detailed examples belong in separate guides because the correct correction process matters more than the code's name alone.

The first mistake is using VAT for a document that is a correction. If KSeF has already accepted the invoice and you are changing amounts, data or the document's effects, the process will usually require a correction rather than a second ordinary invoice.

The second mistake is confusing ZAL with ROZ. An advance invoice documents payment received before the taxable supply, while a settlement invoice closes or settles the transaction after advance payments. If several advances are involved, the wrong type can make later document links harder to maintain.

The third mistake is treating KOR_ZAL and KOR_ROZ as merely technical variants of an ordinary correction. They are separate codes because the corrected document has a different nature. XML validation may detect some problems caused by the wrong selection, but it cannot replace an accounting decision.

The fourth mistake is automatically associating UPR with every fiscal receipt bearing NIP. A simplified invoice has its own rules and requires an assessment of whether the document should enter KSeF at all and in what form.

KSeFGPT supports work with FA(3) invoice types at several stages. The XML validator recognises RodzajFaktury, displays it in the report and flags an unsupported value. The invoice preview turns codes such as KOR_ZAL and KOR_ROZ into clear labels, making it easier to spot a mistake before continuing.

In the full KSeFGPT application, you can organise the process of issuing invoices and corrections within the FA(3) types: prepare the document, check its XML and preview, and work with corrections. The public generator in the free tools section is simpler and is mainly intended for a standard VAT invoice, so it should not be confused with the application's full scope.

The safest process is straightforward: select the correct type, validate the XML file, review the invoice preview and only then submit the document to KSeF or pass it on within the company. Learn more on the KSeFGPT Invoices page.

Before submission, confirm that the RodzajFaktury code matches the actual process rather than only the document name used in the accounting system. An ERP template name and the code in the XML file are not always the same thing.

For a correction, check the corrected invoice number, reason for correction, post-correction amounts and buyer data. For an advance payment, establish whether the document records the payment itself or settles an earlier advance. For UPR, make sure you are not confusing a simplified invoice with a fiscal receipt bearing NIP or a full invoice.

Finally, validate the file against the FA(3) schema. A validator will not make the tax decision for you, but it will quickly identify technical errors, missing fields and an unsupported RodzajFaktury value.