How to invoice a foreign B2B client in KSeF?

A Warsaw software house bills a Berlin agency. A Polish wholesaler ships goods to Czechia. A Katowice manufacturer sells a machine to a buyer in Ukraine. Three transactions, three VAT treatments, three different sets of fields in the FA(3) schema. And one question that keeps coming up in every conversation with a Polish accountant: does this really have to go through KSeF if the customer has never heard of it?

It does. The obligation to issue structured invoices sits with the seller, not the buyer. If you invoice under Polish rules and have a seat or fixed establishment in Poland, the invoice goes into the system regardless of where the other party sits.

Here is what that means in practice, which fields get filled in wrong most often, and how to hand the document to a customer who will never log in.

When a foreign invoice must go through KSeF

The obligation covers, as the Polish Ministry of Finance puts it, all taxpayers required to issue invoices under Polish law, subject to the statutory exemptions (KSeF 2.0 Handbook, Part II). In practice, you issue in KSeF:

• invoices for WDT (intra-Community supply of goods to a VAT-registered business in another member state),

• invoices documenting export of goods outside the EU,

• invoices for B2B services where the place of supply is the customer's country (Article 28b of the VAT Act).

Outside the KSeF obligation you will find, among others, invoices issued by a taxpayer with no seat and no fixed establishment in Poland, invoices under special schemes (OSS, IOSS), and B2C sales, including to foreign consumers.

A separate point worth stating plainly: purchase invoices from foreign suppliers do not enter KSeF. Your Google Ads receipt, your Amazon invoice, your German subcontractor's bill are all booked the way they were before, as intra-Community acquisition or import of services. KSeF governs the Polish issuing side only.

Issuing is only half the job

Your foreign customer has no Polish NIP (tax identification number), cannot authenticate in KSeF and cannot retrieve the document from it. Article 106gb(4) of the VAT Act exists for exactly this. Per the KSeF 2.0 Handbook, the provision covers, among others:

• cases where the place of supply is another EU member state or a third country,

• entities with no seat and no fixed establishment in Poland,

• entities with a fixed establishment in Poland that does not take part in the transaction,

• entities without a NIP, and consumers.

In these cases you make the invoice available to the buyer in a form agreed with them: PDF by email, a printout, EDI, a customer portal. The format is up to you, but the agreement itself is worth having in writing, in a framework contract or standard terms.

Two things that are easy to miss:

The QR code. An invoice used outside KSeF must carry a QR code marked with the KSeF number. Invoices issued in offline mode and not yet submitted require two codes, labelled "OFFLINE" and "CERTYFIKAT".

Consistency with the XML. The Ministry explicitly discourages sending a stripped-down XML to KSeF and putting the remaining details only on the visualisation. Your PDF may add a logo or a support contact, but its substance must match the file in the system.

Good news for exporters: the invoice you hand over outside KSeF may be in a foreign language. You can submit Polish-language XML and send your customer an English or bilingual PDF, as long as the content corresponds.

Identifying the buyer: three fields, three situations

This is where most rejections and corrections originate. FA(3) has a separate field for each type of identifier, and they must not be mixed.

Buyer Fields in Podmiot2/DaneIdentyfikacyjne Example EU taxable person (intra-EU supply, Article 28b services) KodUE + NrVatUE DE + 999999999 Third-country entity with a tax ID KodKraju + NrID CH + 999999999 Third-country entity without a tax ID BrakID = 1 – Polish taxpayer NIP 9999999999

The most common mistakes, named directly by the Ministry:

• putting a prefixed EU VAT number into NrID instead of splitting it into KodUE and NrVatUE,

• merging country code and number in one field (CH9999999999 instead of CH + 9999999999),

• putting a Polish NIP into NrID. KSeF routes the invoice to the buyer based on the NIP field, so this error means your Polish counterparty never receives it.

On the seller side, for intra-EU supplies and Article 28b services the PL prefix goes into a dedicated field, Podmiot1/PrefiksPodatnika, while NIP holds digits only, with no separators and no prefix.

VAT codes: 0 WDT, 0 EX, np I, np II, oo

P_12 is a text field. Entering a numeric value instead of a code will get the file rejected. FA(3) split the old "0" and "np" markers into separate codes:

Transaction P_12 Summary field Annotation Intra-EU supply of goods 0 WDT P_13_6_2 none Export of goods 0 EX P_13_6_3 none B2B services to an EU taxable person (Art. 28b, EU sales listing) np II P_13_9 reverse charge (P_18 = 1) Supply outside Poland not covered by Art. 100(1)(4) np I P_13_8 depends on the transaction Transactions where the buyer accounts for the tax in Poland oo – reverse charge

The np I / np II split comes straight from the schema: np II is reserved for services referred to in Article 100(1)(4) of the VAT Act, meaning those reported in the VAT-UE recapitulative statement (FA(3) schema). Using np I for a service supplied to a German company puts your invoice, your EU sales listing and your JPK_V7 return out of sync.

Intra-EU supplies and exports of goods carry no "reverse charge" annotation. It applies where the buyer is the person liable to account for the tax (Article 106e(1)(18) of the VAT Act).

Foreign currency invoices: the rate and the PLN VAT figure

On a foreign currency invoice, amounts stay in that currency. Only the VAT amount is converted into Polish złoty, in fields P_14_1W, P_14_2W and so on, per Article 106e(11) of the VAT Act. The ISO 4217 currency code goes into KodWaluty, and the rate can be stated per line in FaWiersz/KursWaluty.

The rate is the average NBP (National Bank of Poland) rate from the last business day preceding the date the tax obligation arises (Article 31a of the VAT Act). Not the issue date, and not the KSeF submission date. If the invoice was issued before the tax point arose, the anchor is the day before issuance.

A practical consequence: for intra-EU supplies the tax obligation arises when the invoice is issued, at the latest on the 15th day of the month following delivery. Supply date and issue date are rarely the same day here, and that gap determines which rate is correct.

In Biurko the rate is pulled automatically from NBP table A, with the date derived under Article 31a and rolled back to the last business day when it lands on a weekend or holiday. The PLN VAT figure recalculates together with the invoice lines.

Five mistakes that end in a correction

1. EU VAT number in the wrong field. The file will pass validation, but the data lands in the wrong place.

2. np I instead of np II on services to an EU business, or the reverse.

3. Never delivering the invoice. Submitting to KSeF is not delivery to a foreign buyer.

4. Wrong buyer NIP. KSeF has no cancellation and no buyer-issued correction note. You must issue a correction to zero against the wrong number, then a fresh original invoice with the right data.

5. Rate from the issue date instead of the day before the tax point.

Pre-submission checklist

• Verify the buyer's EU VAT number in VIES and keep the confirmation.

• Put the identifier in the right fields: KodUE + NrVatUE, KodKraju + NrID, or BrakID.

• For intra-EU supplies and Article 28b services, split the PL prefix into PrefiksPodatnika.

• Pick the right P_12 code: 0 WDT, 0 EX, np I or np II.

• Set the reverse charge annotation where the buyer accounts for the tax.

• Check the NBP rate against the tax point date, not the issue date.

• Agree the delivery method with your customer and send the visualisation once issued.

• Collect your zero-rate evidence: CMR, transport documents, IE-599 message for exports.

Summary

Cross-border sales did not disappear from KSeF. They simply have their own set of fields and their own second delivery loop outside the system. Most of the trouble comes not from the rules themselves but from mapping customer data onto the FA(3) schema by hand.

Biurko recognises the buyer type (Polish NIP, EU VAT, foreign entity, no identifier) and maps it to the correct FA(3) fields, then translates a 0% or "np" rate into 0 WDT, 0 EX or np II based on the transaction markers, without anyone typing schema codes. NBP rates and the PLN VAT figure are calculated automatically.

Create a free account and issue your first cross-border invoice in the KSeF test environment before you do it in production.

FAQ

Does an invoice for a German customer have to go through KSeF?

Yes. If you issue it under Polish rules and have a seat or fixed establishment in Poland, it goes into KSeF. That covers intra-EU supplies, exports of goods and B2B services taxed in the customer's country.

Will my foreign customer see the invoice in KSeF?

No. Without a Polish NIP they have no access to the system. Once issued, you must deliver the invoice in a form agreed with them, usually a PDF by email carrying a QR code that lets them verify the document in KSeF.

Services to an EU business: np II or oo?

For Article 28b services reported in the VAT-UE recapitulative statement, the correct code is np II together with the reverse charge annotation. oo applies where the buyer accounts for Polish VAT on the transaction.

Can a KSeF invoice be in English?

The XML file may contain foreign-language data, and the invoice delivered outside KSeF may be in a foreign language or bilingual. The condition is that its substance matches the file submitted to the system.

Do invoices from foreign suppliers appear in KSeF?

No. Entities with no seat and no fixed establishment in Poland are not required to use KSeF. You account for their invoices as before, as intra-Community acquisition or import of services.