Does a translated KSeF invoice PDF have legal force?

A German counterparty asks for an invoice in German, a finance team wants an English PDF, accounting asks for XML, and your system also shows a KSeF number and UPO. These are not competing documents. They are different layers of the same process.

A translated PDF helps the counterparty read the invoice, but it should not be treated as a new invoice or as the standalone source of KSeF data. The safest wording is informational visualization of an invoice issued in KSeF.

For a structured invoice, the formal axis remains FA(3) XML, the KSeF number assigned after acceptance and UPO. When the invoice is shared outside KSeF, the agreed delivery method and a correct visualization, including a QR code where applicable, matter.

KSeFGPT can help download a readable language version of the invoice, but the presentation layer changes, not the source invoice.

An English, German or Ukrainian PDF can be a readable visualization of an invoice issued in KSeF. It should not be described as a separate invoice, a new original or an official translation unless that separate process really happened.

Separate three concepts: structured invoice, PDF visualization and translated visualization. The structured invoice is FA(3) XML data. The PDF is a human-readable view. The translated PDF is a language version of that view.

From the KSeF perspective, the accepted XML comes first, while the PDF supports reading, circulation and communication. For the broader language workflow, read KSeF invoice in English, German and Ukrainian. The difference between PDF and XML is also explained in Can a PDF be sent to KSeF?.

The cleanest way to avoid mistakes is to treat a KSeF invoice as a set of layers. Each layer has a different role, recipient and limitation.

The translated visualization is useful because it helps the counterparty work with the document. It does not prove KSeF acceptance, create the KSeF number or replace UPO.

For quick communication with a counterparty, the PDF is often the most practical layer. A German finance team wants line items, amounts, payment terms and seller data without reading Polish XML.

The PDF does not replace XML in KSeF and does not prove acceptance by the system. For audit, you need the KSeF number, status and UPO. For data checks, accounting needs FA(3) XML.

The translated PDF also does not decide VAT treatment, intra-Community supply, export of services, place of supply or currency questions. It helps people read the document, not make tax decisions.

The key question is not which file is best. The better question is who needs to do what and which layer supports that action.

A foreign counterparty needs to understand the document and pay it. Accounting needs source data and identifiers. Audit needs the process trail. An approver needs a readable copy with amounts, dates and identifiers.

Official KSeF materials describe QR verification codes as a way to access the invoice in KSeF and verify data, especially when using the invoice outside the system. That is why not every arbitrary PDF should be treated the same way.

If an online invoice is shared outside KSeF, the visualization should remain consistent with the source data and include required markings where applicable. For an invoice already in KSeF, the code relates to the KSeF number. Offline modes may involve additional markings such as OFFLINE or CERTYFIKAT, but that is a separate process topic.

Use a checklist before sending: does the PDF come from the same data as the KSeF invoice, does it avoid a new invoice number and manual amount changes, does the visualization include the required QR code, does the email explain the informational role, and are XML, KSeF number and UPO preserved internally?

For the wider process, read Sending invoices to KSeF, Invoice rejected by KSeF and UPO in KSeF.

Wording matters because the email can later enter the counterparty's accounting workflow. One imprecise sentence can suggest a second invoice or an official translation.

The safest phrase is informational visualization of an invoice issued in KSeF. It is less flashy, but it describes the PDF's role more accurately.

Polish: W załączeniu przesyłamy informacyjną wizualizację faktury wystawionej w KSeF. Wersja językowa służy ułatwieniu odczytu dokumentu i nie stanowi odrębnej faktury. Dane źródłowe faktury pozostają w KSeF.

English: Attached is an informational visualization of the invoice issued in KSeF. This language version is provided for readability and is not a separate invoice. The source invoice data remain in KSeF.

German: Im Anhang senden wir eine informative Visualisierung der in KSeF ausgestellten Rechnung. Diese Sprachversion dient der Lesbarkeit und ist keine separate Rechnung. Die Quelldaten bleiben in KSeF.

These templates do not decide tax questions and do not create extra legal claims for the PDF. They simply define the attachment as a readable version for people, with source data remaining in KSeF.

KSeFGPT lets you work with KSeF invoices and download readable PDFs in Polish, English, German and Ukrainian. This helps with foreign counterparties without manually copying data into a separate template.

A clean process is: invoice data and XML, then submission or receipt in KSeF, then KSeF number and UPO, and finally a readable language visualization for the counterparty. KSeFGPT supports that communication layer without changing the source invoice.

Do not promise that the app creates a sworn translation or decides legal status in every country. For the German workflow, see German invoice for a counterparty from Germany in KSeF.

The first mistake is treating a translated PDF as a second invoice. If it comes from KSeF data, it should remain a visualization without new numbering or manual amount changes.

The second mistake is sending the PDF without explaining the attachment's role. The counterparty may not know whether it is an invoice, duplicate, translation, note or supporting material.

The third mistake is failing to keep the KSeF number and UPO internally. The PDF is convenient, but process control needs identifiers and system confirmations.

The fourth mistake is confusing the language layer with tax assessment. An English invoice view does not decide VAT rate, intra-Community supply, export of services or place of supply.

For the technical foundation, read XML and FA(3) format in KSeF. It explains why a structured invoice is data, not only a PDF view.

If process evidence matters, read UPO in KSeF. To understand the source file itself, see How to read KSeF XML.

For foreign counterparty communication, start with KSeF invoice in English, German and Ukrainian, and for German recipients read German invoice for a counterparty from Germany.