Przejdź do głównej treści
KSeF 2.0 · status faktury

Kod 450 w KSeF: „Błąd weryfikacji semantyki dokumentu faktury”

Status 450 oznacza, że KSeF przyjął plik do przetwarzania, a potem odrzucił fakturę przy sprawdzaniu jej treści. To inny kod niż 450 przy logowaniu, który dotyczy tokenu (opisujemy go osobno). Odoo pokaże Ci numer i ogólny opis, a konkretna przyczyna jest w polu details odpowiedzi KSeF.

FlexigoTech · Odpowiada: Víctor Gómez · Aktualizacja: 5 listopada 2026

Najważniejsze

Moduł
KSeF 2.0
Wersje
Odoo 17, 18, 19 i 20
Sprawdzone
w kodzie źródłowym modułu, wersja 17.0 i 20.0 · w źródłach podanych na końcu
Czas czytania
3 min

Co dokładnie zwraca KSeF

W specyfikacji API KSeF 2.9.0 status faktury w sesji 450 ma stały opis „Błąd weryfikacji semantyki dokumentu faktury”. To, co konkretnie się nie zgadza, KSeF dopisuje w polu details tego samego statusu. Ministerstwo Finansów nie publikuje listy tych komunikatów, więc nie ma tabeli w stylu „450 to zawsze ten sam błąd”.

Są za to przypadki, które MF sprawdza w testach swojej biblioteki ksef-client-csharp i w których oczekuje właśnie kodu 450:

  • data wystawienia P_1 ustawiona na jutro według czasu polskiego, bo KSeF liczy P_1 w strefie Warszawy i nie przyjmie daty późniejszej niż chwila przyjęcia faktury;
  • DataWytworzeniaFa wcześniejsza niż 2025-09-01T00:00:00Z, czyli dolna granica tego pola w schemacie FA(3) 1-0E.
Karta kodu 450 KSeF z opisem z API
Kod 450 i jego opis z API KSeF 2.9.0, z polami, od których warto zacząć.

Co widzisz w Odoo

Fakturę do KSeF wysyła moduł l10n_pl_edi z Odoo, który istnieje w Odoo 18, 19 i 20. Po odpowiedzi KSeF ustawia pole „KSeF Status” na Rejected i zapisuje komunikat w historii faktury:

WersjaKomunikat w Odoo
Odoo 18 i 19 po polsku„Status KSeF: Odrzucono (kod: 450). Błąd weryfikacji semantyki dokumentu faktury.”
Odoo 20„KSeF Status: Rejected (Code: 450). Invoice document semantics verification error.” (polskie tłumaczenie tego modułu jest w 20 puste)
Odoo 17Nie ma l10n_pl_edi: fakturę wysyła inny program i to on pokazuje błąd.

Z odpowiedzi KSeF Odoo czyta kod, opis i numer KSeF. Pola details nie zapisuje (opis z KSeF dokleja tylko przy kodzie 500), więc sam Odoo nie powie Ci, który element faktury się nie zgadza.

Skąd wziąć przyczynę

Treść details jest w odpowiedzi KSeF na zapytanie o status faktury w sesji. Przy wysyłce z Odoo potrzebujesz kogoś, kto odczyta ją z API, albo sprawdzenia pliku FA(3) przed wysyłką. Odoo 18, 19 i 20 ma w module kopię schematu FA(3), ale poza testami nic jej nie używa: plik idzie do KSeF bez walidacji ze schematem.

Dwóch rzeczy Odoo jednak pilnuje. Faktury z datą późniejszą niż dzisiejsza w strefie użytkownika nie wyśle w ogóle („The move was skipped because it is future-dated”, w 18 i 19 po polsku „Ten zapis został pominięty ponieważ ma przyszłą datę”). A DataWytworzeniaFa wypełnia chwilą wygenerowania pliku w UTC, więc granica z 2025 roku nie powinna wyjść z faktury wystawionej w Odoo.

Jak wysłać fakturę ponownie

  1. Ustal przyczynę z details albo sprawdź plik FA(3) ze schematem.
  2. Popraw dane w Odoo: datę, kontrahenta, pozycje.
  3. Przywróć fakturę do wersji roboczej. Przy fakturze odrzuconej Odoo czyści jej stan, numer, referencję i sesję KSeF.
  4. Zatwierdź ją i wyślij jeszcze raz opcją „by KSeF (e-Faktura)”. Odoo wysyła tylko faktury bez stanu KSeF, więc bez kroku 3 ponowna wysyłka nie ruszy.
Schemat: co zwraca KSeF przy kodzie 450 i co pokazuje Odoo 20
Schemat na podstawie kodu l10n_pl_edi z Odoo 20 i specyfikacji API KSeF 2.9.0; skreślone jest to, czego Odoo nie zapisuje albo nie robi.

Z naszym modułem

Poland KSeF 2.0 Validator nie wysyła faktur do KSeF. Z subskrypcją FlexigoTech Cloud, jeśli przed wysyłką klikniesz „Validate FA(3) (FlexigoTech Cloud)”, waliduje plik FA(3) ze schematem 1-0E i pokazuje każdy błąd jako wiersz „[error] XSD (ścieżka)”: z miejscem w pliku, bez treści komunikatu, maksymalnie 100 błędów. Wynik nie blokuje wysyłki przez l10n_pl_edi: faktura „Not valid” wyjdzie, jeśli ją wyślesz. Nie wykryje przyczyn, które KSeF sprawdza dopiero u siebie, jak data P_1 względem chwili przyjęcia. Gdy l10n_pl_edi wyśle fakturę, wcześniejsza walidacja dostaje stan Expired, a moduł sprawdza plik, który faktycznie dostał KSeF. W Odoo 17 waliduje plik FA(3) wgrany do faktury.

Kodu 450 nasz moduł nie przejmuje: od l10n_pl_edi bierze tylko stan (Submitted, Accepted albo Rejected) i numer KSeF.

Czytaj dalej

Daty w FA(3): P_1, P_6 i DataWytworzeniaFaReguły dat w schemacie FA(3) 1-0E i w KSeF: P_1 w czasie polskim, P_6, DataWytworzeniaFa od 2025-09-01. Kiedy kończą się kodem 450 i jak wypełnia je Odoo 18, 19 i 20.Statusy techniczne faktury w KSeF: 550, 500, 405, 430 i 435Statusy faktury KSeF niezależne od jej treści: 550 „Operacja została anulowana przez system”, 500, 405, 430 i 435. Co robi z nimi Odoo i czemu 550 zostaje w Sent.Statusy uwierzytelniania KSeF: 415, 425, 450, 470 i 480Statusy logowania do KSeF 2.0 poza certyfikatem: brak uprawnień, unieważnienie, zły token, blokada. Kody 21301 i 21304 i jak to wygląda w Odoo 18-20.
Sprawdzone w kodzie źródłowym modułu (wersja 17.0 i 20.0) i w podlinkowanych źródłach

Źródła