Poland is the fourth country in the European Union to introduce e-Invoice – API specification
The Polish Ministry of Finance on 20 October 2021 issued a specification for the National e-Invoicing System (NeIS), providing tips for software developers wishing to integrate their programs with NeIS (API). This specification is not a source of law, but is only a set of guidelines for developers. The NeIS test environment website (https://ksef-test.mf.gov.pl/) does not contain a graphical user interface for uploading or downloading invoices. It contains material intended for IT departments working on integration with NeIS. This address is also used by the published API. The logical structures used by the API, the OpenApi (formerly Swagger) documentation and editor, and the test environment public key have been made available. For the time being, no descriptive interface specification has been published, as was the case for e-Declaration or the Single Control File. It has been indicated that the test version will use self-generated signatures and seals for authorisation in NeIS, the test version does not offer authorisation via the Trusted Profile and token at this point. Invoices will be submitted using the API provided in batch or interactive mode. An Official Delivery Certificate will be available with a list of invoices sent in a batch packet or during an interactive session. The provided service will verify the correctness of the sent invoices with the working version of the XSD schema. The API introduces permissions that can be assigned to a system user. A privilege management facility is provided that will allow to view, grant and revoke privileges. The types of roles available in the process are also indicated. It is worth noting that the message states that it is planned to make the use of e-Invoice mandatory for entrepreneurs in Poland from 2023.
Authentication and authorisation
Among the methods of authenticating the user of the National e-Invoice System the following are distinguished: Trusted Profile, qualified signature, qualified signature without the Tax Identification Number or Polish Social Identification Number attribute, qualified seal and a one-time token assigned to the taxpayer, entitled entity and possessed permissions. All these methods are based on qualified sources. Among these methods there are authentication vectors based on asynchronous vectors, where authentication occurs as a result of correct certificate qualification (e.g. signature and qualified seal), and synchronous vectors, where identity confirmation is implicit due to trust in the system (e.g. trusted profile, authorisation token). An authenticated user by means of authorisation is granted access to services in the correct context (i.e. the entity and its identifier to which all operations in the system apply). Authorisation is based on the context (e.g. Tax ID.) and the authentication vector. Authentication results in contexts being made available according to roles: owner (company owner), invoice read/write (e.g. company employee, accounting firm), credentials read/manage (e.g. company employee), tax representative (company tax representative), self-invoicing (e.g. company enabling the other company to self-invoice), bailiff, enforcement authority, enforcement operations (company employee). Each of these entities can only perform the operations that are assigned to its role(s). One role can be assigned to many entities and one entity can have many roles. A user who has one of these roles may perform and authorise his operations. Establishing an interactive session is possible for users with the owner or invoice record role. To issue a standard invoice, it is necessary to have one of these roles. Self-invoicing requires the self-invoicing role in addition to having these roles. To issue an authorised invoice, on the other hand, you need the enforcement operations or owner role and the bailiff or enforcement flag assigned by the office. The owner or invoice reading role is required to retrieve the invoice and to assign and read the payment identifier.
Security
According to the project, the communication is to be encrypted in two levels by means of the TLS protocol, which is active independently of the interface, and additional encryption in the form of a symmetrical AES key and its encryption by the RSA System public key. In addition, a cryptographic declaration will always be an additional security measure when sending an invoice and optionally in the case of an interactive session. For data transmission between the user and the system, the HTTP protocol and the REST protocol based on it are used. The transport layer is secured by the TLS 1.2 protocol. Data is sent in JSON, octet stream and XML formats. Invoice packets are sent in ZIP format.
Batch dispatch, general operations and interactive session
Batch dispatch is a series of operations and a process that allows you to issue multiple invoices at once. It also allows you to bypass the invoice document size limitation that exists with an interactive session. The process is atomic by default, which means that all documents must be correct and accepted before sending, otherwise the whole package will be rejected. Any authentication vector is required for this operation except for the authentication token and the certificate fingerprint. For this process to be possible, at least one invoice document must be ready to be sent and one part of the package after compression must not exceed 50 MB. The archive can have a maximum of 100 elements. General operations in NeIS allow access to the system without authentication, for example to check the status and to receive an Official Delivery Certificate without establishing an interactive session. The interactive session and interactive interfaces are used for e.g. credential management, fast dispatch and access to invoices. Unlike batch dispatch, an interactive session sends and accepts one invoice at a time. So one incorrect invoice won’t cause other, valid invoices to be rejected. Once the session is closed, the user receives a list of accepted invoices along with the Official Receipt. The session is established in the taxpayer context and it is not possible to change the context during the session.
Test version
Prior to the launch of NeIS, the system was made available in test access at https://www.podatki.gov.pl/ksef/strefa-testowa-ksef/. The test access made it possible to learn how to use the system without any legal consequences. It also served the purpose of detecting and eliminating possible errors already at the testing stage, so that the system would be ready for launch on 1 January, 2022. From that date, it will be possible to issue structured invoices using the system. According to the plans, it will be obligatory to issue invoices using this system from the beginning of 2023.
Summary
The NeIS system, as indicated, should be secure at many stages of both the creation, sending and receiving of an invoice. The ability to obtain an Official Delivery Certificate provides assurance that invoices issued by company employees have reached the office and have been correctly issued. Invoice dispatch and creation are possible through batch dispatch and an interactive session. In order to use the system to view, search, issue and send invoices, it is necessary to have one of the above-mentioned authentication vectors and to be granted one or more roles by the office.
The process of issuing and delivering a structured invoice using the NeIS system. Own preparation.
The test access and optionality of invoicing with NeIS is intended to prepare entrepreneurs, but also developers handling large-scale accounting processes, for the introduction of the structured invoice as a obligatory form in 2023.
Sources
- https://ksef-test.mf.gov.pl/
- https://www.podatki.gov.pl/ksef/strefa-testowa-ksef/
- Interface specification of the National e-Invoice System (NeIS) issued by the Ministry of Finance on 20 October 2021.
