Co się dzieje przy awarii całkowitej KSeF?

Przy awarii całkowitej, ogłaszanej komunikatem Ministerstwa Finansów, faktur nie przesyła się do KSeF w ogóle. Nie zawierają one także kodów QR — ani KOD I, ani KOD II.

Które pole określa datę wystawienia faktury w KSeF?

KSeF uznaje za datę wystawienia wyłącznie pole P_1 struktury logicznej. To pole wyznacza początek biegu terminu na przesłanie faktury wystawionej w trybie offline.

Tryby offline w KSeF: offline24, awaria, niedostępność

Jakie są tryby offline w KSeF?

Tryb	Przyczyna	Kiedy dostępny	Termin przesłania	Podstawa
offline24	Decyzja podatnika	Bez ograniczeń, w dowolnym momencie	Następny dzień roboczy po dacie wystawienia	art. 106nda
offline (niedostępność)	KSeF	Ogłoszona niedostępność systemu	Następny dzień roboczy po przywróceniu dostępności	art. 106nh
tryb awaryjny	KSeF	Ogłoszona awaria	7 dni roboczych od usunięcia awarii	art. 106nf
awaria całkowita	KSeF	Komunikat Ministerstwa Finansów	Nie przesyła się do KSeF	—

Niedostępność i awaria są ogłaszane w Biuletynie Informacji Publicznej Ministerstwa Finansów oraz komunikatem w interfejsie systemu. Awaria całkowita jest ogłaszana odrębnym komunikatem MF.

Dlaczego offline24 jest inny

Trzy pozostałe tryby są reakcją na stan zewnętrzny: system jest niedostępny, więc wystawiasz poza nim. Offline24 nie ma takiego warunku. Podatnik może z niego skorzystać w dowolnym momencie, bez awarii i bez uzasadnienia, pod warunkiem dotrzymania terminu przesłania.

Z perspektywy projektowej to jest funkcja bezpieczeństwa: gdy integracja zwraca błąd, którego nie potrafisz szybko zdiagnozować, możesz wystawić fakturę i kontynuować sprzedaż, zamiast blokować proces. Z perspektywy audytowej jest to jednak tryb, w którym nie ma zdarzenia zewnętrznego, na które można się powołać. Jeżeli faktura trafiła do KSeF po terminie, jedynym możliwym wyjaśnieniem jest to, co zapisał Twój system.

Która data jest datą wystawienia faktury offline?

KSeF uznaje za datę wystawienia wyłącznie pole P_1 struktury logicznej. To ono wyznacza początek biegu terminu, a nie moment próby wysyłki, moment utworzenia dokumentu w ERP ani znacznik czasu w logu integracji.

Rozbieżność między tymi datami jest częstym źródłem nieświadomego przekroczenia terminu. Dokument utworzony w systemie źródłowym w piątek wieczorem, z P_1 ustawionym na piątek, ale skolejkowany do wysyłki w poniedziałek rano, jest przesłany w terminie — następny dzień roboczy. Ten sam dokument z P_1 ustawionym na czwartek jest już po terminie. Kontrola poprawności P_1 względem faktycznego momentu wystawienia należy do warstwy integracyjnej i rzadko jest w niej zaimplementowana.

Co potwierdzają dwa kody QR na fakturze offline?

Faktury wystawione offline noszą dwa kody, o zupełnie różnym przeznaczeniu.

KOD I — weryfikacja i pobranie faktury

Zawiera adres środowiska, datę, NIP sprzedawcy oraz skrót SHA-256 pliku XML zakodowany w Base64URL. Pozwala odbiorcy zweryfikować, że dokument, który trzyma w ręku, odpowiada temu, co znajduje się w KSeF. KOD I występuje na każdej wizualizacji faktury — również tych wystawionych online.

KOD II — weryfikacja certyfikatu

Podpisywany kluczem prywatnym certyfikatu KSeF typu offline (keyUsage Non-Repudiation) i potwierdza tożsamość wystawcy w momencie, w którym system nie mógł tego potwierdzić. KOD II występuje wyłącznie na fakturach wystawionych offline.

Faktury wystawione podczas awarii całkowitej nie zawierają żadnego z tych kodów.

Warto zapamiętać rozróżnienie typów certyfikatów, bo wzajemnie się wykluczają: certyfikat Authentication (Digital Signature) służy uwierzytelnieniu, certyfikat Offline (Non-Repudiation) służy podpisywaniu KOD II. Organizacja, która wystawia faktury offline, musi mieć wydany ten drugi — i to jest krok, o którym łatwo zapomnieć, dopóki nie okaże się potrzebny w środku incydentu.

Gdzie powstają luki dowodowe

Automatyzacja przenosi decyzję o trybie z człowieka do konfiguracji. To dobra decyzja operacyjna i słaba decyzja dowodowa, jeżeli nic po niej nie zostaje. Cztery pytania, które kontrola zada, a system zwykle nie potrafi na nie odpowiedzieć:

1. Dlaczego ta faktura została wystawiona offline?

Jeżeli odpowiedź brzmi „bo tak działa fallback po trzeciej nieudanej próbie", to jest to odpowiedź o konfiguracji, nie o zdarzeniu. Potrzebny jest zapis: kiedy nastąpiły próby, jakie błędy zwróciły, o której godzinie podjęto decyzję o przełączeniu i który dokument jej dotyczył.

2. Czy w momencie wystawienia rzeczywiście trwała ogłoszona niedostępność?

To pytanie dotyczy trybów opartych na zdarzeniu po stronie KSeF. Powołanie się na tryb awaryjny wymaga wykazania, że awaria była w tym czasie ogłoszona. System, który nie zapisuje stanu ogłoszeń MF w momencie wystawiania, nie potrafi tego wykazać po fakcie — a treść komunikatów BIP nie jest archiwizowana w wygodnej dla audytu formie.

3. Czy każda faktura offline została przesłana w terminie?

Terminy różnią się między trybami, a dla trybu awaryjnego liczą się od usunięcia awarii, nie od jej wystąpienia. Rozliczenie tego wymaga powiązania trzech informacji: trybu, daty P_1 i faktycznego momentu przyjęcia przez KSeF. Jeżeli któraś z nich żyje tylko w logach aplikacyjnych, rozliczenie jest niemożliwe po ich rotacji.

4. Czy któraś faktura offline nigdy nie trafiła do KSeF?

Najpoważniejszy przypadek i najtrudniejszy do wykrycia. Dokument został wystawiony, przekazany kontrahentowi, zaksięgowany — i utknął w kolejce, której nikt nie monitoruje. Bez odrębnego rejestru „wystawione offline, oczekujące na przesłanie" taka faktura wychodzi na jaw dopiero przy uzgodnieniu z kontrahentem albo przy kontroli.

Kontrole, które to zamykają

Rejestr decyzji o trybie. Dla każdej faktury offline: tryb, podstawa decyzji, znacznik czasu, identyfikator dokumentu, wynik prób online, które ją poprzedziły.
Zapis stanu KSeF w momencie wystawienia. Odnotowanie, czy w chwili decyzji obowiązywało ogłoszenie o niedostępności lub awarii — pobrane i zapisane, nie odtwarzane później.
Kolejka z terminem. Osobny rejestr faktur oczekujących na przesłanie, z wyliczonym terminem właściwym dla trybu i alertem przed jego upływem.
Walidacja P_1. Kontrola, czy data wystawienia odpowiada rzeczywistemu momentowi utworzenia dokumentu, wykonana zanim dokument opuści system.
Próg zatwierdzania. Decyzja projektowa: czy przełączenie w tryb offline dla faktury powyżej określonej wartości ma być automatyczne, czy wymagać potwierdzenia człowieka. Dla większości organizacji odpowiedź brzmi „automatyczne do progu, potwierdzane powyżej".
Dostępność certyfikatu offline. Kontrola, czy certyfikat typu Offline jest wydany, ważny i dostępny dla procesu — zanim będzie potrzebny.

Najczęstsze pytania

Czy tryb offline24 wymaga uzasadnienia?

Nie. Jest dostępny bez ograniczeń i jest decyzją podatnika. Termin przesłania to następny dzień roboczy po dacie wystawienia.

Ile czasu jest na przesłanie faktury z trybu awaryjnego?

Siedem dni roboczych od usunięcia awarii. To najdłuższy termin spośród wszystkich trybów.

Czym różni się KOD I od KOD II?

KOD I służy weryfikacji i pobraniu faktury i występuje na każdej wizualizacji. KOD II potwierdza tożsamość wystawcy, jest podpisywany certyfikatem typu Offline i występuje wyłącznie na fakturach offline.

Co się dzieje przy awarii całkowitej?

Faktur nie przesyła się do KSeF w ogóle i nie zawierają one kodów QR.

Które pole określa datę wystawienia?

Wyłącznie P_1. To od niej biegnie termin przesłania.

Czy można korzystać z offline24 rutynowo, dla wszystkich faktur?

Przepisy nie ograniczają liczby faktur wystawianych w tym trybie. Rutynowe korzystanie z niego przenosi jednak całe ryzyko terminowości na Twoją stronę i wymaga niezawodnego mechanizmu dosyłania — co w praktyce jest trudniejsze niż utrzymanie stabilnej integracji online.

Dalej w tym cyklu

Jeżeli decyzję o trybie offline podejmuje w Twojej organizacji proces automatyczny, BarzelVault zapisuje tę decyzję wraz z jej podstawą i wymusza progi zatwierdzania, zanim operacja zostanie wykonana.

W praktyce

Kontrola musi zadziałać, zanim faktura stanie się nieodwracalna.

Przyjętą fakturę ustrukturyzowaną można skorygować, ale nigdy usunąć, a od dnia wejścia kar każdy błąd ma swoją cenę. Barzel stawia próg akceptacji, kontrolę duplikatów i podpisany zapis przed wysyłką, tak aby proces dało się obronić w dniu, w którym zapyta o niego audytor albo urząd skarbowy.

Pozostało 95 dniKary KSeF obowiązują od 1 stycznia 2027 r.

BarzelVault

Firewall działań AI: decyduj, co agent może zrobić, zanim to zrobi.

Progi akceptacji i reguły polityki egzekwowane przed wykonaniem; zatwierdzenia przez człowieka z terminem ważności i eskalacją.
Kryptograficznie podpisane potwierdzenia audytowe: wyzwalacz, dane wejściowe, wersja polityki, osoba zatwierdzająca, wynik.
Izolacja poświadczeń, limity kwot i działań oraz awaryjny wyłącznik.

Plan bezpłatny: 10 000 wywołań miesięczniePlany płatne od 199 USD miesięcznieDostępne na MCPize

Zacznij bezpłatnie Zapytaj e-mailem Strona produktu Dokumentacja

BarzelOps

Nadzorowana automatyzacja procesów między systemami, na których działa firma.

Trwałe, idempotentne wykonanie: przekroczenie czasu jest ponawiane raz, faktura nigdy nie trafia do systemu dwa razy.
Punkty zatwierdzenia przez człowieka, które wstrzymują proces i wznawiają go.
Izolacja per podmiot lub klient, podpisane dowody i przenośny manifest; integracje HubSpot, Xero, Gmail, Google Drive i Slack.

Plan bezpłatny: 100 wywołań dzienniePlany płatne od 19 USD miesięcznieDostępne na MCPize