🇵🇱 E-Invoicing in Poland
Poland's mandatory B2B e-invoicing via the Krajowy System e-Faktur (KSeF) is now live in two phases. Large taxpayers (turnover above 200M PLN) joined on February 1, 2026; all remaining VAT-registered entities — SMEs, sole proprietors, and VAT-exempt businesses with B2B obligations — joined on April 1, 2026. KSeF is a centralized government clearance platform: every invoice must be submitted to and validated by KSeF before it is considered legally issued, and the platform assigns a unique KSeF number plus an Urzędowe Potwierdzenie Odbioru (UPO) receipt that ERP integrations must store.
Poland's approach is architecturally distinct from Peppol-based mandates. The system uses a proprietary FA(3) XML schema (which replaced FA(2) in February 2026), not EN 16931 UBL or CII. Authentication requires qualified electronic signatures, trusted profiles, or authorization tokens for API access. Cross-border invoices issued by Polish VAT payers also require KSeF reporting. Peppol is not used; KSeF is a closed national system. Invoice Navigator validates Polish e-invoices against the FA(3) schema and tracks the KSeF submission lifecycle through to UPO receipt.
Financial penalties — up to 100% of the VAT amount on non-compliant invoices — take effect January 1, 2027. During 2026, the practical risks are real even without monetary fines: invoices not submitted through KSeF are not legally valid for VAT deduction, trading partners on compliant systems may reject non-KSeF invoices, and audit exposure on backdated KSeF compliance will only grow.
The Polish Ministry of Finance has confirmed the FA(3) XSD and KSeF 2.0 API documentation as the authoritative integration references; both were finalized in mid-2025 and have remained stable through the Phase 2 rollout. Micro-entrepreneurs join the mandate on January 1, 2027.
TL;DR
Last updated: January 2026
Mandate Status
Technical Specifications
Common Rejection Patterns
Implementation Notes
KSeF is architecturally different from Peppol-based mandates. If you've built for Belgium or Germany, assume nothing transfers.
Clearance model. Every invoice must be submitted to KSeF via API, validated by the government, and assigned a unique KSeF number before it's considered issued. The buyer retrieves the invoice from KSeF — you don't deliver it directly. This means your pipeline's "send invoice" step is actually "submit to KSeF and wait for acceptance." Rejection means the invoice was never issued.
Proprietary XML schema. KSeF uses its own XML schema (FA(2)), not EN 16931 UBL or CII. If your pipeline is built on EN 16931, you need a dedicated KSeF mapper. The schema has Polish-specific fields (e.g., GTU codes for goods/services classification, MPP split payment markers) that have no EN 16931 equivalent.
Authentication complexity. KSeF requires qualified electronic signatures (kwalifikowany podpis elektroniczny), trusted profiles (profil zaufany), or authorization tokens for API access. Multi-entity setups need per-entity token management. The token refresh logic is non-trivial — tokens expire and the renewal endpoint has rate limits.
What catches integrators off-guard. KSeF stores invoices for 10 years and serves as the legal archive. Credit notes must reference the original KSeF number. Cross-border invoices also require KSeF reporting (the system covers all invoices issued by Polish VAT payers, not just domestic). Batch submission is supported but each invoice gets individual validation — a batch of 1,000 can partially fail.
Recent Updates
🔔 Poland Alerts
E-Invoicing in Poland: FAQ
Ship compliant Poland invoices
Validate, fix, and route Poland e-invoices through a single API. No XML editing required.
Fix an invoice for this country