Country deep dive
KSeF has been rebuilt once already — Poland paused an earlier version after a technical audit found the architecture needed strengthening. KSeF 2.0 is the version that actually went live.
Public-sector invoicing runs on Peppol via the PEF platform, entirely separate from the KSeF platform that would later handle B2B — the two systems don't share infrastructure. The obligation to accept e-invoices phased in from 18 April 2019 (contracts ≥€30,000) to 1 August 2019 (all contracting authorities), under the Act of 9 November 2018.
The Ministry of Finance released the OpenAPI 3.0.4 specification, integration guides with C#/Java examples, .NET and Java SDKs, and the final FA(3) logical structure — replacing FA(2) and shaped by public consultation with businesses, accountants, and IT vendors.
Integrators and businesses gain access to a sandbox for architectural planning and prototype development ahead of the mandatory rollout.
Taxpayers can begin applying for KSeF certificates via the Certificates and Authorizations Module (MCU) — the credential that will fully replace token-based authentication from January 2027.
Large taxpayers with turnover above PLN 200 million became the first group required to issue B2B invoices through the Krajowy System e-Faktur (KSeF) clearance platform.
The KSeF mandate extended to all remaining VAT-registered businesses in Poland (excluding micro-entrepreneurs); an invoice only carries legal force once KSeF has cleared it.
The full-year 2026 grace period (no financial penalties for KSeF errors, regardless of a business's mandatory start date) expires, along with the exception letting the smallest sellers (≤PLN 10,000 gross monthly invoicing) issue outside KSeF.
Micro-entrepreneurs join the KSeF mandate, and the grace period on financial penalties (up to 100% of invoice VAT for non-compliance) ends for everyone.
FA(3) is the third generation of Poland's national schema — each revision has tightened validation and added more structured detail than the last.
FA(3) was shaped directly by tax consultations with entrepreneurs, accountants, auditors, and IT vendors — the attachment support in particular was a direct response to feedback that FA(2) was too rigid for real-world invoicing scenarios.
Suppliers don't apply their own qualified signature — KSeF's own clearance process (validation, sealing, and reference number assignment) is what gives the invoice legal force, similar in spirit to Italy's SDI model.
Because KSeF stores every validated invoice centrally for 10 years, businesses don't need to independently archive invoice XML files for compliance purposes — a genuine operational simplification compared to decentralised regimes.
An invoice without a valid KSeF number is not valid for tax purposes — this is the sharpest practical difference from decentralised models like Germany's, where the file itself carries legal weight without a central clearance step.
KSeF is a true clearance model: the buyer retrieves the invoice from the central system rather than receiving it directly from the seller.
Test thoroughly in the sandbox environment before connecting to production — the API documentation includes full endpoint, parameter, and response-code references specifically to support this.
Plan your long-term authentication approach around qualified seals or KSeF certificates — tokens and the Trusted Profile route are both being phased out on different timelines.
This buyer-retrieves-rather-than-receives model is the key structural difference from Peppol-based countries — there's no "delivery" step in the conventional sense once an invoice clears KSeF.
Four offline modes exist for when KSeF itself is unavailable or unreachable:
Invoices issued offline or in failure mode need a QR code for verification, and must be submitted to KSeF by the next working day. Domestic NIP-holders no longer need a QR code on the printout itself — they retrieve the legally valid invoice through KSeF directly, except in failure mode.
Access setup is a one-time process centred on a single authorisation form and your choice of authentication credential.
Check your invoicing or ERP software against the FA(3) logical structure and KSeF 2.0 API documentation, or plan to use the Ministry's free tools if you don't have in-house development capacity.
This names the person authorised to operate KSeF on your entity's behalf. It's not required if you hold a qualified electronic seal containing your NIP — in that case you can use KSeF directly. The person named in ZAW-FA can then grant further authorisations to others directly within the platform.
Apply for a KSeF certificate via the Certificates and Authorizations Module, or use a token during the transitional period (available only until the end of 2026). Every authorised person needs a NIP or PESEL, or a qualified electronic signature if they have neither.
Use the KSeF 2.0 test environment to pilot invoice submission, receipt retrieval, and error handling — this is where most integration problems surface, well before they hit production.
If an accountant or external service handles invoicing for you, configure their authorisation and delegation rules explicitly rather than sharing your own credentials.
Implement the ability to issue structured invoices outside KSeF during downtime, generate the required QR code, and submit to KSeF no later than the next business day.
Poland's penalty regime is among the strictest in Europe on paper — but a full-year grace period and a planned legislative clarification soften the picture considerably.
Other countries in the same region, ordered by their next dated milestone. Each links to a full briefing.