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.
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. HTTP 450 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ć.
Kluczowy szczegół: ten błąd dotyczy kontekstu, nie samego tokenu. Gdyby token był technicznie niepoprawny, KSeF zwróciłby 401. Gdyby brakowało uprawnień, byłoby to 403. 450 oznacza: „znam token, ale nie wpuszczę go do tego NIP-u”.
Gdzie to występuje
Adresy ap-test.ksef.mf.gov.pl, ap-demo.ksef.mf.gov.pl oraz api-demo.ksef.mf.gov.pl to ś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 produkcji, pod adresem ksef.podatki.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. 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 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ń. To zwraca 403, nie 450.
- Błędu konfiguracji klienta API. Niepoprawne szyfrowanie, format JSON czy nagłówki dają zwykle 400, 401 lub 500.
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.
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.