A new token for KSeF (Poland's National e-Invoicing System) is valid for 365 days rather than forever: that is what the Ministry of Finance draft regulation of 27 October 2026 says. A week later, on 4 November, a parliamentary committee adopted a bill moving the penalties for KSeF errors to 1 January 2028. Read together, those two pieces of news sound like "we have time". They mean something else: the date on which your invoices may stop going out has moved to the day your token expires. And nobody is going to remind you about it.
I am writing this as a business owner, not an engineer. In a company that sends invoices automatically out of Subiekt nexo (a Polish ERP by InsERT) or an integration next to it, deferred penalties change nothing this week. Two other things do: a date in the calendar and a version number.
What moved on 4 November, and what stays
On 4 November 2026 the Public Finance Committee of the Polish parliament adopted a bill under which penalties for KSeF errors start on 1 January 2028 rather than at the beginning of 2027 (a report from the committee sitting). I am not quoting amounts, because they depend on the final wording and on the type of breach. If somebody at your company is counting on a specific number, check the current legal position with your accountant rather than with a headline.
Two caveats are easy to lose behind the words "KSeF postponed". First: this is a bill that has passed a committee, not law in force. A vote in the lower house, the Senate and a signature are still ahead of it, so until then no date is certain. Second, and more important for you: the penalties moved, the obligation did not. An invoice that does not reach KSeF still does not reach your customer, and at that point it hardly matters whether the tax office issues a fine. The money is stuck either way.
| What | Position after 4 November 2026 | What it means for you |
|---|---|---|
| Penalties for KSeF errors | The bill moves them to 1 January 2028 | A year more to tidy up exceptions, not to start |
| The duty to issue invoices in KSeF | Unchanged | Sending has to work every day, penalties or not |
| Validity of a new token | 365 days, draft regulation of 27 October 2026 | One calendar entry a year, for every token |
| Tokens issued under the old rules | Per the draft, until 30 November 2027 at the latest | Work that date out separately: it may fall earlier |
| Subiekt nexo | 62.0 on 21 October, the 62.0.2 fix on 3 November 2026 | Update before the peak, not in the middle of it |
Scroll the table sideways
Three numbers from this week, because they come back in every decision below:
- new KSeF token validity, per the draft
- 365 days
- penalties, per the bill
- 1 Jan 2028
- the Subiekt build with the fix
- 62.0.2
The KSeF token: 365 days of validity instead of forever
A token is a string your software uses to authenticate itself in KSeF instead of signing every invoice with the owner's own signature. You generate it once and paste it into Subiekt or into the integration that sends the documents. Until now it worked for as long as nobody revoked it, so after go-live nobody thought about it again. The draft regulation of 27 October 2026 changes that: a new token is valid for 365 days, and tokens generated under the old rules are to work until 30 November 2027 at the latest (a write-up of the draft).
From an owner's seat this is a move from a one-off implementation to a recurring duty. And a duty of the worst kind: once a year, quietly, with no prompt from any system, usually towards the end of a month, because that is when somebody happened to finish the implementation a year earlier. On top of that, the token rarely sits in one place. In a company selling through several channels, KSeF is called by Subiekt, by the shop integration and by the marketplace tool, and each of them has its own token and its own date.
Before you read on, put the date your token was generated into the calculator below. If you do not know it, that is the first thing to settle this week: the answer sits with whoever implemented KSeF, with your Subiekt vendor or with your accounting office. The calculator sends nothing to any server; it works it out in your browser.
- Calculator
KSeF deadlines for your token
Enter the date your token was generated and pick your Subiekt nexo build. The calculator works out the expiry date, two calendar reminders and a checklist to go through before you swap it.
Sample date: 1 December 2026. Swap it for your own.
Subiekt nexo build
Deadlines for this date
- The token expires
- 1 December 2027
- Reminder, 30 days before
- 1 November 2027
- Last calm day, 7 days before
- 24 November 2027
If this token still comes from the old rules, the draft regulation cuts its validity to 30 November 2027 at the latest. That earlier date then applies, not the one above.
Before you swap the token
- 62.0.2 and newer already carry the second-correction fix. One test is left: issue a correction to a correction on test data and check its status in KSeF.
- Write down who generates the token and whose authorisations it uses. A year from now that is the first question nobody will be able to answer.
- Check how many places this token sits in: Subiekt, the shop integration, the marketplace tool, a script from your accountant. Swapping it in one place stops the sending in the rest.
- Agree the scope of the new token with your accountant before you generate it. A token narrower than the previous one looks like it works, right up to the invoice it has no right to send.
- After the swap, issue one test invoice and check that it came back with a KSeF number. Without that, the first test is a customer's invoice.
- Do the swap with time to spare, not on the expiry day. A week is enough for a mistake in the authorisations not to stop the sending.
To paste into your calendar
KSeF: the token expires on 1 December 2027 1 November 2027: Generate a new KSeF token and swap it in every system 24 November 2027: Last day to swap the KSeF token without rushing
The calculator counts 365 days from the date you enter, following the Polish Ministry of Finance draft regulation of 27 October 2026. It is a draft rather than law in force, so check the current legal position before you decide anything. The type and scope of the token is your accountant's call, not this calculator's.
The calculator counts 365 days from the date you enter and works back two reminders: 30 days before, so there is time to settle the new token's authorisations, and 7 days before, the last moment when the swap is still boring. It also warns you when the date falls on a weekend, in the last days of a month, or past the 30 November 2027 ceiling after which tokens issued under the old rules stop working anyway. That is not fussiness: on the 28th nobody at the company has the headspace to generate tokens.
Subiekt nexo 62.0 and 62.0.2: corrections in KSeF
The second change from the same period is narrower, but it concerns the program you work in directly. InsERT released Subiekt nexo 62.0 on 21 October 2026 and the 62.0.2 fix on 3 November. Both releases circle around corrections in KSeF: 62.0 changes how collective discount corrections are handled and shows the KSeF number next to settlements, while 62.0.2 repairs sending a second correction for the same invoice. The full list is in InsERT's change log and it is worth reading before you update, because it runs longer than those three points.
Why this is an owner's problem and not only an engineer's: a second correction to the same invoice is not an edge case. It turns up with a post-sale discount, with a price corrected twice and with a partial return. If you are running 62.0 or 62.0.1 and somebody at the company says "the correction will not go through to KSeF", it is probably not their mistake but a version number. Worth knowing before anybody starts issuing corrections by hand next to the system.
| Your build | What to do with it | When |
|---|---|---|
| Older than 62.0 | Update the program first, swap the token afterwards | December, outside the invoicing peak |
| 62.0 or 62.0.1 | Install 62.0.2 before a second correction to the same invoice comes up | This month |
| 62.0.2 or newer | A test: a correction to a correction on test data | At the next review |
Scroll the table sideways
You do not update Subiekt on the last day of the month, nor on the day the biggest batch of invoices goes out. The order is boring, which is exactly why it works: a database backup, the update, one test invoice, one test correction, a check of the status in KSeF. For us a review like that takes a few hours, assuming nothing surprises us. Your engineer or your Subiekt vendor will give you their own figure, and it is their number, not mine, that goes into the calendar.
Three places where sending stops in mid-month
Three places keep coming back in our conversations and implementations as the ones where automatic invoice sending stops. None of them has anything to do with penalties, so deferring the sanctions takes not a single one of them off your plate.
An expired token. The date the calculator above worked out. With 365-day validity this stops being theory and becomes a calendar entry that either exists or does not.
An old build of the program or the integration. The Subiekt build numbers are above, but the same trap sits in an integration written to order: if nobody has touched it since go-live, then nobody has checked whether it still talks to KSeF the way it should. KSeF changes its schemas, so code that worked in August may refuse a new document type in December. The question "when did somebody last check this" matters more here than "does it work".
No notification about a failed send. The most expensive of the three, because you cannot see it at all. The automation tries to send, gets an error, writes it to a log and carries on. A week later you have dozens of invoices with no KSeF number and nobody who knows. A good integration does not hide that: it puts the document in a queue, retries, and when it cannot cope it writes to a named person, with the document number and the reason. There is more on where Subiekt and Sfera can surprise you in a separate post on the pitfalls of integrating with nexo.
A plan for December: from a token list to a correction test
You need no project and no budget. You need half a day of somebody's attention and a few calendar entries. The order matters: it starts with establishing the facts, not with an update.
- 01Establish the generation date of every KSeF token at the company and put it on one list: the system, who generated it, what authorisations it has. One sheet of paper is enough, as long as there is only one.
- 02Work out the expiry and reminder dates, with the calculator above if you like, and drop them into the company calendar rather than a private one. A reminder with no name on it wakes nobody.
- 03Check your Subiekt nexo build and schedule the update outside the invoicing peak. On 62.0 and 62.0.1 the 62.0.2 fix goes first.
- 04Issue one test invoice and one correction to a correction, then check that both came back with a KSeF number. Five minutes that replace hope.
- 05Write into your procedures who receives the message about a failed send and how quickly they react. If nobody receives it today, that is the first thing to fix, ahead of the token and ahead of the version.
- 06Ask the vendor of every tool that sends invoices what happens when the token expires, and whether you will be notified before your customer is.
The cost of this plan is time, not an invoice. If it turns out that your invoices are sent by a tool nobody at the company can check, that is a separate conversation and a separate decision, but better to have it in December, while nothing has stopped yet.
What if Apilo, BaseLinker or a custom integration sends the invoices
At many companies Subiekt is not the only place an invoice comes out of. Orders run through Apilo or BaseLinker, the shop issues some of the documents, and foreign sales add a path of their own. Each of those tools authenticates itself in KSeF separately, so behind every expiry date there is a different vendor who either knows about it or does not.
Three questions worth sending them in a single e-mail. First: do you send my invoices to KSeF with your token or with mine, and where is it stored. Second: what happens when the token expires, and will I be notified before my customer notices. Third: which version of your tool supports the current KSeF schemas, and when did you last check that. An answer along the lines of "we will check and come back to you" is also an answer; it just needs writing down with a date.
If the integration is your own, the questions are the same and only the recipient changes. That is how it works on our side: an integration we build stands on your side and its code stays with you, so when authentication rules or document schemas change, one place in the code and one deployment change with them, rather than the process of the whole company. In return, somebody has to know about that one place and have somebody to call, so the name and the contact for whoever looks after the code go on the same sheet as the token dates. More on how we draw that line is on the page about process automation.
For the record, two of our own implementations, with no promises attached. For a seller on five Amazon EU marketplaces we built an application next to Subiekt nexo PRO: it establishes the country and the VAT rate and issues the invoice through Sfera. 100 percent of invoices are created with no manual work and the implementation took 3 weeks (automatic VAT invoices). At an appliance wholesaler the same mechanism tied together a B2B portal, a sales rep application and Subiekt, and the company counts around 180 hours less work a month (a B2B platform). What is missing from both examples: no automation will remind you about a token if nobody entered that reminder.
If the review shows that your invoice sending rests on something you cannot check, the next step is an audit for PLN 699 net: the architecture, the scope, the risks, a fixed price and a deadline, deducted in full from the implementation price. If an update and one calendar entry are enough, we will say so plainly and no audit will be needed. What automation like this costs in total is written up in a separate post on costs.
