KSeF legislative marathon at the finish line

After years(!) of work marked by long periods of downtime and uncertainty, but also sudden twists and turns, it seems that the finish line of the legislative marathon entitled the mandatory KSeF is finally in sight. Let us recall that the first drafts envisaged the entry into force of the mandatory KSeF on 1 January 2024, later the date was postponed to 1 July 2024, and after a change of government and an audit of the system, which resulted in the need to create it from scratch, the date was postponed to 1 February 2026. During this time we had quite extensive consultations on the assumptions of the bill, subsequent versions of the drafts, or structured invoice schemes.

Parliamentary work

Currently, the draft defining the shape of the mandatory KSeF is being processed in the Sejm. On Wednesday 9 July, the first reading of the draft took place, after which it went to the public finance committee on the same day. Anyone expecting any significant changes at the parliamentary stage will be sorely disappointed. Practically all the amendments tabled in committee were of a legislative, editorial or clarifying nature. The only substantive change that was considered concerned the notification of the intention to use an attachment to a structured invoice, specifically the introduction of an indefinite possibility of using this solution instead of the necessity to renew this entitlement periodically, as provided for in the draft submitted to the Parliament.

Unfortunately, the most problematic issue in the form of the offline24 mode was discussed only perfunctorily and no proposals for changes or clarifications were made to dispel the numerous doubts related to the use of this mode.

However, the KSeF is not only about the rules themselves, but also about the technical solutions, and in this aspect there have also been several recent innovations.

Technical documentation

In accordance with the work schedule planned by the MF, a set of information concerning the API environment was published on the MF website on 30 June. Here, most commentators agree that the changes in the way the technical specification information is presented have gone in the right direction. The published material is clear, with numerous examples including code snippets illustrating the use of particular methods. A big plus is certainly that the material is made available on the github platform, which is used by developers in their daily work and therefore more user-friendly than the previous ‘interface software specifications’.

As for the solutions themselves, for taxpayers, information on KSeF certificates to mark invoices ‘offline’, but also to authenticate in the system, is certainly key. It is not yet clear how many certificates will be able to be generated and how exactly the process will work – we will probably find out at the end of September with the release of the test environment.

Important changes from a technical point of view are also planned for the dispatch of invoices, namely the dispatch of packages (so-called batch dispatch). Until now, the risk that an entire batch of invoices would be rejected if even one incorrect invoice was found in a batch was a deterrent to this mode of sending invoices. With the changeover to the new API, this is about to change and only the wrong invoices will be rejected, while the rest of the packet will be accepted by KSeF.

Despite the many pluses of the new API approach, one big minus still remains, namely the deadline for the release of the test environment, which, as I mentioned, is planned for 30 September 2025. Thus, from July to the end of September, taxpayers can create mock-ups or prototypes of solutions, but it will not actually be possible to verify and test them until October.

Schema FA(3)

Alongside the API documentation, the final version of the e-invoice schema, version FA(3), was also published. Compared to the draft version presented in May, there are no major changes, but compared to version FA(2), there are slightly more changes and it is worth devoting a separate entry to them.

What seems to me to be the most significant in terms of schema is of course the addition of an attachment node, allowing more complex data on transactions to be transmitted in a structured way, with a certain degree of freedom in its design.

It is also worth noting some changes in the design of individual elements, such as the payment deadline or defining VAT rates, where several types of rates have appeared, e.g. and 0%, which may require additional data mapping or supplementing in the organisation’s field systems.

Summary

The recent intensification of work indicates the Ministry’s determination to meet the deadline and launch the mandatory KSeF in February 2026. According to the schedule, the legislative stage was supposed to end in July and there are chances that this will happen, although, looking at the calendar of the Sejm and Senate sessions, it is still possible to slip and effectively finish the work in August – the last sessions are scheduled for 5 and 7 August. If the legislation has not been passed by both chambers by then, the next opportunity will not be until September, which would already mean very little time for taxpayers to do preparatory work. In my opinion, there is no point in waiting until the legislation is finally passed and it is better to start preparing in the company now.