KSeF 2.0 vs 1.0: What Changed in the API and the FA(3) Schema

If your ERP vendor tells you they "support KSeF" (Poland's national e-invoicing system), that sentence carries no information. What matters is whether they run on API 2.0 with the FA(3) schema, because since 1 February 2026 nothing else is accepted. The legacy environment addresses were switched off on 17 January 2026, and production KSeF 1.0 stopped during the technical break between 26 and 31 January 2026.

This matters even if you never touch an integration. Schema changes reach into how you number invoices, how you flag zero-rated cross-border sales, and how permissions work inside an accounting team. And from 1 January 2027 the smallest taxpayers join the system. Under the current act, penalties under Article 106ni of the VAT Act apply from the same day; on 16 September 2026 the Ministry of Finance announced it will move them to 1 January 2028 — that is a bill not yet passed, and it moves only the penalties, not the obligation to use KSeF.

Here is what actually differs.

Two different systems, not two versions of one

KSeF 1.0 ran from 2022 as a voluntary system. Its design assumptions were different: authentication welded to session opening, optional encryption in interactive mode, permission inheritance, and the FA(1) then FA(2) schema.

KSeF 2.0 was built for a mandatory regime. The rollout ran as follows:

The address migration is described in the Ministry of Finance notice for integrators.

What changed in the API

The Ministry publishes an official overview of key API 2.0 changes. The parts that matter:

Authentication is separate from sessions. In 1.0, logging in was inseparable from opening an interactive session. In 2.0 you authenticate once, receive a JWT, and open as many sessions as you need. JWT tokens (not the same thing as KSeF tokens) can be refreshed and revoked.

Unified session initialisation. Interactive and batch sessions start the same way:

POST /sessions/online
POST /sessions/batch

Both take a form code and an encrypted AES key.

Encryption is mandatory for every invoice. In 1.0 it was required only for batch submissions. In 2.0 every invoice, including single ones, must be encrypted client-side with a per-session AES key. That key is wrapped using RSA-OAEP with SHA-256 and MGF1-SHA256, and current public key certificates come from GET /security/public-key-certificates.

KSeF certificates. A new module lets an authenticated entity request an internal KSeF certificate, download it, check application status and check its certificate quota. Certificates come in two types: one for authentication and one of the Offline type, needed for the second QR code on invoices issued in offline mode. They are separate certificates and mutually exclusive.

Batch submissions are no longer all-or-nothing. In 1.0 a single malformed invoice could sink the whole package. In 2.0 each invoice is processed independently, and a dedicated endpoint returns the failed ones with their errors.

Duplicate detection changed. Instead of hashing the file, the system compares business data: the Podmiot1 NIP (Polish tax ID), RodzajFaktury (document type) and P_2 (invoice number).

A new permission model. Inheritance was replaced by indirect granting. A client grants your firm a permission with an onward-delegation flag, and your firm then assigns it to named employees. General permissions covering all of an entity's clients are also possible, and there is now a login context for EU entities doing self-billing on behalf of a Polish entity.

Explicit rate limits. Every endpoint has per-second, per-minute and per-hour limits applied per context and IP address. The values are published and differ by environment.

What changed in the FA(3) schema

FA(3) was published in the CRWDE repository on 25 June 2025 and replaced FA(2) on 1 February 2026 (official description).

Attachments. There is now a Zalacznik node, but it is not a PDF stapled to an invoice. The attachment is structured data inside the same XML file, and it may only extend invoice data, never replace fields required by Article 106e of the VAT Act. Prerequisite: a notification to the Head of the National Revenue Administration filed through e-Urząd Skarbowy, processed within three working days (Ministry notice). An invoice with an attachment may not exceed 3 MB, and putting marketing content there can cost you the entitlement.

A new "Employee" role. A third party on the invoice can be flagged as an employee, which helps with travel, fuel and hotel expense allocation. The node is optional, so do not build your entire expense automation on its presence.

New tax codes. The 0% rate was split and the catch-all NP code removed:

0 KR    0% rate, domestic transactions
0 WDT   intra-Community supply of goods
0 EX    export of goods
np II   services where the customer accounts for VAT (Art. 100(1)(4) VAT Act)
np I    other supplies of goods and services outside Poland

For a foreign group this is the single change most likely to break a template. A shared "outside scope" tax code in your ERP no longer maps to one KSeF value.

Flexible payment terms. Instead of a fixed date you can express a number of time units from a starting event, for example 14 days from receipt of the invoice.

Small details that fail validation. Bank account numbers take up to 34 characters (full IBAN, relevant for foreign accounts), item names up to 512 characters, and a field for a KSeF payment identifier was added.

Flat-rate farmer invoices use a separate schema. A VAT RR invoice is not an FA(3) variant. It follows the separate FA_RR ministerial schema with its own form variant and its own document types (VAT_RR, KOR_VAT_RR). An integration that only knows FA(3) cannot issue one.

Why this reaches your business, not just your IT team

Three situations from practice:

Numbering and duplicates. You submit invoice INV/2026/07/14, get a validation error, fix the XML and resubmit under the same number after the first attempt was in fact accepted. Under 1.0 different file contents produced a different hash and went through. Under 2.0 the same tax ID, document type and number is a duplicate. Fixes go through a correction invoice, not a resubmission.

VAT codes. A company selling services to Germany that carried a single "NP" code in its ERP now has to decide between np II and np I at issue time rather than at reporting time. Agree the mapping with your tax advisor once, then encode it in product templates.

Permissions in shared service or accounting teams. Previously an employee with rights to your own invoices automatically handled clients whose permissions your firm held. That link is gone. If people lost visibility of clients in February, the cause is almost always a missing indirect grant, not an outage.

Vendor verification checklist

1. Ask specifically whether the system submits via API 2.0 with FA(3), not whether it "supports KSeF".

2. Confirm it can issue in offline mode, meaning it manages a KSeF certificate and produces the required QR codes.

3. Check FA_RR support if you buy from flat-rate farmers.

4. Confirm one bad invoice in a batch does not block the rest.

5. Review your tax code mapping: 0 KR, 0 WDT, 0 EX, np I, np II.

6. Audit permissions in the MCU module, client by client.

7. If you need attachments, file the e-Urząd Skarbowy notification before you plan the rollout.

Summary

KSeF 2.0 is not a point release. It is a different authentication model, different encryption, a different permission model and a different invoice structure. Most of these differences only become visible when something gets rejected.

Biurko was built on API 2.0 and FA(3) from the start, with separate FA_RR handling, authentication via Profil Zaufany or a KSeF certificate, batch submission, offline modes and purchase invoice import from KSeF. Create a free account at biurko.io and run one real invoice through to UPO (the official receipt confirmation).

FAQ

Can I still issue an invoice using the FA(2) schema? No. Since 1 February 2026 KSeF accepts FA(3) only. This includes corrections to invoices originally issued under FA(2): the correction itself must use the new structure.

Do old API 1.0 tokens and integrations still work? No. Production KSeF 1.0 ended during the technical break between 26 and 31 January 2026, and the legacy environment addresses were switched off on 17 January 2026 with no redirects.

Does every company need a KSeF certificate? Not necessarily. For authentication you can still use a KSeF token today, but under the current rules KSeF tokens expire on 31 December 2026. At consultations on 9 June 2026 the Ministry of Finance proposed keeping them, but no regulation has been adopted yet, so moving to a KSeF certificate is the safer choice. For the second QR code on offline invoices you need a separate certificate of the Offline type; without it an offline invoice has no second QR code.

What can an invoice attachment actually contain? Structured data that supplements the invoice, such as consumption details or settlement line detail. Not a PDF, not a scan, not marketing material. It requires a prior notification to the Head of the National Revenue Administration through e-Urząd Skarbowy.

Does our foreign parent's ERP need to change? If it submits to KSeF directly, yes: the endpoints, encryption and schema all changed. Many groups instead keep the ERP as the source of data and use a local Polish system for the KSeF leg, which limits the change to an export mapping.