Kilka firm, jeden system: fakturowanie przez JDG i spółkę bez chaosu

Polskie prawo pozwala na jedną jednoosobową działalność gospodarczą (JDG) per osoba. Spółki z o.o. nie mają takiego limitu. Seryjni przedsiębiorcy łączą formy: JDG dla dochodów doradczych, spółka dla sklepu e-commerce, może kolejna spółka dla projektu pobocznego. Każdy podmiot ma własny NIP, własne konta bankowe, własną numerację faktur i własną autoryzację KSeF.

KSeF zrobił to trudniejszym. Autoryzacja jest strukturalnie per-NIP. Jeden token, jeden NIP. Jedna sesja logowania, jeden podmiot. Żadne komercyjne narzędzie SMB nie oferuje skonsolidowanego dashboardu cross-entity, wspólnej bazy klientów między NIP, fakturowania między podmiotami powiązanymi ani ról cross-entity. Przełączanie kont istnieje. Konsolidacja nie.

Dlaczego rynek zawodzi tego użytkownika

Czterech polskich liderów SMB SaaS (Fakturownia, iFirma, wFirma, inFakt) dostarcza wsparcie KSeF 2.0. Wszyscy oferują połączone konta lub plany wielofirmowe. To, czego nie oferują, to obszar pracy, który traktuje właściciela jako jednostkę pierwotną, nie firmę.

Ograniczenie jest architektoniczne. Model autoryzacji KSeF jest per-NIP, więc model autentykacji narzędzia musi być per-NIP. Każdy podmiot potrzebuje własnego tokena, własnej sesji, własnych nadań uprawnień. Retrospektywne dodanie obszaru pracy entity-first do produktu account-per-company to przebudowa, nie funkcja. Dlatego żaden incumbenty tego nie dostarczył.

Wynik dla użytkownika: zaloguj się do podmiotu A, wystaw faktury, wyloguj. Zaloguj się do podmiotu B, wystaw faktury, wyloguj. Sprawdź skonsolidowaną pozycję kasową, otwierając arkusz i kopiując liczby z dwóch kart przeglądarki. Nadaj biuru rachunkowemu dostęp dwa razy, raz per podmiot, z osobnymi uprawnieniami. Wystaw fakturę między podmiotową między JDG a spółką używając dwóch osobnych kont, bez systemowego powiązania między nimi.

Model uprawnień KSeF 2.0 jako referencja projektowa

System rządowy ma bardziej granularny model uprawnień niż komercyjne front-endy zbudowane na jego bazie. KSeF 2.0 oddziela nieodwołalne prawa właściciela od nadawanych uprawnień:

KSeF obsługuje nadawanie uprawnień podmiotowi przez NIP, co jest zalecanym wzorcem dla biur rachunkowych. Biuro otrzymuje uprawnienia wystawiania i dostępu dla NIP klienta, z flagą „dalsze przekazywanie", aby mogło delegować wewnętrznie do własnego personelu. Biuro nigdy nie powinno otrzymywać uprawnienia zarządzania uprawnieniami. Historia sesji jest retencjonowana przez 10 lat.

Komercyjne narzędzia SMB pozostają w tyle za tym modelem. Rola PRZEDSIĘBIORCA w wFirma nie może być ograniczona uprawnieniami. Fakturownia oferuje cztery role systemowe z ograniczeniem per-dział, ale bez delegacji cross-entity. Model uprawnień KSeF jest referencją projektową dla tego, co właściwy obszar pracy wielopodmiotowej powinien oferować.

Poprawna architektura: obszar pracy entity-first

Właściciel jest tożsamością pierwotną. Podmioty są obiektami w obszarze pracy właściciela. Każdy podmiot ma własną autoryzację KSeF (token lub certyfikat) zarządzaną pod spodem. Właściciel widzi skonsolidowany widok przez wszystkie podmioty.

Jak to wygląda w praktyce

Jedno logowanie, N podmiotów. Właściciel loguje się raz. Widzi dashboard pokazujący wszystkie swoje podmioty: JDG, spółkę, dodatkowe firmy. Może przełączać konteksty podmiotu jednym kliknięciem, ale może też widzieć widoki skonsolidowane.

Skonsolidowany widok kasowy. Łączne należności przez wszystkie podmioty. Łączne zobowiązania. Zaległe faktury, niezależnie od tego, który podmiot je wystawił. Jeden raport starzenia obejmujący całą stopę biznesową właściciela.

Wspólna baza klientów. Kontrahent, który kupuje od JDG i od spółki, pojawia się raz w bazie kontaktów, z osobnymi historiami faktur per podmiot. Bez duplikatów kart kontrahentów. Bez ryzyka użycia NIP złego podmiotu przy fakturowaniu wspólnego klienta.

Fakturowanie między podmiotowe. Właściciel wystawia fakturę od JDG do swojej spółki. System wie, że oba podmioty należą do tego samego właściciela. Stosuje ceny rynkowe (art. 11 transfer pricing), obsługuje kwestię reprezentacji (art. 210 KSH wymaga prokury dla transakcji między podmiotowych w spółkach), i generuje pakiet dowodów: fakturę, numery KSeF dla obu stron i umowę między podmiotową.

Delegacja biuru per podmiot. Biuro rachunkowe otrzymuje dostęp per podmiot przez NIP, z flagą „dalsze przekazywanie". Biuro widzi wszystkie podmioty klienta w jednym obszarze pracy, może wystawiać faktury dla każdego z nich i delegować do własnego personelu. Właściciel może odwołać dostęp per podmiot w dowolnym momencie.

Czego żadne narzędzie SMB nie robi dziś

Żadne polskie narzędzie fakturowania SMB nie oferuje:

• Skonsolidowanego dashboardu cross-entity pokazującego należności, zobowiązania i pozycję kasową przez wszystkie podmioty jednego właściciela
• Wspólnej bazy kontrahentów z historią faktur per podmiot
• Fakturowania między podmiotowego z wbudowanymi sprawdzeniami compliance (ceny rynkowe, reprezentacja, pakiety dowodów)
• Ról cross-entity (np. pracownik, który może wystawiać dla podmiotu A, ale tylko podglądać podmiot B)
• Logu audytu widocznego dla właściciela obejmującego wszystkie podmioty

To funkcje klasy ERP. Żadne narzędzie SMB ich nie dostarcza, ponieważ architektura ich nie obsługuje. Obszar pracy entity-first to jedna luka strukturalna, której incumbenci nie mogą szybko zamknąć, ponieważ retrospektywne dodanie jej wymaga przemyślenia modelu danych od podstaw.

Nadawanie dostępu księgowemu: zrobione dobrze

Biuro rachunkowe nie ma domyślnego dostępu do Twojego KSeF, nawet jeśli prowadzi Twoją księgowość od lat. Musisz nadać uprawnienia wprost.

Prawidłowa procedura:

1. Nadaj per podmiot, nie per osoba. W KSeF nadaj NIP biura jako uprawniony podmiot, nie PESEL indywidualnego pracownika. Dzięki temu biuro może delegować wewnętrznie.
2. Użyj flagi „dalsze przekazywanie". Pozwala biuru nadawać dostęp swojemu personelowi bez wracania do Ciebie przy każdym nowym pracowniku.
3. Nadaj uprawnienia wystawiania i dostępu. Nie nadawaj uprawnień zarządzania uprawnieniami. Biuro nie powinno móc nadawać dostępu do Twojego KSeF osobom trzecim.
4. Powtórz per podmiot. Jeśli masz JDG i spółkę, nadaj biuru dostęp do obu NIP osobno.
5. Ustaw kwartalne przypomnienie przeglądu. Sprawdź, kto ma dostęp do Twojego KSeF. Usuń każdego, kto nie powinien go już mieć. 10-letnia historia sesji oznacza, że każda akcja jest logowana i audytowalna.

Higiena bezpieczeństwa dla właścicieli wielopodmiotowych

Każdy podmiot to osobna powierzchnia ataku. Skompromitowany token jednego podmiotu nie powinien dawać dostępu do innych.

• Konta imienne, nie współdzielone logowanie. Każda osoba, która ma dostęp do Twoich podmiotów, ma własne konto. Bez współdzielonych haseł.
• Autoryzacja dwuskładnikowa. Włącz 2FA na każdym koncie, które może wystawiać faktury lub podglądać dane finansowe.
• Natychmiastowe odwołanie. Gdy pracownik lub kontrahent odchodzi, odwołaj jego dostęp natychmiast przez wszystkie podmioty. Nie czekaj do końca miesiąca.
• Osobne tokeny per podmiot. Nie używaj tego samego tokena przez NIP. Jeśli jeden token zostanie skompromitowany, promień rażenia to jeden podmiot, nie wszystkie.
• Przegląd logu audytu. Przeglądaj historię sesji każdego podmiotu kwartalnie. Szukaj logowań z nieznanych lokalizacji, faktur wystawionych poza godzinami pracy lub zmian uprawnień, których nie autoryzowałeś.

Obszar pracy wielopodmiotowej Plandesk implementuje wszystkie te kontrole. Właściciel jest tożsamością pierwotną. Podmioty są zarządzane w obszarze pracy, każdy z własną autoryzacją KSeF. Biuro jest uprawnione per podmiot z flagą „dalsze przekazywanie". Fakturowanie między podmiotowe obejmuje sprawdzenia compliance. Log audytu obejmuje wszystkie podmioty i jest widoczny dla właściciela. Architektura istnieje, ponieważ ograniczenie per-NIP jest realne, ale model mentalny użytkownika to „moje firmy", nie „konto firmy A, konto firmy B".

Niniejszy materiał ma charakter informacji ogólnej i nie stanowi porady prawnej ani podatkowej. W konkretnej sytuacji zweryfikuj aktualne przepisy lub skonsultuj się z doradcą.