How KSeF Works
The Clearance Model
KSeF operates a centralized clearance model similar to Italy’s SDI. The tax authority sits between the supplier and the buyer, validating every invoice before it is legally issued. The submission flow works as follows:
Step 1: The supplier generates an invoice in FA(3) XML format and submits it to KSeF via the REST API (or, for lower volumes, via the taxpayer web application).
Step 2: KSeF validates the invoice against the FA(3) schema and checks data consistency — including NIP (tax identification number) verification against the VAT taxpayer registry.
Step 3: If validation passes, KSeF assigns a unique KSeF ID (reference number) and issues a UPO (Urzędowe Poświadczenie Odbioru — official acknowledgment of receipt).
Step 4: The validated invoice is stored on the platform. The buyer retrieves their invoices from KSeF rather than receiving them directly from the seller.
The invoice is legally considered issued at the moment KSeF assigns the reference number. If validation fails, KSeF rejects the invoice with an error message — the invoice is not considered issued, and the supplier must correct the data and resubmit.
FA(3) XML Format
FA(3) is the mandatory structured invoice schema for KSeF, replacing the earlier FA(2) format as of February 1, 2026. The schema defines all required and optional fields for Polish e-invoices in XML format.
Key mandatory fields in the FA(3) schema include:
| Field | Element | Description |
|---|---|---|
| Invoice Date | P_1 | Issue date in YYYY-MM-DD format |
| Invoice Number | P_2 | Sequential number assigned by issuer |
| Seller NIP | DaneIdentyfikacyjne | Supplier’s tax identification number |
| Buyer NIP | NIP | Purchaser’s tax identification number |
| Net Amount | P_11 | Total net value of the invoice |
| VAT Amount | P_11A | Total VAT amount |
| Gross Amount | P_11B | Total gross value |
| Currency | KodWaluty | ISO 4217 currency code (typically PLN) |
The FA(3) schema introduced refinements over FA(2) to improve data accuracy and validation. Detailed technical specifications are published by the Ministry of Finance at ksef.podatki.gov.pl.
KSeF 2.0 API
The KSeF 2.0 API is a REST API documented using the OpenAPI 3.0.4 standard. The Ministry of Finance provides SDK libraries in Java and .NET to facilitate integration. Key API operations include:
- Authentication — Token-based authentication using qualified electronic signatures, trusted profiles, or authorization tokens
- Interactive submission — Single invoice submission with immediate validation response
- Batch submission — Multiple invoices in a single request for high-volume senders
- Invoice retrieval — Downloading invoices assigned to the authenticated taxpayer
- UPO retrieval — Fetching official acknowledgments of receipt
- Status queries — Checking processing status of submitted invoices
The test environment for KSeF 2.0 API has been available since September 30, 2025, allowing integrators and businesses to test their implementations before the mandate took effect.
Offline Mode
KSeF provides a contingency mechanism for system outages. Using an offline certificate, businesses can continue issuing invoices when the platform is unavailable. Offline invoices are signed locally with a timestamp and marked as issued in offline mode. Once KSeF becomes available again, the signed invoices must be uploaded to receive their KSeF IDs.
Why KSeF Matters
The Newest Major EU Clearance Mandate
Poland is the largest Central European economy to adopt real-time clearance e-invoicing. With a GDP ranking among the top six in the EU and millions of active businesses, KSeF will process a massive volume of structured invoices. The phased rollout — starting with approximately 4,200 large taxpayers in February 2026 and expanding to all VAT-registered businesses by April 2026 — means the system is scaling rapidly.
KSeF also represents a model that other EU member states are watching closely. The European Commission’s ViDA initiative aims to introduce similar real-time reporting requirements across the EU by 2030. Businesses that build KSeF compliance now are building infrastructure they’ll need for broader EU mandates.
Real-Time Tax Authority Visibility
The clearance model gives Poland’s Ministry of Finance immediate, granular visibility into every B2B transaction. Unlike post-audit models where tax authorities review filings months later, KSeF sees every invoice at the moment it is issued. This is designed to reduce VAT fraud — following Italy’s experience, where mandatory clearance e-invoicing generated billions in additional tax revenue.
Grace Period Through 2026
A critical detail for businesses adapting to KSeF: no financial penalties will be imposed for non-compliance throughout 2026. This grace period allows businesses to transition their systems without the risk of fines. Penalties take effect from January 1, 2027, making the remainder of 2026 the window for integration, testing, and operational readiness.
Why ERP Vendors Must Support KSeF
If your ERP or accounting software serves Polish businesses, KSeF support is a hard requirement. The FA(3) XML schema is structurally different from UBL, CII, and FatturaPA — you cannot reuse integrations built for other standards. The KSeF API authentication model, the NIP-based validation, and the clearance workflow all require Poland-specific implementation.
The structural approach: validate every invoice against the FA(3) schema and KSeF business rules before submission. Catching errors before they reach KSeF prevents rejected invoices, compliance gaps, and delayed payments.
Invoice Navigator validates KSeF invoices against FA(3) schema rules and Polish business requirements, catching format errors, invalid NIP numbers, and structural issues before submission to the platform.
Common KSeF Validation Errors
These are the errors that cause the most rejections and integration issues with KSeF:
Invalid or inactive NIP — KSeF verifies the buyer’s and seller’s NIP (Numer Identyfikacji Podatkowej) against the VAT taxpayer registry. An incorrect, inactive, or improperly formatted NIP causes automatic rejection. Always verify NIP status against the CEIDG database or the VAT white list before submission.
FA(3) schema non-conformance — The invoice XML does not match the FA(3) schema structure. Common causes: missing mandatory elements, incorrect element ordering, invalid data types, or using the superseded FA(2) format. All invoices from February 1, 2026 must use the FA(3) schema exclusively.
NIP correction complexity — Correcting an incorrect buyer NIP on a KSeF-issued invoice requires a multi-step process: issuing a corrective invoice that zeroes out the original (with the wrong NIP), then issuing a new original invoice with the correct buyer NIP. Simple amendments are not supported.
Authentication failures — KSeF API authentication requires valid qualified electronic signatures, trusted profiles, or properly issued authorization tokens. Expired certificates, incorrect token scopes, or misconfigured authentication flows prevent submission entirely.
Inconsistent VAT calculation — KSeF validates that net amounts, VAT amounts, and gross totals are internally consistent. Rounding mismatches between line items and summary totals trigger rejection. This is especially common when converting from foreign currencies to PLN.
For the full error library with fix guidance: All validation errors →
How to Get Started
Step 1: Understand Your Obligations
If you issue B2B or B2G invoices in Poland, you must use KSeF. The mandate applies to all VAT-registered entities, with phased deadlines: large taxpayers (turnover over PLN 200 million) from February 1, 2026; all other businesses from April 1, 2026; micro-entrepreneurs from January 1, 2027. No financial penalties apply until January 1, 2027.
Step 2: Choose Your Integration Approach
KSeF offers two primary integration paths:
- KSeF API (REST) — For automated, high-volume submission. Requires integration with the KSeF 2.0 API using OpenAPI 3.0.4 specifications. SDKs available in Java and .NET.
- Taxpayer Web Application — For manual, low-volume use. The Ministry of Finance provides a free web portal for issuing and retrieving invoices.
Step 3: Set Up Authentication
KSeF API access requires authentication via qualified electronic signatures, trusted profiles (Profil Zaufany), or authorization tokens issued through the KSeF portal. Configure your credentials and test authentication against the KSeF test environment before going live.
Step 4: Generate Valid FA(3) XML
Your system must produce XML that conforms to the FA(3) schema. Key required elements: seller and buyer NIP, invoice date and number, line items with quantities and prices, VAT breakdown per rate, net/VAT/gross totals, and currency code.
Step 5: Validate Before Submission
Run every invoice through FA(3) schema validation and NIP verification before submitting to KSeF. This prevents rejections and the operational overhead of correcting and resubmitting failed invoices.
For API integration: Developer documentation →
For sandbox testing: Sandbox environment →
Validate Your KSeF Invoice
Check if your invoice passes FA(3) schema validation and Polish business rules before submission. Free online validator — no signup required.
Try Free Validator