KSeF Module Terms
Terms appendix for the KSeF module.
Updated / published: 09.02.2026
Appendix No. 1 to the Terms of Service / KSeF Module Terms
1. Scope
1.1. These Module Terms apply only to Clients who have activated or use the "KSeF" Module.
1.2. The "KSeF" Module is a technical integration enabling data exchange with the National e-Invoicing System (KSeF), in particular sending sales invoices, retrieving purchase invoices, checking document statuses and generating verification QR codes.
1.3. The Service Provider acts as a technical intermediary within the meaning of KSeF regulations. Operations in KSeF are carried out using the Service Provider's certificate, on the basis of permissions granted by the Client in KSeF in the context of the Client identifier.
1.4. The Module supports invoices compliant with the FA(3) KSeF schema within the functionality documented in the Service. The list of supported invoice types, fields and procedures is published and updated by the Service Provider in the Service documentation. Before sending invoices through the Module, the Client is obliged to verify whether its invoicing needs fall within the supported scope.
2. Permissions and Authentication
2.1. The Client is responsible for granting, maintaining and updating permissions in KSeF, including granting the Service Provider, identified by the Service Provider's NIP, the permissions necessary to perform operations within the Module.
2.2. Withdrawal or change by the Client of the Service Provider's permissions in KSeF immediately makes it impossible for the Module to perform operations. The Service Provider is not liable for the consequences of permission withdrawal during ongoing processes, including sending, retrieval or retransmission.
2.3. The Service Provider stores session and authorization data used by the KSeF integration, for example access tokens/session identifiers, in encrypted form (AES-256-GCM) and applies security standards appropriate for storing access credentials. Session/authorization data has a limited validity period; operations may fail if the session expires.
2.4. The Client acknowledges that the integration uses cloud infrastructure in which IP addresses, in particular outbound addresses, may change. If the Client uses IP allowlist-based restrictions (AllowedIps or an equivalent mechanism) within KSeF authorization mechanisms, operations may fail due to infrastructure address changes. The Client is responsible for ensuring that the KSeF configuration is compatible with the integration architecture, for example by ensuring fixed outbound addresses or updating the allowlist as needed.
3. Data Approval and Automations
3.1. The Service provides data preview before sending to KSeF. Triggering the "Issue/Send" action, or an equivalent action, means approval of the data for sending and constitutes the Client's consent to submit the document to KSeF.
3.2. Before sending, the Module converts invoice data to XML compliant with the FA(3) KSeF schema. The Client acknowledges that the conversion covers only fields and procedures supported by the current Module version, in accordance with section 1.4.
3.3. Deferred sending (queueing): if KSeF is temporarily unavailable or by the Client's decision, invoices approved for sending by the Client are queued and sent automatically after KSeF availability is restored, or according to the Client's instruction at the end of the business day. Approval of an invoice for sending by the Client constitutes consent both to immediate and deferred sending.
3.4. The Client acknowledges that the date an invoice is submitted to KSeF may differ from the date indicated by the Client as the issue date in the invoice data (XML). The KSeF number is assigned only when the document is actually accepted by KSeF. The Service Provider is not liable for delays in assigning the KSeF number resulting from KSeF unavailability or send queueing. The Client also acknowledges that, depending on the relationship between the date indicated in the invoice data and the date of submission to KSeF, the invoice may be classified as issued in OFFLINE mode within the meaning of KSeF regulations and rules.
3.5. Pro forma invoices are not sent to KSeF. The Module automatically rejects attempts to send pro forma invoices.
3.6. After an invoice is submitted to KSeF and accepted, the source XML data cannot be modified, in particular because consistency of the QR verification code must be maintained.
4. Automatic Retrieval of Invoices from KSeF
4.1. After activating invoice retrieval, the Module automatically retrieves, at regular intervals, purchase invoices issued to the Client's NIP from KSeF, including invoices in which the Client appears as an entity indicated in Subject1, Subject2 and Subject3 sections of the KSeF document.
4.2. Retrieved invoices are automatically converted from KSeF XML format into the Service's internal format and registered as purchase documents on the Client's account.
4.3. The Client is responsible for verifying the correctness of automatically imported purchase invoices, including their classification, contractor data and amounts.
4.4. Launching automatic invoice retrieval constitutes the Client's acceptance that documents will be created on the Client's account automatically, without individual approval of each invoice before import.
4.5. If the Client uses the preliminary verification function for purchase invoices ("Trusted contractors"), invoices requiring approval will be marked with an appropriate status. The Client is responsible for timely review and approval of such invoices.
5. Corrections
5.1. The Module enables generation of correcting invoices, including zeroing corrections, and sending them to KSeF.
5.2. The Client is responsible for verifying the correctness and justification of generated corrections, including zeroing corrections, before approving them for sending.
5.3. The Client acknowledges that after a document is accepted in KSeF there is no mechanism for withdrawing/deleting the accepted invoice; if necessary, correction is performed by issuing a correcting invoice in accordance with applicable law.
6. Retry Mechanisms and Error Handling
6.1. The Module uses automatic retry mechanisms for operations that failed for technical reasons, for example timeout or temporary KSeF unavailability.
6.2. Operations whose retry did not succeed after the retry limit is exhausted are routed to the dead letter queue (DLQ) and handled by the Service Provider's technical support team.
6.3. The Service Provider uses deduplication mechanisms intended to prevent duplicate submissions to KSeF. The Service Provider is not liable for duplicates resulting from unusual KSeF API behavior or edge cases in retry logic.
6.4. The Client is obliged to monitor invoice sending statuses to KSeF through the Service interface and to report detected irregularities to the Service Provider.
7. QR Codes
7.1. The Module may generate verification QR codes (or verification links) for invoices, to the extent and in cases required by KSeF regulations and rules, in particular for making an invoice available or using it outside KSeF.
7.2. For an invoice issued in ONLINE mode and made available or used outside KSeF, as a rule one QR code is generated to provide access to the invoice in KSeF and verify the data.
7.3. For invoices made available outside KSeF before submission to KSeF in OFFLINE modes within the meaning of KSeF rules, two QR codes may appear on the visualization: the first providing access to the invoice and data verification (OFFLINE), and the second for verification of the issuer's identity (CERTIFICATE), in accordance with KSeF rules.
7.4. The Service Provider is not liable for inability to verify QR codes resulting from KSeF unavailability or from conditions not being met on the Client's side, for example lack of data necessary for verification in a given scenario.
8. Data Storage and XML Files
8.1. The Module stores copies of XML files of invoices sent to and retrieved from KSeF in the Service Provider's cloud infrastructure.
8.2. XML files within the Module are stored for the duration of the Agreement, unless separate regulations provide otherwise.
8.3. Notwithstanding the above, the Client acknowledges that invoices in KSeF are stored in the KSeF system for the period provided by law, generally 10 years.
8.4. At the Client's request, the Service Provider will make available to the Client copies of stored XML files concerning the Client's invoices.
8.5. In the event of Agreement termination, the Service Provider will enable the Client to download stored XML files within a reasonable time before account deletion, in accordance with section XI of the Terms of Service.
9. Automatic Processes and Schedule
9.1. The Module performs the following automatic processes:
a) Incoming invoice retrieval - cyclically, at regular intervals;
b) Send status synchronization - cyclically, to verify assigned KSeF numbers and UPO statuses;
c) Retry of failed operations - cyclically, for invoices whose processing ended with an error;
d) Batch sending of pending invoices - once per day, or with another frequency resulting from configuration, for invoices approved for deferred sending (queued) or waiting to be submitted.
9.2. Launching the Module and activating relevant functions (sending/retrieval) constitutes the Client's acceptance of the above automatic processes and their parameters.
9.3. The Service Provider reserves the right to change the frequency and parameters of automatic processes to optimize Module operation, without degrading Service quality.
10. Liability
10.1. The Client is responsible for the substantive correctness of data and documents submitted to KSeF and the legality of their submission, including correctness of contractor data, amounts, VAT rates and procedure markings.
10.2. The Client is responsible for verifying whether invoice types and tax procedures used by the Client fall within the functionality supported by the current Module version, in accordance with section 1.4. The Service Provider is not liable for irregularities in KSeF documents resulting from the Client's use of unsupported invoice types or tax procedures.
10.3. The Service Provider is responsible for due technical diligence in integration, i.e. conversion, sending and retrieval of data according to data and processes accepted by the Client, within supported functionality and subject to the liability limitations in the Terms of Service.
10.4. The Service Provider is not liable for:
a) unavailability, errors or delays on the side of KSeF (the Ministry of Finance system);
b) errors in source data approved by the Client;
c) consequences of the Client withdrawing or changing the Service Provider's permissions in KSeF;
d) delays in sending invoices to KSeF resulting from KSeF unavailability or deferred sending (queueing);
e) duplicate documents in KSeF resulting from unusual KSeF API behavior;
f) irregularities resulting from the use of unsupported invoice types or tax procedures;
g) irregularities in automatically imported purchase invoices not verified by the Client;
h) consequences of the Client applying allowlist-based restrictions (AllowedIps or an equivalent mechanism) incompatible with the integration architecture.
11. Logs and Monitoring
11.1. The Service Provider keeps technical logs of integration operations for diagnostics, security and accountability.
11.2. The Service Provider monitors error queues (DLQ) and takes corrective actions in the event of persistent operation failures.
11.3. Periodic reports on unresolved processing errors are generated automatically and analyzed by the Service Provider's support team.
11.4. The Client may monitor KSeF operation statuses (sending, retrieval, errors) through the Service interface.
12. Module Changes
12.1. Changes to the Module Terms are subject to the rules in section XV of the Terms of Service concerning changes to Module Terms.
12.2. The Service Provider may expand the scope of supported FA(3) functionality without changing the Module Terms, provided the expansion does not restrict existing functionality.
12.3. If support for a specific invoice type or procedure is planned to be withdrawn, the Service Provider will inform Clients using that functionality at least 30 days in advance.