How Polish Accounting Firms Are Managing KSeF Tokens for 50+ Clients at Once

--

If you run an accounting firm in Poland, the past year has meant one thing above everything else: KSeF. The National e-Invoice System (Krajowy System e-Faktur) has dominated compliance conversations for months, and for good reason. But most of the public discussion focuses on the invoice format itself. What gets far less attention is the authentication layer, and that is where the real operational headache lives.

One Token Per Client, Multiplied by 50

KSeF uses a token-based authorization model. Each company registered in the system can generate API tokens that allow authorized software to send and receive invoices on its behalf. Simple enough in theory. In practice, when you are a bookkeeper managing the finances of 50, 80, or 150 businesses, you suddenly have 50 to 150 separate tokens to generate, store, rotate, and track.

Each token is tied to a specific NIP (Polish tax identification number). Each one has its own permissions scope, its own expiration window, and its own generation date. If a token gets revoked, the connected software stops working silently. If you store tokens in a shared spreadsheet and someone leaves the company, that spreadsheet is now a security liability. And if a client asks you to revoke their access immediately, you need to find the right token fast, not scroll through rows in a Google Sheet under pressure.

This is not a hypothetical. It is the daily reality for hundreds of Polish accounting offices right now.

What KSeF Actually Requires Under the Hood

KSeF authentication works through the Ministry of Finance API. You can find the full technical terminology explained in the KSeF glossary, but the short version is this: to interact with the system on behalf of a taxpayer, your software needs a valid session token. To get a session token, you first need an authorization token that was granted by that taxpayer.

The authorization token is generated in the KSeF production environment by the company’s NIP holder, or someone they explicitly delegate. Once you have it, you use it to open sessions and send or receive invoices. The token does not expire on a fixed schedule, but it can be revoked by the client at any time, and it is specific to the NIP it was issued for.

The technical flow is straightforward for a single client. Multiply it across dozens of clients, with different delegation setups, different software configurations, and different client expectations for how often credentials should rotate, and the complexity becomes real.

How Firms Are Actually Handling This

From conversations with accountants working in this space, there are roughly three approaches in active use right now.

The first is a spreadsheet or text document. It works, technically. Firms list client NIP, token value, date of generation, who generated it, and maybe a rotation reminder. This approach is fine for five clients. At thirty it becomes fragile. At eighty it is a genuine liability, both operationally and from a data security standpoint.

The second approach involves password managers like 1Password or Bitwarden. Better than a spreadsheet for security, but these tools were not designed for structured credential management across dozens of businesses with context-specific fields. You end up with messy folder structures and no way to see at a glance which tokens are stale, which clients have not yet delegated access, or whether a token belongs to the production environment versus test.

The third approach, where firms with larger client books are moving, is dedicated tooling. The idea is simple: a system that stores KSeF tokens alongside client NIP data, tracks their status, and integrates directly with the invoicing workflow. No copy-pasting between a credential vault and an invoicing app. No switching tabs to check whether a token is still valid before sending a batch of invoices.

This operational challenge is exactly what shaped the design of FakturaFlow. The platform was built from the start for accounting firms handling KSeF access for multiple clients, with token management treated as a core part of the data model rather than bolted on afterward. When you are sending invoices for forty clients in a single morning, the token is not a side detail, it is part of the critical path.

The Pattern That Keeps Emerging

The firms that struggle most with KSeF are not struggling with the invoice format. The XML schema, the mandatory fields, the FA namespace, those are learnable problems. The struggle is operational: credentials, delegation chains, permissions, client communication about access, and what happens when a token breaks something at 4pm on a Friday.

The firms handling it smoothly have made a deliberate choice about where token data lives and how that storage connects to their daily invoicing work. That choice is worth making explicitly, before something breaks at an inconvenient moment.

If you are managing KSeF access for a larger client book, how are you currently handling token storage and rotation? Spreadsheet, password manager, custom solution, or something else entirely?