From 1 April 2026 mandatory structured invoicing covers all remaining Polish VAT payers. For companies trading across borders this produces a workflow that looks redundant at first glance: an invoice for a Berlin client is filed with a Polish government system, and then emailed to the client as a PDF anyway.
That duplication is deliberate. KSeF acts as the registry of record, not as a delivery channel to a party without a Polish tax identification number. The risk sits in the gaps between those two flows, where a mislabelled line can cost you a JPK_V7 (VAT ledger file) correction or the right to apply a zero rate.
Here is what a foreign-facing Polish entity needs to get right: scope, delivery, rate coding, counterparty identification and FX.
When a foreign invoice must go through KSeF
The test is the status of the issuer, not the customer. A Polish established taxpayer is in scope for cross-border sales too: intra-EU supplies of goods, exports, and services taxed where the customer belongs.
The Ministry of Finance publishes the scope of mandatory KSeF together with the exclusions. Four groups matter for cross-border trade:
invoices issued by taxpayers with no seat and no fixed establishment in Poland, or whose Polish fixed establishment does not participate in the transaction,
special schemes: non-Union OSS, IOSS, occasional international road passenger transport, and the SME exemption under art. 113a of the Polish VAT Act,
self-billing where either party is not identified by a Polish NIP (tax identification number) for the transaction,
sales to private individuals.
Two nuances are easy to miss. For the special schemes and the SME exemption, voluntary KSeF filing is not even possible. And for an intra-EU supply under self-billing, where the customer uses an EU VAT number issued outside Poland, the invoice may be filed in KSeF despite the exclusion.
Whether a Polish subsidiary or branch constitutes a fixed establishment for this purpose is precisely the question foreign-owned groups keep asking. The Ministry issued tax guidance dated 28 January 2026 on exactly this point, and it is worth reading before assuming your structure is out of scope.
Delivery outside KSeF and the mandatory QR code
Your Hamburg customer has no Polish NIP and therefore no way into the system. Art. 106gb sec. 4 of the VAT Act requires the seller to hand the invoice over in a form agreed with the buyer. The provision lists six situations, including a place of supply in another EU member state or a third country, a buyer without a seat or fixed establishment in Poland, and a buyer that does not use a NIP at all.
The form is up to you: PDF by email, paper, XML, EDI, a customer portal. What is not optional is the marking. Per the Ministry's page on QR verification codes:
Issuing mode Codes Label Online one (CODE I) KSeF number printed below the code Offline24, KSeF outage, emergency mode (before upload) two "OFFLINE" and "CERTYFIKAT" Offline after upload to KSeF one (CODE I) KSeF number
The verification code encodes the API resource address, the issue date from field P_1 of the FA(3) schema, the seller's NIP and the invoice identifier, a cryptographic digest of the XML file. The details sit in the regulation of the Minister of Finance and Economy of 12 December 2025 on the use of KSeF (Dz. U. 2025 item 1815). Practical consequence: a visualisation without the code does not satisfy the requirement, and the second code requires a type 2 KSeF certificate, which you need to obtain in advance rather than during an outage. See also: [SLUG-OFFLINE-MODE].
Rate coding in FA(3): where most errors originate
Your invoicing screen shows one line labelled "0%". The FA(3) structure sees three distinct things, and field P_12 carries a different token for each.
Transaction P_12 token Summary field Domestic zero rate 0 P_13_6_1 Intra-EU supply of goods (WDT) 0 WDT P_13_6_2 Export of goods 0 EX P_13_6_3 Services supplied outside Poland np I P_13_8 EU services under art. 100 sec. 1 pt 4 np II P_13_9 Reverse charge oo P_13_10, forces P_18
An example. A Polish software company invoices a Dutch client for development work. The service is taxed in the Netherlands and settled by the customer, so the amount belongs in P_13_9 as np II, because the transaction is also reported in the EC Sales List (informacja podsumowująca VAT-UE). If the software writes plain np I, the VAT return and the EC Sales List stop reconciling, and the mismatch surfaces at the tax office rather than in your accounting system.
Biurko keeps a single zero rate in the interface and derives the token from transaction markers set on the invoice: intra-EU supply, intra-EU service, export, triangular transaction, margin scheme. The FA(3) adapter maps each combination to the correct P_12 token and summary field, and any line rated oo automatically sets the reverse charge marker P_18. The same annotations print on the PDF you send to the customer.
Identifying the buyer: EU VAT number, foreign ID or none
FA(3) distinguishes how the counterparty in the Podmiot2 (buyer) section is identified. Typing a German VAT number into the Polish NIP field either gets the document rejected or, worse, accepted with a wrong identifier.
NrVatUE: an EU customer with an EU VAT number, country prefix plus digits. This is the only route for a zero-rated intra-EU supply.
NrID: a non-EU entity, national identifier together with a country code.
BrakID: a buyer that uses no tax identifier at all.
Biurko treats these as separate buyer types, validates the EU VAT number format, requires a two-letter country code and lets you record an EORI number for customs purposes. One boundary worth stating plainly: the validation checks format, not the counterparty's live status in VIES. Confirming the number in VIES before applying the zero rate remains a separate step, because it is a substantive condition of the supply rather than an XML question.
Foreign currency: getting the rate defensible
KSeF accepts invoices in EUR, USD, GBP and other currencies, but FA(3) requires the conversion rate. Under art. 31a sec. 1 of the VAT Act, amounts are converted at the average National Bank of Poland (NBP) rate from the last business day preceding the day the tax obligation arises. If the invoice was issued earlier than that, the rate from the business day preceding issuance applies.
Simple until you hit a service settled per period, where the tax point falls at the end of the period, or an invoice issued ahead of delivery. Biurko anchors on the earlier of the tax point date and the issue date, steps back to the last business day, and pulls the rate from NBP table A along with the table number, searching up to five days back when a given day has no quotation. The rate, its date and the table number are stored on the invoice, so nobody has to reconstruct the arithmetic during an audit.
What KSeF does not cover: purchase invoices from abroad
Invoices from foreign suppliers stay outside the system. Intra-EU acquisitions, imported services and imported goods are documented by issuers who are not subject to Polish invoicing rules, so an invoice from Google Ads, AWS or a Czech subcontractor arrives by email as before and is recorded in JPK_V7 the way it always was.
That leaves you with two parallel document flows: outbound cross-border sales through KSeF plus separate delivery, and inbound foreign purchases through the ordinary channel. Software that handles only the first one quietly transfers the difference to your accountant.
Checklist before your first cross-border KSeF invoice
Confirm the transaction is not excluded (non-Union OSS, IOSS, SME, self-billing without a Polish NIP).
Agree the delivery method with the customer and record it in the contract or terms.
Verify that the visualisation you send carries the QR verification code with the KSeF number.
Pick the correct buyer identification type: EU VAT number, foreign ID or none.
Check the customer's EU VAT number in VIES before applying the zero rate to an intra-EU supply.
Make sure each line carries the
P_12token matching the transaction, not a plain domestic zero.Confirm the FX rate: NBP table A from the last business day before the relevant anchor date.
Obtain a type 2 KSeF certificate if you want to issue in offline mode with both QR codes.
Summary
Cross-border invoicing in KSeF is not a separate regime. It is the same document with two extra requirements: precise transaction coding inside FA(3), and delivery outside the system with a verification code attached. Most failures trace back to software that treats every zero rate as the same zero rate.
Biurko separates intra-EU supply, export, EU services and reverse charge at the FA(3) mapping layer, pulls the NBP rate according to the art. 31a anchor rule, and sends the PDF to your customer straight from the panel. The interface runs in Polish, English and Ukrainian, which matters when finance, sales and the accounting office sit in different countries. Create a free account and issue your first cross-border invoice against the KSeF test environment.
FAQ
Do I have to issue invoices to EU customers through KSeF? Yes, if you are a Polish established VAT payer. The obligation follows the seller's status, not the buyer's. You then deliver the invoice to the customer outside KSeF in a form agreed with them, per art. 106gb sec. 4 of the VAT Act.
Can my foreign customer access the invoice in KSeF? Not without a Polish NIP. You have to provide a visualisation, typically a PDF by email or a printout, marked with a QR verification code that lets them confirm the invoice data held in the system.
How is an intra-EU supply coded in FA(3)? A zero-rated intra-EU supply line carries the token 0 WDT in field P_12 and its value goes to summary field P_13_6_2. Domestic zero rate and export have separate tokens, so they cannot be used interchangeably.
Do invoices from foreign suppliers go into KSeF? No. Intra-EU acquisitions, imported services and imported goods remain outside the system, because their issuers are not subject to Polish invoicing rules. You record them in JPK_V7 as before.
Which exchange rate applies to an invoice in EUR? The average NBP rate from the last business day preceding the day the tax obligation arises, or from the business day preceding issuance if the invoice was issued earlier (art. 31a sec. 1 and 2 of the VAT Act).
See also: [SLUG-KSEF-CORRECTIONS], [SLUG-KSEF-DEADLINES], [SLUG-KSEF-ERRORS].