German-language invoice for a counterparty from Germany in KSeF

A Polish seller can handle an invoice for a company from Germany in KSeF if the invoice is issued under Polish invoicing rules. This is different from receiving a purchase invoice from a German supplier, which is not automatically an invoice issued by a Polish taxpayer in KSeF.

In KSeFGPT, the user prepares the invoice in the Invoices module, selects or adds a counterparty with country DE, enters the VAT EU identifier if required, address, currency, line items and rates, then checks the preview before sending the XML to KSeF.

KSeFGPT can generate a German-language informational visualization of the invoice as a PDF. That PDF helps the German finance team read the document, but it is not a second invoice and does not change the FA(3) XML data.

If a Polish seller issues an invoice under Polish invoicing rules, a foreign buyer does not automatically remove the document from the KSeF process. In practice, the invoice may be a structured invoice and its primary technical form is FA(3) XML. The difference between invoice data and a readable view is explained in XML and FA(3) format in KSeF.

KSeF is not a universal mailbox for every foreign invoice. If a Polish company receives a document from a German supplier, that purchase document and its tax treatment should be assessed separately by accounting.

This article explains the operational flow in KSeFGPT. It does not decide whether a given transaction is an intra-Community supply, export of services, reverse charge, 0% VAT or another tax case. Confirm that assessment with accounting based on the transaction type and supporting documents.

The process is easier when the German counterparty is saved with the correct country and tax identifier. KSeFGPT supports working with a counterparty database, so the user can select an existing entity or add a new German buyer. For data cleanup, see Building a contractor database from KSeF invoices.

For Germany, the key country code is DE. Names such as Germany, Niemcy or Deutschland may appear in business communication, but invoice data and integrations need a clear country code. For an EU counterparty, the VAT EU identifier may also be relevant.

Do not assume that country DE automatically means 0% intra-Community supply. The VAT rate and required invoice notes depend on the transaction, buyer status, evidence and accounting assessment.

The safer process is to prepare the invoice first, review the preview and XML, and only then consciously send the document to KSeF. Opening a preview or filling out fields should not be treated as submission to the system.

In practice, open the application, go to the Invoices module, start issuing an invoice, choose the active seller company, select or add the German buyer, enter line items, currency, rates and payment term, then review the document before sending it to KSeF.

This distinction matters because invoice data and tax qualification are separate topics. KSeFGPT can help prepare, preview and submit the document, but the user remains responsible for the correctness of data and tax classification.

After confirmation, KSeFGPT works with the prepared invoice XML and passes it into the submission process. For the user, the important part is the result: the document goes through KSeF submission and later status handling.

For the German counterparty, technical details are usually not the point. They need a readable file, invoice number, amount and payment term. For the seller, the formal invoice history remains in KSeF. The broader process is described in Sending invoices to KSeF.

If the German counterparty will not retrieve the invoice directly from KSeF, the seller should provide a readable document through an agreed channel, most often by email with a PDF attachment.

KSeFGPT solves the practical communication problem here. Instead of sending a Polish visualization to a German finance team, the user can generate a German-language visualization. The document language can be selected in the invoice download flow.

The wording is important: the German PDF is an informational visualization of an invoice issued in KSeF. It should not be described as a second invoice, a new invoice number or an independent accounting document.

For the broader language-version concept, read KSeF invoice in English, German and Ukrainian.

The email should explain the role of the attachment without creating extra tax claims. The key point is that the file is a German-language visualization of an invoice issued in KSeF.

Subject: Rechnung aus KSeF - Informationskopie

Message: Im Anhang senden wir Ihnen eine informative Visualisierung der in KSeF ausgestellten Rechnung. Die Sprachversion dient der besseren Lesbarkeit. Die Quelldaten der Rechnung bleiben in KSeF. Bitte verwenden Sie die Rechnungsnummer und die Zahlungsfrist aus dem beigefügten Dokument.

This wording does not suggest that a second invoice has been issued. It says that the attachment is a readable version, while the source invoice data remains in KSeF.

The first mistake is leaving country PL next to a German address or entering the wrong identifier for the buyer. That can make counterparty data unclear and create follow-up questions from accounting.

The second mistake is treating the German PDF as a separate invoice. If the user downloads a visualization from KSeFGPT, it should circulate as an informational version, without a new number and without manually creating another document.

The third mistake is assuming that every invoice to Germany automatically means 0% intra-Community supply. That may be correct only under specific conditions and should be confirmed separately.

The fourth mistake is sending a Polish PDF to a German-speaking finance team even though a German-language visualization can be generated in KSeFGPT.

For invoices issued to German counterparties, the main risk is not the language of the PDF. The risk appears when invoice data, tax qualification and counterparty communication are mixed into one decision.

A practical process separates those layers: verify counterparty data and line items before submission, confirm VAT treatment with accounting, and treat the German PDF as a communication aid. The counterparty receives a readable document, while the formal invoice history remains aligned with KSeF.

That is why this article uses the phrase informational visualization. It is less flashy than saying invoice in any language, but it describes the KSeF reality more accurately: the display language changes, not the source invoice.

First, read KSeF invoice in English, German and Ukrainian to understand why a translated PDF is a communication layer, not a change to invoice data.

If you work with German companies regularly, organize your counterparty records using Building a contractor database from KSeF invoices.

When the buyer data is ready, continue with Sending invoices to KSeF. For the technical document layer, return to XML and FA(3) format in KSeF.