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, entirely separate from the KSeF platform that would later handle B2B — the two systems don't share infrastructure.
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.
The first wave of businesses must issue every domestic B2B invoice through KSeF using the FA(3) schema — the same date the FA(3) format formally replaced FA(2) for everyone still using the old structure voluntarily.
Coverage extends to every remaining VAT-registered business, including foreign companies registered for Polish VAT without a fixed establishment. The Trusted Profile authentication method is withdrawn on the same date — plan around the remaining three methods below.
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.
The smallest remaining sellers enter KSeF, KSeF certificates fully replace tokens for authentication, and Article 106ni penalties (up to 100% of invoice VAT) take effect 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.
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.
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.
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.
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.
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.
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.