KSeF offline and emergency mode: what your system must handle

KSeF emergency mode is the procedure for a failure of KSeF, Poland's National e-Invoicing System, announced by the Polish Ministry of Finance (MF): you issue an electronic invoice in the FA(3) structure, deliver it to the buyer in the agreed way and send it to KSeF within 7 working days of the end of the failure. Besides emergency mode, the regulations provide for three other arrangements: offline24 mode, offline mode during KSeF unavailability (e.g. during maintenance work) and total failure, during which invoices are not sent to KSeF at all.

For your system, this means a specific list of tasks: the issue date, two QR codes and the offline certificate, a queue with submission deadlines, rejection handling, numbering, and purchase invoices received outside KSeF. This article is based on the legislation and Ministry of Finance materials; it is not a description of a client implementation.

Which modes apply when KSeF is unavailable?

The regulations provide for four modes. The Ministry of Finance describes the first three as “in essence a single offline mode”: an electronic invoice in the FA(3) structure that is sent to KSeF later. In a total failure, invoices are issued and delivered entirely outside KSeF.

• Offline24 does not require proof that the internet was down. If the problem is on your side, or KSeF is responding slowly and the Ministry of Finance has not announced anything, you are left with offline24 — which has the shortest deadline.
• A notice about disruptions does not mean unavailability or a failure. You can use offline mode during KSeF unavailability and emergency mode only within the period announced by the Ministry of Finance.

BIP is the Ministry of Finance's Public Information Bulletin (Biuletyn Informacji Publicznej), and the KSeF interface software in practice means the KSeF API (the Ministry refers to its specification in the KSeF API 2.0 technical documentation).

How does your system know that the Ministry of Finance has announced unavailability or a failure?

Deadlines are counted from the end of the announced period, so the system has to know the dates given in the Ministry of Finance announcements in the BIP and in the KSeF API. The system status is also published by Latarnia KSeF — a public Ministry of Finance interface that is independent of KSeF and requires no login (https://api-latarnia.ksef.mf.gov.pl/), which, according to the Ministry, accounting software can integrate with. GET /status returns AVAILABLE, MAINTENANCE, FAILURE or TOTAL_FAILURE, and GET /messages returns announcements, which remain available for 30 days after the event ends. Your system should:

• poll Latarnia and show the KSeF status to the person who issues invoices;
• record announcements (type, start, end) against the invoices from that period — so that it is clear why an invoice was issued in a given mode;
• switch modes only after a Ministry of Finance announcement, not after the first connection error — until then, treat an invoice issued without a connection to KSeF as issued in offline24 mode.

How do you issue an invoice in offline mode: the date, QR codes and the certificate?

The issue date and midnight

In the three offline modes, the issue date is the date in the P_1 field (the issue date in the FA(3) structure). An invoice sent as “online” (offlineMode: false) that KSeF accepts for processing on a later day than the day in P_1 is treated as an offline24 invoice — KSeF will mark it as offline itself. In an interactive session, KSeF treats the moment the invoice is sent as the moment of acceptance; in a batch session, the moment the session is opened. The rule for your system: send an invoice with the current date in P_1 before midnight (in a batch session it is enough to open the session before midnight), or treat it as an offline24 invoice from the outset.

Two QR codes

An offline invoice delivered to the buyer outside KSeF before it receives a KSeF number carries two QR codes:

• CODE I — access to the invoice in KSeF and verification of its data, with the label “OFFLINE”. The link contains, among other things, the seller's tax ID (NIP), the date in P_1 and the SHA-256 hash of the XML file.
• CODE II — confirmation of the issuer's identity, with the label “CERTYFIKAT” (Polish for “certificate”); the link is signed with a KSeF certificate.

Your system generates the codes locally, every time it creates a visualisation of the invoice (e.g. a PDF or a printout). Once the invoice has a KSeF number, its visualisation delivered outside KSeF carries only one QR code, with the KSeF number underneath.

CODE I contains the hash of the XML file, so the system should save the file as it was at the moment of issue and send exactly that file to KSeF. Any change, even to the file creation date alone, produces a different hash from the one in the code the buyer already has. The exception is a technical correction, described below. We described how the links are built in our article on the KSeF API for developers (in Polish).

KSeF certificate for offline mode

Generating CODE II requires a type 2 (offline) KSeF certificate, which is issued separately from the certificate used for logging in — a single certificate cannot serve both purposes. It is valid for no more than 2 years, and once revoked it cannot be used again. The certificate is issued either to a person or to a company. A company certificate is not linked to a specific person, so the company is responsible for it: according to the Ministry of Finance, it should keep a record of who downloaded it, who it was handed to, who used it and when it was revoked. The system needs access to the private key it uses to sign CODE II, and it should warn you before the certificate expires.

How and to whom should you deliver an invoice before it is assigned a KSeF number?

A transaction confirmation is an optional document that is not an invoice. It contains the details of the parties, the invoice number (P_2), the total amount due (P_15) and two QR codes with the captions “sprawdź fakturę w KSeF” (“check the invoice in KSeF”) and “zweryfikuj wystawcę faktury” (“verify the invoice issuer”) above them. With it, the buyer can check, among other things, whether the invoice has already been sent to KSeF. In a shop or at a petrol station (the Ministry of Finance's examples), the system should print it using a separate template.

The mode also determines the date on which the buyer receives the invoice. In offline24 mode and during KSeF unavailability, a VAT taxpayer (active or exempt) receives the invoice on the day it is assigned a KSeF number. In emergency mode, the date of receipt is the day the invoice is actually received or, if the KSeF number was assigned earlier, the day the number was assigned. For buyers under Article 106gb(4) to whom the invoice was delivered outside KSeF, the date of receipt is the day they actually receive it.

Note: the “only through KSeF” rule during unavailability is stated by the Ministry of Finance; Article 106nh(4) of the Polish VAT Act does not currently refer directly to Article 106nda(3). A Polish government draft act is intended to correct this cross-reference “due to a legislative error”; as at 29 October 2026, the draft is already in the Sejm (print no. 3245).

How do you keep track of the deadline for sending invoices to KSeF?

Every offline invoice goes into a queue with its mode and a deadline counted from the relevant event:

• Offline24. The next working day after the day of issue.
• Unavailability. The next working day after the day it ends.
• A failure in the meantime. If the Ministry of Finance announces a failure before you send an invoice issued in offline24 mode or during KSeF unavailability, you have 7 working days from the end of that failure. If the Ministry announces another failure within those 7 days, the deadline runs from the end of that subsequent failure.
• Total failure. If the Ministry of Finance announces one before the invoice reaches KSeF (for unavailability and emergency mode — before the submission deadline expires), the invoices no longer have to be sent: the VAT Act expressly lifts the obligation to send them (Article 106nha point 2, Article 106nh(3) point 2, Article 106nf(7)). The system must be able to exclude such invoices from sending.

When invoices are sent to KSeF later, you declare OFFLINE mode (offlineMode: true); the sender must be authenticated and authorised to issue invoices. A correcting invoice issued in offline24 mode must also be sent without delay, and no later than the next working day after the day it was issued.

The queue should have:

• a deadline for each invoice and a notification to the person responsible before it passes;
• automatic retries using the same saved XML file;
• a report of invoices without a KSeF number at the end of the day;
• an editing lock on an invoice waiting to be sent — changing its content means a correcting invoice, issued after the number has been assigned.

An offline24 invoice, an invoice from a period of unavailability or an emergency-mode invoice that is not sent on time is one of three situations that carry penalties — we described them in our article on KSeF penalties from 2027. Under the current rules, penalties apply from 1 January 2027. On 20 October 2026, the Polish government adopted a draft act that would postpone them until the end of 2027 (penalties from 1 January 2028). Status as at 29 October 2026: the draft is already in the Sejm (print no. 3245); after the first reading on 21 October 2026, it was referred to the Public Finance Committee, and the act has not been passed. Until the amendment has passed through the Sejm and the Senate, been signed by the President, been published in the Journal of Laws (Dziennik Ustaw) and entered into force, the current rules apply, and the KSeF obligation itself does not change.

We described how error handling and emergency mode fit into the project as a whole, from reviewing your systems to deployment, in our article on integrating KSeF with your own system, shop or ERP.

What should you do if KSeF rejects an offline invoice on submission?

An offline invoice may already have reached the buyer when KSeF refuses to accept it on submission, e.g. because it does not conform to the schema. For this case, the Ministry of Finance has provided for a technical correction: resending a corrected XML file without changing the content of the invoice.

• For technical errors: non-conformity with the schema, an exceeded file size, a duplicate or another technical validation error that prevented the invoice from receiving a KSeF number. It does not cover cases where the entities on the invoice lack permissions (e.g. self-billing, local government units, VAT groups), and it is not allowed once another valid correction has already been accepted (error codes 21166 and 21167).
• Interactive session only. It applies to invoices rejected in either type of session, but it is sent only interactively, with offlineMode: true and the hashOfCorrectedInvoice field, i.e. the SHA-256 hash of the rejected file.
• The old QR code still works. KSeF links the corrected invoice to the original one, so CODE I from the first version leads to the corrected invoice.

So the system needs a saved hash of every file sent, a distinction between technical errors and permission errors (the latter must be handled by a member of staff), and the ability to send in an interactive session. The Ministry of Finance sources we reviewed do not say explicitly whether a technical correction has to be sent within the submission deadline that applies to the given mode, so the system should show the rejection immediately to the person responsible for the queue.

Numbering, duplicates and corrections: what should you watch out for with offline invoices?

• A unique number within a NIP. KSeF rejects a file as a duplicate (code 440) when the seller's NIP, the invoice number (P_2) and the invoice type are the same as in an invoice already accepted, and it enforces this for 10 years. Branches and other units that issue invoices on behalf of the same company (with the same seller NIP) must agree on numbering rules — in offline mode they work without contact with KSeF. When a send is retried after a dropped connection, code 440 may mean that the first attempt succeeded.
• Order of numbers. KSeF accepting invoices in a different order from the numbering, e.g. after a file has been rejected, is not a reason to reject the invoice or to issue a correcting invoice to fix the number, provided that sequential numbering was kept when the XML files were prepared.
• A lost invoice. If an offline24 invoice or an invoice from a period of unavailability, delivered outside KSeF to a buyer under Article 106gb(4), is lost or destroyed before it is sent to KSeF, it is reissued with the same data; the reissued invoice may contain the issue date and the word “DUPLIKAT” (“duplicate”). In emergency mode, the seller can also, at the buyer's request, make the same invoice available again if it has not yet reached KSeF — so the system should be able to make the saved file available again.
• Correcting invoices only after the KSeF number is assigned. A correcting invoice for an invoice from the offline modes is issued after the original invoice has been assigned a KSeF number, and it states that number.

How do you receive a purchase invoice issued in KSeF emergency mode?

In emergency mode, a supplier can deliver an invoice to you outside KSeF, as a PDF or a printout with the “OFFLINE” and “CERTYFIKAT” codes; once it has been sent to KSeF, it receives a KSeF number and the seller does not have to deliver it again. KSeF does not send notifications about new invoices, so your purchasing software has to poll it itself. It should also:

• accept an invoice from outside KSeF flagged as “waiting for a KSeF number”, and not post it a second time when it appears in KSeF;
• match it automatically to the invoice from KSeF by the SHA-256 hash of the file: CODE I contains it in Base64URL format, and the invoice metadata in KSeF contain it in Base64 (invoiceHash), alongside the mode (Offline) and, after a technical correction, the hash of the original file (hashOfCorrectedInvoice); as a fallback, by the seller's NIP, the number and the date;
• set the date of receipt according to the rules described above. An example from the Ministry of Finance manual (the failure described in it is hypothetical): an invoice issued during a failure on 6 November 2026 received its KSeF number on 12 November, and the printout reached the buyer by post on 13 November, so the date of receipt is 12 November 2026;
• not block payment for an emergency-mode invoice — from 1 January 2027, an active VAT taxpayer paying another active VAT taxpayer by bank transfer provides the invoice's KSeF number or a collective identifier (Article 108g of the Polish VAT Act). The obligation covers structured invoices as well as offline24 invoices and invoices from a period of unavailability (except those not entered into KSeF because of a failure announcement), but according to the Ministry of Finance it does not apply to emergency-mode invoices (Article 106nf). So the system should distinguish the invoice's mode and not hold back a transfer just because an emergency-mode invoice does not yet have a KSeF number.

We described the other stages of receiving purchase invoices in our article on importing purchase invoices from KSeF.

How can you check whether your system and procedure are ready?

Write the procedure down before you need it. It should set out at least:

• who decides on switching to a mode and who checks the Ministry of Finance announcements or Latarnia;
• where the offline certificate is kept, who uses it and when it expires;
• who watches the queue once KSeF is working again and receives a notification before the deadline;
• a template for a total failure — a paper or electronic invoice that does not have to follow the FA(3) structure, without QR codes and outside the sending queue;
• agreed channels for buyers for emergency mode.

Test in the KSeF test environment (it has its own address for QR codes; Latarnia also has a test environment): an invoice dated the previous day, a PDF with two codes, later submission, a rejected file and a technical correction, a retry with code 440, and the response to each Latarnia status. Ask the vendor of your off-the-shelf software whether it supports all of this.

If your invoices are created in your own system, shop or ERP, handling emergency mode is part of the scope of KSeF integration. The cost is the number of hours times €46 net (excl. VAT). As a rough guide: sending invoices to KSeF — 24–60 hours, i.e. €1,100–2,750 net (excl. VAT); receiving purchase invoices, including the connection to KSeF — 38–100 hours, i.e. €1,750–4,600 net (excl. VAT); the full receiving package with a second channel for invoices from outside KSeF and an archive — 78–202 hours, i.e. €3,600–9,300 net (excl. VAT). Sending and receiving are one project (shared authentication and error handling); for the whole project you need to add 12 to 24 hours for architecture, logging and deployment. This is an illustration, not an offer: the cost calculator will show an indicative price range, and we give specific price ranges within 2–3 working days of reviewing your systems. We transfer full intellectual property rights to the code and design to you once all stages have been accepted and all invoices paid.

Euro amounts converted at the NBP mid-market rate of 14 September 2026 (€1 = 4.3391 zł) and rounded. We invoice in PLN.

CodePort does not advise on tax matters. Confirm the scope of your company's obligations with your accountants, and we will take care of the technical side.