KSeF nie działa w 2026: offline24 i 7 dni na fakturę (i jak nie zatrzymać automatyzacji fakturowania)

Kiedy pytają mnie, co zrobić, gdy KSeF padnie w środę rano, a firma ma do wystawienia 80 faktur przed końcem dnia, pierwsza odpowiedź brzmi: to nie jest problem KSeF, tylko problem waszej automatyzacji. System rządowy miał i będzie miał awarie, planowane i nie. To fakt, z którym trzeba się pogodzić, a nie walczyć. Problemem jest to, że większość wdrożeń automatyzacji fakturowania zakłada ciągłą dostępność API KSeF i w ogóle nie przewiduje, co się dzieje, gdy odpowiedź z serwera nie przychodzi. Wtedy proces się zatrzymuje, faktury wiszą w limbo, a ktoś w księgowości dowiaduje się o tym dopiero, gdy klient dzwoni z pytaniem, gdzie jest dokument.

Awaria KSeF to nie koniec świata, tylko brak procedury

W mediach i w newsletterach księgowych temat awarii KSeF bywa podawany w tonie katastroficznym: system padnie, firmy nie będą mogły wystawiać faktur, chaos. To nieprawda, a przynajmniej nie musi nią być. Ustawodawca od początku przewidział, że system centralny będzie miał przerwy w działaniu, i wprowadził konkretny mechanizm na taką okoliczność. Problem nie leży w przepisach, tylko w tym, że firmy budują automatyzację fakturowania tak, jakby KSeF był niezawodny jak prąd w gniazdku. Nie jest. Traktuję to podobnie jak integrację z dowolnym zewnętrznym API: jeśli zakładam 100% dostępności, prędzej czy później dostanę telefon o 8 rano, że „nic nie działa”.

Z punktu widzenia wdrożeniowego różnica między firmą, która przechodzi awarię bez większego echa, a firmą, która wpada w panikę, nie leży w znajomości przepisów. Leży w tym, czy proces fakturowania ma wbudowaną kolejkę i mechanizm ponawiania prób. Jeśli faktura, która nie poszła do KSeF za pierwszym razem, po prostu czeka w buforze i próbuje ponownie co kilka minut, nikt nawet nie zauważa, że była awaria. Jeśli jedyną ścieżką jest ręczne sprawdzanie statusu w przeglądarce, to tak, wtedy robi się nerwowo.

Co faktycznie mówią przepisy: offline24, 7 dni i numer nadany wstecz

Zacznijmy od tego, co jest faktem, a nie interpretacją. Tryb offline24 pozwala wystawić fakturę poza systemem KSeF, w sytuacji niedostępności systemu, i dostarczyć ją do nabywcy od razu, bez czekania na numer KSeF. Obowiązek przesłania takiej faktury do systemu centralnego nie znika, tylko jest odroczony: podatnik ma 7 dni roboczych na przesłanie dokumentu do KSeF, licząc od ustania przyczyny, która uniemożliwiała wystawienie faktury w systemie na bieżąco. Po przesłaniu faktura dostaje numer KSeF nadany retrospektywnie, czyli z datą wsteczną odpowiadającą faktycznemu wystawieniu dokumentu, nie dacie zgłoszenia do systemu.

To jest kluczowa różnica w porównaniu z obawami, które krążą po grupach księgowych: nikt nie traci prawa do wystawienia faktury na czas tylko dlatego, że serwery MF akurat nie odpowiadają. Dokument jest ważny od momentu wystawienia w trybie offline, pod warunkiem dotrzymania terminu na jego późniejsze przesłanie.

Awaria planowana a niezapowiedziana - różnica, która ma znaczenie operacyjne

Ministerstwo Finansów rozróżnia dwie sytuacje. Awaria planowana to taka, o której MF informuje z wyprzedzeniem w komunikacie, zwykle w związku z pracami serwisowymi albo aktualizacją systemu. W takim przypadku firmy wiedzą zawczasu, że w danym oknie czasowym KSeF będzie niedostępny, i mogą się na to przygotować, choćby przesuwając wysyłkę partii faktur na godziny przed lub po ogłoszonej przerwie. Awaria niezapowiedziana to zupełnie inna historia: system przestaje odpowiadać bez ostrzeżenia, co w praktyce oznacza, że automatyzacja musi sama wykryć ten stan, bo nikt nie zdąży zareagować ręcznie. To właśnie dla tego scenariusza buduje się logikę retry, nie dla awarii planowanych, bo te da się ominąć harmonogramem.

Ministerstwo w trakcie przygotowań do pełnego wdrożenia publikowało komunikaty o testowych awariach i przerwach w działaniu środowiska KSeF, co samo w sobie jest dobrym sygnałem: system był i będzie testowany pod kątem odporności, a firmy, które już teraz mają w swoich procesach obsługę takich zdarzeń, wchodzą w obowiązkowy KSeF spokojniej niż te, które dowiedzą się o awarii dopiero na produkcji.

Terminy obowiązkowego KSeF w 2026 roku

Dla porządku: obowiązek korzystania z KSeF wchodzi etapami. Najwięksi podatnicy, czyli firmy z obrotem przekraczającym 200 mln zł w poprzednim roku podatkowym, są objęci obowiązkiem od lutego 2026. Pozostali podatnicy, w tym mniejsze firmy, dołączają do systemu od kwietnia 2026. To oznacza, że praktycznie każda firma wystawiająca faktury B2B w Polsce w ciągu najbliższych miesięcy będzie musiała mieć działający, odporny na przerwy proces integracji z KSeF, niezależnie od tego, czy robi to przez własne IT, biuro rachunkowe, czy zewnętrzną automatyzację.

Dlaczego w automatyzacji pada nie system, tylko proces bez retry

W kilku wdrożeniach, które prowadziliśmy, powtarzał się ten sam wzorzec: firma ma działającą integrację fakturową, wszystko idzie gładko przez miesiące, a potem jeden dzień z problemami po stronie KSeF (albo zwykłym timeoutem sieciowym, bo to też się zdarza niezależnie od żadnej „oficjalnej” awarii) powoduje, że kilkanaście faktur po prostu znika z radaru. Nie dlatego, że przepisy są złe, tylko dlatego, że automatyzacja była zbudowana na założeniu „request poszedł, odpowiedź przyszła, koniec tematu”. Bez obsługi błędu, bez ponowienia próby, bez informacji dla człowieka, że coś wymaga uwagi.

To jest dokładnie ten typ ryzyka, który trzeba zaadresować przed wdrożeniem, nie po pierwszej wpadce. Jeśli proces fakturowania jest zautomatyzowany w n8n, Make albo podobnym narzędziu, a krok wysyłki do KSeF nie ma logiki ponawiania i kolejkowania, to firma w praktyce działa na włączonym ryzyku przestoju przy każdej, nawet najdrobniejszej, niedostępności systemu. Więcej o tym, jak takie procesy wygląda od środka, piszemy przy okazji automatyzacji faktur, bo to jeden z tych obszarów, gdzie brak odporności na błędy kosztuje realne pieniądze i nerwy, nie tylko w kontekście KSeF.

Jak budujemy fallback w n8n i Make: bufor, retry, alert

Konkretny mechanizm, który stosujemy, składa się z trzech elementów i żaden z nich osobno nie wystarczy.

Po pierwsze, bufor faktur. Każda faktura, zanim trafi do KSeF, ląduje najpierw w lokalnej bazie albo w arkuszu/kolejce (w zależności od skali, może to być Postgres, Airtable, Google Sheets, a w większych wdrożeniach dedykowana kolejka typu RabbitMQ czy wbudowana kolejka workflow). Status startowy to „do wysłania”. Dopiero po potwierdzeniu przyjęcia przez KSeF status zmienia się na „wysłano”. Dzięki temu nawet jeśli serwer MF nie odpowie, dokument nie ginie, tylko zostaje w stanie oczekującym.

Po drugie, logika ponownych prób. Workflow próbuje wysłać fakturę, a jeśli dostaje błąd (timeout, kod 5xx, brak odpowiedzi w zadanym czasie), nie kończy działania błędem krytycznym, tylko wraca do bufora i próbuje ponownie po odczekaniu, zwykle rosnącym interwale, np. 2 minuty, potem 10, potem 30. To standardowy wzorzec exponential backoff, dobrze znany z integracji API, i działa tu równie dobrze jak w każdej innej automatyzacji sieciowej. Dopiero po przekroczeniu rozsądnej liczby prób (u nas to zwykle kilka godzin nieudanych wysyłek) system przestaje próbować co kilka minut i przechodzi do trybu oczekiwania z powiadomieniem.

Po trzecie, alert do człowieka. To element, który najczęściej jest pomijany, a jest najważniejszy. Automat robi 80-90% roboty: próbuje, ponawia, loguje. Ale decyzję, czy przejść w tryb offline24 i wystawić fakturę poza systemem, czy czekać na przywrócenie dostępności, zostawiamy człowiekowi, zwykle księgowej albo osobie odpowiedzialnej za fakturowanie. Automatyzacja wysyła wiadomość (Slack, e-mail, czasem SMS przy dłuższych przestojach) z informacją: tyle a tyle faktur czeka, od tylu godzin, ostatni błąd to taki a taki. Osoba decyzyjna ma wtedy pełny obraz sytuacji, zamiast dowiadywać się o problemie przypadkiem.

Dla firm, które fakturowanie obsługują przez biuro rachunkowe albo mają je mocno splecione z księgowością, ten sam mechanizm trzeba spiąć z procesami po stronie biura, bo inaczej fallback działa technicznie, ale informacja i tak nie dociera do właściwej osoby na czas. Przy większej skali klientów to już temat na osobne wdrożenie, które opisujemy przy automatyzacji biura rachunkowego, bo tam dochodzi dodatkowa warstwa: wielu klientów, wiele profili KSeF, różne terminy i różne tolerancje na opóźnienie.

Czego fallback nie rozwiąże

Nie chcę tu sprzedawać wizji, że dobrze zbudowana automatyzacja rozwiązuje wszystko. Nie rozwiązuje. Jeśli awaria trwa dłużej niż kilkanaście godzin, a firma wystawia setki faktur dziennie, sam bufor i retry nie zastąpią decyzji biznesowej: czy przechodzimy w tryb offline24 dla całej puli dokumentów, czy czekamy. To decyzja, którą powinien podjąć człowiek znający kontekst, nie algorytm. Automatyzacja dostarcza dane do tej decyzji szybciej i w czytelnej formie, ale samej decyzji nie podejmuje, i dobrze, bo konsekwencje błędnej decyzji (np. przesłanie faktur po terminie 7 dni roboczych) ponosi firma, nie skrypt.

Drugie ograniczenie: fallback nie chroni przed błędami w samych danych faktury. Jeśli NIP kontrahenta jest błędny albo brakuje wymaganego pola, retry będzie powtarzał ten sam błąd w nieskończoność, tylko opóźniając moment, w którym ktoś to zauważy. Dlatego w naszych wdrożeniach walidacja danych wejściowych happens zawsze przed wejściem do kolejki wysyłkowej, nie po błędzie z KSeF. To tańsze i szybsze niż debugowanie przez logi API.

Trzecie: monitoring statusu KSeF trzeba traktować poważnie, ale nie fanatycznie. Nie polecam budowania osobnego dashboardu z pollingiem co minutę, bo to i tak nie przyspieszy decyzji o przejściu w offline24, a generuje niepotrzebny ruch. Wystarczy, że workflow sam rejestruje wzorzec powtarzających się błędów i po przekroczeniu sensownego progu (np. trzy nieudane próby w ciągu godziny) eskaluje temat do człowieka. Prostsze rozwiązania zwykle są trwalsze niż rozbudowane systemy monitoringu budowane „na wszelki wypadek”.