Weryfikacja negatywna – dokument niezgodny ze schematem XSD
Komunikat weryfikacja negatywna – dokument niezgodny ze schematem XSD oznacza jedno: Krajowy System e-Faktur (KSeF) odrzucił przesłany plik, bo jego struktura nie odpowiada oficjalnemu wzorowi faktury, czyli schematowi FA(3). Faktura nie została wystawiona, nie dostała numeru KSeF i nie powstanie dla niej UPO (urzędowe poświadczenie odbioru). Z punktu widzenia systemu ten dokument po prostu nie istnieje.
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.
Co dokładnie znaczy „weryfikacja negatywna"
W KSeF wysyłka faktury przebiega w krokach: otwierasz sesję, przesyłasz plik, a system nadaje przetwarzaniu status. Weryfikacja negatywna 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.
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ć.
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-2026zamiast2026-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
Krok 1. Zapisz pełną treść komunikatu
Zanim cokolwiek zmienisz, skopiuj cały komunikat zwrócony przez KSeF lub Twój program księgowy — razem z kodem błędu i, jeśli występuje, wskazaniem linii, pozycji w pliku lub nazwy elementu. To najcenniejsza informacja diagnostyczna i najczęściej ginie przy ponownej próbie wysyłki.
Krok 2. Zlokalizuj wskazany element w pliku XML
Jeśli komunikat wskazuje nazwę elementu (np. P_1, czyli datę wystawienia)
albo numer linii, otwórz plik XML w edytorze tekstowym z numeracją linii i przejdź
bezpośrednio w to miejsce. W większości przypadków przyczyna jest widoczna od
razu: pole puste, wartość w złym formacie albo element wstawiony nie tam,
gdzie trzeba.
Gdy komunikat wskazuje element następujący po problematycznym, sprawdź także pole bezpośrednio wcześniejsze. Walidatory XSD często sygnalizują błąd dopiero w momencie, w którym napotkają element „nie na swoim miejscu".
Krok 3. Porównaj sekcję z aktualnym schematem FA(3)
Aktualny wzór dokumentu i dokumentacja są publikowane na oficjalnych stronach Ministerstwa Finansów dotyczących KSeF. Sprawdź trzy rzeczy dla wskazanej sekcji: czy pole jest obowiązkowe, jaki ma typ i jaka jest wymagana kolejność elementów wokół niego.
Krok 4. Zwaliduj plik lokalnie przed ponowną wysyłką
Nie wysyłaj poprawionego pliku „na próbę". Sprawdź go najpierw walidatorem XSD po swojej stronie — to zajmuje sekundy i pozwala wyłapać kolejne błędy w tym samym przebiegu, zamiast odkrywać je pojedynczo przy kolejnych odrzuceniach. Metodę i dostępne narzędzia opisuje osobny przewodnik: Jak zwalidować fakturę KSeF przed wysłaniem.
Krok 5. Sprawdź, czy błąd nie jest systematyczny
Jeśli ta sama niezgodność pojawia się na wielu fakturach, przyczyna leży w programie wystawiającym lub w danych źródłowych (np. nazwa kontrahenta w kartotece przekracza limit znaków). Poprawianie plików pojedynczo tylko odsuwa problem w czasie — warto zgłosić błąd dostawcy oprogramowania albo poprawić dane w kartotece.
Krok 6. Wyślij ponownie i potwierdź numer KSeF
Po ponownej wysyłce sprawdź status przetwarzania i zapisz numer KSeF oraz UPO. Dopiero to potwierdza, że faktura została wystawiona. Do czasu uzyskania numeru dokument formalnie nie funkcjonuje w obrocie.
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
Czy faktura odrzucona jako niezgodna ze schematem XSD została wystawiona?
Nie. Dokument z weryfikacją negatywną nie otrzymuje numeru KSeF ani UPO i nie trafia do systemu. W obrocie prawnym taka faktura nie funkcjonuje, dlatego poprawia się plik i wysyła go ponownie.
Czy taką fakturę trzeba skorygować fakturą korygującą?
Nie. Korekta dotyczy dokumentu już wystawionego. Przy odrzuceniu ze względu na schemat poprawia się plik źródłowy i przesyła go jeszcze raz jako ten sam dokument.
Dlaczego mój plik otwiera się poprawnie, a KSeF go odrzuca?
To dwie różne kontrole. Plik może być poprawnym XML-em pod względem składni i jednocześnie niezgodnym ze schematem FA(3) — na przykład przez złą kolejność elementów lub brak pola obowiązkowego w konkretnym typie faktury.
Czy mogę użyć ponownie tego samego numeru faktury?
Tak. Odrzucony dokument nie został zarejestrowany, więc numer własny pozostaje niewykorzystany. Warto tylko zachować zgodność z własną ewidencją, żeby nie powstała luka w numeracji.
Czy zgodność ze schematem XSD oznacza, że faktura jest bezpieczna?
Nie. Walidacja XSD potwierdza wyłącznie poprawną strukturę pliku. Nie ocenia prawdziwości transakcji, poprawności numeru rachunku ani tego, czy dokument nie jest elementem oszustwa fakturowego.
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
Treść ma charakter informacyjny i edukacyjny. Nie stanowi porady prawnej ani podatkowej.
Przydatne serwisy
Pierwszy serwis prezentuje informacje o statusie samego KSeF, drugi – komunikaty techniczne Ministerstwa Finansów.