Token vs. certificate: not the same thing in new packaging

If you're new to the Polish system: every business invoicing in Poland must submit structured invoices through KSeF (Krajowy System e-Faktur), the government's central e-invoicing platform. The rollout is staged — large taxpayers from February 1, 2026, everyone else from April 1, 2026, and the smallest businesses from January 1, 2027. Your software talks to KSeF via API, and that connection has to be authenticated.

Two mechanisms exist today, and they're architecturally very different.

A token is an access key that carries the taxpayer's permissions inside it, declared at the moment of generation. It never expires on its own, and once generated, whoever holds it can act in KSeF within the permissions baked into it.

A KSeF certificate is purely an identity credential — conceptually closer to a qualified electronic signature. Permissions aren't embedded; the system checks them at every login based on the tax identifier (NIP or PESEL) recorded in the certificate. Change an employee's permissions and the certificate stays valid — KSeF simply applies the new scope.

The timeline:

Where this stands on 8 October 2026: the timeline above follows the rules currently in force. Under the current rules KSeF tokens expire on 31 December 2026. At consultations on 9 June 2026 the Ministry of Finance proposed keeping them (with a validity of 1 to 365 days), but no regulation has been adopted yet, so moving to a KSeF certificate is the safer choice. We covered what the proposal actually changes separately. One thing holds either way: the second QR code (KOD II) in offline modes requires a certificate, and a token will not do that job.

Since February 2026, you apply for a certificate via the KSeF 2.0 API or the official Taxpayer Application, after authenticating with a Polish trusted profile (Profil Zaufany), a qualified electronic signature, or — for companies — a qualified electronic seal.

Why we didn't build token support "just for now"

Honestly? It was tempting. Token integration is technically trivial — attach a key to your requests and you're in. Certificates demand far more: an XAdES-BES signature flow for API authentication, private key management, expiry tracking. The Ministry's technical documentation makes it clear this is a different order of complexity.

But we ran the opportunity cost. Building token support meant weeks of engineering on a mechanism with a published shutdown date. Then a forced migration of every customer — in Q4 2026, exactly when accounting offices hit peak season and KSeF faces its heaviest load since the mandate began. The worst possible moment to ask users to "generate a new credential and reconfigure your integration from scratch."

There was a second, bigger argument: without an Offline-type certificate, there is no second QR code in offline modes. And offline modes aren't an exotic edge case — they're the core business-continuity safeguard in the whole system.

The Offline-type certificate: something tokens never could do

The Ministry of Finance issues two certificate types, generated separately:

• Authentication type — logging into KSeF, in both interactive and batch sessions. The functional successor to today's token.

• Offline type — used for the second QR code (KOD II), confirming the issuer's identity, on invoices in the special modes: offline24, offline during system unavailability, and emergency mode.

The Offline type is genuinely new capability. When KSeF has scheduled downtime, or your internet drops on invoicing day, an invoice issued offline with QR verification codes, the second generated from an Offline-type certificate, is fully valid — you just submit it to the system within the statutory deadline. A token never enabled this and never will.

Biurko has supported both types since our first integration release: the Authentication type handles login, the Offline type signs the second QR code on offline invoices, and verification links plus QR codes are generated automatically under the hood. The user simply sees that the invoice went out in offline24 mode and will be submitted automatically once the system is back.

Example: an outage at 4:40 PM on a Friday

Take a sole proprietor in IT services, the classic last-minute invoicer, who hits a KSeF interface outage right before a weekend. With a token-based tool, he'd stare at a connection error. In Biurko, the invoice goes out in offline24 mode with verification codes, the client receives a PDF with QR codes right away (with an Offline-type certificate), and the document flows into KSeF automatically once availability is restored. Zero action required.

What this decision cost us (the honest part)

So this doesn't read like "our decision was brilliant and painless":

Onboarding got harder. With a token, users pasted a string. With a certificate, they first authenticate with KSeF (Profil Zaufany, qualified signature, or qualified seal for companies), file an application, and download the credential. We built a step-by-step wizard inside Biurko, but let's be real — it's more clicks than pasting a token.

Certificates expire. Maximum validity is 2 years from issuance or a chosen start date. An expired certificate halts the integration. We had to build expiry monitoring and advance notifications — for accounting offices managing dozens of tax IDs, that's a dedicated module, not a side feature.

The learning curve was real. XAdES-BES, key management, NIP/PESEL permission contexts — our first weeks of development were slower than the token route would have been.

Even so, we're migrating exactly nobody: Biurko never connected with a token, so tokens expiring changes nothing for us, whichever way the token question lands. If the current rule holds, our customers face no change on January 1, 2027. If tokens stay under new terms, they still face none, because the second QR code in offline modes still requires an Offline-type certificate. That was the entire bet.

What to do in 2026 — a checklist for token-based integrations

1. Find out what your integration runs on. If your invoicing software connects to KSeF with a token, the date on the books is still December 31, 2026. The Ministry's proposal may lift it, but until there is a regulation, plan as if it stands.

2. Ask your vendor for a concrete migration plan. Specifically: do they support the Authentication and Offline certificate types, and since when.

3. Obtain your certificate early. Apply through the KSeF 2.0 Taxpayer Application after authenticating with Profil Zaufany or a qualified signature. Don't wait for December.

4. Running a company (not a sole proprietorship)? Consider a qualified electronic seal. A certificate issued on the company's NIP may require seal-based authentication, and procurement takes time.

5. Plan certificate governance. Separate certificates for the owner, the accounting team, and each sales system mean revoking one doesn't paralyze the rest.

6. Track the expiry date. Certificates last at most 2 years — set a renewal reminder or use a tool that watches it for you.

Bottom line

KSeF tokens were a bridge solution. The rules in force close that bridge on December 31, 2026, and the Ministry of Finance has proposed keeping tokens permanently on a short validity — no legislation has settled it yet. Either way, certificates aren't just a new login method: they're the only path to the second QR code in offline invoicing modes and a cleaner access-management model.

With Biurko there's no migration to plan, because Biurko never connected with a token: you connect with a Trusted Profile (the default) or a certificate, and for steady, automatic operation you order a KSeF certificate in Biurko after the first connection with a Trusted Profile, with automatic expiry monitoring (Authentication and Offline types). Create an account at biurko.io (every new company gets 14 days of the TEAM plan without a card, then moves to the free FREE plan) and enter 2027 with zero technical debt. To practise without legal effect, use the Biurko demo (demo.biurko.io, 7-day access, the KSeF demo environment); an account on app.biurko.io sends invoices to production KSeF, so every invoice you send there is real.

FAQ

When do KSeF tokens stop working?

Under the current rules KSeF tokens expire on 31 December 2026. At consultations on 9 June 2026 the Ministry of Finance proposed keeping them (with a validity of 1 to 365 days), but no regulation has been adopted yet, so moving to a KSeF certificate is the safer choice. During the transition (from February 1, 2026) both run in parallel, and the second QR code in offline modes stays reserved for certificates.

What is a KSeF certificate?

A KSeF certificate is an electronic identity credential used to authenticate with Poland's national e-invoicing system, similar in concept to a qualified signature. Unlike tokens, it carries no embedded permissions — KSeF checks the holder's current permissions at each login based on their NIP or PESEL identifier.

What's the difference between Authentication-type and Offline-type certificates?

Authentication-type certificates authenticate you in KSeF for interactive and batch API sessions. Offline-type certificates produce the second QR code (KOD II) on invoices issued in offline modes (offline24, system unavailability, emergency mode). They're issued separately — one certificate can't cover both uses.

How do foreign-owned companies in Poland get a KSeF certificate?

The company applies via the KSeF 2.0 API or Taxpayer Application after authenticating, for example with a qualified electronic seal issued on the company's Polish NIP. The certificate is valid for up to 2 years, and the company can issue multiple certificates for different teams or systems.

What happens if I'm still on a token in 2027?

As the law stands today, token-based authentication stops working on January 1, 2027 and your invoicing software loses its KSeF connection. If the Ministry's proposal becomes law, tokens keep working but on a validity counted in days and still without the second QR code in offline modes. Under the current act, penalties under Article 106ni of the VAT Act apply from 1 January 2027. On 16 September 2026 the Ministry of Finance announced it will move them to 1 January 2028; that is a bill not yet passed, and it moves only the penalties, not the obligation to use KSeF. Holding a certificate early beats betting on a rule change.