KSeF: Poland's E-Invoicing Mandate, and Whether Your Polish Entity Is In Scope

Most English-language searches for KSeF come from outside Poland. That is not an accident: the question that actually matters for a multinational is whether a Polish VAT registration alone drags you into the system. It usually does not, and the test is specific.

The dates

The FA(2) structure was retired on 1 February 2026 and fully replaced by FA(3). If you built against FA(2), that work needs revisiting.

The fixed-establishment test

This is the part worth reading carefully.

A foreign company must use KSeF only if it has a fixed establishment in Poland that participates in the supply of the goods or services being invoiced.

A foreign business that is registered for Polish VAT but has no fixed establishment is not obliged to issue invoices through KSeF.

So the sequence for a group with Polish exposure is:

1. Do we have a fixed establishment in Poland? If no, the issuing obligation does not apply, even with a Polish VAT number.
2. If yes, does that establishment participate in the supply being invoiced? The obligation attaches to the transaction, not just to the entity.
3. Either way, can we receive through KSeF? Your Polish counterparties will be issuing through it, and their invoice is the one you need to book.

That third point is the one most often missed. Scoping tends to focus on the issuing obligation, but if you buy from Polish suppliers, structured invoices are arriving whether or not you issue any.

How clearance changes the model

KSeF is not a network. It is a clearance system, and that distinction has practical consequences.

In a network model like Peppol, you send to your counterparty through an access point and the state is not in the path. In a clearance model, the invoice goes to the tax authority first. KSeF validates it, assigns it an identification number, and only then is it a legally issued invoice. The document your customer receives is the cleared one.

Three things follow:

• There is no access point to buy. What you need is an integration with the government API and the FA(3) schema.
• The clearance number matters. It is the proof the invoice legally exists, and it belongs in your records.
• Rejection is a business event, not a technical retry. A schema failure means no invoice was issued at all.

Italy's SdI works the same way. Peppol countries such as Belgium and Norway do not. Our guide to what each country actually mandates covers which model applies where.

What FA(3) requires

FA(3) is a Polish national schema, not an EN 16931 CIUS, so a European invoice generator will not emit it without Poland-specific mapping. Expect to supply:

• Seller and buyer NIP numbers
• Invoice type codes drawn from the Polish list
• Line-level VAT rates against Polish rate categories
• Polish-specific fields for corrections and advance invoices

If your ERP already emits Peppol BIS Billing 3.0 or ZUGFeRD, that gets you the semantic content but not the syntax. The mapping work is real.

Where this sits against the rest of Europe

Poland is one of four different mechanisms a group trading across the EU may hit at once:

• Poland and Italy: government clearance portals, no private network
• Belgium, Norway, Slovakia: the Peppol network
• France: certified approved platforms, a model of its own
• Germany: a format requirement with no mandated transport at all

There is no single integration that satisfies all four. Vendors who suggest otherwise are generally reselling four integrations on one invoice. The full mandate timeline sets out which countries fall where.

Sources

• E-invoicing in Poland: complete guide to KSeF, Marosa VAT
• Poland implements mandatory B2B electronic invoicing with KSeF from 2026, EDICOM

Related reading

• European e-invoicing mandate timeline
• France, 1 September 2026
• Does your ERP support Peppol?
• EDI Inspector, free in-browser EDI file reader