KSeF offline24, unavailability, and outages in Poland

How offline24, KSeF unavailability, and an outage differ: invoice submission deadlines, two QR codes, a type 2 certificate, and a business procedure.

KSeF provides several procedures for issuing invoices without a live connection to the system. They are not equivalent. Offline24, announced unavailability, and a declared outage have different conditions and, above all, different deadlines for submitting documents later.

Three deadlines and a separate total outage procedure

The main rule is that invoices issued under offline24, unavailability, and an ordinary outage must ultimately be submitted to KSeF. The deadline depends on the procedure:

offline24 — without delay, and no later than the next business day after the date of issue,
KSeF unavailability — no later than the next business day after the unavailability period ends,
KSeF outage — within 7 business days after the outage ends.

Do not try to remember one general “later” deadline. The accounting system should record which procedure was used, when the invoice was issued, and which event starts the submission deadline.

A total outage announced by the Minister of Finance through the mass media is a separate procedure. Invoices are then issued on paper or electronically, do not have to comply with FA(3), carry no QR codes, and are not submitted to KSeF after the event ends.

The guide KSeF for a JDG in Poland in 2026 explains the fundamentals of KSeF and the timetable for the mandate.

Offline24 does not require an outage announcement

Offline24 can be used when the business does not have a live connection to KSeF, for example because of an internet problem, mobile work, or a brief interruption in its own software. Official answers from the Ministry of Finance state that the taxpayer does not have to provide additional proof that internet access was unavailable. The procedure may also be used when no such limitation exists.

This does not, however, allow submission to be postponed indefinitely. The document must comply with the current structured invoice schema and then be submitted to KSeF without delay, no later than the next business day after it was issued.

If an invoice is issued on Friday, the deadline will generally move to the next business day. In practice, the software should calculate it with weekends and public holidays taken into account. Do not rely solely on a manual reminder from the accountant.

KSeF unavailability

Unavailability means a period when KSeF is not operating, for example because of planned maintenance announced by the Ministry of Finance. During this period, a business can continue issuing documents outside the system and submit them later.

The deadline is not calculated from the date of each invoice but from the end of the announced unavailability period. The invoice must be submitted no later than the next business day after the unavailability ends.

The business procedure should record the source of the announcement, the start and end times of the unavailability, and the list of invoices issued during that period. This makes it possible to reconstruct why a document was not submitted online and calculate the deadline correctly.

An outage declared by the Ministry of Finance

The outage procedure applies to a KSeF outage declared through the designated channels, including the Ministry of Finance’s Public Information Bulletin (BIP) and interface software. Do not confuse this with a failure of the business owner’s laptop, router, or software. Problems on the business’s side will normally require offline24, not the seven-business-day outage deadline.

After the declared outage ends, invoices issued under this procedure must be submitted to KSeF within 7 business days. The longer deadline should not be an excuse to leave the entire batch until the last moment. Once the system is restored, queues, validation errors, or the need to correct a file may arise.

A good approach is to submit documents in batches and check statuses every day. A software message saying “sent” does not prove that the document was accepted. Once processing succeeds, retain the KSeF number and UPO.

Two QR codes before the invoice is submitted

Whether two codes are required depends on the procedure and the type of buyer. Under offline24 and during unavailability, an invoice can be provided outside KSeF before submission to buyers specified in Article 106gb(4) of the VAT Act, including a foreign entity, a consumer, or a buyer without a NIP. That visual representation has two QR codes. Before a KSeF number is assigned, a domestic taxpayer with a NIP may receive a transaction confirmation; as a rule, the actual invoice is delivered to that buyer through KSeF.

During an announced ordinary KSeF outage, the invoice is provided outside the system and two QR codes are used. This rule does not apply to a total outage, when no QR codes are added.

The first code is marked OFFLINE. It is used to verify invoice data and provide access to the document. The second is marked CERTYFIKAT and confirms the issuer’s identity.

Two codes are required because the invoice does not yet have a KSeF number. The recipient should be able to verify both the document data and the identity of the entity that issued it.

Date of issue and receipt

Under offline24, unavailability, and an ordinary outage, the date of issue is the date entered by the seller in field P_1. The date of receipt depends on the procedure and the buyer’s status.

Under offline24 and during unavailability, a domestic taxpayer with a NIP receives the invoice on the date on which it is assigned a KSeF number. A buyer covered by Article 106gb(4) receives it on the date it is actually provided outside the system. During an ordinary outage, special rules compare the date of actual delivery with the date on which the KSeF number is assigned. During a total outage, the date of receipt is the date on which the document is actually received.

The situation changes once the invoice has been submitted to KSeF and assigned a number. A visual representation used outside the system then needs only one QR code linked to the KSeF number. The second code confirming the issuer is no longer needed because the document has been accepted by the system.

Type 2 KSeF certificate

Generating the second QR code marked CERTYFIKAT requires a previously obtained type 2 KSeF certificate, intended for issuing invoices under special procedures and confirming the issuer’s identity.

Do not wait until the connection is lost to arrange the certificate. The business should obtain it in advance, check its validity, and test the generation of a correct visual representation. It should also specify who stores the certificate and how it is protected against unauthorized use.

This is particularly important in accounting firms and businesses with multiple sales workstations. Permissions to act on the taxpayer’s behalf and the technical use of the certificate must match the adopted access model. The article KSeF permissions for an accountant and accounting firm explains this in more detail.

What to record when issuing an invoice offline

Every document should leave a clear operational trail. Retain:

your own invoice number and the date of issue,
the procedure used,
the date and time when the file was created,
the logical schema version,
information about delivery of the visual representation to the buyer,
the markings and QR codes used,
the submission deadline calculated for the relevant procedure,
the submission status, KSeF number, and UPO after acceptance.

If KSeF rejects a file for technical reasons, an attempted submission alone cannot be treated as preserving the deadline. You must identify the error, correct the document in accordance with the rules for the case, and resubmit it. Checks should therefore take place before the deadline expires, not afterwards.

An emergency procedure for a small business

A simple instruction may consist of a few steps. First, the employee checks whether the problem concerns local internet access or software, unavailability, an ordinary outage, or a total outage announced by the Minister of Finance. The employee then selects the correct procedure. Under offline24, unavailability, and an ordinary outage, they create an invoice compliant with FA(3); a total outage follows separate rules.

If the invoice is provided outside KSeF before submission for the relevant procedure and buyer, the software generates the two correct QR codes using a valid type 2 certificate. In other cases, a domestic taxpayer with a NIP may receive a transaction confirmation. The invoice enters a submission queue with a specific deadline. Documents issued during a total outage do not enter that queue because they are not submitted to KSeF later.

A backup person should also be designated. If the only person with access is absent, the business must still meet the deadline. Permissions and certificates should be prepared to maintain continuity without sharing the business owner’s private signature.

Most common mistakes

The first mistake is applying the seven-business-day deadline to every technical interruption. That deadline applies to a declared outage, not an ordinary loss of internet access at the business. The second is calculating the unavailability deadline from the invoice date rather than from the end of the unavailability.

Another mistake is applying one QR-code rule mechanically to every buyer and every procedure. Two codes are used only where the rules provide for an invoice to be delivered outside KSeF; a transaction confirmation and a total outage work differently. It is also risky to obtain a type 2 certificate only when a problem occurs or to treat an attempted submission as equivalent to invoice acceptance.

A good procedure distinguishes between event types, calculates deadlines automatically, and requires verification of the UPO. This allows special procedures to maintain sales continuity instead of creating a backlog of unconfirmed documents.

KSeF offline24, unavailability, and outages in Poland — deadlines and QR codes

When an invoice cannot be sent to KSeF in Poland

offline24

Unavailability

Failure

Total outage