Poland: Ministry of Finance Confirms KSeF Token Authentication Survives Beyond 2026

KGT Country Update | 15 September 2026 | VAT, e-invoicing and SAF-T monitor

On 11 September 2026, the Polish Ministry of Finance added a new question to its official KSeF 2.0 questions and answers page confirming that token-based authentication will not expire at the end of 2026 but will remain available indefinitely. A companion statement was added to the Ministry's Certyfikaty KSeF guidance page on 1 September 2026.

The decision removes a deadline that currently sits in a regulation, and the Ministry states that the regulation will be amended accordingly. Businesses should not read this as meaning that nothing changes: the Ministry has separately proposed giving each individual token a validity period of between one and 365 days, with automatic renewal.

Background

KSeF became mandatory on 1 February 2026 for taxpayers with turnover above PLN 200 million and on 1 April 2026 for all other taxpayers, with penalties following in 2027. Authentication to the system can be performed either with a KSeF certificate or with a token, which the governing regulation describes not as a token but as an alphanumeric string.

Under the original design, tokens were a transitional mechanism. Paragraph 13(1)(1) of the Regulation of the Minister of Finance and the Economy of 12 December 2025 on the use of KSeF, published in the Journal of Laws for 2025 at item 1815 under the enabling provision in Article 106r of the VAT Act, set 31 December 2026 as the end point.

Earlier editions of the Ministry's own KSeF 2.0 manual said so expressly: the edition of 1 February 2026 stated that the ability to generate and use tokens would expire at the end of 2026, with a footnote citing that paragraph.

Software vendors and taxpayers argued against the sunset, principally because certificate lifecycle management is materially heavier than token management for groups with many Polish registrations and many integrating systems. The Ministry accepted the argument.

The Legislative Change

Strictly, no legislative change has yet occurred. The deadline sits in a regulation, and the regulation has not been amended. What has happened is that the Ministry has stated its decision in official guidance and has undertaken to amend the regulation.

The decision first appeared in Part I of the KSeF 2.0 manual, published on 7 August 2026, which records that under the original assumptions tokens were to operate only until 31 December 2026, that considering submissions from businesses and software providers the Ministry has decided to retain that authentication method for an indefinite period, and that the regulation on the use of KSeF will be amended accordingly. The manual's own change register carries the same entry under August 2026.

The Ministry then restated the position twice in the current review window. On 1 September 2026, it modified its Certyfikaty KSeF guidance page, which now states that tokens will be retained indefinitely and that the regulation will be amended.

On 11 September 2026 it updated its KSeF 2.0 questions and answers page, adding a new question asking whether the ability to use tokens will expire at the end of 2026 and answering that it will not. The same update rewrote an existing answer: where the page previously said that certificates and tokens would operate in parallel for a certain time and that tokens would work until the end of 2026, it now says simply that both methods operate in parallel.

This is guidance operating within an unamended legal framework, and that gap matters. Until the regulation is amended, paragraph 13(1)(1) still contains the 31 December 2026 date. As at the date of this update no draft amending regulation has been identified. The Ministry's published position is clear, but the legal text has not yet caught up with it.

The Point Most Commentary Has Missed

Indefinite retention applies to the method, not to the individual credential. In its summary of the first post-implementation consultations, published in June 2026, the Ministry proposed setting a validity period for tokens of between one and 365 days, together with a new permission allowing a token to be renewed automatically.

The current rule, as stated in Part I of the manual, is that a token remains valid until it is revoked. If the consultation proposal is carried into the amending regulation, that changes: every token acquires an expiry date, and every integration needs a renewal mechanism. A business reading the aggregated coverage as confirmation that its existing token configuration can be left untouched is exposed to exactly the failure the sunset was expected to cause, simply on a different schedule.

Scope

• Applies to every taxpayer or service provider authenticating to KSeF 2.0, whether integrating from SAP directly or through a third-party access provider.
• Affects both authentication methods, since the change removes the forced migration from tokens to certificates that many groups had scheduled for the second half of 2026.
• Does not change the KSeF mandate dates, the invoice format, or the penalty regime commencing in 2027.

Timeline

• 12 December 2025 Regulation on the use of KSeF, Journal of Laws 2025 item 1815, sets 31 December 2026 as the end date for the alphanumeric string authentication method in paragraph 13(1)(1).
• 1 February 2026 KSeF 2.0 manual Part I still states that tokens expire at the end of 2026.
• June 2026 Ministry consultation summary proposes a token validity period of one to 365 days with automatic renewal.
• 7 August 2026  KSeF 2.0 manuals Parts I to IV published; Part I records the decision to retain tokens indefinitely.
• 1 September 2026 Certyfikaty KSeF guidance page modified to state the same position.
• 11 September 2026 KSeF 2.0 questions and answers page updated with a new question confirming tokens do not expire at the end of 2026.
• Outstanding amendment of the regulation. No draft identified as at 15 September 2026.

The Accompanying Manuals

The four KSeF 2.0 manuals published on 7 August 2026 are the Ministry's principal operational guidance. Part I covers starting to use KSeF, Part II covers issuing and receiving invoices, Part III covers additional functionality, and Part IV covers KSeF in local government units and VAT groups together with the remaining permission models. Part IV also covers tax representatives, court enforcement officers and enforcement authorities, public procurement, and the PEF and Peppol route. A fifth manual for non-governmental organizations, and separate user manuals for the taxpayer application and the mobile application, sit on the same download page.

Each of the four manuals states its legal position as at 1 February 2026, and none carries a version number, which makes the file name date the only reliable identifier. Businesses maintaining an internal document register should record the file name rather than a version.

Two Related Corrections

First, on the KSeF number in payment messages. The obligation to quote the KSeF number, including in split payment transfers, applies to payments made from 1 January 2027, under the new Article 108g of the VAT Act and the amended Article 108a(3)(3). Both the Ministry's questions and answers page and its dedicated guidance page on the KSeF number and the collective identifier state that date. Coverage in circulation that gives an August 2026 start date for this obligation is incorrect.

Under the Act of 5 August 2025 amending the VAT Act and certain other acts (Journal of Laws / Dz.U. 2025, item 1203), the obligation to include the KSeF number in the payment title (transfer message) for structured invoices was postponed to 1 January 2027, which is the currently binding deadline.

Second, on collective correction invoices. The Ministry confirms that a correction invoice must identify every original invoice it corrects, giving for each the number assigned by the taxpayer, the KSeF number and the date of issue. This is reflected in the FA(3) structure through the corrected invoice data element. This position is not new, but it remains a common source of rejection.

Required Actions

• Do not decommission token-based authentication or force a migration to certificates on the basis of the 31 December 2026 date. That migration is no longer required.
• Equally, do not assume the configuration is now stable. Design the integration so that a token validity period and an automatic renewal mechanism can be introduced without re-engineering, because the Ministry has proposed both.
• Inventory every KSeF token in use across the group, assign a named owner to each, and record which system and which Polish registration it serves. Groups with many registrations frequently cannot answer this question today.
• Watch for the amending regulation. Until it is published, the 31 December 2026 date remains in the legal text even though the Ministry has said it will not be applied.
• Confirm that payment file logic schedules the KSeF number requirement, including in split payment, for payments from 1 January 2027 and not earlier.
• Verify that collective correction invoices generated from SAP populate the corrected invoice data element for every original invoice, with taxpayer number, KSeF number and issue date.
• Record the KSeF 2.0 manual file names in the internal control documentation, since the manuals carry no version numbers.

Practical Implications

The immediate effect is a saving. A number of groups had scheduled a token to certificate migration for the fourth quarter of 2026, competing for the same resources as year-end. That migration can be canceled.

The second-order effect is less comfortable. The Ministry has removed a hard deadline and proposed a softer but more pervasive change in its place. A sunset is a single event that can be project-managed; a per-credential validity period with automatic renewal is an operational capability that has to exist permanently and be monitored. The second is cheaper to build early and expensive to retrofit.

More generally, this development illustrates why the Polish mandate has to be monitored at the level of the Ministry's own guidance pages rather than through summaries. The decision was made in a manual in August, restated on a guidance page in September, and restated again in a question added to a FAQ. None of those is a legislative act, none generated a press release, and the aggregated coverage attached it to a date on which nothing was published.

Expected Next Steps

The amending regulation is the instrument to watch. It will show whether the one to 365 day validity proposal has been carried through, and if so on what commencement date and with what transitional treatment for tokens already issued. KGT will report it when it is published. The Ministry continues to update the questions and answers page without separate announcement, so that page should be monitored directly.

How Can KGT Support You?

KGT delivers SAP-integrated electronic invoicing and statutory reporting. Our SAP add-on for KSeF manages authentication, session handling and certificate and token lifecycle alongside the production of the FA(3) structured invoice from SAP billing data, and reconciles the KSeF acknowledgment back to the SAP document so that the compliance record and the accounting record cannot drift apart. We maintain the add-on against each published API release and against changes in the Ministry's operational guidance.

For clients running SAP Document and Reporting Compliance we support scoping, configuration, country activation, credential governance across multiple Polish registrations, and the reconciliation controls between KSeF, JPK_V7M and the VAT return. Where a client is choosing between an add-on and a DRC country version, we give an even-handed assessment of which fits their landscape and release calendar.

This country update is provided for general information only and does not constitute tax, legal or professional advice.