Poland's KSeF / FA_VAT: what developers need to know
Poland's e-invoicing mandate isn't hypothetical anymore — it's rolling out on a fixed schedule right now. If you sell to Polish businesses, or build invoicing software that might, here's the shape of what you need to support.
The schedule
- 1 February 2026 — mandatory for large taxpayers.
- 1 April 2026 — mandatory for most B2B businesses.
- 1 January 2027 — mandatory for micro-enterprises.
Poland's Ministry of Finance has said the schedule will not be postponed again — after previous delays, this is treated as final.
KSeF is a clearance system, not a delivery network
KSeF (Krajowy System e-Faktur) works like Italy's SDI: it's a
centralized government platform, and an invoice only becomes a legally
valid faktura ustrukturyzowana (structured invoice) once it's been
submitted through KSeF's own API and assigned an official reference number
(NrKSeF). Producing a well-formed FA_VAT XML document
is necessary, but it isn't the finish line — submission to KSeF is what
makes it real.
The current schema is FA(2) (wzor 2023/06/29/12648) — the version KSeF Produkcyjne actually accepts for the 2026 rollout, not the newer FA(3) draft.
Scope worth knowing about
A few things about FA_VAT are easy to get wrong if you're used to EN 16931-family invoices:
- VAT rates. The schema's rate enum includes deprecated historical rates, flat-rate schemes, 0%, exempt, reverse-charge and out-of-scope codes — but the rates you'll actually issue against today are Poland's current standard rates: 23%, 8%, 5%.
- Currency. Unlike Spain's Facturae, FA_VAT has no single-currency restriction — any ISO 4217 currency the schema recognizes works, with amounts simply in the invoice's own currency.
- Seller identification. The seller must carry a Polish
NIP (with or without a
PLprefix) — KSeF only exists for Polish VAT payers, so there's no foreign-seller branch in the schema at all. - Buyer identification. A
PL-prefixed buyer id is emitted as a NIP; any other country-prefixed id uses FA_VAT's generic foreign-tax-id fields; no buyer VAT id at all uses the schema's own "no tax id" marker.
Pre-flight, not submission. Generating
and validating a FA_VAT document doesn't talk to KSeF and doesn't produce
a NrKSeF — exactly like a FatturaPA endpoint that doesn't
drive SDI. The document is structurally correct and ready; submitting it
through your own KSeF channel remains a separate step.
curl -X POST "$BASE/v1/validate/ksef" \ -H "Content-Type: application/xml" --data-binary @faktura.xml
See the full KSeF landing page for the field reference, or grab an already-validated sample FA_VAT file to test your own integration against.
Keep reading
Want to try this against a real invoice?
Every example above calls the same API you can call today — validate for free, or read the full reference.