Kod 450 jest jednym z najbardziej irytujących komunikatów w KSeF, bo mówi, że coś jest źle, ale nie mówi co. Faktura wygląda poprawnie, program ją przyjął, a Krajowy System e-Faktur odrzuca ją z lakonicznym „Błąd weryfikacji semantyki dokumentu faktury”. Bez wskazania pola, bez numeru wiersza, bez podpowiedzi.
W tym artykule pokazujemy, które pola struktury FA(3) najczęściej wywołują ten błąd. Lista pochodzi z naszych własnych wdrożeń: każdy z opisanych punktów realnie zwrócił 450, zanim udało się go namierzyć.
Uwaga na początek: kod 450 pojawia się w dwóch zupełnie różnych sytuacjach. Mylenie ich to najczęstszy powód straconego czasu, więc opisujemy je osobno. Inne kody, na przykład 440 (duplikat faktury) czy 435 (błąd odszyfrowania), mają własne poradniki, a wszystkie zebraliśmy w zestawieniu kodów błędów KSeF.
Dwa różne znaczenia kodu 450
Wariant pierwszy, znacznie częstszy: odrzucona faktura. Wysyłka przeszła, sesja działa, ale KSeF nie przyjął dokumentu. W odpowiedzi widać "code": 450, "description": "Błąd weryfikacji semantyki dokumentu faktury". To znaczy, że plik XML jest poprawny technicznie, ale jego treść łamie zasady struktury FA(3). Temu poświęcona jest większość tego tekstu.
Wariant drugi, rzadszy: odmowa przy logowaniu. Status 450 w odpowiedzi na zapytanie o stan uwierzytelnienia, na przykład z komunikatem Token cannot be used in nip-XXXXXXXXXX context. Tu nie ma jeszcze żadnej faktury, problem dotyczy uwierzytelnienia. Opisujemy go w drugiej części.
Rozróżnienie jest proste: jeżeli w komunikacie pada słowo „semantyki”, masz wariant pierwszy. Jeżeli pada „token”, masz wariant drugi.
Dlaczego KSeF nie mówi, które pole jest błędne
To nie jest awaria ani niedoróbka konkretnego programu. Walidacja semantyczna po stronie MF sprawdza dokument jako całość i zwraca jedną zbiorczą odpowiedź. Czasem dołączony jest details, na przykład „Nieprawidłowy XML” albo „Could not find schema information for the element…”, ale w wielu przypadkach nie ma nawet tego.
Praktyczny skutek: poprawianie faktury metodą prób i błędów potrafi zająć pół dnia. Dlatego warto zacząć od listy pól, które statystycznie odpowiadają za większość odrzuceń.
Pola FA(3), które najczęściej wywołują 450
Poniższe punkty to błędy, które sami popełniliśmy i naprawiliśmy, budując generator FA(3). Każdy z nich przechodzi walidację schematu XSD, a mimo to kończy się kodem 450.
1. Stara przestrzeń nazw, czyli FA(2) zamiast FA(3)
Najczęstszy błąd przy migracji ze starszej struktury. FA(2) używa http://crd.gov.pl/wzor/2023/06/29/12648/, FA(3) używa http://crd.gov.pl/wzor/2025/06/25/13775/. Wystarczy zostawić starą wartość, żeby KSeF odrzucił dokument z detalem „Could not find schema information for the element”. Sprawdź to jako pierwsze, bo naprawa trwa sekundę.
2. P_1M to miejsce wystawienia, nie data
Pole P_1M bywa wypełniane datą przez analogię do P_1. To miejscowość. Data w tym polu to pewne odrzucenie.
3. Pomylone pola w wierszu faktury
To źródło największej liczby odrzuceń, bo pól jest kilka i łatwo je poprzestawiać:
- P_8A — jednostka miary (
szt.,usł.,godz.) - P_8B — ilość
- P_9A — cena jednostkowa netto
- P_11 — wartość netto pozycji, czyli ilość razy cena jednostkowa
- P_12 — stawka VAT jako liczba, na przykład
23
Dwa klasyczne błędy: wstawienie kwoty brutto do P_11 oraz wstawienie ceny jednostkowej do P_12. Oba dają 450 bez żadnej wskazówki.
Sama stawka VAT bywa też odrzucana osobno, z innym komunikatem niż 450. Opisaliśmy to w tekście o błędzie stawki VAT w KSeF.
4. Data w wierszu to P_6A, nie P_6
Na poziomie Fa polem daty sprzedaży jest P_6. W pojedynczym wierszu odpowiednik nazywa się P_6A. Użycie P_6 wewnątrz wiersza to literówka, która kosztuje odrzucenie.
5. Płaskie Adnotacje zamiast zagnieżdżonych
W FA(3) nie działa zapis w rodzaju <P_19>2</P_19>. Znaczniki „nie dotyczy” są zagnieżdżone w osobnych elementach:
Zwolnienie→P_19N= 1NoweSrodkiTransportu→P_22N= 1PMarzy→P_PMarzyN= 1
To jedna z ważniejszych różnic względem FA(2) i częsty powód, dla którego działający wcześniej generator nagle przestaje przechodzić.
6. Brak flag JST i GV w Podmiot2
Sekcja nabywcy wymaga obu znaczników. Dla zwykłego nabywcy komercyjnego wartością jest 2. Ich pominięcie kończy się 450.
7. Zła kolejność elementów pod znacznikiem Fa
Kolejność w FA(3) jest inna niż w FA(2). FaWiersz występuje po sumach, Adnotacje i RodzajFaktury, a nie przed nimi. Schemat XSD tego nie zawsze wychwyci, walidacja semantyczna owszem.
8. Niepoprawny NIP nabywcy
NIP musi mieć poprawną sumę kontrolną. Ciąg dziesięciu cyfr, który wygląda sensownie, ale nie przechodzi walidacji, zostanie odrzucony. Dla nabywcy zagranicznego lub osoby prywatnej NIP-u nie podaje się w ogóle — używa się przewidzianych do tego oznaczeń, a nie NIP-u zastępczego.
Jak podejść do poprawiania po kolei
- Sprawdź przestrzeń nazw. Sekunda pracy, częsta przyczyna.
- Porównaj wiersz faktury z listą pól powyżej. Zwłaszcza P_11 i P_12.
- Sprawdź Adnotacje. Jeżeli generator pochodzi z czasów FA(2), to prawdopodobny winowajca.
- Sprawdź kolejność elementów pod Fa.
- Zwaliduj NIP-y, własny i nabywcy.
- Podziel dokument na pół. Jeżeli nadal nie wiadomo, wyślij fakturę z jedną pozycją zamiast wszystkich. Odrzucenie wskaże, czy problem jest w nagłówku, czy w wierszach.
Nasz darmowy walidator XML sprawdza część z tych rzeczy przed wysyłką. Zaznaczamy uczciwie: nie odtwarza pełnej walidacji semantycznej MF, więc pewne błędy i tak wyjdą dopiero przy wysyłce do KSeF.
Wariant drugi: 450 przy logowaniu tokenem
Ta część dotyczy zupełnie innej sytuacji. Nie ma jeszcze żadnej faktury, a KSeF odmawia samego uwierzytelnienia komunikatem status.code: 450, "Token cannot be used in nip-XXXXXXXXXX context." Liczba po nip- to NIP, na którym próbujemy operować.
To nie jest kod HTTP. Odpowiedź przychodzi z kodem HTTP 200, a 450 to status.code w jej treści. Oficjalny opis brzmi „Uwierzytelnianie zakończone niepowodzeniem z powodu błędnego tokenu”, a szczegóły mówią, co dokładnie jest nie tak. Dokumentacja API KSeF wymienia osiem takich wariantów: „Nieprawidłowe wyzwanie autoryzacyjne”, „Nieprawidłowy token”, „Nieprawidłowy czas tokena”, „Token unieważniony”, „Token nieaktywny”, „Nieprawidłowe szyfrowanie tokena”, „Nieprawidłowe kodowanie tokena” oraz „Token nie może być użyty w kontekście…”.
Ta część tekstu dotyczy ostatniego wariantu, czyli kontekstu. Oznacza on: „znam token, ale nie wpuszczę go do tego NIP-u”. Pozostałe warianty dotyczą samego tokenu albo sposobu, w jaki program go przesyła. Przy tokenie unieważnionym lub nieaktywnym zwykle pomaga nowy token wygenerowany w Aplikacji Podatnika. Brak uprawnień przy logowaniu to inny kod, 415 ze szczegółem „Brak przypisanych uprawnień” (błąd 415 w KSeF), a pełną listę kodów logowania znajdziesz w zestawieniu kodów błędów KSeF.
Gdzie to występuje
Pod adresami ap-test.ksef.mf.gov.pl, ap-demo.ksef.mf.gov.pl oraz api-demo.ksef.mf.gov.pl działają środowiska, w których ten wariant pojawia się zdecydowanie najczęściej. Dane są tam wprowadzane mniej rygorystycznie niż w produkcji, a niektóre testowe NIP-y bywają niepoprawnie zarejestrowane, niezsynchronizowane albo po prostu „zużyte” wieloma poprzednimi testami integratorów.
W środowisku produkcyjnym (Aplikacja Podatnika pod adresem ap.ksef.mf.gov.pl) ten wariant zdarza się rzadko.
Trzy przyczyny
NIP nie jest aktywny w danym środowisku. Musi istnieć w bazie MF konkretnego środowiska jako aktywny podatnik VAT. Nie wystarczy, że istnieje w produkcji: środowiska testowe mają oddzielne dane, a synchronizacja z rejestrami jest niepełna.
Token wygenerowano w innym NIP-ie. Token KSeF nosi w sobie deklarację NIP, w którym może działać. Ma postać YYYYMMDD-EC-HEX-HEX-NN|nip-XXXXXXXXXX|HEX. NIP po nip- musi zgadzać się z NIP-em w żądaniu.
„Uszkodzony” NIP w bazie testowej MF. Najmniej oczywista przyczyna, której dokumentacja MF nie opisuje. Niektóre testowe NIP-y, przez które przeszło wielu integratorów, trafiają w stan, w którym po stronie MF coś jest niespójne. Token jest poprawny, NIP istnieje, ale każda próba kończy się 450. Dla biura wygląda to jak własny błąd, a według naszych obserwacji jest błędem danych po stronie MF.
Czego ten wariant nie oznacza
- Braku certyfikatu uwierzytelniającego. Przy uwierzytelnianiu tokenem certyfikat nie jest wymagany.
- Niewystarczających uprawnień. Przy logowaniu to kod 415, a po zalogowaniu HTTP 403, nie 450.
- Błędu konfiguracji klienta API. Źle zaszyfrowany token też daje 450, ale z innym szczegółem („Nieprawidłowe szyfrowanie tokena”). Błędny format żądania to zwykle HTTP 400 z kodem 21405 (błąd 21405 w KSeF), a brak zalogowania to HTTP 401.
Czego nauczyła nas własna walka z tym wariantem
W naszym wdrożeniu w 2026 r. spędziliśmy dwa tygodnie, próbując naprawić 450 w środowisku testowym przy poprawnym tokenie, poprawnym NIP-ie i pełnej walidacji kryptograficznej po stronie klienta. Pomogła jedna zmiana: przeniesienie testów na inny NIP. Świeży NIP, świeży token wygenerowany w aplikacji Podatnika, jedna próba — czysta autoryzacja, status.code: 200, isTokenRedeemed: true.
Wniosek praktyczny: jeśli wszystko po Twojej stronie jest poprawne, a błąd nie znika, to prawdopodobnie nie chodzi o Twoją konfigurację. Zmień NIP. Nam samym oszczędziłoby to dwóch tygodni.
Jeżeli ten wariant wystąpi w produkcji przy poprawnym NIP-ie i tokenie, po stronie biura nie ma już czego sprawdzać. Wtedy zgłoszenie do MF:
- Formularz na
ksef.podatki.gov.pl/formularz/ - E-mail:
jpk.helpdesk@mf.gov.pl(działa i odpowiada) - Telefon 22 330 03 30, menu 6 → 1 → 2 (po polsku)
Czas odpowiedzi liczy się w dniach lub tygodniach, więc najpierw warto wyczerpać kroki powyżej.
Jeżeli 450 pojawia się przy logowaniu, a nie przy fakturze, pomocne będą osobne poradniki: certyfikat KSeF i jego rodzaje, Aplikacja Podatnika KSeF oraz jak wystawić fakturę w KSeF krok po kroku.
Nie chcesz, żeby błędy KSeF lądowały na Twoim biurku? FakturaFlow przejmuje wysyłkę faktur do KSeF za biuro rachunkowe. Autoryzacja, generowanie poprawnego FA(3) i pobranie UPO dzieją się po naszej stronie, więc nie tracisz dni na diagnozowanie komunikatów takich jak 450. Zobacz, jak FakturaFlow obsługuje KSeF za biuro.
Podsumowanie
Kod 450 znaczy dwie różne rzeczy. Najczęściej oznacza odrzuconą fakturę, czyli „Błąd weryfikacji semantyki dokumentu faktury” — plik jest technicznie poprawny, ale jego treść łamie zasady FA(3). KSeF nie wskazuje pola, więc zacznij od przestrzeni nazw, pól P_11 i P_12 w wierszu, zagnieżdżonych Adnotacji i kolejności elementów pod Fa.
Rzadziej 450 pojawia się przy logowaniu tokenem, prawie zawsze w środowisku testowym, i wtedy najskuteczniejszym ruchem jest zmiana NIP-u na inny aktywny.