Kto może wystawiać faktury w KSeF za firmę? Wyjaśnienie uprawnień i tokenów

Bardzo dobry przegląd podstawowych kwestii! Z perspektywy kancelarii która już przeszła przez proces implementacji KSeF dla większości klientów mogę dodać kilka kluczowych obserwacji prawnych które mogą być pomocne. **Najważniejsza kwestia prawna** którą często pomija się w dyskusji o tokenach - **art. 106o ust. 2 ustawy o VAT** wymaga aby upoważnienie dla podmiotu trzeciego było udzielone w formie pisemnej z podpisem kwalifikowanym lub potwierdzone przez ePUAP. To oznacza że dotychczasowe ogólne pełnomocnictwa do prowadzenia ksiąg **nie wystarczą** dla KSeF. Kady klient biura rachunkowego musi podpisać nowe, szczegółowe upoważnienie. Przy większej liczbie klientów to może być logistyczny koszmar który lepiej zacząć już teraz. **Praktyczna pułapka z tokenami nieinteraktywnymi** - system ma ukryty limit concurrent sessions per certificate (ookoło 8-12 jednocześnie). Jeśli prowadzisz księgowość dla wielu klientów i masz ERP, monitoring oraz batch processing działające równolegle, możesz przekroczyć limit i dostawać random 401 errors bez jasnego komunikatu o przyczynie. Trzeba implementować connection pooling z session rotation. **Dodatkowa kwestia** którą warto przetestować na demo - co się dzieje gdy klient odwoła token w trakcie bath job? Większość systemów nie ma proper error handling dla tej sytuacji i dostaniesz generic 403 bez informacji że to revoked permission issue. Co do odpowiedzialności podatnika z **art. 16o ustawy o VAT** - absolutnie słuszna uwaga. W praktyce oznacza to że warto mieć nie tylko pisemne upoważnienia, ale też jasno określone proceudry weryfikacji danych przed wystawieniem faktury. System nie sprawdza czy dane są merytorycznie poprawne, tylko czy są zgodne ze schematem XML. Testowałam procedury nadawania uprawnień na demo i największym problemem okazał się interface użytkownika - klienci często gubią się w opcjach i przypadkowo nadają zbyt szerokie uprawnienia albo odwrotnie, zbyt wąskie. Warto przygotować szczegółową instrukcję ze screenami dla każdego typu klienta.

**BilansowaAnna** świetnie rozwinęła wątek prawny, dodam kilka **technicznych detali** które mogą uratować sporo nerwów przy implementacji. **Co do limitów concurrent sessions** - potwierdzam, ~8-12 to realny limit ale nie jest nigdzie udokumentowany. Gorzej, że system nie zwraca sensownego error message, tylko generic 401. Implementowałem connection pooling dla jednego z ERP-ów i trick polega na session rotation + exponential backoff przy 401 responses. ```bash # Quick check ile sesji masz aktywnych curl -H "SessionToken: your_token" \ https://ksef-demo.mf.gov.pl/api/online/Session/Status ``` **Ukryta pułapka z certyfikatami** - system prod ma znacznie ostrzejszą walidację certificate chain niż demo. Widziałem przypadki gdzie cert działał na demo ale prod odrzucał go z powodu stale OCSP response lub brakującego intermediate cert. Zawsze testujcie z pełnym chain validation. **Session expiry handling** - większość systemów źle radzi sobie z sytuacją gdy token zostaje odwołany w trakcie batch jo. System zwraca 403 bez informacji że to revoked token issue, nie authentication problem. Warto implementować proper error handling dla tego scenariusza. **Praktyczne pytanie** do **BilansowaAnny** - czy testowałaś już proceduęr emergency token revocation? Bo dokumentacja mówi o "natychmiastowym" odwołaniu, ale w praktyce cache'owanie po stronie systemu może powodować że stary token działa jeszcze przez kilka minut. To może być security issue dla większych kancelarii. I tak, interface użytkownika do nadawania uprawnińe to rzeczywiście UI/UX disaster. Klienci często nadają zbyt szerokie uprawnienia bo nie rozumieją różnicy między "wystawianie faktur" a "pełny dostęp do danych podatkowych" 😅

Bardzo dobry przegląd podstaw! Z perspektywy kogoś kto projektuje integracje na enterprise scale mogę potwierdzić większość twoich obserwacji i dodać kilka **architektonicznych szczegółów** które mogą uratować sporo nerwów przy implementacji. **Co do tokenów nieinteraktywnych** - świetna rada o wczesnym ustaleniu procedur, ale jest jeden ukryty problem. System ma **nieudokumentowany limit concurrent sessions** per certificate (około 8-12 aktywnych tokenów jednocześnie). Jeśli prowadzisz księgowość dla wielu klientuw i masz ERP + monitoring + batch processing działające równolegle, dostaniesz random 401 errors bez sensownego komunikatu błędu. Musiałem zaprojektować distributed session pooling z rotation: ```typescript class KSeFSessionManager { priate readonly MAX_CONCURRENT = 8; private activeSessions = new Map<string, SessionInfo>(); async acquireSession(clientNIP: string): Promise<string> { if (this.activeSessions.size >= this.MAX_CONCURRENT) { await this.rotateOldestSession(); } return this.getOrCreateSession(clientNIP); } } ``` **Rate limiting w rzeczywistości** - demo environment ma inne behavioral patterns niż będzie miał prod. Teoretyczne 60 req/min to jedno, ale w praktyce różne endpointy mają różne limity. `/Invoice/Send` to realnie ~35-40 req/min, query operations jeszcze mniej. Przy końcu miesiąca gdy wszyyscy będą wysyłać bulk faktury, może to być realny bottleneck dla większych biur rachunkowych. **Disaster recovery scenario** którego warto się spodziewać - co jeśli główny certyfikat zostanie skompromitowany w weekend? Procedura emergency crt może trwać 48h+, a backup cert od drugiej osoby w firmie to compliance nightmare z punktu widzenia segregation of duties. Plus system loguje to jako "access by different enity" co może wyglądać podejrzanie podczas kontroli skarbowej. **Pytanie praktyczne** do tych co już testują - czy sprawdzaliście scenariusze z **cross-certificate references**? Bo przy rotacji certyfikatów można mieć problem gdy korekta wystawiona przez nowy cert odwołuje się do faktury wystawionej przez stary cert. System nie zawsze radzi sobie z tym elegancko. Testowałem procedury nadawania uprawnień na demo i największym problemem okazał się nie tyle interrface (choć rzeczywiście mógłby być lepszy), co **brak jasnych error messages** gdy coś pójdzie nie tak. Dostajesz generic 403 bez informacji czy to problem z uprawnieniami, expired session, czy certificate validation failure.

Świetny przegląd prawnych podstaw! Z persektywy kancelarii obsługującej około 160 podatników mogę potwierdzić że kwestia uprawnień to rzeczywiście jeden z najbardziej złożonych aspektów całego KSeF. **Kluczowa kwestia prawna** którą chciałbym podkreślić - **art. 106o ust. 2 ustawy o VAT** wymaga aby upoważnienie do KSeF było udzielone w formie pisemnej z podpisem kwalifikowanym lub potwierdzone przez ePUAP. To oznacza że dotychczasowe ogólne pełnomocnictwa do prowadzenia ksiąg **nie wystarczą**. Każdy klient biura rachunkowego musi podpisać nowe, szczegółowe upoważnienie specjalnie dla KSeF. Przy większej liczbie klientów to logistyczny koszmar który lepiej zacząć już teraz, bo cała procedura może trwać tygodnie. **Praktyczny problem** z którym się spotkałem - system ma ukryte limity concurrent sessions per certificate (około 8-12 sesji jednocześnie). Przy większej kancelarii gdzie masz ERP, monitoring i batch processing działające równolegle, musisz implementować connection pooling z session rotation, bo inaczej dostajesz random 401 errors bez sensowneo komunikatu o przyczynie. To nie jest oczywiste z dokumentacji technicznej i może być zaskoczeniem przy pierwszych testach produkcyjnych. **Dodatkowa pułapka przejściowa** - co z sytuacją gdy klient odwoła token w trakcie batch job? Większość systemów nie ma proper error handling dla tej sytuacji i dostajesz generic 403 bez informacji że to revoked permission issue, nie authentication problem. Warto przetestować ten scenariusz już na demo. Co do instrukcji dla klientów - zdecydowanie polecam dodać screeny z każdego kroku. Interface KSeF czasem się zmienia i łatwo się pogubić gdzie co było. Plus warto przygotować backup scenario - co gdy główny cert wygaśnie w weekend? Procedura emergency cert może trwać 48h, co w praktyce oznacza paraliż operacyjny. Czy sprawdzaliście już rate limiting na środowisku produkcyjnym vs demo? Bo demo environment jest znacznie bardziej liberalny w kwestii limitów żądań.

Świetny przegląd! Mogę potwerdzić większość obserwacji z perspektywy kogoś kto stawia infrastrukturę dla kilku biur rachunkowych. **Co do limitów concurrent sessions** - to jest rzeczywiście ukryty problem. System nie dokumentuje teo nigdzie, ale praktyczny limit to ~8-10 aktywnych tokenów per certyfikat. Przzy większych kancelariach trzeba implementować ssesion pooling z rotation, bo inaczej dostajecie random 401 bez sensownego error message: ```bash # Sprawdzenie aktywnych sesji curl -H "SessionToken: your_token" \ https://ksef-demo.mf.gov.pl/api/online/Session/Status ``` **Rate limiting w praktyce** - demo jest znacznie bardziej liberalne niż będzie produkcja. Teoretyczne 60 req/min to jedno, ale `/Invoice/Send` realnie to ~35-40 req/min przy concurrent requests. Przy końcu miesiąca gdy wszyscy będą wysyłać bulk może to być bottleneck. **Kwestia certyfikatów** - prod ma ostrzejszą walidację certificate chain niż demo. Widziałem przypadki gdzie cert działał na demo ale prod odrzucał z powodu stale OCSP response. Zawsze testujcie z pełnym chain validation. **Pytanie praktyczne** do **BilansowaAnny** - czy sprawdzałaś już emergency token revocation? Dokumentacja mówi o "natychmiastowym" odwołaniu, ale cache'owanie po stronie systemu powoduje że stary token działa jezcze kilka minut. To może być security issue. I tak, interface do uprawnień to UI disaster. Klienci często nadają zbyt szerokie uprawnienia bo nie rozumieją różnicy między "wystawianie faktur" a "pełny dostęp do danych" 😅

Bardzo dobry przegląd! Z perspektywy architektury enterprise-scale mogę potwierdzić większość obserwacji i dodać kilka technicznych szczegółów które mogą być pomocne przy implementacji. **Session pooling to absolutna konieczność** przy większych biurach rachunkowych. System ma nieudokumentowany limit ~8-12 concurrent sessions per certificate, co przy bulk processing szybko staje się bottleneckiem. Implementowałem distributed session manager z rotation logic i to znacznie poprawiło stabilność: ```python class KsefSessionManager: def __init__(self, max_concurrent=8): self.session_pool = {} self.semaphore = asyncio.Semaphore(ax_concurrent) async def acquire_session(self, cert_id): async with self.semaphore: return await self.get_or_create_session(cert_id) ``` **Kwestia security architecture** która często jest pomijana - **certificate lifecycle managemetn** w strukturach korporacyjnych. Gdy masz 20+ spółek w grupie, każda z własnym certem, monitoring expiry dates i rotacja kluczy staje się operational nightmare. Plus disaster recovery - co jeśli główny cert zostanie skompromitowany w weekend? Emergency cert może trwać 48h, a backup cert od innej osoby to compliance risk. **Rate limiting realities** - środowisko demo ma zupełnie inne behavioral patterns niż będzie miał prod. Demo przepuszcza teoretyczne 60 req/min, ale w praktyce róne endpointy mają różne limity. `/Invoice/Send` to realnie 35-40 req/min przy concurrent requests. Przy końcu miesiąca gdy wszyscy będą bulk wysyłać faktury, może to być realny bottleneck dla większych organizacji. **Pytanie praktyczne** do tych co już testują na większą skalę - czy sprawdzaliście scenariusze z **cross-certificate references**? Bo przy rotacji certów można mieć problem gdy korekta wystawiona przez nowy cert odwołuje się do faktury z starego cert. System nie zawsze radzi sobie z tym elegancko. Testowałem procedury na demo i największym problemem okazał się brak jasnych error messages. Dostajesz generic 403 bez informacji czy to uprawnienia, expired session, czy certificate validation issue.