Can an invoice in KSeF be in English?

Yes. In ordinary transactions between private businesses, a KSeF invoice can contain English product names, service descriptions and other free-text information. This concerns data recorded in the invoice itself, not only the language of a later PDF. Requirements for invoice content, applicable annotations and the FA(3) format still apply.

Do not translate XML element names, codes or flags required by the schema. Writing a service description in English is different from changing the document's technical structure. Separate Polish-language obligations may apply, including to consumer transactions and entities covered by the Polish Language Act.

The Ministry of Finance allows English or bilingual invoice visualizations provided that, after translation, their substance matches the XML submitted to KSeF. Downloading another PDF does not change an accepted invoice or create a second invoice.

KSeFGPT lets you download an English visualization of an incoming or outgoing invoice. Read the line-item descriptions and notes too: choosing English labels does not guarantee translation of every description. During a tax inspection, documentation within its scope may need a Polish translation at the inspecting officer's request.

KSeF organizes the technical and formal invoice layer, but it does not remove the language barrier. An Accounts Payable specialist may not understand Polish labels and still needs to find the invoice number, amount due, currency, due date and bank account quickly.

An English visualization is useful even when the counterparty is not based in an English-speaking country. English is the shared language of cost approval, purchase orders and payments for many international teams. The broader language workflow is covered in KSeF invoices in English, German and Ukrainian.

Choose the language of the service description when preparing the invoice data. You can choose the visualization language later, when downloading the PDF. Keeping these decisions separate helps avoid an invalid XML file or a document the recipient cannot understand. The legal and FA(3) references below were checked on September 19, 2026; language alone does not determine VAT treatment, place of supply or currency.

1. What an English KSeF invoice means

2. Can product and service descriptions in the XML be in English?

3. Which Polish wording and separate language rules matter?

4. When is a Polish translation required during a tax inspection?

5. How to download an English invoice PDF in KSeFGPT

6. How to check the English version before sending

7. What to write to the foreign counterparty

8. Common mistakes with English invoice visualizations

9. Keeping invoice data and communication consistent

10. Frequently asked questions

Before sending the document, decide on the descriptions, check applicable annotations and compare the visualization with the invoice data.

An English KSeF invoice may mean English descriptions in the source invoice or an English presentation of a document that has already been issued. Both can be used together. The language of the schema does not determine the language of every value entered into it.

FA(3) fixes the names and arrangement of XML elements and the permitted values in code-based fields. Replacing them with your own translations can make the file incompatible with the schema. Entering an English service description in its designated text field does not change that structure.

The PDF is a separate layer. In its KSeF FAQ, the Ministry of Finance requires an English or bilingual visualization to match the substance of the submitted XML after translation. This does not permit changes to amounts, parties, dates or the meaning of a description when creating a language version.

Once the invoice has been accepted, selecting a PDF language does not change its own invoice number, KSeF number or source data. See the separate explanation of translated KSeF invoices, PDF, XML and UPO for the roles of those documents and confirmations.

Yes. For an ordinary transaction between private businesses, you can enter an English product name or service description in the appropriate invoice field. Article 106e(1)(7) of the Polish VAT Act requires the name or type of the goods or service but does not itself impose a general Polish-language requirement. The specific obligations in the next section still need a separate check.

In the official FA(3) schema, the product or service name is a text field with a length of 1 to 512 characters. Its definition contains no restriction to Polish. This applies to that particular field: other text fields may have different limits, while fields with prescribed codes do not accept arbitrary descriptions.

Consider website maintenance for September 2026. If that is the service actually supplied, the English description should preserve its scope and period. Service alone may be too vague for the recipient or accounting team to identify the supply.

A bilingual description is an option if it fits the field and both versions convey the same meaning. It is a practical choice for ordinary B2B transactions, not an extra requirement imposed by FA(3). Preserve party names, order references and identifiers in line with the transaction records.

Successful XML validation confirms technical compliance within the checks performed by the validator. It does not establish that a description matches the service actually performed or that the VAT treatment is correct. Review the content before submission: downloading an English PDF later will not correct data in an invoice already accepted by KSeF.

The freedom to choose a description's language does not remove required tax annotations. Article 106e(1)(16), (17), (18) and (18a) of the VAT Act specifies wording for particular cases. FA(3) represents these cases through the appropriate flags, which must reflect the transaction. An English note in an arbitrary field cannot replace a required flag.

The visualization must retain the meaning of the applicable annotation. A cautious approach is to keep its statutory Polish wording alongside an English explanation. This is an editorial recommendation to reduce misunderstandings, not a claim that MF prohibits a wholly English visualization. Do not add every annotation below to every invoice: each has its own conditions.

The Polish Language Act applies separately. Article 7(1) covers consumer transactions where the consumer lives in Poland when the contract is concluded and the contract is to be performed in Poland. Article 7a expressly includes invoices within that scope. Article 7(2) also covers non-consumer transactions conducted by entities listed in Article 4, including specified bodies and institutions performing public tasks.

Do not automatically apply the answer for private B2B transactions to a consumer invoice or transactions covered by those rules. Article 8 provides for parallel language versions and a specific exception for certain documents requested by a non-Polish citizen who understands the language and has first been informed of the right to a Polish version. Being a foreign recipient alone is not enough to disregard those conditions.

Article 287 § 1 point 2 of the Polish Tax Ordinance requires a Polish translation of foreign-language documentation concerning matters covered by a tax inspection when requested by the inspecting officer. Under § 2, the inspected person bears the cost. The trigger is the inspection's scope and the officer's request, not merely the existence of an English invoice.

This provision does not establish an advance obligation to translate every invoice or an automatic requirement for a sworn translation. It concerns a tax inspection and should not be treated as a single rule for every interaction with a tax authority. In a particular case, check the legal basis, specified documents, deadline and translation requirements in the request.

When translating documentation, retain its connection to the source invoice number and data. Preparing a Polish translation for an inspection is not a reason to issue the invoice again in KSeF. A substantive error in the source invoice must be considered separately from its translation.

In KSeFGPT, the language is selected when downloading the readable invoice version. There is no need to copy the data into a separate template or create a new document in a text editor.

MF confirms that an English or bilingual visualization is possible if its substance matches the XML after translation. For the online invoice described here, which already has a KSeF number and is being used outside the system, also check the QR verification code with the KSeF number. Determine the sharing method from the recipient's circumstances, not the file's language.

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

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

Step 3: select English. Polish, German and Ukrainian versions are available as well.

Step 4: download and open the file before sharing it. Generating the PDF does not replace a human review.

Step 5: compare it with the source data and then use the agreed delivery channel. The distinction between source data and a readable view is explained further in Translated KSeF invoice, PDF, XML and UPO.

After downloading, the key task is to check the fields the same way an Accounts Payable team will read them.

The review should follow the recipient's workflow. A foreign finance team will not begin with XML analysis. It will first look for the invoice number, party data, purchase-order reference, totals and due date.

Invoice number: compare the issuer's invoice number with the source document. Do not replace it with the KSeF number because the identifiers serve different purposes.

Issue date and supply date: verify the invoice date and the sale, service or delivery date when shown on the invoice.

Seller, buyer and VAT ID: check legal names, addresses, country and tax identifiers. An English label does not correct inaccurate counterparty data.

Purchase order or reference: if the counterparty requires a PO, project or contract number, make sure it is present and easy to identify.

Line items: check descriptions, quantities, units, prices and discounts. This is the most important manual check because free-text descriptions may remain in their source language.

Net, VAT and gross: compare the taxable amount, tax and gross amount for each rate and the entire invoice. Confirm the currency as well.

Due date and payment details: the recipient must be able to find the due date, bank account or IBAN and any agreed transfer instructions. An error here can delay payment even when the invoice itself is valid.

Before sending an outgoing invoice, retain the XML, status, KSeF number and UPO; compare totals and currency; read the line-item descriptions; verify payment details; confirm the delivery channel and any markings required in the specific case. For an incoming invoice, do not assume access to the issuer's UPO.

Also check that the PDF correctly shows the tax annotations applicable to the invoice. Translating a description or label must not remove their meaning or replace a required flag in the source data.

Once the fields are checked, prepare a message that clearly defines the attachment.

A good message sends the file, states the invoice number and explains the attachment. It does not need a lengthy KSeF explanation or additional tax claims.

First message to Accounts Payable: Please find attached the English visualization of invoice [invoice number], issued in the Polish KSeF system. The language version is provided for readability and is not a separate invoice. Please use the due date and payment details shown in the document.

Request for confirmation or forwarding: Please confirm receipt of invoice [invoice number]. If another person or Accounts Payable team is responsible for processing it, please forward this message or share the correct billing contact with us.

Clarification of the document's role: The attached English PDF is an informational visualization of the invoice issued in KSeF. It does not create a second invoice or change the source invoice data. The invoice reference, amounts and payment terms remain the same.

Accounts Payable is the team that processes supplier invoices and liabilities. Invoice reference identifies the invoice or order, due date is the payment deadline and payment details include the account and transfer information.

For a United States buyer, check the buyer data and transaction context separately in How to issue an invoice to a US company in KSeF.

Once the email is clear, remove the errors that most often create a second, inconsistent document flow.

A second document number: an English visualization should not receive a new number merely because the label language changed. It remains a readable version of the same invoice.

Manual retyping: recreating an English invoice in a text editor increases the risk of differences in price, tax, currency or payment deadline. Generate the visualization from the same data instead.

Assuming complete translation: service names, project numbers, notes and other free-text content may require a separate check or deliberate wording that the recipient understands.

Confusing identifiers: invoice number is the issuer's document number, while the KSeF number is assigned after the system accepts the document. They are not interchangeable.

No email context: an unexplained attachment may look like another invoice, a duplicate or a replacement. One sentence about the English visualization of a KSeF invoice prevents this confusion.

Deriving tax from language: an English PDF does not confirm VAT, reverse charge, intra-Community supply or place of supply. Language and tax correctness are separate checks.

Translating the XML itself: do not replace element names or codes with English equivalents. To change only how an accepted invoice is read, prepare a matching visualization; do not resubmit it with a new invoice number solely because of the language.

Secure data consistency first, then optimize the language and delivery channel. The English version will support payment instead of creating uncertainty.

The main value of an English visualization is not the creation of another document. It removes friction between a correctly handled KSeF invoice and the day-to-day work of the person who must approve and pay it.

The counterparty's finance team should be able to identify five elements immediately: invoice number, transaction parties, amount and currency, due date and payment details. When these match the source, the readable PDF can materially speed up processing.

The language version must not obscure substantive checks. An incorrect buyer identifier, VAT treatment or bank account remains incorrect under a proper English label. Data, tax and delivery-method reviews must therefore remain separate.

A reliable process combines both layers: for an outgoing invoice, the company retains the XML, status, KSeF number and UPO, while the counterparty receives a document it can read and route for payment.

KSeFGPT lets users prepare an invoice in a form or AI Chat, review the data, submit the document to KSeF and download a readable visualization in the recipient's language. The user works with the same invoice instead of manually creating a second file with separate amounts.

Visualizations are available in Polish, English, German and Ukrainian. Selecting a language supports communication but does not replace free-text review or the tax decision for the transaction.

For the full multilingual workflow, start with KSeF invoices in English, German and Ukrainian.

To distinguish documents and confirmations, read Translated KSeF invoice, PDF, XML and UPO.

For an English-speaking buyer outside the EU, see How to issue an invoice to a US company in KSeF.

When the recipient works in German, continue with KSeF invoice in German for a German counterparty.