KSeF in August 2026: what to do if your company still is not ready

Mandatory KSeF has been running for half a year, and yet every week we still talk to companies that issue invoices outside the system. Rarely out of neglect: more often their accounting software never got the module, the integration with their own ERP did not fit the budget, or someone heard that "there are no penalties in 2026 anyway" and pushed the topic back. This article is for those companies — and for the IT teams that now have to wire this into systems that are already running.

Start with the distinction that gets blurred in almost every conversation: no penalties is not the same as no obligation. The duty to issue structured invoices has been in force since 1 February 2026 for the largest taxpayers and since 1 April 2026 for everyone else. What was deferred are the monetary penalties — until 31 December 2026. That leaves under five months, and a KSeF rollout is not a swap of invoicing software: it changes dates, numbering, document flow, payments, and permissions.

What already applies, and what is still ahead?

The calendar is simple, though it has several layers. Since 1 February 2026, invoices go through KSeF for companies whose sales value including VAT exceeded PLN 200 million in 2024. From that same date every taxpayer must be able to receive invoices through KSeF — including those who do not issue through it yet. Since 1 April 2026 the issuing duty covers all remaining businesses, including those exempt from VAT.

Two groups sit outside that rhythm. Taxpayers whose monthly sales documented by invoices do not exceed PLN 10,000 gross may issue paper or electronic invoices outside KSeF until the end of 2026 — but they must receive invoices through KSeF like everyone else, and from 1 January 2027 the full duty applies to them too. Invoices to private individuals who do not run a business go into KSeF voluntarily, not by obligation. Through 31 December 2026 there is also a carve-out for invoices issued via cash registers and for receipts with a tax ID treated as simplified invoices.

What actually changes in daily work?

The first change concerns dates and is the source of most confusion. A structured invoice is deemed issued on the day it is sent to KSeF (Article 106na(1) of the VAT Act), and deemed received on the day the KSeF number is assigned to it. If the date in field P_1 is earlier than the day the system accepts the document, KSeF itself classifies the submission as offline mode and takes the P_1 value as the issue date. Your own invoice numbering stays as it is, but a second identifier appears next to it — the KSeF number assigned by the system.

The KSeF number is always 35 characters with a fixed structure: the seller's tax ID, the acceptance date, twelve hexadecimal characters, and a two-character CRC-8 checksum. This is the number that has to reach payments from 2027, so it is worth deciding now where you will store it and how you will tie it to receivables. Since the number carries a checksum, you can — and should — validate it locally before it goes into a transfer retyped by hand from an invoice visualisation.

The second change is attachments. Since 1 February 2026 structured invoices may carry an attachment, but not automatically: you must first declare that intention on the ZGL_ZAL form in the e-Tax Office. The declaration is processed within a maximum of three business days, and confirmation arrives at the e-mail address given on it. If your invoices are useless without a specification — hourly services, transport, utilities — file that declaration before you start rebuilding templates.

The third change is working when KSeF does not answer, and the law distinguishes four situations here. Offline24 mode (Article 106nda) is your own decision, no outage required: you issue the invoice outside the system and send it in no later than the next business day. Offline mode (Article 106nh) is triggered by an unavailability announced by the Ministry of Finance, with a deadline of the next business day after it ends. Emergency mode (Article 106nf) applies to a declared KSeF failure and gives 7 business days from the moment it ends; if another failure notice appears in that window, the clock restarts. A total failure, announced through mass media, removes the duty to send the invoice to KSeF at all.

In the offline modes, an invoice handed to the buyer outside the system must carry two QR codes: the first lets the invoice be verified in KSeF, the second confirms the issuer's identity and requires holding a KSeF certificate. That is the kind of detail that surprises people on a Friday afternoon — you need the certificate before it turns out to be needed, not in the middle of an outage.

We are not ready — four typical situations

We issue invoices in Excel or Word. This is the cheapest and simplest case to fix. The Ministry of Finance provides the free KSeF Taxpayer Application and the KSeF Mobile Application, where you can issue and receive invoices in the FA(3) schema with no integration and no fees. They have no accounting features — they will not compute a lump-sum tax or file a return — but they close the invoicing obligation immediately. For a company issuing a dozen or so invoices a month, that is often enough for the whole of 2026.

We have accounting software, but without a KSeF module. Start with a question to the vendor, not with a project: most Polish platforms already ship KSeF submission, it just has to be switched on and the permissions configured. If the answer is that the module is not coming, you have three ways out: change the software, add a separate submission gateway alongside it, or work in the free Ministry application and move data into accounting by hand. The third only works at small volumes.

We have our own ERP or CRM and our code generates the invoices. This is an integration project and is best treated like any other: the test environment first, then pre-production, and only then production. The scope is described in the next section. The realistic timeline is not a week — granting permissions and obtaining certificates alone can take several days before the first line of code exists.

Our accounting is handled by an external bookkeeping office. Permissions in KSeF are granted by the taxpayer, not by the office. The office needs the permission to view invoices, and to issue them if it also invoices on your behalf; when it serves many clients, permissions can be granted indirectly, with a flag allowing further delegation. If the company has no qualified electronic seal, the first natural person is designated with a ZAW-FA notification filed in the e-Tax Office; since 1 January 2026 filing it through ePUAP is not treated as effective delivery. That one person then grants further permissions electronically, inside the system.

What does integrating with the KSeF API look like?

The Ministry of Finance runs three public environments: a test environment carrying release candidates, a pre-production demo environment configured like production, and production, where invoices have full legal force. Production accepts only the FA(3) schema — the older FA(2) survives on the test environment only. It is also worth knowing that test-environment data is not isolated between integrators, so tests use random tax IDs, never real ones. The API documentation and the official Java and C# clients are published by the Ministry on GitHub — before you write your own HTTP client, check whether the ready one is enough.

flowchart LR
  subgraph AUTH["1. Authentication"]
    direction TB
    A1["challenge<br/>valid for 10 minutes"] --> A2["XAdES signature<br/>or KSeF token"]
    A2 --> A3["accessToken ~15 min<br/>refreshToken up to 7 days"]
  end
  subgraph SEND["2. Submission"]
    direction TB
    B1["AES-256 key<br/>encrypted with the Ministry key"] --> B2["session: interactive<br/>or batch"]
    B2 --> B3["XML in the FA 3 schema<br/>up to 1 MB without attachment"]
  end
  subgraph CONF["3. Confirmation"]
    direction TB
    C1["poll for status<br/>processing is async"] --> C2["KSeF number, 35 chars<br/>+ UPO"]
  end
  subgraph KEEP["4. On your side"]
    direction TB
    D1["KSeF number, UPO,<br/>original XML, submission mode"] --> D2["deduplicate incoming<br/>by KSeF number"]
  end
  AUTH --> SEND --> CONF --> KEEP

Authentication. It starts by fetching a one-off challenge, valid for 10 minutes. Then you either sign the authorisation document with a XAdES signature — a person's qualified signature, a company seal, or a KSeF certificate — or you use a KSeF token encrypted with RSA-OAEP and SHA-256. In return you get a short-lived accessToken, on the order of a quarter of an hour, and a refreshToken valid for up to 7 days. A KSeF token never carries broader permissions than the person who generated it, and a permission change invalidates previously issued tokens — the kind of detail that takes an integration down on the day someone leaves the accounting team.

Submission. Invoices are sent inside a session: interactive for single documents, batch for packages. The XML is encrypted with an AES-256-CBC key, and the symmetric key itself with the Ministry of Finance's public key, using RSAES-OAEP with MGF1 based on SHA-256. Limits you need at design time: up to 1 MB per invoice without an attachment, up to 3 MB with one, a maximum of 10,000 invoices per session, and an interactive session that lives for 12 hours from opening.

Confirmation. KSeF processes an invoice asynchronously, so after submission you poll for status and only then receive the KSeF number and the UPO — the official confirmation of receipt. It is the UPO, not the response code of the submission itself, that proves the invoice was accepted. Design this as a state machine with retries, not as a single call inside a database transaction.

Limits and errors. Request limits are counted separately for each pair of authentication context plus IP address, on a sliding time window. Once you cross a threshold you get a 429 response with a Retry-After header, and repeated breaches lengthen the block. The practical conclusion: exponential backoff that respects Retry-After is not a good practice here, it is a condition of working at all. Between 20:00 and 06:00 higher download limits apply — a natural window for bulk synchronisation of purchase invoices.

What stays on your side. The KSeF number, the UPO, the original invoice XML, and the submission mode — that is the minimum that should land in your database and your backup. KSeF stores invoices, but reconstructing your ledgers from it during an audit or a dispute with a counterparty is far slower than querying your own table. On the receiving side, plan for incremental fetching of purchase invoices and deduplication by KSeF number — it is the only globally unique identifier, so the only one you can safely build on.

One announcement that matters for planning: KSeF tokens were meant to stop working at the end of 2026, but at the consultations on 9 June 2026 the Ministry of Finance announced it would keep them as a permanent login method, with a configurable validity period and automatic renewal. That is an announcement, not a rule in force. If you are building the integration today, design it so the authentication method can be swapped without rewriting the rest.

Where does AI fit into all this?

Not where it is usually promised. Issuing an invoice into KSeF is an integration problem, not an intelligence problem: the schema is rigid, validation sits on the system's side, and a language model will not speed anything up here — it can only add mistakes. If someone sells you "AI that will issue your KSeF invoices", they are selling you an API client with a nicer name.

The sensible uses sit on the other side of the flow — where the volume suddenly grew, because since February every purchase invoice arrives through one channel. Matching a purchase invoice to an order and a contract. Categorising costs and catching duplicates, which happen more often than theory suggests when you receive from KSeF and from an e-mail inbox in parallel. Checking counterparties in public registers: for payments of PLN 15,000 and above, Article 117ba of the Tax Ordinance requires verifying the bank account on the Ministry's White List anyway, so it is better done by a system than by someone's memory. And finally, answering questions like "how much VAT do I owe this month" from accounting data rather than from the model's memory.

That is exactly how we built Accounting AI Agent: it connects to wFirma through the API, checks counterparties against the White List and the company register, and can send an invoice to KSeF in the FA(3) schema and wait for the official confirmation. We described it from the user's side in the article on the assistant connected to wFirma and from the architecture side in the piece on the accounting agent. And if you are letting AI into your document flow, remember the AI Act transparency duties that have applied since 2 August 2026 — we unpacked them in the article on where the AI Act stands in August 2026.

What to do in the coming weeks

1. Establish which group you are in. The obligation date, the PLN 10,000 monthly threshold, consumer invoices, cash registers. Without that, the rest of the plan is guesswork rather than a plan.

2. Check permissions before you check software. Who in the company holds KSeF permissions, whether there is a backup person, and whether anyone revokes them when people change roles. If the company has no qualified electronic seal, file ZAW-FA in the e-Tax Office — not through ePUAP.

3. Obtain KSeF certificates before they become urgent. They are needed for the second QR code in the offline modes and for a stable system integration. The limits are generous for a tax ID and narrow for a natural person identified by a personal number, so map out in advance who needs what.

4. Write an outage procedure and test it. Who decides to switch to offline24, where the QR codes come from, who watches the resubmission deadline, and who monitors failure notices. That procedure fits on one page and is worth more than another training session.

5. If you issue invoices with attachments, file ZGL_ZAL. Processing takes up to three business days, and without the confirmation the attachment simply will not pass through the system.

6. Plan 2027 now. The KSeF number in payments touches banking and receivables, not invoicing. If those are two separate systems at your company, this is a quarter-long project, not a December one.

7. Get purchase-invoice intake in order. Incremental fetching, deduplication by KSeF number, one place of truth. This is the most underrated part of the rollout, because the duty to receive arrived before the duty to issue and many companies simply missed it.

Is this tax advice?

It is not. It is a snapshot as of 16 August 2026, written so there is somewhere to start. KSeF dates and details have already changed several times, so check the current information at ksef.podatki.gov.pl before you act, and take your company's specific situation to an accountant or tax adviser. If the question is instead "how do we wire KSeF into our ERP without stopping sales" — that is a conversation we have every day. Write to us: development@mi-code.pl.