E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · Offline24 implementation testing

KSeF Offline24 QR codes and ERP test pack

Test KSeF Offline24 in your ERP: two QR codes, Type 2 certificate signing, invoice hashes, queues, deadlines and recovery evidence.

Quick verdict:
  • Scope the test around issuance, pre-submission delivery and post-acceptance presentation as three separate states.
  • The highest-impact defect is a QR payload generated from bytes or an environment different from the submitted invoice.
  • Start by assigning one accountable owner to freeze the XML, calculate its hash and preserve the resulting test evidence.
Get Poland readiness reportOfficial sources
Last checked: 4 August 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

1. Decide when Offline24 and the two-code case apply

Officially, every taxpayer may choose Offline24, including when transmission-network or Internet difficulties prevent normal online work. It is distinct from officially announced KSeF unavailability, emergency or failure, and total failure; those states have different consequences and must not be selected merely because an ERP cannot connect. The tax process owner should record the permitted trigger and mode. The two-code presentation applies when an Offline24 invoice is made available outside KSeF before submission to a recipient covered by art. 106gb(4), such as a foreign buyer, consumer or buyer without a NIP. A domestic VAT taxpayer buyer normally receives through KSeF. Recommended control: use recipient status, delivery timing and KSeF status as explicit decision inputs. Key mistakes are adding two codes to every Offline24 invoice or treating a local outage as an announced system failure. Acceptance criterion: test cases for domestic VAT, foreign, consumer and no-NIP recipients produce the documented delivery route and QR state, with the decision logged.

Guide

2. Freeze FA(3), P_1 and deterministic invoice bytes

The official prerequisites are an electronic invoice using the applicable logical structure—FA(3) since 1 February 2026—and an issue date in P_1. The QR payload relies on invoice-file data, so the XML submitted later must correspond to the file whose SHA-256 hash was encoded. The ERP integration owner should freeze canonical output after business approval: encoding, namespaces, whitespace and element ordering must not drift between QR generation, storage and submission. Deterministic bytes are a recommended engineering control, not a separate statutory invoice rule. Include boundary-date and non-ASCII fixtures. A PDF rendering is only a visualization, not the structured invoice. Risks include recalculating P_1 from print time, pretty-printing XML after hashing, or regenerating an equivalent invoice with different bytes. Acceptance criterion: 100 repeated exports of one fixture yield byte-identical XML and the same Base64URL SHA-256 value, while a deliberate one-byte change produces a different hash and blocks release.

Guide

3. Implement KOD I for invoice access and data verification

Before submission, KOD I is labelled OFFLINE and enables invoice access or data verification. Build it locally from the verification base URL for the active environment, issue date P_1, seller NIP and the Base64URL-encoded SHA-256 hash of the invoice file, following the official technical specification exactly. The integration developer owns payload construction; tax owns P_1 and NIP source quality. Use the production host qr.ksef.mf.gov.pl only for production, with the separately documented test and demo hosts in their respective environments. Recommended controls include typed environment configuration and test vectors. Common errors are hashing the PDF, using standard Base64 padding, normalizing XML after hashing or falling back to production. Acceptance criterion: every fixture matches an independently calculated hash and expected URL; scanning resolves only to the selected environment; wrong NIP, date or hash negative tests fail verification; and the visible caption reads OFFLINE before KSeF acceptance.

Guide

4. Implement KOD II with a Type 2 certificate and guarded private key

KOD II is labelled CERTYFIKAT and verifies issuer identity and invoice authenticity. Its payload includes the context identifier type and value, seller NIP, certificate serial number, the same invoice hash used for KOD I, and a cryptographic signature made with the private key of an active Type 2 Offline KSeF certificate. Type 1 Authentication cannot generate KOD II. Security owns key custody, ERP owns payload and certificate selection, and tax confirms context. Recommended controls are protected keys, least-privilege signing, validity checks, audit logs and fail-closed handling. Never log private-key material or substitute a convenient authentication certificate. Acceptance criterion: approved test vectors verify successfully, a changed hash or context invalidates the signature, an expired or wrong certificate is rejected, Type 1 selection is impossible in the UI and API, and signing logs identify request, certificate serial, timestamp and result without exposing secrets.

Guide

5. Run an end-to-end ERP matrix, not isolated QR unit tests

Use a realistic scenario: seller NIP 5210000000 issues an FA(3) invoice at 16:40 on Monday with P_1 set to that Monday, cannot transmit immediately, and provides it that evening to a foreign buyer before submission. The system should freeze XML, calculate one hash, create OFFLINE and CERTYFIKAT codes, render both with labels, queue the same file using offlineMode:true, submit it, store the KSeF number and then switch any later outside-KSeF visualization to one KOD I labelled with that KSeF number. Repeat for domestic VAT, consumer and no-NIP buyers. Test wrong context, altered bytes, unavailable keys and duplicate workers. Product owns the matrix, QA execution and tax signs off expected treatment. Acceptance criterion: each state transition is reproducible, both pre-submission codes reference the same hash, accepted records retain one KSeF number, and no post-acceptance document shows the obsolete pair.

Guide

6. Control the queue, deadline, idempotency and reconciliation

For taxpayer-chosen Offline24, the invoice must be sent to KSeF without delay and no later than the next working day after issue to receive a KSeF number. If an officially announced KSeF failure begins before submission, the deadline becomes seven working days after that failure ends; in a total failure, the invoice is not subsequently sent. These official rules require distinct mode and deadline logic. The platform owner should implement a durable queue using offlineMode:true, immutable hashes, idempotency keys, bounded retries and reconciliation. Operations owns alerts; tax owns working-day and exceptional-state interpretation. Mistakes include retrying regenerated XML, resetting a deadline on every attempt or treating HTTP failure as official KSeF failure. Acceptance criterion: crash/restart and duplicate-worker tests create no duplicate business invoice, overdue-risk alerts fire before the configured threshold, and daily reconciliation accounts for every queued hash as pending, accepted, rejected or escalated.

Guide

7. Accept scanning, rendering, environment separation and accessibility

QR graphics must follow ISO/IEC 18004:2024. Test the smallest supported print and digital sizes, common printers, mobile cameras and delivery conversions. Verify that each code remains paired with its correct OFFLINE or CERTYFIKAT label and is not cropped, rescaled unevenly or visually swapped. Where a structured delivery format cannot carry a graphic, official guidance permits the link or graphic and its label to be supplied separately with the invoice. That flexibility does not remove payload or labelling requirements. QA owns scan coverage, UX owns readable placement, and release engineering owns strict separation of demo, test and production configuration. Recommended controls include visual regression tests and an environment banner outside production. Acceptance criterion: all supported render paths scan on the agreed device matrix, decoded hosts match the environment, labels are readable without relying on colour, keyboard-accessible links expose descriptive text, and a release test proves that no test or demo URL can enter a production artifact.

Guide

8. Test rejection, technical correction and recovery

A technical validation rejection must not become permission to alter commercial content silently. The documented technical-correction mechanism can link a corrected technical file to the rejected original hash; use it only within the official conditions and preserve both artifacts and the relationship. Separately, a correction invoice concerning an Offline24 original should wait until that original has a KSeF number. The recovery owner should be named jointly by tax and integration teams, with security involved if signing failed. Test schema rejection, payload mismatch, expired certificate, transient submission error and a response lost after acceptance. Recommended controls include quarantine, business-data review and reconciliation before retry. Never overwrite rejected XML, issue a business correction too early or lose hash lineage. Acceptance criterion: the system distinguishes retry, documented technical correction and business correction; preserves original and replacement hashes; prevents premature correction issuance; and recovers a lost response by querying status rather than blindly creating another submission.

Guide

9. Choose suppliers by proof, then retain an evidence pack

Ask an ERP or connector supplier to demonstrate the complete state machine with your fixtures, not merely show two QR images. Decision criteria should cover FA(3) byte stability, exact KOD I construction, Type 2 signing, private-key integration, recipient-based two-code logic, offlineMode:true submission, working-day deadlines, idempotent recovery, post-acceptance presentation and environment isolation. Require named owners for tax configuration, signing infrastructure, queue operations and production support. Supplier risks include irreproducible hashing, unclear key custody, manual deadlines and weak rejection lineage. Recommended evidence—not a statutory test regime—includes approved requirements, decoded payloads, reference hashes, signature and scan results, queue logs, negative tests, reconciliation and remediation owners. Acceptance criterion: all critical cases pass, no high-risk defect is waived without accountable approval and a target date, and the evidence pack can trace one invoice from frozen XML through both pre-submission codes, submission response and final KSeF-number presentation. Use the readiness report to turn gaps into an owned delivery plan.

Checklist

Document the business trigger for taxpayer-chosen Offline24 separately from officially announced KSeF states.

Map recipient type and delivery timing to the normal KSeF route or the pre-submission two-code case.

Freeze FA(3) XML bytes and confirm P_1 before calculating the invoice-file hash.

Reproduce the Base64URL SHA-256 hash independently from the stored invoice file.

Validate KOD I fields, OFFLINE label and environment-specific verification host.

Sign KOD II only with an active Type 2 Offline certificate and protected private key.

Submit the identical queued file with offlineMode:true and an idempotency control.

Exercise working-day deadlines, retries, restarts, duplicate workers and response-loss recovery.

Scan every supported rendering and verify labels, decoded payloads and accessible alternatives.

Retain rejection lineage, reconciliation results, KSeF number and accountable remediation owners.

FAQ

Does every Offline24 invoice need two QR codes?

No. The pair applies when an Offline24 invoice is provided outside KSeF before submission to an art. 106gb(4) recipient, such as a foreign buyer, consumer or buyer without NIP. A domestic VAT taxpayer buyer normally receives through KSeF.

What does each pre-submission code verify?

KOD I, labelled OFFLINE, supports invoice access or data verification using invoice attributes and the file hash. KOD II, labelled CERTYFIKAT, verifies issuer identity and authenticity through certificate data and a signature over the specified payload.

Can a Type 1 Authentication certificate create KOD II?

No. KOD II requires an active Type 2 Offline KSeF certificate and its private key. ERP validation should reject a Type 1 selection rather than attempting to repurpose it for offline invoice signing.

Which file should be hashed for the QR payloads?

Hash the electronic structured invoice file used for the flow, not its PDF visualization. Keep the bytes deterministic and use the same invoice hash in KOD I and KOD II, following the official Base64URL SHA-256 construction.

What changes after KSeF accepts the invoice?

After acceptance and assignment of a KSeF number, a later visualization supplied outside KSeF uses one KOD I labelled with that KSeF number. It should not keep presenting the earlier OFFLINE and CERTYFIKAT pair.

When must an Offline24 invoice be submitted?

Send it without delay, no later than the next working day after issue. An announced failure beginning before submission changes the deadline to seven working days after it ends; total failure means no later submission.

How should the ERP handle a technical validation rejection?

Preserve the rejected file and hash, classify the error and use the documented technical-correction mechanism only where applicable. It may link a corrected technical file to the rejected hash, but it does not authorize changing business content.

Can a correction invoice be issued before the Offline24 original is accepted?

A correction concerning an Offline24 original should wait until the original has a KSeF number. Build a system guard and an exception queue so users cannot bypass that sequence while the original remains pending or rejected.

Key regulations, formats and terms

PolandKSeFKrajowy System e-FakturPolish Ministry of Financepodatki.gov.plstructured invoiceAPI authenticationinvoice correctionsaccounting softwareVATSMEecommerceEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeKSeF Offline24 QR codes and ERP test pack

Poland — Country hub

Poland

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.