Poland KSeF 2026: What ERP Vendors Need to Know Before April 1

Poland's KSeF mandate is no longer on the horizon — it's here. Large enterprises have been live since February 1, 2026. On April 1, 2026, the obligation extends to every remaining VAT-registered entity in Poland, including SMEs and sole proprietors. If your ERP platform serves customers operating in Poland, you have approximately three weeks to be compliant.

This guide covers the technical requirements, timeline, penalties, and what your integration team needs to prioritise right now.

---

Timeline: Key Dates at a Glance

Date	Obligation
February 1, 2026	Mandatory KSeF for large taxpayers (first wave)
April 1, 2026	Mandatory KSeF for all remaining VAT-registered entities, including SMEs and sole proprietors
January 1, 2027	Financial penalties for non-compliance take effect

The two-month stagger between large and small taxpayers was intentional — it gave the KSeF infrastructure time to absorb high transaction volumes before the broader rollout. The test environment (sandbox) has been available since September 2025, and the final FA(3) schema and KSeF 2.0 API documentation were published in June 2025, so there has been time to prepare. That window closes on April 1.

---

Technical Requirements: FA(3) and KSeF 2.0

The FA(3) Schema

The FA(3) structured invoice schema replaces FA(2) as of February 2026. If your platform was built against FA(2), it will not meet the April 1 mandate for SME customers.

Key changes in FA(3):

• New VAT rate codes — the classification structure for VAT rates has been updated, including handling of new reduced rate categories
• Supplementary file attachments — FA(3) allows invoice-level binary attachments, meaning ERP platforms can include supporting documents alongside the structured XML
• Revised field ordering and element cardinality — some previously optional fields are now required; validate your mapping carefully against the Ministry of Finance's published XSD
• EN 16931 alignment — while KSeF remains a proprietary national system (not Peppol), the data model has moved closer to the European standard, which reduces the mapping distance from existing UBL or CII implementations

The schema is published by Poland's Ministry of Finance. There is no alternative format accepted for B2B transactions within KSeF scope — unlike France, which accepts UBL, CII, and Factur-X, Poland mandates FA(3) exclusively.

KSeF 2.0 API

The KSeF 2.0 API follows the OpenAPI standard. The Ministry of Finance provides SDKs for Java and .NET. Two submission modes are supported:

Interactive mode — suitable for low-volume issuers. The invoice is submitted synchronously and a UPO (Urzędowe Potwierdzenie Odbioru — the official receipt) is returned in the same request cycle.

Batch mode — designed for high-volume environments. Invoices are submitted asynchronously. The ERP polls for the UPO after a delay. This is the appropriate mode for any customer issuing more than a few hundred invoices per day.

Authentication is session-based, using either a qualified electronic signature or a token issued via the AADE-style authorisation flow (company TIN + authorisation token). Integration patterns, example requests, and response schemas are documented in the official KSeF 2.0 API specification.

The UPO is the legally binding proof of invoice receipt. Your platform must store it and make it retrievable per invoice — this is an audit requirement, not an edge case.

---

Who Is Affected

In scope from April 1, 2026:

• All VAT-registered entities in Poland not already covered by the February 1 wave
• This includes SMEs, sole proprietors, and VAT-exempt entities with B2B transaction obligations
• Both domestic B2B sales and exports outside the EU are in scope
• Intra-EU transactions remain outside the mandatory scope for now

Out of scope:

• Consumer (B2C) transactions
• Intra-EU B2B (optional, not mandatory)
• Businesses with no VAT registration in Poland

If your ERP platform serves customers in Poland across any of the in-scope categories, your integration is required to be live by April 1.

---

Penalties

For 2026, Poland has granted a de facto grace period on financial penalties. No monetary fines apply for KSeF non-compliance during the current year. This was confirmed by the Ministry of Finance in early March 2026, which also clarified that when penalties do apply, they will be assessed proportionally rather than always at the maximum rate.

However, the absence of financial penalties in 2026 does not mean non-compliance is risk-free:

• VAT deduction risk: invoices issued outside KSeF during 2026 will lack the KSeF identifier. In an audit, buyers relying on those invoices for input VAT deduction face a higher evidentiary burden and potential delays in VAT refunds.
• Trading partner rejection: large buyers — already live on KSeF since February — are increasingly configuring their AP systems to accept only KSeF-validated invoices. Non-KSeF invoices from SME suppliers may simply be refused.
• 2027 cliff: from January 1, 2027, financial penalties of up to 100% of the VAT amount on a non-compliant invoice apply. ERP platforms that miss the April 1 deadline are building up a larger backlog of non-compliant transactions that will need to be addressed before year-end.

---

What ERP Vendors Should Do

Validate your FA(3) implementation now

Run your invoice generation logic against the Ministry of Finance's official XSD for FA(3). Common failure points include incorrect VAT rate codes, missing mandatory fields that were optional in FA(2), and attachment handling for platforms that support supplementary documents.

Test end-to-end in the KSeF sandbox

The test environment has been available since September 2025. If you haven't already run full submission cycles — including UPO retrieval and error-case handling — do it before April 1. The sandbox mirrors production authentication flows, so it's a reliable test of your complete integration stack, not just schema validation.

Implement UPO storage

The UPO must be stored per invoice and linked back to the originating transaction. Verify that your platform captures and persists the KSeF invoice identifier (KSeF number) returned on successful submission, and that it's exposed in the document record for audit retrieval.

Plan for batch mode at scale

If any of your Polish customers issue high invoice volumes, verify that your integration handles batch submission and asynchronous UPO polling correctly. Batch mode failure modes (partial submission success, timeout handling, retry logic) are common sources of production incidents in early mandate rollouts.

Communicate clearly with your customers

ERP vendors that have informed their Polish customers of the April 1 requirement and the status of their integration reduce support escalations. A brief factsheet or in-app notice explaining what KSeF compliance means for users — specifically that invoices will now be submitted to KSeF automatically and that the KSeF number will appear on their invoice records — goes a long way.

---

FAQ

What is KSeF?

KSeF (Krajowy System e-Faktur) is Poland's National E-Invoicing System, operated by the Ministry of Finance. It acts as a centralized clearance platform: B2B invoices must be submitted to KSeF, which assigns a unique identifier and stores the invoice. The invoice is legally valid only after it receives the KSeF number and an official UPO receipt.

Does KSeF apply to all businesses in Poland from April 1, 2026?

It applies to all VAT-registered entities not already covered by the February 1, 2026 large taxpayer wave. This includes SMEs, sole proprietors, and VAT-exempt businesses with B2B obligations. Consumer (B2C) transactions and intra-EU sales are not in scope for mandatory KSeF submission.

Can we still use Peppol or UBL for Polish customers?

No. Poland mandates the FA(3) XML schema exclusively for KSeF submissions. There is no Peppol access point model for Poland — invoices are submitted directly to the KSeF API. If your platform generates UBL or CII for other markets, you will need a separate FA(3) mapping for Polish transactions.

What is the FA(3) schema and where can I get it?

FA(3) is the structured invoice schema defined by Poland's Ministry of Finance. It replaces FA(2) as of February 2026. The official XSD and documentation are published by the Ministry of Finance on the gov.pl KSeF technical resources portal. The KSeF 2.0 API documentation was finalised in June 2025.

Are there financial penalties for missing the April 1, 2026 KSeF deadline?

Not in 2026. Poland has confirmed that financial penalties for KSeF non-compliance will not be enforced until January 1, 2027. However, non-KSeF invoices face practical risks: buyers may reject them, VAT deduction claims are harder to defend in an audit, and the penalty exposure from January 2027 increases with each non-compliant transaction.

What is a UPO and why does it matter for KSeF?

UPO (Urzędowe Potwierdzenie Odbioru) is the official receipt issued by KSeF on successful invoice submission. It contains the KSeF invoice number and a timestamp. The UPO is the legal proof that the invoice was received into the system. Your platform must store it and associate it with the originating invoice record — it will be required in any VAT audit.

---

Resources

• KSeF technical documentation — Ministry of Finance (gov.pl)
• KSeF 2.0 API documentation and FA(3) schema — Comarch summary
• Poland KSeF mandate overview — EDICOM
• KSeF penalties clarification — VATupdate (March 2026)

---

Invoice Navigator provides e-invoicing compliance infrastructure for ERP vendors integrating with national systems across the EU. If you're building or updating a KSeF integration, contact our team to discuss API-level support.