Process Description Poland

Introduction

On 1 February 2026, Poland will make a second attempt to introduce the obligation to send and receive electronic invoices in Poland with KSeF 2.0. KSeF 2.0 will change some technical processes, but the basic principle of a central reporting office for invoices will remain the same. This means that all invoices will be sent and received via the KSeF API. The XML format FA(2) will be replaced by FA(3), which offers several new features, such as the option to attach supplementary files.

Legal information

Retarus strongly recommends consulting a local tax advisor regarding tax law issues. The information provided here is not guaranteed.

Outbound invoices

The outbound transfer of invoices is divided into several steps, which are described below.

Step 1: Creation and transmission

The Retarus customer creates an electronic invoice in their ERP system and sends it to Retarus in an internal (and documented) format (source format). Attachments can be transmitted if this is documented (Base64 encoded). The transmission protocol can be selected from a variety of existing standard protocols (such as tRFC, AS2 or SFTP).

Step 2: Data processing and KSeF transfer

Retarus converts the source format into the required XML target format FA(3). The resulting XML document is validated in a further step. The currently valid Schematron of the Polish authorities is used for this purpose. If the check fails, the invoice is not sent. A verification report is generated and sent to the customer via email. If the verification is successful, the electronic invoice is transmitted to KSeF via the KSeF API.

If the KSeF system is temporarily unavailable, attempts will be made to resend the invoices for a certain period of time. The transmission of the status feedback (UPO) may therefore take longer. Offline mode will not be used.

Step 3: Status feedback UPO

After a successful transfer, Retarus requests or retrieves the status message (UPO) for each invoice via the KSeF API. The status message contains important information that the Retarus customer must retain (you can obtain information relevant to tax law regarding the handling of the UPO/KSeF ID from your tax advisor).

Step 4: Archive

Retarus then transfers the source and target documents, as well as the corresponding UPO file (in the original), to a Retarus SFTP server. The customer is given access to this server and can retrieve these documents for further processing within 30 days before they are automatically deleted

Inbound invoices

Receiving invoices involves several steps, which are described below.

Step 1: Retrieve invoices

Retarus checks at regular intervals via the KSeF API whether new incoming invoices are available. If so, the XML is retrieved via the KSeF API.

Step 2: Data processing

Retarus converts the FA(3) XML invoice into the required in-house format and then transmits the document to the customer's system using the agreed protocol.

Step 3: Archive

Retarus then transfers the source and target documents to a Retarus SFTP server. The customer is given access to this server and can retrieve these documents for further processing within 30 days before they are automatically deleted.