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 and administrative penalties activate.
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:
Date Milestone 30 Jun 2025 API 2.0 documentation (OpenAPI 3.0.4) and FA(3) schema published 30 Sep 2025 Open testing of API 2.0 15 Oct 2025 Pre-production (Demo) environment 1 Nov 2025 Certificates and Permissions Module (MCU) goes live 1 Jan 2026 Attachment notification form opens in e-Urząd Skarbowy (the tax e-office) 17 Jan 2026 Legacy environment addresses shut down 1 Feb 2026 KSeF 2.0 in production, FA(3) only
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. 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. The certificate is used for authentication and is required to issue invoices in offline mode.
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 grew from 32 to 34 characters (full IBAN, relevant for foreign accounts), item names 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
Ask specifically whether the system submits via API 2.0 with FA(3), not whether it "supports KSeF".
Confirm it can issue in offline mode, meaning it manages a KSeF certificate and produces the required QR codes.
Check FA_RR support if you buy from flat-rate farmers.
Confirm one bad invoice in a batch does not block the rest.
Review your tax code mapping:
0_KR,0_WDT,0_EX,NP_I,NP_II.Audit permissions in the MCU module, client by client.
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, certificate-based authentication, 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? The certificate is used for authentication and is required for issuing invoices in offline mode. If you work strictly online and authenticate another way you can operate without one, but you lose the fallback path.
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.