Automatic KSeF Resubmission After an Outage: How Biurko Handles It

Friday, 4:40 PM. You issue the last invoice of the week and the KSeF gateway stops answering. The invoice is legally valid from the moment it is issued, your customer receives it, but a clock has started: under Article 106nda of the Polish VAT Act, an offline24 invoice must be transmitted to KSeF without delay, at the latest on the next business day.

In practice that means Monday, 11:59 PM. Unless the Ministry of Finance declares a system failure and the deadline shifts. Unless Monday is a public holiday. Unless you simply forget, because on Monday morning one Friday invoice is not the first thing on your mind.

Under the current act, penalties under Article 106ni of the VAT Act apply from 1 January 2027. On 16 September 2026 the Ministry of Finance announced it will move them to 1 January 2028; that is a bill not yet passed, and it moves only the penalties, not the obligation to use KSeF. This article explains why watching an offline queue should not be a human job, and how Biurko removes it.

The deadline does not start when you remember it exists

KSeF's special modes run on different clocks. That is where most mistakes come from: in a user interface they look identical, but in the VAT Act they are four separate provisions.

Two things worth internalising. First, "offline24" does not mean twenty-four clock hours. An invoice issued on Friday evening is due by the end of Monday, and if Monday is a holiday, the next working day after that. Second, for downtime and failures the clock runs from the end of the outage as announced by the Ministry, not from the invoice date. If downtime lasted three days and you issued 60 invoices during it, all 60 share a single deadline.

Humans are bad at tracking that. Schedulers are good at it.

Biurko notices the outage before you do

The app does not wait for you to hit "send" and watch it fail. Every call to the KSeF gateway is observed. When the gateway returns three errors within 60 seconds, Biurko sends new submissions in that environment to offline24 mode. On top of that, every 5 minutes it reads the Ministry notices about downtime, failure and total failure (the "Latarnia" feed) and picks the mode and the deadline accordingly.

The threshold is deliberately forgiving. A single 5xx cannot be allowed to switch an entire company into offline mode, because the gateway will happily throw a random timeout and recover a second later. Only a repeated pattern counts as a signal.

Detection is per environment. A production outage does not stop the demo, and demo problems do not block real invoices.

Rate limiting is handled separately. KSeF can return a Retry-After header measured in thousands of seconds, which would freeze your invoicing screen for the best part of an hour even though the gateway is back in minutes. Biurko caps that wait at a sane maximum and retries.

An offline invoice is a complete document from second one

Switching to offline mode does not mean the invoice is "pending". It is issued, it carries the date from field P_1 of the FA(3) XML structure, and your customer can have it immediately.

At that moment Biurko produces:

• FA(3) XML,

• CODE I: a QR code with a verification link to KSeF (the seller's NIP, the issue date and the SHA-256 hash of the invoice file; no invoice number or amounts), signed "OFFLINE",

• CODE II (signed "CERTYFIKAT"): a second QR code confirming the issuer's identity, produced only when the company has a KSeF certificate of the Offline type,

• a PDF showing the offline block and the transmission deadline.

That is the set of codes the Ministry provides for when an invoice is handed to a buyer outside KSeF. A foreign counterparty, a consumer, or a buyer with no Polish NIP (tax identification number) receives a document with QR codes; the invoice can be verified in KSeF by CODE I once it has been transmitted.

When KSeF recovers, the queue drains itself

This is the core of it. Once an environment is healthy again, Biurko sweeps, every 5 minutes, the transmissions waiting in offline mode and releases them for submission.

The mechanism guards four things:

1. Its own environment only. A production transmission is not released until production is back. Records belonging to other environments keep flowing.

2. No duplicates. Each transmission is claimed under a row lock and stamped with a dispatch time. Even if the worker queue is backed up and chewing through a backlog, the same invoice will not be sent to KSeF twice.

3. The deadline. Records whose statutory deadline has passed are not resubmitted automatically. Biurko marks them "Needs review" and sends a notification, and what happens next is your decision. Biurko does not warn you before the deadline runs out.

4. The original marking. An invoice resubmitted after recovery still carries the offline code your customer already received. Same document, same QR code, plus a KSeF number.

After a successful submission Biurko fetches the UPO (the official confirmation receipt issued by KSeF) and notifies you. If KSeF rejects the invoice, you get the error translated into plain language rather than a raw code from the API docs.

What Biurko will not do for you

Honestly, because this is the section most vendors skip.

• The second QR code needs a KSeF certificate of the Offline type. It is a separate certificate from the one you log in to KSeF with (the Authentication type), and Biurko can order both from the Ministry. Without an Offline certificate Biurko will issue the offline invoice with one code (CODE I) and a warning; an offline invoice handed to a buyer outside KSeF should carry both codes. Order the certificate before you need it.

• A total failure is a different procedure. It is announced by the Minister of Finance through public media, and invoices issued during it are never sent to KSeF. Automation has nothing to push.

• A credit note needs the original's KSeF number. If the original invoice is still sitting in the offline queue, it must get its number first. No software can bypass that rule.

• Automation will not fix wrong data. If the buyer's NIP is invalid, the invoice comes back rejected no matter who sent it or when.

A concrete scenario

Marta runs a small design company near Katowice and has a KSeF Offline certificate in Biurko. On Thursday at 3:20 PM the KSeF gateway starts timing out. She does not notice, because she is on the phone with a client.

Biurko sees the run of failures and sends new submissions to offline24 mode. The next 14 invoices issued that afternoon receive two QR codes and go out to customers as PDFs by email, showing the KSeF transmission deadline. In the panel they wait with the status "Oczekuje wysyłki" (awaiting submission).

At 6:05 PM KSeF comes back. Marta is already at home. The queue drains on its own, the invoices receive their KSeF numbers, and a UPO is attached to each one. On Friday morning Marta sees 14 green statuses and a single notification: one invoice rejected because the buyer's NIP is no longer active. She fixes one document instead of chasing fourteen.

Checklist: do this before KSeF goes down

1. Order a KSeF certificate of the Offline type and check its expiry date. Without it an offline invoice will carry only one QR code.

2. Check whether your system detects unavailability itself, or waits for you to click "send" and see an error.

3. Agree with your customers on how offline invoices are delivered, so nobody disputes the receipt date.

4. Confirm your PDF visualisation carries both QR codes, not just one.

5. Verify that resubmission after recovery is automatic, and that something prevents the same invoice being sent twice.

6. Learn the difference: offline24 and announced downtime mean the next business day; a declared failure means 7 business days.

7. Turn on notifications for offline queueing and for KSeF rejections.

Summary

Offline modes are not a premium feature or a curiosity for power users. They are a normal part of working with a system that sometimes does not answer. The only question is whether, after an outage, you sit down with a list of invoices and tick them off by hand while counting business days, or you simply see that everything went through.

Biurko treats the offline queue as infrastructure, not as your to-do item. It detects, queues, resubmits, fetches the UPO, and speaks up only when something actually needs a human.

Create a Biurko account: every new company gets 14 days of the TEAM plan without a card, then moves to the free FREE plan. To practise without legal effect, use the Biurko demo (demo.biurko.io, 7-day access, the KSeF demo environment). An account on app.biurko.io sends invoices to production KSeF, so every invoice you send there is real.

FAQ

How long do I have to send an offline24 invoice to KSeF? Without delay, at the latest on the next business day after the day of issue (Art. 106nda of the VAT Act). The "24" in offline24 is not twenty-four clock hours. A Friday invoice is due by the end of Monday, provided Monday is a working day.

Can software resubmit the invoice automatically once KSeF is back? Yes, and it should. Every 5 minutes Biurko checks the queued invoices and releases them automatically once the gateway works, separately for each environment, with a lock that prevents double submission.

What if the Ministry declares a failure while my offline24 deadline is running? The emergency-mode deadline applies instead: 7 business days from the end of the declared failure. Announcements are published in the Ministry's public information bulletin (BIP) and surfaced through the KSeF interface software.

Do I need a KSeF certificate for offline mode? Not to issue the invoice itself, but the second QR code (CODE II, confirming the issuer's identity) is produced only with a KSeF certificate of the Offline type. It is a separate certificate from the login (Authentication) certificate; Biurko can order both from the Ministry. Without an Offline certificate Biurko issues the invoice with one code (CODE I) and a warning.

What is the penalty for missing the resubmission deadline? Under the current act, penalties under Article 106ni of the VAT Act apply from 1 January 2027. On 16 September 2026 the Ministry of Finance announced it will move them to 1 January 2028; that is a bill not yet passed. The obligation to transmit the invoice exists regardless of penalties. Details: podatki.gov.pl.