How to issue an invoice to a US company in KSeF

An invoice for a US company in KSeF starts with the Polish issuer, not only with the buyer's country. If the seller is covered by the KSeF obligation, they need to check whether the document should be created as a structured invoice even when the counterparty does not have a Polish NIP.

The main practical risk is mixing three layers: the tax data of the transaction, the technical FA(3) XML and the readable version for the US counterparty. KSeF needs the correct structure, accounting needs the correct VAT treatment, and the counterparty usually needs an understandable PDF in English.

KSeFGPT can help with the operational process: collect counterparty data, issue the invoice, check XML, send the document to KSeF, save the status, KSeF number and UPO, and prepare a readable language version. It does not replace the tax decision on VAT rate, place of supply or supporting documents for the transaction.

Start by organizing responsibilities. KSeF answers how to issue and identify a structured invoice. Accounting answers how to settle a sale to a US company. The counterparty answers how they want to receive a readable version of the document outside the Polish system.

Collect these details before issuing: full legal name of the US company, address, country, tax identifier if it appears on the invoice, invoice email, currency, description of the supply, VAT decision, payment terms and the method of sharing the invoice after it is accepted in KSeF.

Do not assume that the US automatically excludes KSeF, that every document to the US has the same VAT rate, that an English PDF replaces XML, or that a foreign recipient will download the invoice themselves like a Polish taxpayer with a NIP.

1. How to issue an invoice to a US company in KSeF

2. US counterparty data without a Polish NIP

3. VAT, currency and transaction description for the US

4. Does a US company receive the invoice through KSeF?

5. How KSeFGPT helps with an invoice for a US company

6. Common mistakes and expert perspective

The table below gathers the decisions that need to be made before sending an invoice to KSeF and before sharing a readable version with the counterparty in the US.

The safest way to treat this topic is as a five-step process: first confirm the KSeF obligation on the Polish issuer side, then determine the US buyer data, then decide with accounting on VAT and currency, prepare a correct structured invoice, and finally share a readable version of the document with the counterparty.

Do not start with the question of whether the US customer has a KSeF account. For a Polish seller, it is more important to know whether the invoice has to be issued as a structured invoice and how to describe a buyer that does not have a Polish NIP. Only later do you decide on communication with the counterparty and sending a PDF or visualization.

Check in this order: the Polish issuer's KSeF status, buyer data, VAT decision, currency, XML correctness, sharing method outside KSeF and the complete submission trace, meaning KSeF number, status and UPO.

If you need broader context on the submission itself, read Sending invoices to KSeF. For the language version for the recipient, see KSeF invoice in English, German and Ukrainian.

In an invoice for a US company, do not try to force the buyer into a Polish NIP format. Start with the data that actually identifies the counterparty: full legal name, address, country, invoice email, contact person and tax identifier if the counterparty provides one and it should appear on the invoice.

The FA(3) schema supports different buyer identification variants. For a Polish buyer, the natural choice is NIP. For an EU counterparty, an EU VAT identifier may appear. For a non-EU entity such as a US company, another tax identifier with a country code may matter, or the no-identifier variant if no identifier appears on the invoice.

Data checklist: legal name, address, country US, tax identifier if it should appear on the invoice, invoice email address, contact person, purchase order or contract number, and visualization language for the recipient.

This does not mean that you should enter any number received in an email from the counterparty. Identification data should come from the contract, order, accounting data or confirmation from the counterparty. If the sales team only has a trade name, it is worth collecting full billing data before issuing the invoice.

The most sensitive part of an invoice to the US is not technical, but tax-related. A service supplied to a company, a supply of goods, a license, subscription, consulting, export of goods or a service performed partly in Poland can each be assessed differently. That is why this article should not give one universal VAT rate for all invoices to the US.

Before issuing the document, agree with accounting what exactly you are selling, who the buyer is, where the place of supply or delivery is, what invoice currency applies, which exchange rate to use, whether a tax note is needed on the invoice and which documents support the transaction. Only after that decision does it make sense to move to the invoice form and XML.

Confirm with accounting: type of supply, place of taxation, currency, exchange rate, VAT rate or designation, line-item description, documents supporting the sale and the wording of any note for the counterparty.

In KSeF, the technical layer depends on FA(3) data consistency: dates, currency, items, amounts, rates, totals and party data must match. If the tax decision is uncertain, technical validation will not fix incorrect VAT treatment. It can say that the structure is correct, but not that the transaction has been assessed correctly for tax purposes.

A domestic buyer with a Polish NIP can receive invoices in KSeF in the standard flow. With a US counterparty, the practical situation is different: the buyer may not use KSeF, may not have a Polish identifier and may expect normal email communication or a procurement portal. That is why, apart from issuing the invoice itself, you need to plan how to share a readable version of the document.

In practice, for buyers without a registered office or fixed establishment in Poland, the invoice is shared outside KSeF in a way agreed with the buyer. This may be an email with a PDF, the counterparty's portal or another agreed channel, but the form should allow the recipient to read the document and verify it according to KSeF rules.

Do not confuse sharing outside KSeF with claiming that the PDF is the source invoice. The source layer for KSeF is FA(3) XML, and after acceptance also the KSeF number and UPO. An English PDF is a practical human-readable visualization that helps the counterparty book the document, approve payment and pass it internally.

For an invoice shared outside KSeF, remember the verification QR code and the access or identification data required to verify the document. For an invoice issued online after acceptance by KSeF, the KSeF number is crucial. Offline modes may introduce additional markings, so do not treat any PDF without the proper elements as a complete sharing process.

Agree with the counterparty: sending channel, visualization language, email address or portal, information about the KSeF number, document verification method and the person on the customer side responsible for payment.

In an email to a US company, describe the attachment neutrally: as an informational visualization of an invoice issued in the Polish KSeF system. Avoid wording that suggests a second invoice has been created or that the English PDF replaces the source data. The difference between PDF, XML, KSeF number and UPO is explained more broadly in Translated KSeF invoice, PDF, XML and UPO.

KSeFGPT should not be described as a tax adviser or a government system. Its role is operational: it helps prepare and control invoice data, work with counterparties, validate XML, send the document to KSeF and organize statuses after submission.

With a US company, three elements are especially useful. First, the counterparty database helps avoid retyping the name, address and contact data every time. Second, the Invoices module supports outgoing FA(3) invoices, validation and submission. Third, PDF language versions help share a readable document with a person who does not work in Polish.

Operational example: a Polish SaaS company issues a monthly invoice to a Delaware company. In KSeFGPT, it saves the counterparty data, confirms VAT treatment with accounting, checks XML, sends the invoice to KSeF and, after acceptance, downloads an English visualization for the customer's finance team.

The supported visualization language versions in KSeFGPT are Polish, English, Ukrainian and German. For a US counterparty, you will usually choose English, but the same process also helps when the document must go to a team working in German or Ukrainian.

A good KSeFGPT process looks like this: prepare the counterparty, issue the invoice, check the data and XML, send the document to KSeF, save the status, KSeF number and UPO, and then share a readable visualization with the counterparty. If the VAT treatment is uncertain, stop the process before submission and confirm it with accounting.

The first mistake is assuming that because the buyer is from the US, KSeF disappears from the process. This simplification can be risky, because the obligation to issue a structured invoice is assessed mainly from the perspective of the Polish issuer and the scope of the regulations, not only by the buyer's country.

The second mistake is treating XML validation as confirmation of the correct VAT rate. A technically correct file may still contain incorrect transaction classification. That is why the VAT decision, currency, description and supporting documents should be prepared before clicking send.

The third mistake is sending the counterparty a Polish visualization without explaining what KSeF is and what the KSeF number means. A US company may need a simple email in English, a readable PDF and clear information that the source invoice was issued in the Polish e-invoicing system.

KSeF changes the form and technical trace of an invoice, but it does not remove the classic tax questions involved in international sales. You still need to know what is being sold, where the place of supply is, who the buyer is and which documents support the transaction.

In practice, the best process is not a salesperson entering a few data points into a system and expecting the validator to decide everything automatically. The validator should check the structure and data consistency. The tax decision should be prepared earlier and, in non-standard cases, confirmed by accounting or an adviser.

A good KSeF application helps reduce operational errors: it does not lose the KSeF number, shows the status, allows UPO download, stores counterparty data and supports communication. It should not promise that choosing a form will replace analysis of a US transaction.

If you are issuing your first invoice to a US company, start with a correct KSeF process and clear communication with the counterparty, and only then optimize automation.

For the recipient language version, read KSeF invoice in English, German and Ukrainian. If you want to distinguish PDF, XML and UPO, return to Translated KSeF invoice, PDF, XML and UPO.

For submission and statuses, the guide Sending invoices to KSeF will be useful. If you want to control identifiers after submission, also read KSeF number on invoice.