Home › Guides

Poland KSeF: permissions, offline modes and recovery

A KSeF outage plan starts with the reason an invoice cannot reach the system. Local connectivity problems, announced unavailability and an officially declared outage have different procedures. They also require prepared permissions, certificates and evidence. A generic promise to "upload everything when the connection returns" leaves both timing and document handling unresolved.

Use this guide to prepare a recovery process for an already assessed invoice population. Keep the KSeF recovery worksheet beside the operating instructions. The workflow and test controls are recommendations; the cited Ministry pages establish the specific mode distinctions.

Define the population and authorized operators

The tax owner should approve which legal entity issues the invoice, whether issuance is mandatory, and which recipients receive through KSeF or an agreed outside route. Record exceptions explicitly. The authority's scope page distinguishes phased issuance, the temporary low-value arrangement and relevant nonresident/fixed-establishment circumstances. Do not infer scope from the mere possession of a Polish VAT number. KSeF: mandatory scope.

List every billing source and issuer identity. Then assign who can administer permissions, issue documents, retrieve them and review outcomes. A shared-service employee and an outside accountant need explicit authority for their actual tasks. Keep access approval separate from a successful technical login.

Prepare a joiner, role-change and departure process. Revoke permissions when the business relationship ends, check any service identities and confirm who covers an absent administrator. The Ministry's onboarding handbook describes the permission and authentication arrangements; use its current route rather than screenshots from the former certificate/permission module. Ministry: KSeF 2.0 onboarding handbook.

Prepare the two certificate purposes

KSeF distinguishes type 1 certificates for authentication from type 2 certificates for offline issuer verification. They are generated separately; one certificate does not cover both purposes. The authority states a maximum validity of two years and describes API/application access to certificate functions from February 2026. KSeF: certificates.

Record the certificate holder, purpose, validity, storage location, permitted software use, renewal owner and revocation route. Keep private keys in the approved security arrangement, not in the worksheet. Test that the intended issuer can perform the offline function before an incident; an authentication certificate alone does not establish that readiness.

Define an expiry alert early enough to renew and test. Rehearse a revoked certificate and a departed user's credentials. The acceptance evidence should show that authorized billing continues and the obsolete credential no longer works.

Select the actual mode

For offline24, the authority requires the applicable electronic structure, currently FA(3), and submission without delay, no later than the next working day after issuance. It also describes special handling if an officially declared outage intervenes. Where the specified outside-KSeF recipient receives the document before submission, the two-code arrangement uses OFFLINE and CERTYFIKAT, the latter requiring type 2. KSeF: offline24.

For announced unavailability, use the separately published procedure: submission is due no later than the next working day after that unavailability ends, subject to the described intervening-outage rules. The trigger is the system's announced condition, not the operator deciding that a slow response feels like an outage. KSeF: unavailability.

For an officially announced outage, the authority's emergency procedure uses seven working days after the outage ends. Total failure, announced through the specified public channels, has a different treatment: documents issued under that procedure are not subsequently sent to KSeF. Verify the actual announcement and mode before applying either rule. KSeF: emergency mode, KSeF: total failure.

Store the trigger evidence, start/end times and responsible tax decision against the incident. Calculate deadlines using the applicable working-day calendar. An internal escalation should occur before that deadline, leaving time to investigate rejected documents. When the mode changes during an incident, reassess the remaining queue instead of silently keeping the first rule.

Preserve the invoice and every processing state

The ERP should keep the business invoice identifier, issue date, structured payload, operating mode, attempt identifiers and eventual KSeF reference/outcome as related facts. Use statuses that distinguish unsent, outcome unknown, rejected and accepted. Do not make "exported" mean "accepted."

Determine how the recipient receives or accesses the document for its actual category and operating mode. Keep a customer-facing rendering linked to the structured original and the appropriate identifiers. Test the required QR behaviour using the deployed connector and current authority instructions; a visually plausible QR image does not prove correct content or verification.

Work through an offline24 invoice

This synthetic test assumes a Polish issuer is in scope, the buyer is entitled to the selected outside-KSeF delivery route, and tax approves offline24. On a hypothetical working Monday, the seller creates PL-100 for PLN 1,000 net plus illustrative 23% VAT, total PLN 1,230. There are no special tax rules, holidays or further system announcements.

The integration cannot connect. The operator records offline24, preserves the FA(3) payload and provides the buyer with the correctly prepared document through the approved route. The certificate/QR test must pass before the process is accepted. The source invoice is still one sale for PLN 1,230.

Connectivity returns Tuesday morning. The recovery operator submits the retained invoice, captures its response and KSeF identifier, and reconciles the accepted content to PL-100. Under the stated no-holiday assumptions, Tuesday is the next working day. The system's original issue date remains Monday; the submission timestamp is Tuesday. Neither is overwritten to make them match.

Now test an alternative branch: an announced outage occurs before upload. The operator records the official notice and obtains the revised mode/deadline decision. The system does not apply the simple Tuesday expectation blindly. This branch is a change in the procedural basis, not permission to discard the invoice history.

Recover unknown outcomes and corrections

If a connection times out after transmission, first determine whether KSeF accepted the original attempt using the supported status/query process. Keep the result unknown until evidence resolves it. Do not create PL-101 merely to get a clean response, because that can create a second commercial document.

If the invoice is rejected, preserve the response and resolve its specific cause. Assign data errors to AR/master-data owners and transport/schema issues to integration. Use the verified correction/resubmission procedure for the chosen situation.

The offline24 page specifically requires the original offline invoice to be submitted and receive its KSeF number before issuing its correcting invoice. In a test where a PLN 100 net plus PLN 23 VAT reduction is approved, verify the original reference and expected commercial balance of PLN 1,107, while preserving both documents. Do not apply that arithmetic as a rule for every correction type.

Approve the recovered population

AR owns business documents; tax owns scope and mode decisions; security owns key handling; the administrator owns access; integration owns submissions and response capture. A controller should reconcile incident totals and approve closure.

Start with every invoice issued during the incident, including documents from secondary billing systems. Reconcile counts and net/VAT/gross amounts to accepted records, legitimate non-submission cases and unresolved exceptions. Keep mode-specific populations distinct. A queue of zero is not sufficient if someone deleted failed entries.

Ready checklist

• ☐ Entity, recipient routes and exceptional populations have tax approval.
• ☐ Operators and service identities have appropriate permissions and substitutes.
• ☐ Certificate purpose, expiry, renewal and revocation are tested.
• ☐ Incident classification uses official evidence where required.
• ☐ Each mode has its own working-day deadline and escalation rule.
• ☐ Structured originals, response history and KSeF references can be retrieved.
• ☐ Unknown outcomes and rejected submissions recover without duplicate sales.
• ☐ Corrections reference the accepted original as required by the selected procedure.
• ☐ The controller reconciles the entire incident population before closure.

Extend the test pack using localization acceptance tests and maintain changes through localization change management.

Worksheet: KSeF permissions and recovery worksheet

Copy this worksheet for each case. It records decisions and evidence; it does not determine the tax or legal treatment.

Sources checked: 17 October 2026. Real deadlines depend on the actual mode, official announcements and calendar. No ERP product support or untested operational menu is implied.

Related on this site

• Country pages: key facts with sources
• E-invoicing matrix: country × ERP support
• All guides

Vendor documentation is cited only as an example of the level of evidence to ask for; it is not a recommendation or a ranking. This guide is general information, not tax or legal advice. Checked 2026-10-17.

Related: Glossary – abbreviations and terms used in these guides (SAF-T, Peppol, CTC, EN 16931, IFRS and more).

Page last updated: 2026-10-17 · Markdown version