One point of standing before the detail. The binding text of the Polish VAT Act is the Polish one, published in the Dziennik Ustaw. This page is a working guide for a reader who does not read Polish; where a deadline matters, check the instrument, and where the two diverge the Polish text governs.
What are the offline modes in KSeF?
| Mode | Trigger | When available | Transmission deadline | Basis |
|---|---|---|---|---|
| offline24 | The taxpayer's decision | Without restriction, at any time | Next working day after the date of issue | art. 106nda |
| offline (niedostępność) | KSeF | Announced unavailability of the system | Next working day after availability is restored | art. 106nh |
| tryb awaryjny | KSeF | Announced failure | 7 working days from removal of the failure | art. 106nf |
| awaria całkowita | KSeF | Separate communication from the Ministry of Finance | Not transmitted to KSeF | — |
Unavailability and failure are announced in the Biuletyn Informacji Publicznej of the Ministry of Finance and by a message in the system interface. A total failure is announced by a separate communication from the Ministry.
The vocabulary, because the translation is where this goes wrong
Niedostępność means unavailability. Awaria means a failure or breakdown. Both are declared by the Ministry, and English material frequently renders both as emergency mode
— which is the label properly belonging to only one of them, tryb awaryjny under art. 106nf. The consequence of the merge is not academic: the deadline in that mode is seven working days from the removal of the failure, while the deadline for unavailability is the next working day after availability is restored. A procedure written against the wrong one of those is wrong by roughly a factor of seven in one direction, or several days late in the other.
Offline24 is not a failure mode at all, and the name misleads in English: the 24 refers to the mode's unconditional availability, not to a 24-hour window. The deadline is the next working day after the date of issue, which over a Polish public holiday may be considerably more than twenty-four hours, and over a Friday considerably more still.
Why offline24 is the different one
The other three modes are reactions to an external state: the system is unavailable, so you issue outside it. Offline24 carries no such condition. The taxpayer may use it at any moment, with no failure and no justification, provided the transmission deadline is met.
From a design point of view that is a safety feature. When an integration returns an error you cannot diagnose quickly, you can issue the invoice and keep selling instead of blocking the process. From an audit point of view it is the mode in which there is no external event to point to. If the invoice reaches KSeF late, the only available explanation is whatever your own system wrote down at the time.
Which date is the issue date of an offline invoice?
KSeF treats only field P_1 of the logical structure as the date of issue. That field, and nothing else, starts the clock — not the moment of the transmission attempt, not the moment the document was created in the ERP, not the timestamp in an integration log.
The divergence between those dates is a common source of unknowing lateness. A document created in the source system on a Friday evening, with P_1 set to Friday but queued for transmission on Monday morning, is transmitted on time: the next working day. The same document with P_1 set to Thursday is already late. Validating P_1 against the actual moment of issue belongs in the integration layer, and is rarely implemented there.
For a group, one further caution. The deadlines are expressed in dni robocze, working days on the Polish calendar. A shared service centre or follow-the-sun operations team computing deadlines on a UK, German or United States holiday calendar will get some of them wrong in both directions, and the errors will cluster in exactly the periods — public holidays, month ends — when volumes are highest and staffing thinnest.
What do the two QR codes on an offline invoice confirm?
Invoices issued offline carry two codes with entirely different purposes.
KOD I — verification and retrieval
Contains the environment address, the date, the seller's NIP and the SHA-256 hash of the XML file encoded in Base64URL. It lets a recipient verify that the document in their hands corresponds to what is held in KSeF. KOD I appears on every invoice visualisation, including those issued online.
KOD II — certificate verification
Signed with the private key of a KSeF certificate of the offline type (keyUsage Non-Repudiation), it confirms the identity of the issuer at the moment when the system itself could not. KOD II appears only on invoices issued offline.
Invoices issued during a total failure carry neither code.
The distinction between certificate types is worth committing to memory, because they are mutually exclusive: an Authentication certificate (Digital Signature) is for authenticating to the system, an Offline certificate (Non-Repudiation) is for signing KOD II. An organisation that issues invoices offline must hold the second kind — and this is the step that is easy to forget until it turns out to be needed in the middle of an incident. In a group it is also a per-taxpayer step, not a per-platform one: the certificate belongs to the Polish entity, so a shared integration serving several entities needs one for each.
Which entities in a group does this apply to?
The offline regime follows the invoicing obligation, and that obligation attaches to the Polish taxpayer. Art. 106ga ust. 2 of the VAT Act excludes a taxpayer with neither a seat nor a fixed establishment in Poland, and a taxpayer without a Polish seat whose fixed establishment in Poland does not participate in the supply for which the invoice is issued. A Polish VAT registration is not by itself a fixed establishment; the Ministry of Finance published objaśnienia podatkowe on that determination on 28 January 2026, and the test is set out in the companion article on KSeF penalties from 1 January 2027.
Two consequences follow for continuity planning. First, the offline procedure has to exist for every in-scope entity, including the smallest: there is no deferral for micro-entrepreneurs, who came into the obligation on 1 April 2026 like everyone else — the bill that would have excluded them until 31 December 2027, Sejm druk nr 2321 of 13 February 2026, stalled after its first reading on 13 March 2026 and was never enacted, though it is still cited as law in advisory material. See the register of corrections. Second, an invoice that is issued offline and then transmitted still becomes permanent on acceptance: KSeF assigns a numer KSeF, and from that moment the document can be corrected but never deleted. A queue that transmits the same offline invoice twice does not produce a retryable error; it produces two invoices and a correction to write.
Where do the evidence gaps appear?
Automation moves the choice of mode from a person to a configuration. That is a good operational decision and a weak evidential one, if nothing survives it. Four questions an inspection will ask, which most systems cannot answer:
1. Why was this invoice issued offline?
If the answer is because that is what the fallback does after the third failed attempt
, that is an answer about configuration, not about an event. What is needed is a record: when the attempts occurred, what errors they returned, at what time the decision to switch was taken, and which document it concerned.
2. Was an announced unavailability actually in force at the moment of issue?
This applies to the modes triggered by an event on the KSeF side. Relying on tryb awaryjny requires showing that a failure was announced at the time. A system that does not record the state of the Ministry's announcements at the moment of issue cannot show this afterwards, and the content of BIP announcements is not archived in a form convenient for audit. For a group whose operations centre sits outside Poland, this is also a language problem: the announcement is published in Polish, and a monitoring process that depends on someone reading it is not a control.
3. Was every offline invoice transmitted on time?
The deadlines differ between modes, and for the emergency mode they run from the removal of the failure rather than its onset. Settling this requires binding three facts together: the mode, the P_1 date and the actual moment of acceptance by KSeF. If any one of them lives only in application logs, the reconciliation becomes impossible once those logs rotate. The general requirements are in the KSeF audit trail.
4. Did any offline invoice never reach KSeF at all?
The most serious case and the hardest to detect. The document was issued, handed to the counterparty and booked — and then stuck in a queue nobody monitors. Without a separate register of invoices issued offline and awaiting transmission, such an invoice surfaces only during a reconciliation with the counterparty or during an inspection.
What controls close this?
- A register of mode decisions. For each offline invoice: the mode, the basis for the decision, a timestamp, the document identifier, and the outcome of the online attempts that preceded it.
- A record of the KSeF state at the moment of issue. Whether an announcement of unavailability or failure was in force when the decision was taken — fetched and stored then, not reconstructed later.
- A queue with deadlines. A separate register of invoices awaiting transmission, with the deadline computed for the applicable mode and an alert before it expires.
- P_1 validation. A check that the declared date of issue matches the actual moment of issue, performed before the document leaves the system.
- An approval threshold. A design decision: whether switching an invoice above a given value into offline mode is automatic or requires human confirmation. For most organisations the answer is automatic below the threshold and confirmed above it — the mechanics are in approval thresholds before submission and, more generally, in approval checkpoints.
- Availability of the offline certificate. A check that a certificate of the Offline type is issued, valid and reachable by the process, for each Polish taxpayer, before it is needed.
What a group does differently
Three things, none of them technical. The mode decision has to be attributable to an individual Polish taxpayer, not to the platform that made it, because the obligation and any penalty attach to the entity. The announcement-monitoring control has to work without a Polish speaker on shift. And the reconciliation of the offline queue belongs in the month-end close of the Polish entity, not in an operations dashboard — the reason being that from 1 January 2027 an untransmitted invoice stops being an operational item and starts being a penalty under art. 106ni, mitigated under art. 189d only to the extent you can prove what happened. Where the mode decision is taken by an AI agent rather than a deterministic rule, the record also has to carry the model and policy version in force, since the decision cannot be reproduced by re-running it later; audit trail requirements for AI agents covers that ground.
In practice
BarzelVault applies policy and approval thresholds ahead of execution and issues signed audit receipts, so a switch into offline mode is recorded with its basis at the moment it is taken. BarzelOps runs the cross-system workflow with durable state, approval checkpoints and tenant isolation, which is what keeps a transmission queue and its deadlines attributable to a single Polish entity.
Frequently asked questions
Does offline24 require a justification?
No. It is available without restriction and is the taxpayer's own decision. The transmission deadline is the next working day after the date of issue.
How long is the deadline in emergency mode?
Seven working days from the removal of the failure. It is the longest deadline of any of the modes, and it runs from removal, not from onset.
What is the difference between KOD I and KOD II?
KOD I is for verifying and retrieving the invoice and appears on every visualisation. KOD II confirms the identity of the issuer, is signed with a certificate of the Offline type, and appears only on invoices issued offline.
What happens during a total failure?
Invoices are not transmitted to KSeF at all, and they carry no QR codes.
Which field determines the date of issue?
Only P_1. The transmission deadline runs from it.
Can offline24 be used routinely, for every invoice?
The rules do not cap the number of invoices issued in that mode. Routine use, however, transfers the whole timeliness risk to your side and demands a reliable transmission mechanism — which in practice is harder than keeping a stable online integration running.
Where this leads
The four states are easy to distinguish once they are written down side by side, and almost impossible to distinguish from English-language secondary material. For a group the working conclusion is narrow: write four procedures rather than one, compute deadlines on the Polish working-day calendar, record the mode decision and the system state at the moment of the decision, and reconcile the outstanding queue to zero every month. Everything in that list is cheap before 1 January 2027, and none of it can be assembled after the fact.
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
95 days leftKSeF penalties apply from 1 January 2027
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Related
- KSeF penalties from 1 January 2027
- Approval thresholds before a KSeF invoice becomes irreversible
- What KSeF automation actually costs
- The KSeF audit trail: documenting an automated operation
- Glossary of regulatory and technical terms
Sources
- Ustawa o podatku od towarów i usług (Polish VAT Act), art. 106nda, art. 106nf, art. 106nh; also art. 106ga and art. 106ni.
- Ministerstwo Finansów, technical documentation: tryby-offline.md, kody-qr.md, certyfikaty-KSeF.md — github.com/CIRFMF/ksef-docs.
- Ministerstwo Finansów, Podręcznik KSeF 2.0, część III — dodatkowe funkcjonalności KSeF (legal position as at 1 February 2026).
- Ustawa z dnia 5 sierpnia 2025 r. o zmianie ustawy o podatku od towarów i usług oraz niektórych innych ustaw, Dz.U. 2025 poz. 1203.
- Ministerstwo Finansów, Zakres obowiązkowego KSeF — scope and the 1 February and 1 April 2026 dates.
- Ministerstwo Finansów, Objaśnienia podatkowe z 28 stycznia 2026 r. on determining a fixed establishment in Poland for the purposes of issuing invoices through KSeF.
- Ministerstwo Finansów, Information sheet on the FA(3) logical structure, 4 March 2026 (English) — the structure in which
P_1sits. - Kodeks postępowania administracyjnego, art. 189d.
- Sejm RP, druk nr 2321 — private members bill of 13 February 2026, first reading 13 March 2026, not enacted.
This article is a working guide for English-speaking readers and does not constitute tax or legal advice. The binding text is the Polish one.