How to issue a VAT invoice in KSeF step by step

A regular sales invoice in KSeF is a structured XML FA(3) invoice. In the `RodzajFaktury` field it should use the value `VAT`, because the official FA(3) schema describes this code as a basic invoice.

Correct issuance is not only about choosing one code. You must prepare seller and buyer data, invoice number, dates, line items, VAT rates, totals, payment data, and then check the XML before submission.

After submission, what matters is the KSeF status, KSeF number, and UPO. If the document is a correction, advance invoice, final settlement invoice after an advance payment, or simplified invoice, do not automatically treat it as a regular `VAT` invoice. If the sale uses the VAT margin procedure, check the additional annotations and procedure fields instead of assuming a plain basic invoice without markings.

1. When you issue a VAT invoice in KSeF

2. Is this really a regular VAT invoice

3. What data to prepare before issuing the invoice

4. Step 1: choose the company and permissions

5. Step 2: set RodzajFaktury VAT

6. Step 3: complete party data

7. Step 4: add line items, rates, and totals

8. Step 5: generate XML FA(3)

9. Step 6: check the invoice before submission

10. Step 7: submit the invoice and collect confirmations

This guide is about a regular sales invoice, meaning a basic invoice in the FA(3) structure. It is the typical document for selling goods or services when you are not documenting an advance payment, not settling a previous advance payment, and not correcting an invoice already accepted by KSeF.

The key distinction is practical: an invoice may contain VAT, but it should not always use the XML code `VAT`. An advance invoice, final invoice after an advance payment, or correction may contain VAT, but in FA(3) they belong to separate processes.

If you are not sure, start with the map of invoice types in KSeF. This article assumes that after that decision you are issuing a regular sales invoice.

Before filling in the form, pause for a short decision. This step can prevent later corrections, rejections, and manual explanations in accounting.

The table below is a practical working list, not a literal quote from Article 106e of the Polish VAT Act. For unusual transactions, advance invoices, currencies, special procedures, or foreign sales, confirm the requirements with accounting.

For a typical sales invoice, the most important point is that the business data can be clearly recorded in FA(3): who sells, who buys, what is being sold, for how much, with which VAT rate, and when the document is to be issued.

Before issuing the invoice, make sure you are working in the context of the correct taxpayer. In practice, this means the correct company, the correct seller NIP, and a person or system with permission to issue invoices.

This step is especially important in an accounting office, a group of companies, or any business where one person handles several entities. Technically correct XML will not solve the problem if the invoice was created from the wrong taxpayer account.

If you are still configuring access, return to the guide on how to generate a KSeF certificate. This article focuses on issuing the invoice after access has been prepared.

For a regular sales invoice in FA(3), the key field is `RodzajFaktury`. In the official schema, the value `VAT` means a basic invoice. It is not a marketing label or a PDF caption, but a code in XML.

Do not use `VAT` as the default answer for every sales document. If the document corrects an earlier invoice, documents an advance payment, or settles an advance payment, the type should follow the process, not the name of a template in your software.

Good practice: show the invoice type in the document preview or validation report. The issuer should see whether they are sending `VAT`, `KOR`, `ZAL`, `ROZ`, `UPR`, `KOR_ZAL`, or `KOR_ROZ` before the document reaches KSeF.

In a regular VAT invoice, start with the seller and buyer. For a Polish B2B transaction, the most important data is the NIP, full name, and address. For a foreign counterparty, identifiers and country also matter, and sometimes the invoice text in another language is needed for the recipient.

Do not enter a NIP with random spaces, hyphens, or prefixes if the tool expects clean data. If you use a contractor database, check whether the data is not older than the contract or order.

KSeF does not remove the company's responsibility for contractor data quality. The system may detect some structural errors, but it will not confirm for you that you are selling to the correct legal entity or that the customer's name is current.

After party data, move to invoice line items. Each line should clearly describe the goods or service, quantity, unit, price, VAT rate, and value. If you use a discount, make sure it is consistent with the line amounts and invoice totals.

For a regular VAT invoice, the most common control fields are net amounts by rate, tax amounts, and total amount due. In FA(3), these appear as structured data, not as a PDF table.

If you want to understand the technical XML fields, go to the guide on XML and the FA(3) format in KSeF. Here the process matters more: line item data must match the invoice math and the accounting decision.

You can prepare the invoice in the Taxpayer Application, accounting software, an ERP system, or a tool that generates XML FA(3). Regardless of the tool, the result must comply with the structure required by KSeF.

The public KSeF XML invoice generator in KSeFGPT helps prepare a regular VAT invoice as XML. It is useful for simple cases and data tests, but it does not replace the full submission process to KSeF. Public free tools require an email address and are subject to a daily free-use limit.

Do not treat a downloaded PDF or preview as an invoice accepted by KSeF. A PDF is a readable visualization for humans. The structured invoice is XML, and effective issuance in KSeF is confirmed only by status, KSeF number, and UPO.

Pre-submission validation should have two levels. The first is technical: whether the XML complies with FA(3), has the required fields, and uses a supported invoice type. The second is accounting: whether the data, amounts, and document type reflect the real sale.

Minimum pre-submission check: `RodzajFaktury = VAT`, correct seller NIP, buyer NIP or correct identifier and country if applicable, correct invoice number, dates, line items, VAT rates, totals, currency, and payment. If something does not match, correct the XML before submission instead of relying on a correction afterwards.

For a quick file check, you can use the KSeF XML validator. The validator does not make tax decisions for the company, but it helps detect structural errors and obvious inconsistencies before the next process step.

After preparing and checking XML, the submission stage begins. In online mode, a structured invoice is considered issued on the date it is sent to KSeF, and considered received using KSeF on the date the system assigns the invoice identifying number.

For the company process, three pieces of information matter most: submission status, KSeF number, and UPO. The invoice number from your own series, usually field `P_2`, is not the KSeF number. These are two different identifiers and both should be stored.

The detailed process of sessions, submission, and confirmation retrieval is described in the guide on sending invoices to KSeF. This article stops at the minimum needed for a regular VAT invoice.

After acceptance, store the KSeF number, UPO, your own invoice number, submission date, and status. If you use an invoicing system, this data should return to the invoice record, not remain only in a downloaded file.

Internally, it is worth separating three states: invoice draft, XML ready for submission, and invoice accepted by KSeF. The most errors appear when a team treats a generated file or PDF preview as a document already effectively accepted.

If the UPO does not appear immediately, check the process status instead of immediately issuing a second invoice with the same data. A duplicate can create a bigger problem than a short wait for confirmation.

The first mistake is using the `VAT` type for a document that should be a correction, an advance invoice, or a settlement of an advance payment. Technical validation alone does not fix this, because some decisions follow from the business and tax process.

The second mistake is inconsistent math: line items look correct, but net totals, VAT, and gross totals do not match after a discount or rounding. The third mistake is contractor data copied from an old record without checking the current NIP and name.

The fourth mistake is reissuing a document outside the correct process after rejection or missing UPO. If KSeF rejected the invoice, start with the diagnostic guide on invoice rejected by KSeF.

KSeFGPT helps on two levels. Public tools let you prepare XML for a regular VAT invoice and check the file with a validator. This is a useful stage for simple invoices, data tests, and learning the FA(3) structure.

The full invoice module is a broader document workflow: organizing invoices, monitoring statuses, working with XML, previewing documents, links between records, and data needed by accounting. The public generator should not be confused with the full KSeF submission and handling system.

The safest company process is: prepare data, generate XML, check validation, submit the invoice in a tool that supports KSeF, store the KSeF number and UPO. KSeFGPT describes this direction more broadly on the invoices module page.

Use this list as a short procedure for a regular VAT invoice. If any point raises doubt, stop submission and correct the data before sending the document to KSeF.

If this article answers your question about a regular sales invoice, the next steps depend on the problem in front of you.

First read invoice types in KSeF if you are not sure whether `VAT` is the correct type. Then go to sending invoices to KSeF if you want to understand sessions, statuses, and confirmations.

If the problem is technical, return to XML and the FA(3) format in KSeF. If the document did not pass through KSeF, start with the guide on invoice rejected by KSeF.