Weryfikacja negatywna – dokument niezgodny ze schematem XSD (kod 401)

Komunikat weryfikacja negatywna – dokument niezgodny ze schematem xsd oznacza jedno: system odrzucił przesłany plik, bo jego struktura nie odpowiada oficjalnemu wzorowi dokumentu (schematowi XSD). Dokument nie został przyjęty i nie powstanie dla niego UPO (urzędowe poświadczenie odbioru) — w sensie prawnym nie został złożony. Numer referencyjny wysyłki pozostaje jednak ważny: to nim sprawdzasz status przetwarzania i pod nim znajdziesz treść błędu.

To błąd czysto techniczny, a nie zarzut merytoryczny. Nie oznacza, że kwoty są złe albo że kontrahent jest nieuczciwy — oznacza, że plik XML ma nie ten kształt, którego system oczekuje: brakuje wymaganego pola, elementy są w złej kolejności albo wartość nie mieści się w dopuszczalnym formacie. W tym artykule pokazuję, jak czytać ten komunikat, jak w kilka minut namierzyć konkretne pole, które go wywołało, i jak uniknąć powtórek tego samego odrzucenia.

Skąd bierze się kod 401 i którego systemu dotyczy

Jeżeli obok komunikatu widzisz liczbę 401, dokument prawie na pewno poszedł przez bramkę e-Dokumenty Ministerstwa Finansów — tę samą, przez którą wysyła się JPK_V7, deklaracje PIT, CIT czy VIU-DO. W tej bramce status przetwarzania to trzycyfrowy kod, a 401 ma stałe znaczenie: "weryfikacja negatywna – dokument niezgodny ze schematem xsd". Dla porównania 200 to przetworzenie zakończone poprawnie (można pobrać UPO), a kolejne kody z tej rodziny oznaczają inne przyczyny odrzucenia — na przykład 404 (nieważny certyfikat), 405 (certyfikat odwołany) czy 408 (dokument zawiera błędy uniemożliwiające przetworzenie).

Uwaga na kod 407: jego znaczenie zależy od tego, co wysyłasz. Przy deklaracjach (PIT, CIT, VIU-DO) oznacza dokument z certyfikatem o nieprawidłowej ścieżce certyfikacji, a przy JPK — przesłanie duplikatu dokumentu już przetworzonego. Zanim zaczniesz szukać przyczyny, sprawdź więc opis kodu dla właściwego kanału wysyłki.

Trzy uwagi, które oszczędzają sporo czasu przy diagnozie:

• To nie jest HTTP 401. Kod 401 w protokole HTTP oznacza problem z uwierzytelnieniem ("nie wiadomo, kim jesteś"). Tutaj 401 to status przetwarzania dokumentu i z logowaniem nie ma nic wspólnego. Zbieżność liczb jest przypadkowa.
• KSeF nie używa tego kodu. Ma własną numerację statusów, więc jeśli odrzucenie przyszło z KSeF, kodu 401 tam nie zobaczysz. Sama sytuacja jest jednak analogiczna — plik nie zgadza się ze schematem i faktura nie zostaje wystawiona — więc procedura naprawy opisana niżej działa tak samo.
• Najważniejsza treść jest w nawiasie kwadratowym. Komunikat zwykle kończy się doprecyzowaniem w [ ], często po angielsku — i to ono, a nie samo słowo "401", wskazuje konkretne pole.

Jeśli szukasz jednak błędu 401 dotyczącego dostępu do API lub portalu KSeF, to osobny temat: Błąd 401 w KSeF – uwierzytelnienie, uprawnienia i token.

Najczęstsze przyczyny kodu 401 przy JPK_V7 i deklaracjach

W plikach JPK_V7 i deklaracjach wysyłanych przez bramkę e-Dokumenty powtarza się wąski zestaw przyczyn:

• data spoza dopuszczalnego zakresu — literówka w roku (np. 2190-09-09) wystarczy, żeby dokument nie przeszedł walidacji,
• pusty numer dokumentu zakupu w ewidencji zakupów VAT — pole jest obowiązkowe,
• niepoprawny NIP — za długi, za krótki albo brakujący (własny lub kontrahenta),
• adres e-mail z polskimi znakami lub spacją w danych podstawowych firmy,
• brak numeru i daty KSeF przy dokumencie z KSeF, albo — dla dokumentu spoza KSeF — brak jednego z atrybutów OFF, BFK, DI,
• kwota mniejsza lub równa 0,00 w polu, które wymaga wartości dodatniej (typowe przy VIU-DO).

Po poprawieniu danych dokument wysyła się ponownie i sprawdza status jeszcze raz — nie składa się korekty.

Co dokładnie znaczy "weryfikacja negatywna"

Wysyłka dokumentu do systemów Ministerstwa Finansów przebiega w krokach: przesyłasz plik, dostajesz numer referencyjny, a system nadaje przetwarzaniu status. Weryfikacja negatywna (w bramce e-Dokumenty: kod 401) to status końcowy oznaczający, że dokument nie przeszedł kontroli i został odrzucony. Doprecyzowanie "dokument niezgodny ze schematem xsd" wskazuje, na którym etapie kontrola się zatrzymała. W KSeF działa to analogicznie: otwierasz sesję, przesyłasz fakturę, a status końcowy mówi, czy dokument został przyjęty.

Warto rozróżnić trzy sytuacje, które w codziennej pracy łatwo pomylić:

• Weryfikacja negatywna (niezgodność ze schematem XSD) — plik ma złą strukturę. Faktura nie powstała.
• Odrzucenie z powodu reguł systemowych lub uprawnień — plik jest zgodny ze schematem, ale coś innego blokuje przyjęcie (np. brak uprawnień, zła sesja, duplikat).
• Przyjęcie z błędem merytorycznym — faktura przeszła walidację i ma numer KSeF, ale zawiera pomyłkę w danych. System jej nie zatrzyma.

Tylko pierwszy przypadek jest tematem tego artykułu. Jest jednocześnie najłatwiejszy do naprawienia, bo komunikat zwykle wskazuje miejsce błędu.

Czym jest schemat XSD i dlaczego faktura musi mu odpowiadać

XSD to plik opisujący dozwoloną budowę dokumentu XML. Można go traktować jak formularz urzędowy z narzuconym układem rubryk: określa, które pola są obowiązkowe, które opcjonalne, w jakiej kolejności występują, jakiego typu wartości przyjmują (data, liczba, tekst) i jak długie mogą być.

Każdy typ dokumentu ma swój wzór: JPK_V7 ma własny schemat, deklaracje PIT i CIT swoje, a dla faktur ustrukturyzowanych w KSeF obowiązującym wzorem jest FA(3). Jeśli przesłany XML odbiega od tego wzoru choćby w jednym miejscu, system nie próbuje "domyślać się" intencji — odrzuca całość. Stąd sytuacja, w której poprawna merytorycznie faktura zostaje zablokowana przez jeden znak w polu daty.

Sam plik może być przy tym poprawnym XML-em (czyli mieć poprawnie domknięte znaczniki), a mimo to być niezgodny ze schematem. To dwie różne kontrole: pierwsza sprawdza składnię, druga zgodność z wzorem. Jeśli struktura pliku XML jest dla Ciebie nowa, zacznij od przewodnika Jak czytać XML faktury z KSeF.

Najczęstsze przyczyny niezgodności ze schematem XSD

Z praktyki wdrożeniowej powtarza się kilka wzorców. Uszeregowałem je od najczęstszych.

1. Zła kolejność elementów

Schemat FA(3) w większości sekcji wymaga ustalonej kolejności pól. Jeśli program wystawiający fakturę wygeneruje DataWytworzeniaFa przed KodFormularza, plik zostanie odrzucony, mimo że oba pola istnieją i mają poprawne wartości. To najczęstsza przyczyna zaskoczenia: "przecież wszystko tam jest".

2. Brak pola obowiązkowego

Typowo dotyczy sytuacji brzegowych: faktura dla nabywcy zagranicznego bez NIP, faktura zaliczkowa, korekta odwołująca się do dokumentu pierwotnego. W każdym z tych przypadków schemat wymaga zestawu pól, którego zwykła faktura krajowa nie potrzebuje.

3. Wartość niezgodna z formatem pola

Klasyczne przykłady:

• data zapisana jako 26-07-2026 zamiast 2026-07-26,
• NIP z myślnikami lub spacjami (000-000-00-00) zamiast dziesięciu cyfr,
• kwota z przecinkiem dziesiętnym (1234,56) zamiast kropki (1234.56),
• kod waluty zapisany małymi literami zamiast wielkimi.

Wszystkie dane w tym artykule są fikcyjne — przy diagnozie własnej faktury podstawiaj wartości ze swojego pliku.

4. Wartość spoza dozwolonego zbioru

Część pól przyjmuje wyłącznie wartości ze słownika (np. rodzaj faktury, kod formularza, stawka podatku w postaci symbolicznej). Wpisanie własnego opisu w takim polu kończy się odrzuceniem.

5. Przekroczenie długości pola

Nazwy kontrahentów, opisy pozycji i adresy mają limity znaków. Długa nazwa firmy sklejona z dopiskiem ("sp. z o.o. w restrukturyzacji, oddział…") potrafi ten limit przekroczyć.

6. Nieprawidłowa deklaracja przestrzeni nazw lub kodowania

Jeśli plik zadeklaruje inną przestrzeń nazw (namespace) niż wymagana przez FA(3) albo kodowanie inne niż UTF-8, walidacja nie ruszy z miejsca. Polskie znaki diakrytyczne zapisane w złym kodowaniu też potrafią zablokować dokument.

7. Wysyłka pliku w starym wzorze

Dokument zbudowany według wcześniejszej wersji struktury zostanie odrzucony jako niezgodny ze schematem obowiązującym. Ten wariant jest częsty tuż po zmianie wersji wzoru albo przy migracji między środowiskiem testowym a produkcyjnym.

Jak naprawić weryfikację negatywną – krok po kroku

Co się dzieje z fakturą po odrzuceniu

Odrzucony dokument nie trafia do repozytorium KSeF. To ma trzy praktyczne konsekwencje.

Po pierwsze, nie ma czego korygować. Faktura korygująca dotyczy dokumentu, który został wystawiony. Przy weryfikacji negatywnej poprawia się plik źródłowy i wysyła ponownie — jako ten sam dokument, nie jako korektę.

Po drugie, numeracja pozostaje wolna. Numer własny użyty w odrzuconym pliku nie został skonsumowany przez system, więc można go użyć ponownie po poprawce. Warto jednak zachować spójność z własną ewidencją, żeby nie powstała luka w numeracji.

Po trzecie, termin wystawienia biegnie dalej. Odrzucenie nie zatrzymuje terminów wynikających z przepisów, dlatego powtarzające się niezgodności ze schematem przy dużym wolumenie faktur to realne ryzyko operacyjne, a nie drobiazg techniczny.

Czego KSeF nie sprawdza

Walidacja względem schematu XSD odpowiada wyłącznie na pytanie: "czy ten plik ma właściwy kształt". Nie odpowiada na pytanie, czy faktura jest prawdziwa, zasadna i bezpieczna do zapłaty.

KSeF nie zweryfikuje, czy:

• opisana transakcja rzeczywiście miała miejsce,
• NIP należy do firmy, z którą faktycznie współpracujesz,
• numer rachunku bankowego na fakturze należy do wystawcy i nie został podmieniony,
• kwota odpowiada zamówieniu lub umowie,
• kontrahent jest czynnym podatnikiem VAT,
• faktura nie jest elementem oszustwa fakturowego.

Dokument w pełni zgodny ze schematem XSD może być fakturą scamową, czyli elementem procesu oszustwa — na przykład podszycia się pod stałego dostawcę ze zmienionym numerem rachunku. Poprawność techniczna i wiarygodność dokumentu to dwie różne rzeczy. Pełne zestawienie granic kontroli systemowej znajdziesz tutaj: Co KSeF sprawdza, a czego nie sprawdza.

Jak można to zweryfikować automatycznie

Weryfikacja negatywna ze względu na schemat XSD to problem, który dobrze poddaje się automatyzacji — po obu stronach obiegu faktury.

Po stronie wystawiania sensowne jest wpięcie walidacji XSD do procesu tuż przed wysyłką, tak aby błąd struktury został wykryty lokalnie, a nie dopiero po odrzuceniu przez system. Przy większych wolumenach warto też zbierać statystykę odrzuceń według typu błędu — powtarzalny wzorzec zwykle wskazuje jedną wadę w programie lub w danych źródłowych.

Po stronie odbierania faktur automatyzacja zaczyna się dopiero tam, gdzie kończy się walidacja techniczna: porównanie danych faktury z zamówieniem, sprawdzenie NIP-u i numeru rachunku, wykrywanie zmian względem poprzednich dokumentów od tego samego kontrahenta i przypisanie dokumentowi oceny ryzyka, która kieruje wątpliwe przypadki do ręcznej akceptacji. Żadne narzędzie nie daje pewności co do każdej faktury, ale reguły tego typu wyłapują wzorce, które przy ręcznym przeglądzie łatwo przeoczyć. Na czym polega ocena ryzyka dokumentu — Czym jest risk score faktury.

FAQ

Powiązane artykuły

• Błędy walidacji KSeF – co oznaczają – przegląd komunikatów i kategorii błędów
• Błędy walidacji w KSeF: XML/XSD, potem logika biznesowa – kolejność diagnozy odrzuconej faktury
• Jak zwalidować fakturę KSeF przed wysłaniem – walidacja lokalna i narzędzia
• Struktura FA(3) – co zawiera i czego nie zawiera – sekcje i pola schematu faktury
• Jak czytać XML faktury z KSeF – orientacja w pliku i najważniejszych polach
• Błąd 401 w KSeF – uprawnienia, token, kontekst – HTTP 401 przy dostępie do API i portalu

---

Treść ma charakter informacyjny i edukacyjny. Nie stanowi porady prawnej ani podatkowej.