Several Companies, One System: Invoicing Across a JDG and a Spółka Without Chaos

Polish law allows one sole proprietorship (jednoosobowa działalność gospodarcza, JDG) per person. Limited companies (spółki z o.o.) have no such limit. Serial entrepreneurs stack the forms: a JDG for consulting income, a spółka for an e-commerce store, maybe another spółka for a side venture. Each entity has its own NIP, its own bank accounts, its own invoice numbering, and its own KSeF authorisation.

KSeF made this harder. Authorisation is structurally per-NIP. One token, one NIP. One login session, one entity. No commercial SMB tool offers a consolidated cross-entity dashboard, a shared client base across NIPs, intercompany invoicing, or cross-entity roles. Account switching exists. Consolidation does not.

Why the Market Fails This User

The four Polish SMB SaaS leaders (Fakturownia, iFirma, wFirma, inFakt) all ship KSeF 2.0 support. They all offer linked accounts or multi-company plans. What they do not offer is a workspace that treats the owner as the primary unit, not the company.

The constraint is architectural. KSeF's authorisation model is per-NIP, so the tool's authentication model must be per-NIP. Each entity needs its own token, its own session, its own permission grants. Retrofitting an entity-first workspace onto an account-per-company product is a rewrite, not a feature. That is why no incumbent has shipped it.

The result for the user: log in to entity A, issue invoices, log out. Log in to entity B, issue invoices, log out. Check the consolidated cash position by opening a spreadsheet and copying numbers from two browser tabs. Grant the accounting office access twice, once per entity, with separate permissions. Issue an intercompany invoice between your JDG and your spółka using two separate accounts, with no system-level link between them.

KSeF 2.0 Permission Model as Design Reference

The government system has a more granular permission model than the commercial front-ends built on top of it. KSeF 2.0 separates unrevocable owner rights from grantable permissions:

KSeF supports granting permissions to an entity by NIP, which is the recommended pattern for accounting offices. The biuro receives issuing and access rights for the client's NIP, with the "dalsze przekazywanie" flag so it can delegate internally to its own staff. The biuro should never receive the permissions-management right. Session history is retained for 10 years.

Commercial SMB tools lag behind this model. wFirma's PRZEDSIĘBIORCA role cannot be permission-limited. Fakturownia offers four system roles with per-dział restriction but no cross-entity delegation. The KSeF permission model is the design reference for what a proper multi-entity workspace should offer.

The Correct Architecture: Entity-First Workspace

The owner is the primary identity. Entities are objects within the owner's workspace. Each entity has its own KSeF authorisation (token or certificate) managed under the hood. The owner sees a consolidated view across all entities.

What this looks like in practice

One login, N entities. The owner logs in once. They see a dashboard showing all their entities: the JDG, the spółka, any additional companies. They can switch between entity contexts with one click, but they can also see consolidated views.

Consolidated cash view. Total receivables across all entities. Total payables. Overdue invoices, regardless of which entity issued them. A single aging report that spans the owner's entire business footprint.

Shared client base. A contractor who buys from both the JDG and the spółka appears once in the contact database, with separate invoice histories per entity. No duplicate contractor cards. No risk of using the wrong entity's NIP when invoicing a shared client.

Intercompany invoicing. The owner issues an invoice from their JDG to their spółka. The system knows both entities belong to the same owner. It applies market-rate pricing (art. 11 transfer pricing rules), handles the representation issue (art. 210 KSH requires a proxy for intercompany transactions in spółki), and generates the evidence pack: the invoice, the KSeF numbers for both sides, and the intercompany agreement.

Accountant-as-entity delegation. The biuro is granted access per entity by NIP, with the "dalsze przekazywanie" flag. The biuro sees all client entities in one workspace, can issue invoices for any of them, and can delegate to its own staff. The owner can revoke access per entity at any time.

What no SMB tool does today

No Polish SMB invoicing tool offers:

• A consolidated cross-entity dashboard showing receivables, payables, and cash position across all entities owned by one person
• A shared contractor database with per-entity invoice histories
• Intercompany invoicing with built-in compliance checks (market pricing, representation, evidence packs)
• Cross-entity roles (e.g., an employee who can issue for entity A but only view entity B)
• An owner-visible audit log spanning all entities

These are ERP-class features. No SMB tool ships them because the architecture does not support them. The entity-first workspace is the one structural gap incumbents cannot close quickly, because retrofitting it requires rethinking the data model from the ground up.

Granting Your Accountant Access: Done Right

The biuro rachunkowe has no default access to your KSeF, even if they have been doing your accounting for years. You must grant permissions explicitly.

The correct procedure:

1. Grant by entity, not by person. In KSeF, grant the biuro's NIP as the authorised entity, not an individual employee's PESEL. This way the biuro can delegate internally.
2. Use the "dalsze przekazywanie" flag. This allows the biuro to grant access to its own staff without coming back to you for each new employee.
3. Grant issuing and access rights. Do not grant permissions-management rights. The biuro should not be able to grant access to your KSeF to third parties.
4. Repeat per entity. If you have a JDG and a spółka, grant the biuro access to both NIPs separately.
5. Set a quarterly review reminder. Check who has access to your KSeF. Remove anyone who should no longer have it. The 10-year session history means every action is logged and auditable.

Security Hygiene for Multi-Entity Owners

Each entity is a separate attack surface. A compromised token for one entity should not grant access to others.

• Named accounts, not shared logins. Each person who accesses your entities has their own account. No shared passwords.
• Two-factor authentication. Enable 2FA on every account that can issue invoices or view financial data.
• Instant revocation. When an employee or contractor leaves, revoke their access immediately across all entities. Do not wait for the end of the month.
• Separate tokens per entity. Do not reuse a token across NIPs. If one token is compromised, the blast radius is one entity, not all of them.
• Audit log review. Review the session history for each entity quarterly. Look for logins from unfamiliar locations, invoices issued outside business hours, or permission changes you did not authorize.

Plandesk's multi-entity workspace implements all of these controls. The owner is the primary identity. Entities are managed within the workspace, each with its own KSeF authorisation. The biuro is granted per entity with the "dalsze przekazywanie" flag. Intercompany invoicing includes compliance checks. The audit log spans all entities and is owner-visible. The architecture exists because the per-NIP constraint is real, but the user's mental model is "my businesses," not "company A's account, company B's account."

This material is information of a general nature and does not constitute legal or tax advice. For a specific situation, verify the current rules or consult a qualified adviser.