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.
From 1 January 2027, missing that deadline carries an administrative penalty. 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 three separate provisions.
Mode Trigger Deadline to send to KSeF Legal basis offline24 problem on your side (no internet, gateway too slow) without delay, at the latest the next business day after issue Art. 106nda offline (unavailability) Ministry announces downtime in its public bulletin (BIP) at the latest the next business day after downtime ends Art. 106nh emergency (awaryjny) Ministry announces a failure in BIP 7 business days from the end of the failure Art. 106nf total failure announced through public media invoices are not sent to KSeF at all Art. 106nf(4)
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 a run of failed responses piles up inside a short window, Biurko flips that environment into outage state.
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 your test sandbox, and demo problems do not block real invoices. That sounds like an implementation detail until you run an accounting office with fifteen client companies in one panel, where one stuck session must not freeze everything else.
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 marked with the mode the invoice was issued in,
an offline reference code derived from the canonical XML, unique to that document,
a QR code marked OFFLINE, which lets anyone verify the invoice against the KSeF database,
a QR code from your KSeF type 2 certificate, confirming the issuer's identity,
a PDF showing the offline block and the transmission deadline.
That is exactly the set the Ministry requires 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 they can verify before KSeF has even assigned a number to it.
When KSeF recovers, the queue drains itself
This is the core of it. Once an environment is healthy again, Biurko sweeps the transmissions waiting in offline mode and releases them for submission.
The mechanism guards four things:
Its own environment only. A production transmission is not released until production is back. Records belonging to other environments keep flowing.
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.
The deadline. Records past the statutory deadline are not quietly pushed through in the background. They surface as something for you to decide on, not something to sweep under the rug.
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.
You need the type 2 KSeF certificate in advance. Without it you cannot generate the second QR code, and an offline invoice without that code does not meet the requirements for handing it to a buyer outside KSeF. You request it in the Taxpayer Application or through the API, and it is valid for two years. Get it 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. Biurko enforces the order, but it cannot bypass the statute.
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 accounting office near Katowice with 23 client companies. 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 flips the production environment into offline mode. The next 14 invoices issued that afternoon receive offline codes and QR codes, and go out to customers as PDFs by email. A banner appears in the panel showing how many documents are queued and when they are due.
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
Download your type 2 KSeF certificate and check its expiry date. Offline invoicing depends on it.
Check whether your system detects unavailability itself, or waits for you to click "send" and see an error.
Agree with your customers on how offline invoices are delivered, so nobody disputes the receipt date.
Confirm your PDF visualisation carries both QR codes, not just one.
Verify that resubmission after recovery is automatic, and that something prevents the same invoice being sent twice.
Learn the difference: offline24 and announced downtime mean the next business day; a declared failure means 7 business days.
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 and test offline24 in the sandbox before production tests you. 14 days free, no card required.
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. Biurko polls gateway availability and releases queued invoices automatically, 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? Yes. The type 2 KSeF certificate generates the QR code confirming the issuer's identity. Without it you cannot hand a buyer an offline invoice that meets the Ministry's requirements. You obtain it in the KSeF 2.0 Taxpayer Application or through the API; it is valid for two years.
What is the penalty for missing the resubmission deadline? Administrative sanctions under Art. 106ni of the VAT Act apply from 1 January 2027. Until then a transition period runs, but the obligation to transmit the invoice exists regardless of penalties. Details: podatki.gov.pl.
Internal links to substitute: [SLUG-KSEF-CERTIFICATE-TYPE-2], [SLUG-KSEF-QR-CODES], [SLUG-KSEF-DEADLINES-2026], [SLUG-MULTI-COMPANY-PANEL]