KSeF Invoice in Ukrainian for a Counterparty or Finance Team

An invoice processed through Poland's National e-Invoice System (KSeF) can have a Ukrainian or Polish-Ukrainian visualisation. The view must remain substantively consistent with the source XML data. In KSeFGPT, an incoming or outgoing invoice can be downloaded as a PDF with Ukrainian labels.

The recipient's language does not determine their KSeF status. A Polish company with a Polish Tax Identification Number (NIP) may receive the invoice through the system, while a Ukrainian PDF helps its finance team read it. A Ukrainian company without a Polish NIP may need the document through an agreed channel outside KSeF, with the correct visualisation and QR code.

Changing the language does not alter the FA(3) XML, the issuer's invoice number, the KSeF number, UPO, amounts, currency or dates. A test of the same invoice in Polish and Ukrainian also confirmed an identical URL encoded in the QR code, but showed that some system-generated values and free-text content can remain in Polish.

This guide includes a recipient matrix, instructions for downloading the Українська version, a Polish-Ukrainian field check and short message templates that explain the PDF without creating a second invoice workflow.

Yes, if an invoice in Ukrainian means a foreign-language or bilingual visualisation that is consistent with the invoice data. The official Polish Ministry of Finance FAQ states that a visualisation may be prepared in a foreign language or in two languages, provided that it remains substantively consistent with the XML submitted to KSeF.

Three situations need to be separated. The first is Ukrainian text entered into an XML field that permits it. The second is Ukrainian visualisation labels, such as Продавець, Покупець and Дата виставлення. The third is translation of free-text content, such as a service description or note. Each layer requires a different check.

Not every field in the FA(3) structure necessarily accepts unrestricted Cyrillic text. Individual XSD elements have their own data types, length limits and patterns. A Ukrainian label also does not automatically translate a value entered by the issuer.

The roles of each document are explained further in Translated KSeF invoice, PDF, XML and UPO. Once the language layer is clear, the next question is who should receive the document and what role the PDF has for that recipient.

1. Can a KSeF invoice be in Ukrainian?

2. First identify who will receive the document

3. What the Ukrainian version changes and what it does not

4. How to download a Ukrainian PDF in KSeFGPT

5. How to check the Ukrainian version before sending it

6. How to send the invoice to a Ukrainian counterparty

7. Рахунок, рахунок-фактура or податкова накладна?

8. Common mistakes with an invoice in Ukrainian

9. Expert perspective

10. How KSeFGPT supports the Ukrainian invoice workflow

11. Frequently asked questions

A Ukrainian version is useful only when it remains consistent with the source and reaches the recipient through the correct channel.

A common mistake starts with this assumption: the recipient speaks Ukrainian, so the invoice should be sent outside KSeF. Language, nationality and country alone are not enough to determine the delivery channel. First establish the entity's status and the role of the person who needs to read the PDF.

A Polish company with a NIP may employ Ukrainian-speaking staff in its finance team. The company will generally receive the invoice through KSeF when the entity and transaction fall within that channel, while the Ukrainian PDF helps the team read it. If the recipient is a Ukrainian company without a Polish NIP, agree the delivery method with that recipient and check the required markings for a visualisation used outside KSeF.

The Ukrainian nationality of a Polish business owner does not change the company's status either. If the recipient is a consumer, do not apply B2B rules automatically. Use guidance specific to consumer invoices and assess the particular relationship.

This matrix does not decide export treatment, place of supply, VAT rate or customs obligations. Once the recipient is identified, the roles of the XML, KSeF number, UPO and Ukrainian PDF can be assigned correctly.

A Ukrainian visualisation primarily changes presentation. The recipient sees Ukrainian headings and labels that make the seller, buyer, dates, amounts and payment details easier to find. It does not create a new dataset, and the role of the PDF depends on the recipient's status and the invoice delivery channel.

The issuer assigns its own invoice number and uses it in its records. The KSeF number is a separate identifier assigned after the system accepts the document. UPO is the official acknowledgement of the acceptance process, but it is not an invoice translation and does not have to be a standard attachment for the recipient.

Interpret the PDF in the context of the recipient's status. For a Polish taxpayer receiving the document through KSeF, it will usually be a readable visualisation. For certain foreign recipients, a document delivered outside KSeF through an agreed method may serve as the invoice received by that recipient. One simplified label therefore does not fit every case.

If you need to recreate a readable view directly from source data, read How to convert KSeF XML into a readable PDF invoice. Once the document layers are clear, you can safely download the Ukrainian version in the application.

In KSeFGPT, you select the visualisation language while downloading the same invoice. There is no need to copy amounts into a separate template or create a second document manually.

Step 1: open the Invoices module and go to Incoming or Outgoing, depending on where the document is stored.

Step 2: find the correct invoice and expand the options next to the PDF button.

Step 3: select Українська. Polish, English and German are available in the same list.

Step 4: download and open the file before sharing it. Confirm that the PDF refers to the correct invoice and that the labels are readable.

Step 5: compare the document with the source, then deliver it through the correct channel. Downloading the file does not replace a review of the data, free-text content or QR code.

The next step is a Polish-Ukrainian check so that the recipient and issuer can verify the same values even though the labels differ.

On August 4, 2026, we used generator version 1.1.4-HF2 to create two PDF files from the same anonymised FA(3) invoice: one in Polish and one in Ukrainian. The issuer's invoice number, KSeF number, NIP identifiers, transaction parties, addresses, dates, currency, amounts, payment deadline and URL encoded in the QR code remained identical.

Labels that changed in the Ukrainian PDF included Основний рахунок, Номер рахунка:, Продавець, Покупець, Код валюти:, Сума нетто, Сума податку and Сума брутто. The product or service name and footer entered in Cyrillic remained identical in both versions, confirming that the generator does not translate free-text content.

The test also showed mixed-language system-generated values. In the Ukrainian file, values including Polska, NIE, Faktura wystawiona w walucie PLN, szt, zw, Przelew and the page numbering remained in Polish. The feature should therefore be described as a visualisation with Ukrainian labels, not a guarantee that the whole PDF is translated.

The characters і, ї, є and ґ, together with the Ukrainian apostrophe, rendered correctly and could be read from the test free-text content. In your own document, still check item names, notes, purchase order number, payment description and other user-entered values.

The table below reproduces labels observed in the current generator. After this check, you can prepare the delivery message and verify the QR code.

Start with the recipient status from the earlier matrix. Not every Ukrainian-speaking recipient receives a document outside KSeF, and not every foreign company follows the same delivery process. Establish the channel, addressee and role of the attachment before sending the message.

If an online invoice has been accepted by KSeF and the visualisation is used outside the system, check CODE I. The code opens document verification, and the KSeF number appears below it. Do not copy a code from another invoice or add it manually without linking it to the correct data.

First delivery of the document: До цього листа додаємо візуалізацію рахунка-фактури № [номер] українською мовою у форматі PDF. Рахунок-фактуру виставлено через польську систему KSeF. Цю мовну версію підготовлено для зручного ознайомлення з документом; вона не є окремим рахунком-фактурою. Під час оплати просимо керуватися сумою, терміном оплати та платіжними реквізитами, зазначеними в документі.

Request for confirmation or forwarding to accounting: Підтвердіть, будь ласка, отримання рахунка-фактури № [номер]. Якщо документ опрацьовує інший працівник або бухгалтерія, перешліть їм, будь ласка, це повідомлення.

Explanation of the relationship between the PDF and KSeF: Доданий до листа PDF-файл є візуалізацією даних того самого рахунка-фактури з назвами полів українською мовою. Рахунок-фактуру виставлено через KSeF. Цей файл не є новим рахунком-фактурою і не змінює вихідних даних документа.

Adapt the greeting, invoice number and contact details to the recipient relationship. For important business correspondence, have a person proficient in the recipient's language review the Ukrainian wording. Once the attachment's role is clear, use the right term for the document itself.

In Ukrainian business communication, you will encounter рахунок and, for a readable invoice visualisation, рахунок-фактура. The latter is understood as the name of a commercial document, although the current Ukrainian KSeFGPT PDF uses Основний рахунок as its title.

This article does not use податкова накладна as a translation of a Polish KSeF invoice. It does not assess the document's status under Ukrainian law, so the templates use рахунок-фактура and describe the role of the PDF explicitly.

A clear term for the attachment is візуалізація рахунка-фактури українською мовою, meaning a Ukrainian-language invoice visualisation. It describes the language and role of the file without suggesting that a document compliant with another tax system has been created.

Match the terminology to the recipient's practice and arrange a language review, especially for contracts or correspondence about legal effects. Once the document name is clear, the remaining process errors are easier to spot.

Using language instead of recipient status: the fact that someone works in Ukrainian does not decide the country, NIP, delivery channel or VAT treatment.

Creating a second invoice manually: copying data into a separate file increases the risk of a different number, amount, currency or due date. Generate the language version from the same invoice data instead.

Missing or incorrect QR code: a document used outside KSeF must be assessed against the markings required for its status. The code is not decorative and must verify the correct invoice.

Assuming a complete translation: Ukrainian labels do not guarantee translation of line-item names, notes, purchase order numbers or payment descriptions.

Confusing identifiers: the issuer assigns its invoice number, while the KSeF number is created after acceptance. A recipient may need both, but they serve different purposes.

Using the wrong document name: податкова накладна may imply a status that should not be inferred from the Ukrainian language version alone.

Sending the PDF without context: the recipient may not know whether it is a new invoice, a translation, a copy or a view of a KSeF document. A short explanation reduces communication friction and makes the data easier to review.

Once these errors are removed, the language version becomes a practical aid instead of creating a second, inconsistent document flow.

The order of languages in the menu is less important than data consistency and the correct invoice delivery channel. If either is wrong, even a perfectly translated visualisation will not repair the process.

A useful Ukrainian version helps the recipient find the transaction parties, document number, amount and currency, payment deadline and bank account without extra explanation. It achieves this without assigning a new number or changing the source data.

In practice, the issuer should retain a record of the XML, status, KSeF number and UPO while also providing a document that the recipient can read. When the visualisation is used outside KSeF, its QR code and markings also need to be checked.

Tax, consumer, customs and language issues may require separate assessment. This article organises the communication and document-checking process, but does not replace analysis of a specific transaction.

KSeFGPT lets you prepare an invoice in a form or through AI Chat, review the data and submit the document to KSeF when it is ready. The same module supports incoming and outgoing invoices and lets you download readable visualisations.

Visualisations are available in Polish, English, German and Ukrainian. This avoids building a second PDF manually and copying amounts into it. You still need to review free-text content, recipient status, delivery method and QR code.

This feature applies to the invoice visualisation. It does not mean that every part of the application interface, every AI function or every value in the document is automatically translated into Ukrainian.

To keep the complete process in one place, prepare the invoice, submit it to KSeF and download a version that the recipient can read.

If you handle several languages, start with KSeF invoices in English, German and Ukrainian.

The roles of the source, visualisation and confirmations are explained in Translated KSeF invoice, PDF, XML and UPO.

For an international finance-team workflow, read KSeF invoice in English for a foreign counterparty.

For a German-speaking recipient, continue with KSeF invoice in German for a German counterparty.