KSeF permissions in an accounting office: 40 clients, 40 different kinds of access, and the list nobody keeps

The Access Nobody Wrote Down

Ask an accounting office owner how many clients they serve in KSeF and you'll get a number within a second. Ask how each of those clients gave the office access, and you'll get a pause.

This post is about that pause. For the last three weeks I've written about bank statements in enova365, Optima and nexo. Today I'm going back to KSeF, because there's a problem here that no ERP setting fixes: the access itself.

Between January and April 2026 every office went through the same scramble. Forty clients, forty phone calls, forty times "please log in to the Aplikacja Podatnika and click this". Each client did it slightly differently, because each one was guided by a different person on a different day. It worked, and invoices started flowing. But nobody wrote down what was actually granted, to whom, and how.

That's fine until one of three things happens: an accountant leaves, a certificate expires, or a client changes who manages their permissions. Then you discover that your office's access to KSeF isn't one setup. It's forty separate decisions made by forty clients, and you have no list of them.

Four Ways a Client Can Grant Access

In KSeF 2.0 the client decides how the office gets in. The differences between the options only show up later.

Entity-level (podmiotowe), with delegation. The client grants a permission to the office's NIP and ticks the option allowing the office to pass it on to its employees. The office then decides who in its team issues or reads that client's invoices. When someone leaves, the office removes them itself. This is the shape you want for every client.

Entity-level, without delegation. The client grants to the office's NIP but doesn't tick delegation. On the phone it sounds identical. In practice, though, the office's ability to hand work to a specific person is limited, and each staff change can mean going back to the client.

Personal (osobowe) to a named accountant. The client grants the permission to Anna's PESEL or NIP. It's the fastest to explain on the phone ("just type in Anna's details"), and I'd guess it's what a good share of offices ended up with for their smaller clients. The catch: the permission belongs to Anna, not to your office.

Personal to the client's own staff, with the office using their credentials. Nobody admits to this one, but it exists: the client's bookkeeper logs in and the office works through them, or a token was generated on the client's side and emailed over. The office has access, and KSeF has no trace of it.

Then there's the scope. The permission types include issuing invoices, access to invoices and managing permissions. An office that only reads purchase invoices for booking needs less than one that also issues sales invoices for the client. Grants were made in a hurry, so plenty of offices hold more scope than they use. Or less than they think.

Tokens, Certificates and the ZAW-FA Person

The second layer is how your software authenticates.

Tokens from KSeF 1.0 don't work in 2.0. New ones could be generated from 1 February 2026, and the Ministry of Finance has said token authentication stays in KSeF 2.0 without an end date. Convenient, yes. It's also exactly why nobody tracks tokens: they don't expire, so they get forgotten. That includes the ones sitting in an old integration nobody has touched in months.

KSeF certificates are the opposite. They're valid for at most two years from issue. Most offices that moved to certificates did it in the first months of 2026, which means a cluster of renewals will arrive in early 2028, all at once, during the busiest part of the year. If your integration runs on a certificate, its expiry date belongs in a calendar with a name next to it.

The third piece sits on the client's side, and you have no control over it. A company without a qualified seal designates one person with the ZAW-FA notification, and that person then manages permissions electronically. Since 2026, ZAW-FA can't be filed effectively through ePUAP. It goes through e-Urząd Skarbowy, e-Doręczenia or on paper. If the client's ZAW-FA person leaves, the client files a new ZAW-FA. Until then, nobody at the client can change your access. Not even to fix it when it breaks.

You need to know who that person is at each client. Not their login. Their name and phone number.

The Register: One Afternoon, Nine Columns

Here's what to build. One row per client, nine columns:

1. Client NIP and name
2. Grant type: entity-level with delegation / entity-level without / personal / none visible
3. If personal: which person (and are they still on staff?)
4. Scope: issuing, access to invoices, permission management
5. Who at the office actually works with this client in KSeF
6. How your software authenticates: token or certificate
7. Certificate expiry date, if any
8. The client's permission manager (the ZAW-FA person or their delegate), with a phone number
9. Date last verified

Most of it you can read from the Aplikacja Podatnika and from your integration settings. Column 8 you'll have to ask for. For 40 clients, it's an afternoon, maybe two.

So what does a first pass usually turn up? I'll describe a hypothetical 40-client office, because the pattern tells you more than any single number. Most clients sit in the first bucket. A handful have personal grants to one or two people. One of those people left in the spring. Two or three clients have no visible grant to the office at all, because the work runs through the client's own login. And a couple of integrations still hold a token that nobody remembers creating.

The row that matters most is the personal grant to someone who's left. That person can, in principle, still read those clients' invoices. This isn't a technical problem. It's a data-protection problem with your office's name on it, and you can't fix it without the client. Which is exactly why it has to be on a list.

Why This Is an Agent's First Job, Not Its Last

When I plan an agent for an office, KSeF access is the first thing that breaks it. Not the model, not the booking logic. The agent downloads purchase invoices for 40 clients using the office's credentials. If three of those clients quietly lost access, the agent doesn't fail loudly. It reports "no new invoices", which looks exactly like a quiet week.

It's the same trap as the unwatched nightly job I described in the enova365 scheduler post. "Nothing arrived" and "we can't see anymore" produce the same empty result.

So the first build is read-only, and deliberately dull:

• Every night, try to read invoice metadata for each client in the register. An access error goes to a named person as an alert, not into a log file.
• Every week, list certificates expiring within 60 days, plus any personal grants held by people no longer on the staff list.
• Every month, flag the clients whose "last verified" date is older than 90 days.

The agent grants nothing and revokes nothing. Permission management is exactly the level-four action from my post on liability: it stays with a person who can be named in under a minute. The agent's job is simpler: that person hears about the problem before the client does.

There's a link to the access lag too: the days between "we agreed" and "the connector has working credentials". With a register, an office can tell me on day one which clients are ready. Without one, the first two weeks of every project go on finding out.

Two Numbers to Take Away

If you do nothing else this week, count two things:

1. The share of clients on entity-level access with delegation. That's the only shape where staff changes are your office's business alone. Aim for every client, and use your next conversation with each one to move them across.
2. The number of personal grants held by people who no longer work for you. The target is zero. Get there by the end of the month.

If you'd like a second pair of eyes on the register, send me the anonymised columns and I'll tell you which clients to call first.