Faktura odrzucona przez KSeF? Najczęstsze błędy i sposoby naprawy

Poprawna odpowiedź techniczna na żądanie wysyłki nie oznacza jeszcze, że KSeF przyjął fakturę. Status 100 informuje o przyjęciu do dalszego przetwarzania, status 150 o trwającym przetwarzaniu, a dopiero status 200 oznacza sukces faktury.

Odrzucony dokument nie otrzymuje numeru KSeF ani UPO i nie zostaje wystawiony w KSeF. Najpierw odczytaj kod, opis i szczegóły błędu. Dopiero potem popraw datę P_1, XML FA(3), uprawnienia, sposób szyfrowania lub inną wskazaną przyczynę.

Najkrótsza bezpieczna procedura to: sprawdź status, zachowaj szczegóły odpowiedzi i wysłany XML, wyklucz wcześniejszy sukces, popraw źródło błędu, zwaliduj nowy plik, wyślij go ponownie i monitoruj wynik do uzyskania numeru KSeF oraz UPO.

Widzisz komunikat po wysyłce, ale nie masz numeru KSeF ani UPO. Najgorszą reakcją jest natychmiastowe ponowienie wysyłki bez sprawdzenia wyniku. Endpoint może przyjąć żądanie, zaszyfrowany plik i metadane, a następnie dopiero rozpocząć przetwarzanie faktury.

Statusy 100 i 150 nie oznaczają odrzucenia. Nie są też sukcesem końcowym. W tych stanach należy kontynuować sprawdzanie statusu tej samej faktury, zamiast tworzyć kolejną wysyłkę.

Kody błędów trzeba interpretować razem z polami description, details i extensions. Sam kod wskazuje kategorię problemu, ale szczegóły odpowiedzi prowadzą do konkretnej przyczyny.

Nie wysyłaj ponownie dokumentu tylko dlatego, że nie widzisz jeszcze UPO. Najpierw sprawdź status i numer KSeF.

Numer referencyjny sesji lub faktury służy do śledzenia operacji technicznej. Nie jest numerem KSeF. Numer KSeF identyfikuje fakturę przyjętą przez system, a UPO jest urzędowym potwierdzeniem dostępnym po pozytywnym przetworzeniu.

Status faktury może zawierać numer KSeF, datę jego nadania i adres do pobrania UPO. Dane te są skutkiem sukcesu faktury, a nie samego rozpoczęcia wysyłki.

Jeżeli weryfikacja jest negatywna, KSeF nie nadaje numeru. Taki dokument nie został wystawiony w KSeF. Można więc poprawić jego dane i ponowić wysyłkę jako faktury pierwotnej, a nie jako korekty.

Pole P_1 zawiera datę wystawienia wskazaną przez wystawcę. Trzeba porównać ją z faktyczną datą przesłania dokumentu do KSeF. Trzy możliwe relacje prowadzą do trzech różnych wyników.

Przykład odrzucenia: plik przesyłasz 2 czerwca 2026 r., ale w P_1 wpisano 3 czerwca 2026 r. Data z przyszłości powoduje odrzucenie XML na bramce.

Przykład offline24: w P_1 wpisano 2 czerwca 2026 r., a fakturę przesyłasz 3 czerwca 2026 r. Wcześniejsze P_1 nie powoduje automatycznego odrzucenia. Dokument jest kwalifikowany jako wystawiony w trybie offline24 i podlega terminowi właściwemu dla tego trybu.

Od 1 lutego 2026 r. obowiązującym wzorem faktury ustrukturyzowanej jest FA(3). KSeF porównuje przesłany XML z zadeklarowaną strukturą XSD. Brak pola wymaganego, niedozwolony format wartości, niewłaściwy typ danych, błędna kolejność lub struktura elementów albo użycie niezgodnego schematu może zakończyć się odrzuceniem.

Kod 430 oznacza błąd weryfikacji pliku faktury. Kod 450 wskazuje błąd weryfikacji semantyki dokumentu. W obu przypadkach trzeba przeczytać szczegóły odpowiedzi i poprawić dane w systemie źródłowym, a następnie wygenerować XML ponownie.

Walidacja KSeF ma granice. Ministerstwo Finansów wskazuje, że system nie weryfikuje obliczeń matematycznych faktury i nie odrzuca jej wyłącznie dlatego, że VAT został błędnie wyliczony względem kwoty netto. Przyjęcie dokumentu nie potwierdza więc pełnej poprawności rachunkowej, podatkowej ani biznesowej danych.

Możliwość uwierzytelnienia w KSeF nie oznacza automatycznie prawa do wystawiania faktur w każdym kontekście. Chronione zasoby API wymagają tokenu dostępu, a wysłanie zwykłej faktury wymaga właściwego uprawnienia, wskazanego w API jako InvoiceWrite.

Kod 410 oznacza nieprawidłowy zakres uprawnień faktury. Sprawdź, czy sesja została otwarta dla właściwego podatnika, czy token lub sesja są nadal ważne, kto faktycznie wysyła dokument i czy ta osoba albo podmiot ma prawo do wystawiania w danym kontekście.

Poprawianie XML nie pomoże, jeśli przyczyną jest dostęp. W takim przypadku trzeba naprawić konfigurację uwierzytelnienia lub uprawnień i dopiero potem ponowić wysyłkę niezmienionego merytorycznie dokumentu.

Kod 440 oznacza, że KSeF rozpoznał duplikat faktury. Odpowiedź może zawierać originalSessionReferenceNumber oraz originalKsefNumber, czyli dane prowadzące do pierwotnej sesji i wcześniej nadanego numeru KSeF.

Najpierw odszukaj wskazaną fakturę, sprawdź jej status i pobierz UPO. Nie generuj nowego dokumentu ani nie zmieniaj numeru faktury tylko po to, aby ominąć kontrolę duplikatu.

Oficjalne źródła potwierdzają kod 440 i dane zwracane przez API, ale nie dają podstawy do publikowania szczegółowego algorytmu rozpoznawania duplikatów. W praktyce należy opierać decyzję na wyniku API i śladzie wcześniejszego sukcesu.

1. Zachowaj numer referencyjny sesji, numer referencyjny faktury, dokładny czas operacji i wysłany XML. Bez tego trudniej odtworzyć przebieg zdarzeń.

2. Pobierz status konkretnej faktury. Nie ograniczaj się do komunikatu, że żądanie zostało przyjęte przez endpoint.

3. Odczytaj pola code, description, details i extensions. Zapisz pełną odpowiedź, ponieważ skrócony komunikat w interfejsie może nie pokazywać wszystkich danych diagnostycznych.

4. Przypisz błąd do kategorii: data P_1, FA(3) lub XSD, semantyka, uprawnienia, szyfrowanie, załącznik, duplikat albo problem techniczny.

5. Sprawdź, czy dokument nie ma już numeru KSeF. Jest to obowiązkowe przed każdą ponowną wysyłką.

6. Popraw źródło danych, nie tylko końcowy tekst XML. Dzięki temu kolejny dokument wygenerowany przez system nie powtórzy tego samego błędu.

Jeżeli faktura nie dostała numeru KSeF, popraw dane źródłowe lub dostęp. Następnie wygeneruj nowy XML FA(3), sprawdź zgodność struktury, rozpocznij prawidłową sesję i prześlij dokument ponownie.

Po wysyłce monitoruj tę fakturę aż do statusu końcowego. Statusy 100 i 150 wymagają dalszego oczekiwania. Status błędu wymaga ponownej diagnozy. Proces uznaj za zakończony dopiero po statusie 200, nadaniu numeru KSeF i udostępnieniu UPO.

Jeżeli dokument ma już numer KSeF, nie edytuj go i nie wysyłaj poprawionej wersji jako tej samej faktury. Przyjęty dokument pozostaje w systemie, a błąd poprawia się według zasad faktury korygującej.

Przed utworzeniem kolejnej wysyłki przejdź całą listę kontroli. Najważniejszy punkt to wykluczenie, że wcześniejsza operacja zakończyła się sukcesem, mimo że Twoja aplikacja nie pokazała jeszcze UPO.

Lokalny walidator pomaga wykrywać problemy techniczne w XML przed wysyłką, ale nie zastępuje biznesowej walidacji KSeF, nie potwierdza przyjęcia przez system i nie gwarantuje pełnej poprawności podatkowej dokumentu.

Ten poradnik służy do diagnozy konkretnego odrzucenia. Pełny przebieg procesu opisuje artykuł Wysyłka faktur do KSeF, a znaczenie potwierdzenia po sukcesie wyjaśnia poradnik UPO w KSeF.

Budowę dokumentu i rolę schematu opisuje artykuł XML i format FA(3) w KSeF. Jeżeli błąd dotyczy faktury, która ma już numer KSeF, właściwą ścieżkę znajdziesz w poradniku Faktura korygująca w KSeF.

Po błędzie nie zaczynaj od edycji przypadkowych pól. Najpierw ustal końcowy status i zachowaj pełną odpowiedź API. Wyklucz wcześniejszy sukces, przypisz problem do jednej kategorii i popraw dane w systemie źródłowym.

Po wygenerowaniu nowego XML sprawdź strukturę, uprawnienia i P_1. Następnie wyślij dokument w prawidłowej sesji i monitoruj go do statusu 200, numeru KSeF oraz UPO. Jeżeli numer KSeF już istnieje, przejdź do korekty zamiast ponownej wysyłki.

Rekomendowane poradniki: Wysyłka faktur do KSeF, UPO w KSeF, XML i format FA(3) w KSeF oraz Faktura korygująca w KSeF.