Invoice visualization in the National e-Invoicing System (KSeF) in Poland – when can a PDF create VAT risk?

data stored in an XML file easier to read. It is not a separate commercial document that can be freely prepared according to a company’s own template without reference to the structured invoice submitted to KSeF. In practice, businesses should treat the visualization as a readable representation of the data sent to the National e-Invoicing System, not as a separate sales document.

This issue becomes particularly important after the mandatory implementation of KSeF in Poland. For most taxpayers, the structured invoice in XML format becomes the core tax document, while the PDF file or printout serves an operational purpose. It may be used for communication with contractors, payment processing, cost approval, internal archiving or sharing invoices with people who do not work directly with technical data. For this reason, the visualization should not be treated as just any auxiliary document, but as a readable representation of the data submitted to KSeF.

This business practice is understandable. The problem arises when the visualization starts to differ from the structured invoice in a way that may change how the transaction, amounts, settlements or scope of supply are understood. In extreme cases, an incorrectly prepared PDF may be assessed not as a supporting visualization, but as a separate invoice.

What is invoice visualization in the National e-Invoicing System (KSeF) in Poland?

A structured invoice issued through the National e-Invoicing System (KSeF) in Poland takes the form of an XML file. This format is designed primarily for processing by IT systems, not for convenient human reading. For this reason, businesses commonly use invoice visualizations, most often in PDF format.

A visualization presents XML data in a layout similar to a traditional invoice. It may include, among other things, seller and buyer details, invoice number, dates, description of goods or services, taxable base, VAT rates, tax amounts, gross value and payment details.

The key point is that the visualization should not create new tax content. Its function is to display the data included in the structured invoice, not to supplement, modify or replace it.

Is a KSeF invoice visualization an invoice?

As a rule, a correctly prepared visualization of an invoice issued in the National e-Invoicing System (KSeF) in Poland is not a separate invoice. It is a technical and informational representation of the structured invoice that has already been issued in the system and assigned a KSeF number.

This means that sending a PDF visualization to a contractor should not be treated as re-issuing the invoice, provided that the document accurately reflects the data from the structured invoice. In this model, the only invoice documenting the sale remains the invoice stored in KSeF. This is important, among other things, for determining the invoice issue date. If the invoice has been issued in the National e-Invoicing System and assigned an identifying number in the system, the later delivery of its visualization to the contractor should not change the invoice issue date for Polish VAT purposes. The PDF delivery date is then only the date on which a readable image of the invoice was provided.

Why do companies still use PDF visualizations?

Invoice visualizations remain necessary despite the operation of KSeF because many business processes still require a readable document. This is particularly relevant in companies where invoices are reviewed not only by accounting teams, but also by purchasing, sales, logistics, controlling departments or employees responsible for approving payments.

A visualization is useful in particular for:

• quick verification of invoice data by an employee,
• providing the document to a contractor outside KSeF where required by regulations or arrangements between the parties,
• supporting cost approval workflows,
• checking data consistency between sales, accounting and payment systems,
• auxiliary archiving in the internal document workflow.

However, this does not mean that the PDF can function independently of the XML file. The more the visualization resembles a standalone invoice, and the more it contains data that differs from the file submitted to the National e-Invoicing System (KSeF), the higher the tax risk.

QR code and KSeF number on the invoice visualization

In practice, a visualization of an invoice issued in the National e-Invoicing System (KSeF) often includes the KSeF number and a QR code. Their purpose is to link the visualization with the structured invoice and allow the document to be verified.

The QR code is particularly important when the invoice is used outside KSeF. It makes it possible to verify invoice data and confirm access to the document in the system. However, the QR code should not be treated as an element that automatically removes every risk connected with the content of the visualization.

If the PDF contains data that differs from the XML file, the KSeF number or QR code alone does not necessarily make the document safe. From a tax perspective, the key issue is whether the content of the visualization is consistent with the structured invoice.

When can invoice visualization in KSeF create tax risk?

The greatest risk arises when the visualization is not a faithful representation of the data submitted to the National e-Invoicing System. This applies not only to obvious errors in amounts, but also to differences that may affect how the buyer understands the transaction.

Risky situations may include:

• showing data on the PDF that is not included in the XML file,
• omitting data from the PDF that was included in the XML file and affects the settlement,
• presenting a different amount payable,
• adding charges, deductions or discounts outside the invoice structure,
• using descriptions that may change how the subject of the transaction is understood,
• changing field names in a way that may mislead the buyer,
• preparing a visualization that looks like a standalone invoice but does not exactly correspond to the data in KSeF.

In practice, a problem may arise even when the basic invoice data is the same, but the way the settlement is presented creates uncertainty as to the final amount due or the nature of the supply.

Individual interpretation of 30 April 2026 – an important signal for taxpayers in Poland

In an individual tax interpretation dated 30 April 2026, the Director of the National Tax Information drew attention to the risk connected with an invoice visualization that differs from the data submitted to the National e-Invoicing System (KSeF).

The case concerned a taxpayer planning to issue structured invoices in XML format and then send PDF visualizations to contractors.

The visualization was intended to include, among other elements, the KSeF number, the date of submission to the system and a QR code. However, the taxpayer also assumed that certain differences between the XML and PDF could occur, including a different presentation of data, additional business descriptions, different header names and differences relating to charges or deductions affecting the amount payable.

The authority considered this approach incorrect. It indicated that the visualization should remain consistent with the structured invoice. If additional data is relevant to the settlement and has been included in the XML structure, it should also be reflected in the visualization. Conversely, if the taxpayer presents data on the PDF differently, this may mislead the recipient as to the terms of the transaction.

The key practical conclusion from this interpretation is clear: taxpayers should not treat the visualization as a place for freely adapting the invoice to their own business needs. If the PDF is intended to be a visualization of an invoice issued in KSeF, it must be consistent with that invoice.

Can a defective invoice visualization be treated as an empty invoice?

Such a risk may arise if the PDF document is not merely a visualization of a structured invoice, but starts to function as a separate document showing a VAT amount. In that case, the Polish tax authority may examine whether Article 108 of the Polish VAT Act applies.

This provision imposes an obligation to pay the tax shown on an invoice. In practice, it is most often associated with so-called empty invoices, meaning documents that do not reflect an actual transaction. However, risk may also arise where a taxpayer introduces two documents relating to the same sale into circulation, and one of them is not a faithful representation of the structured invoice issued in the National e-Invoicing System.

This does not mean that every PDF visualization is an empty invoice. Such a conclusion would go too far. A correct visualization, consistent with the XML file, has an auxiliary function. The issue concerns situations where the document shared outside KSeF contains discrepancies significant enough for it to be treated as an independent invoicing document.

What additional data can be included in a visualization?

A visualization may include technical and identification elements that help link the document with the invoice in KSeF. This applies in particular to the KSeF number, QR code and information allowing the invoice to be verified.

Caution is required, however, in relation to data concerning the transaction itself, amounts, payments, discounts, deductions, charges, classification of goods or services, or commercial terms. If such information is relevant to the settlement, the first step should be to consider whether it should be properly included in the structured invoice.

Additional data should not:

• change the meaning of information included in the XML file,
• affect how the amount due is understood,
• suggest transaction terms other than those shown in the KSeF invoice,
• replace fields in the FA(3) structure,
• cause the contractor to receive a different picture of the transaction than the one resulting from the structured invoice.

The safest approach is to apply a simple principle: the visualization should reflect the invoice, not supplement it.

Invoice visualization and the FA(3) structure

As the National e-Invoicing System (KSeF) develops, the logical structure of the invoice becomes increasingly important. It determines which data is submitted to the system and how it should be processed by accounting software.

If a business wants to show specific information relating to the settlement, it should first check whether the FA(3) structure provides appropriate fields for that data. This may concern, among other things, additional settlement elements, payment data or item descriptions.

It is incorrect to omit information relevant to the contractor in the XML file while showing it on the PDF, or the other way around: to include data in the XML file but not show it in the visualization. In both cases, there may be a risk of inconsistency between documents.

Can field names be changed in the invoice visualization?

Changing the graphic layout of the document does not automatically mean that an error has occurred. A visualization may be prepared in different systems and will not always look identical. The problem appears when the terminology used changes the meaning of the data or suggests that a given field has a different meaning than in the invoice structure.

For example, changing the description of an invoice item may seem to be only an editorial adjustment. However, if the new header or description means that the buyer may understand the subject of the transaction, scope of supply or settlement value differently, such a change becomes risky.

In practice, companies should avoid creative modifications of field names, especially in areas relating to invoice items, amounts, discounts, tax and payments. It is safer to use descriptions that remain as close as possible to the meaning of the data resulting from the structured invoice.

Invoice visualization and the invoice issue date

Providing the visualization to a contractor should not be treated as the invoice issue date if the invoice has already been issued in the National e-Invoicing System (KSeF) and assigned an identifying number in the system. In such a situation, the date on which the PDF is sent is technical and informational.

For businesses, this means that internal procedures should distinguish between:

• the date the invoice is issued in KSeF,
• the date the KSeF number is assigned,
• the date the visualization is provided to the contractor,
• the date the document is received or downloaded in internal processes.

Confusing these dates may lead to errors in records, VAT settlements, payment processes and deadline monitoring. Therefore, companies should ensure that their accounting system and document workflow procedures clearly identify which event is relevant for tax purposes and which is only organizational.

How to prepare a safe invoice visualization in the National e-Invoicing System (KSeF) in Poland

A safe visualization should be designed together with the invoicing process, not as an additional PDF template created independently of the XML file. The most important point is to maintain consistency between the data in KSeF, the financial and accounting system, and the document shared with the contractor.

In practice, the following rules are worth applying:

• the visualization should be generated based on data from the structured invoice,
• amounts should correspond to the XML data,
• additional settlement information should be included in the structure if the structure provides appropriate fields for it,
• the PDF should not show an alternative amount payable if it does not clearly result from the structured invoice,
• field names and descriptions should not change the meaning of the data,
• the QR code and KSeF number should be used in line with the rules for using invoices outside KSeF,
• every visualization template should be tested before implementation.

Testing atypical cases is particularly important, including invoices with discounts, corrections, additional charges, deductions, advance payments, partial payments, multiple VAT rates or complex item descriptions.

The importance of accounting procedures and data controls

The National e-Invoicing System (KSeF) will reduce some technical errors, but it will not replace proper accounting procedures. The system will accept an invoice that complies with the structure, but responsibility for the correctness of data, its classification and the consistency of processes remains with the taxpayer.

From a company’s perspective, the invoicing process should include not only sending the XML file to KSeF, but also checking what will be shown to the contractor in the visualization. This is especially important for organizations using several systems, such as sales, warehouse, accounting, payment and customer communication tools.

The implementation of KSeF should therefore be combined with a review of invoicing procedures, document workflow and invoice posting processes.

Companies that need support in this area can use getsix® accounting services in Poland, including accounting support, tax settlements and assistance in organizing financial processes.

The most common mistakes in KSeF invoice visualizations

The most common mistakes do not result from preparing a PDF as such, but from a lack of control over what exactly appears in the visualization. In practice, the problem may be the automatic generation of a document based on a template that has not been adjusted to the KSeF structure.

Typical mistakes include:

• adding commercial information outside the invoice structure,
• using a PDF template that is inconsistent with the XML data,
• presenting a different amount payable than the amount resulting from the invoice,
• omitting important settlement data visible in the XML file,
• using item descriptions that do not correspond to the data in the structure,
• failing to include a QR code where the invoice is used outside KSeF and such marking is required,
• failing to test corrective invoices and more complex transactions.

It is worth remembering that the problem may only become visible on the buyer’s side. If the contractor downloads the invoice from KSeF and compares it with the PDF received from the seller, discrepancies may lead to disputes, payment delays or questions from the accounting department.

Invoice visualization in relations with foreign contractors

Invoice visualization in the National e-Invoicing System (KSeF) in Poland is particularly important in relations with foreign contractors, who may not use KSeF in the same way as Polish taxpayers. In such cases, the PDF may perform an important communication function, because it allows the recipient to understand the invoice content without having to analyse the XML file.

However, this does not change the basic rule: the document provided outside KSeF should correspond to the structured invoice. If a foreign contractor receives a PDF, they should receive a readable image of the same invoice that was issued in the system.

For companies handling international sales, consistent language and system procedures are especially important. Translations of descriptions, product names, payment terms and additional information should not lead to discrepancies in how the transaction is understood. If a company uses bilingual document templates, it should check whether the language version changes the meaning of the data included in the structured invoice.

---

A visualization of an invoice issued in the National e-Invoicing System (KSeF) is a necessary business tool because it presents XML data in a readable format. However, it should not be treated as an independent document that can be freely modified.

The key rule is simple: the visualization should reflect the structured invoice. If the PDF contains data that differs from the XML file, omits information relevant to the settlement or presents the transaction differently, tax risk may arise, including the risk that the document could be treated as a separate invoice. For businesses in Poland, this means that invoice templates, procedures and data controls must be prepared carefully. Implementing KSeF does not end with sending the invoice to the system. It also includes how the company presents the invoice to the contractor, posts documents in accounting records and ensures data consistency across the entire financial process.