| |

KSeF Token – what it is, how it works, and what to watch out for in practice

With the mandatory implementation of the National e-Invoicing System (KSeF), the concept of the KSeF token appears more and more frequently. For many entrepreneurs, it sounds technical and abstract, while at the same time it is of key importance for access security to invoices and the proper functioning of accounting systems.

In this article, I explain what a KSeF token is, how it works, what it is used for, and what risks are associated with its incorrect use.

What is a KSeF token?

A KSeF token is a special string of 40 characters (an access key) used for authentication and authorization when connecting to the National e-Invoicing System.

In practice, a token:

  • replaces the need to log in to KSeF each time using a qualified electronic signature or a trusted profile,
  • enables accounting systems and applications (e.g. invoicing software) to access KSeF,
  • operates within a specific scope of permissions assigned at the moment of its generation.

The most important point: whoever has the token technically has access to KSeF within the scope of the permissions assigned to that token.


How is a KSeF token generated?

A KSeF token is generated:

  1. after prior authentication in KSeF (e.g. using a qualified electronic signature),
  2. by specifying the scope of permissions,
  3. by generating the token within the system.

The token may then be:

  • entered into accounting software,
  • used by an accounting office,
  • applied in an API integration (e.g. ERP systems or sales platforms).

From that moment on, the system does not “know” who physically uses the token – only the fact that the token itself is being used matters.


What permissions can a token have?

This is one of the most frequently underestimated aspects.

A KSeF token is not only a login – it contains specific capabilities, such as:

  • issuing invoices,
  • viewing invoices,
  • retrieving data from KSeF,
  • accessing historical data.

In practice, this means that:

  • one token may grant very broad access,
  • granting excessively wide permissions can be risky,
  • configuration errors in the token may result in unauthorized actions.

A KSeF token = sensitive data

The Ministry of Finance explicitly indicates that a KSeF token should be treated as critical data, similar to:

  • online banking passwords,
  • API keys,
  • login credentials for financial systems.

Why?

Because:

  • a token can be copied,
  • a token can be passed on,
  • the system does not distinguish who is actually using it.

If a token falls into unauthorized hands, the consequences may be very serious: from unauthorized invoice issuance to full access to a company’s financial data.


The most common mistakes made by entrepreneurs and companies

From accounting practice, I most often encounter the following problems:

1. One token “for everything”

One token, one full set of permissions, used by:

  • the business owner,
  • the accounting office,
  • the system integrator,
  • the invoicing software.

This creates enormous operational risk.

2. Sending the token by e-mail or messenger

A token sent by e-mail = a token potentially taken over.
There is no technical control over who and when uses it.

3. No control after an employee leaves or an accounting office changes

Tokens are often:

  • not revoked,
  • “left behind” in old systems,
  • still granting access even though cooperation has ended.

4. No emergency procedure

Many companies do not know:

  • how to revoke a token,
  • who is responsible for its security,
  • how to quickly block access in case of an incident.

Token and tax liability

An important and often overlooked issue:

➡️ The taxpayer is responsible for what happens in KSeF.
Even if the invoice was issued “by the system” or “by the accounting office”.

If the token:

  • was shared without control,
  • had overly broad permissions,
  • was not properly secured,

then, as a rule, the responsibility still rests with the taxpayer.


How to safely use KSeF tokens – recommendations

From a practical perspective, I recommend:

  1. Minimum permissions
    Create tokens only with the permissions that are strictly necessary.
  2. Separate tokens for different roles
    Use separate tokens for:
  • invoicing software,
  • the accounting office,
  • technical integrations.
  1. Control and documentation
    Know:
  • who generated the token,
  • what it is used for,
  • where it is applied,
  • when it should be revoked.
  1. A token revocation procedure
    A change of accountant, integrator, or employee = revocation of the token.

Summary

A KSeF token is a powerful tool, but at the same time a serious risk if it is used without awareness of its consequences.

This is not a “technical detail” to be handled by a programmer or an accountant.
It is a system element that directly affects:

  • data security,
  • tax liability,
  • the risk of errors and abuse.

For this reason, KSeF tokens should be managed consciously, carefully, and with clear procedures, not “quickly and ad hoc”.