E-Invoice Finder
Menu
Countries Compare software Deadlines Guides Checker Check obligation
ENFRDEPLNL
Poland · accounting access controls

How to build a KSeF permissions matrix for accounting firms

Build a least-privilege KSeF permissions matrix for accounting firms, client teams and shared services, with role examples, tests and offboarding controls.

Quick verdict:
  • Treat a client switch as a controlled boundary, not a dropdown convenience.
  • A successful login proves identity, not authority to perform every operation.
  • Retain denial results: they show that the boundary works when it matters.
Get Poland readiness reportOfficial sources
Last checked: 26 July 2026Based on official sourcesClear summaryBusiness guidance, not legal advice
Official sources prioritized
Last-checked dates visible
Free checker, no signup required

What you need to know

Guide

1. Set the practical scope before assigning access

Start with the services actually delivered for each client: invoice preparation, issuing, retrieval, bookkeeping, corrections, exception handling and permission administration. The Ministry of Finance advises accounting professionals to map client workflows, update agreements and cooperation rules, check accounting-software integration, choose a supported authentication method and test issuing and receiving in test and pre-production/demo environments. Create one register covering each client NIP, service, application, environment and owner. For every workflow, record who initiates and approves it, the required KSeF operation and who handles failure. Include shared services and outsourced bookkeeping, but do not give technical support invoice access merely because it maintains the connector. Use synthetic data outside production. Recheck current KSeF tools and the contract before launch because delegation paths may change.

Guide

2. Separate identity, authentication and authorization

Identity answers who or what is acting. Authentication proves that identity through an officially supported method. Authorization determines what the authenticated identity may do for a particular client. Keep these as separate columns in the matrix: an authentication success must never be treated as proof that issuing, viewing or rights administration is allowed. Record the identity type, authentication method, client context, operation, expected authorization and local role. Never share personal credentials, certificates or private keys, or place secrets in tickets. Ministry guidance distinguishes owner rights such as managing rights, managing subordinate units and viewing rights, and says owner rights cannot be withdrawn. Treat owner access as exceptional and monitor it closely. Assign named custodians for company credentials without giving them unrestricted business authority.

Guide

3. Design the client-to-firm grant and internal allocation separately

The client must grant the accounting firm appropriate KSeF rights. Model that external grant separately from the firm's allocation of work to named employees where the current KSeF model and the agreement support it. The external record should identify the client, firm, scope, approver and review date. The internal record should identify each worker, assigned clients, tasks, local role and manager. Choose deliberately between direct rights for a named accountant, rights associated with the firm, or another currently supported arrangement. Verify any delegation, relinquishment or inheritance behavior in official tools and API, and document it in the contract. Official tutorials distinguish granting a natural person rights for one selected client versus all clients and show withdrawal of a right; use the narrowest suitable scope. Where a company needs to designate an authorised person, the applicable ZAW-FA route may be relevant, but it is not a universal requirement for every entity or user.

Guide

4. Build a role matrix around concrete operations

Use operations rather than job titles. A retrieval bookkeeper may need viewing but no issuing or rights management. An accounts-receivable issuer may need issuing for selected clients but no viewing beyond what the workflow requires. A client-access administrator may manage rights, while the ability to grant further rights should be separately justified and tightly restricted. A supervisor may review queues and logs without receiving administrator access. For every role, mark view, issue, manage rights and grant further rights as Allowed, Denied or Not applicable; add client scope, time limit, approver and evidence. Avoid bundled ‘full accountant’ roles. Separate invoice processing from permission administration, and require a second approval for broad or further-grant capability. Official material lists issuing, viewing, managing rights and granting further rights, but verify combinations and indirect access in the current KSeF interface/API and contract.

Guide

5. Enforce multi-client segregation and shared-service boundaries

A worker serving several clients should enter an explicit client context before viewing, issuing or reconciling. Display the client name and NIP prominently, clear prior-client results and keep imports, queues, exports and error files partitioned. Disable an ‘all clients’ view unless a documented need outweighs the exposure. Shared-service teams should maintain client-specific queues, approvals and reconciliation totals. Test that a file, API request or deep link prepared for Client A cannot be submitted or viewed under Client B. Monitor unexpected client switching, cross-NIP searches, exports and permission changes. Reconcile KSeF results by client and date. If a platform uses indirect rights through the accounting firm, verify in current official tools what the client can see about individual workers; the Ministry's FAQ raises this question, so do not promise visibility that has not been demonstrated.

Guide

6. Control joiners, movers, leavers, cover and subcontractors

For a joiner, require approval, training, a named identity, a client list and passed access tests. For a mover, remove old duties before adding new ones. For a leaver, disable local accounts, withdraw applicable KSeF rights, remove deployed authentication material, terminate sessions, review activity and retain evidence. Temporary cover needs a named sponsor, exact clients, limited operations and automatic expiry. Subcontractors need explicit scope, named operators, secure authentication, controlled delegation, incident duties, logs and a tested exit. Never lend a departing employee's credential or private key to their replacement. Also verify what happens to any delegated rights when an administrator or intermediary loses access; current official FAQs raise this scenario, and the safe operational response is to test and reconcile rather than infer.

Guide

7. Run six acceptance scenarios and preserve evidence

Run these scenarios in the closest safe KSeF environment, then repeat production-safe checks after release. Capture identity, client, expected result, timestamp, redacted trace, application log and reviewer. 1. View allowed: a retrieval user opens a synthetic invoice for Client A; confirm success and an attributable log. 2. View denied: the same user requests Client B, which is outside scope; confirm denial and no data leakage in search, cache or export. 3. Issue allowed: an authorised issuer submits a synthetic Client A invoice; match its result to the job and reconciliation record. 4. Issue denied: a view-only user attempts submission; confirm the request fails before or at authorization and creates a useful event. 5. Administration boundary: an issuer attempts to manage or grant rights; confirm denial, while an approved administrator completes the controlled change with approval evidence. 6. Lifecycle removal: withdraw a test user's access, terminate local access and retry view, issue and client switching; confirm all are denied and reconcile the current rights record. Treat unexpected success as a release blocker. Keep timestamps, non-secret identifiers and before-and-after rights records, not screenshots alone.

Guide

8. Allocate mistakes, incidents and contractual responsibilities

Common failures include using a broad role for convenience, confusing login with permission, granting access to the wrong NIP, leaving temporary cover active, sharing a personal credential, or assuming local application removal also withdraws KSeF rights. Another risk is unclear ownership: the client expects the firm to investigate while the firm expects its software vendor to retain the decisive logs. The agreement and procedure should assign approval, reviews, KSeF and application logs, reconciliation, monitoring, incident response, access withdrawal and communication. Define evidence retention and escalation times. For suspected misuse, contain access, preserve logs, identify affected clients and invoices, withdraw or replace compromised access as appropriate, reconcile activity, correct the configuration and retest. Do not delete evidence or circulate private keys. Seek qualified advice for legal, tax, employment or notification obligations.

Guide

9. Apply decision criteria and take the next actions

Approve the design only when every production task has a named accountable role, client scope, supported authentication route, minimum KSeF rights, local-system control, test result and review date. Reject shared personal identities, unexplained ‘all clients’ scope, undocumented further-grant capability and untested denials. Escalate unresolved owner-right exposure and missing audit records. Next, ask each client to confirm its services and grant model; reconcile current KSeF rights with contracts and the matrix; remove stale or excessive access; test software integration in the official test and pre-production/demo environments; and run the six scenarios. Use current KSeF interface/API evidence, not old screenshots or FAQ interpretations. Review after staffing, service, software or delegation changes and periodically thereafter.

Checklist

List every client NIP, contracted KSeF service, application, environment and accountable owner.

Separate identity, authentication method, KSeF authorization and local application role in the matrix.

Document each client's grant to the accounting-firm entity separately from named-worker allocation where used.

Mark view, issue, manage rights and grant-further-rights capability as Allowed, Denied or Not applicable for every role.

Require explicit client-context selection and segregate queues, files, exports, caches and reconciliation records.

Remove old scope before adding new scope for movers, and retain evidence for joiners and leavers.

Time-limit temporary cover and subcontractor access, with named sponsors and no unapproved onward delegation.

Run all six positive and negative scenarios and retain redacted responses, logs and before-and-after rights records.

Assign contractual ownership for approvals, reviews, logs, reconciliation, incidents, withdrawal and evidence retention.

Reconcile the approved matrix against the current KSeF interface/API after every material change and periodic review.

FAQ

Should KSeF rights go to the accounting firm or a named accountant?

Compare current client-to-firm and direct-to-person arrangements against continuity, accountability, segregation and offboarding. Keep the client's grant separate from internal allocation where used, and verify the route in current KSeF tools and the agreement. Never share a person's credential or private key.

Can an accounting firm have view-only or issue-only access?

Official material identifies viewing and issuing as distinct rights, while the 27 April 2026 FAQs raise view-only and issue-only questions. Do not infer a guaranteed combination from a question alone. Confirm it in the current interface/API, test allowed and denied actions, and record the agreed scope.

Does each client need to grant KSeF access?

Ministry guidance says clients must grant the accounting firm appropriate rights. Keep a grant and approval record for each client rather than treating a contract or software account as KSeF authorization. Verify the scope and withdrawal behavior of any broader arrangement.

How should a firm separate KSeF access across multiple clients?

Use client-specific assignments, explicit NIP selection, segregated queues, visible context, per-client reconciliation and cross-client denial tests. Limit all-client views and bulk exports. A user serving Clients A and B must still be unable to reach Client C.

Can accounting-firm staff delegate rights to other staff?

Do not assume they can or should. Granting further rights needs a documented reason, narrow scope and stronger approval. Official material discusses grant paths, withdrawal and intermediary behavior, but verify the exact result in current official tools/API and the contract.

What should happen when an accountant leaves or changes role?

Remove obsolete client scope, disable local access, withdraw applicable KSeF rights, remove deployed authentication material, terminate sessions and review activity. Test that viewing, issuing and administration are denied. For role changes, remove old permissions before adding new ones.

Can a client see which accounting-firm employee has indirect rights?

The published FAQ raises this question but does not justify a universal answer. Demonstrate visibility in the current KSeF interface, document what each party can audit, and close gaps with named internal assignments and logs.

Who should own KSeF logs and incident response?

Assign ownership in the agreement and runbook. State who supplies logs, reconciles activity, monitors anomalies, contains access, withdraws rights and contacts affected parties. Test evidence retrieval before an incident and seek qualified advice on notification duties.

Key regulations, formats and terms

PolandKSeFKrajowy System e-FakturPolish Ministry of Financepodatki.gov.plstructured invoiceAPI authenticationinvoice correctionsaccounting softwareVATSMEecommerceEuropean CommissioneInvoicingEN 16931Directive 2014/55/EUstructured electronic invoiceVAT automationcross-border tradeKSeF permissions matrix for accounting firms and shared-service teams

Poland — Country hub

Poland

Open country hub →

Use the country hub to see every related deadline, checklist, format guide and software comparison for this market.

Continue reading

Official sources

We prioritize official government and EU sources where available and keep last-checked dates visible for mandate-sensitive pages.