KSeF odrzuca fakturę? Poznaj 10 błędów walidacji FA(3)

Odrzucenie faktury w KSeF wygląda niepozornie: w odpowiedzi sesji pojawia się trzycyfrowy kod i krótki komunikat po polsku. Problem w tym, że ten komunikat prawie nigdy nie wskazuje pola, które faktycznie zawiodło.

Ma to bezpośrednie skutki podatkowe. Zgodnie z art. 106na ust. 1 ustawy o VAT fakturę ustrukturyzowaną uznaje się za wystawioną w dniu jej przesłania do KSeF. Jeśli pierwsza próba wysyłki zakończyła się odrzuceniem, a poprawiony plik trafił do systemu dopiero w kolejnym miesiącu, zmienia się okres rozliczeniowy.

Ten artykuł porządkuje kody odpowiedzi KSeF i pokazuje, co konkretnie w pliku FA(3) je wywołuje.

Jakie kody zwraca KSeF dla pojedynczej faktury

Status faktury w sesji jest opisany w oficjalnej specyfikacji API KSeF 2.0. Poniżej pełna lista kodów końcowych.

Kod Znaczenie Czy to problem z treścią faktury 200 Sukces, nadano numer KSeF Nie 405 Przetwarzanie anulowane z powodu błędu sesji Nie 410 Nieprawidłowy zakres uprawnień Nie, to uprawnienia 415 Brak możliwości wysłania faktury z załącznikiem Częściowo 430 Błąd weryfikacji pliku faktury Tak 435 Błąd odszyfrowania pliku Nie, to warstwa transportowa 440 Duplikat faktury Tak 450 Błąd weryfikacji semantyki dokumentu faktury Tak 500 Nieznany błąd Zgłoszenie do MF 550 Operacja anulowana przez system Ponów wysyłkę

Kluczowe rozróżnienie: 430 to warstwa pliku i schemy, 450 to reguły biznesowe wewnątrz dokumentu, 440 to konflikt z tym, co już jest w bazie MF.

10 błędów, które generują większość odrzuceń

1. Duplikat numeru faktury (kod 440)

KSeF wykrywa duplikaty globalnie. Kryterium to kombinacja trzech wartości: NIP sprzedawcy (Podmiot1:NIP), rodzaj faktury (RodzajFaktury) i numer faktury (P_2). Unikalność jest utrzymywana przez 10 pełnych lat od końca roku wystawienia.

Najczęstszy scenariusz: integracja nie doczekała odpowiedzi, uznała wysyłkę za nieudaną i ponowiła ją z tym samym numerem. Faktura już wtedy była w systemie. Drugi scenariusz dotyczy firm z oddziałami wystawiającymi w imieniu tego samego NIP bez uzgodnionej numeracji.

2. Kodowanie i struktura pliku XML (kod 430)

Wymagania techniczne są ostre. Plik musi być zapisany w UTF-8 bez znaku BOM (bajty 0xEF 0xBB 0xBF), nie może zawierać instrukcji przetwarzania XML, a jeśli zawiera prolog, ten prolog nie może deklarować innego kodowania niż UTF-8. Zakazane są też niezalecane znaki Unicode z zakresów takich jak [#x7F-#x84] czy [#xFDD0-#xFDEF].

BOM to klasyk przy generowaniu XML w Windows. Znaki kontrolne pojawiają się, gdy nazwa towaru została skopiowana z arkusza albo z systemu magazynowego.

3. NIP niezgodny ze wzorcem lub sumą kontrolną

Typ TNrNIP w schemacie FA(3) wymusza wzorzec [1-9]((\d[1-9])|([1-9]\d))\d{7}. To dziesięć cyfr bez myślników, bez spacji i bez prefiksu PL. Wartość PL5252344078 odpada od razu na poziomie XSD.

Osobno KSeF sprawdza sumę kontrolną NIP dla Podmiot1, Podmiot2, Podmiot3 i PodmiotUpowazniony. Ta kontrola działa tylko na produkcji, co jest częstą pułapką: plik przechodzi na środowisku testowym i wywala się na produkcyjnym.

4. Data wystawienia z przyszłości

Data w polu P_1 nie może być późniejsza niż data przyjęcia dokumentu przez KSeF. Wystarczy, że system generuje P_1 w strefie lokalnej, a serwer porównuje ją z czasem UTC, żeby faktury wystawiane wieczorem 31 stycznia leciały jako datowane na 1 lutego.

5. Błędny nagłówek dokumentu

Blok Naglowek ma sztywne wartości. Atrybut kodSystemowy musi brzmieć dokładnie FA (3), ze spacją przed nawiasem. wersjaSchemy to 1-0E, a WariantFormularza to 3. Dodatkowo DataWytworzeniaFa nie może być wcześniejsza niż 2025-09-01T00:00:00Z.

Ostatni warunek wykłada stare zestawy testowe i fixtury przeniesione z FA(2).

<Naglowek>
  <KodFormularza kodSystemowy="FA (3)" wersjaSchemy="1-0E">FA</KodFormularza>
  <WariantFormularza>3</WariantFormularza>
  <DataWytworzeniaFa>2026-08-29T10:15:00Z</DataWytworzeniaFa>
</Naglowek>

6. Kwoty w formacie, którego schema nie akceptuje

Typ TKwotowy ma wzorzec -?([1-9]\d{0,15}|0)(\.\d{1,2})?. W praktyce oznacza to cztery zakazy: brak przecinka jako separatora dziesiętnego, brak separatora tysięcy, maksymalnie dwa miejsca po przecinku i brak zer wiodących.

Wartość w XML Wynik 1230.50 Poprawna 1230,50 Odrzucona 1 230.50 Odrzucona 1230.500 Odrzucona 01230.50 Odrzucona

Trzy miejsca po przecinku to problem systemów, które liczą ceny jednostkowe z większą precyzją i przenoszą je wprost do pól kwotowych. Cena jednostkowa ma osobny typ dopuszczający więcej miejsc, wartości sprzedaży nie.

7. Przekroczona długość pól tekstowych

Podstawowy typ znakowy w schemacie ma limit 240 znaków i jest jednoliniowy. Nazwa podmiotu mieści 512 znaków, ulica 65, numer budynku 9, numer lokalu 10, kod pocztowy 8, miejscowość 56.

Najczęściej pęka nazwa towaru sklejona z opisem oraz adres, w którym cała linia adresowa trafiła do pola ulicy.

8. Brak uprawnień w kontekście wysyłki (kod 410)

Wysłanie faktury wymaga uprawnień do jej wystawienia w kontekście danego podmiotu. Kod 410 pojawia się, gdy biuro rachunkowe nie ma nadanego uprawnienia dla NIP klienta, gdy wygasło pełnomocnictwo albo gdy przy samofakturowaniu nabywca nie ma uprawnienia do wystawiania w imieniu sprzedawcy.

To nie jest błąd pliku. Poprawianie XML tu nie pomoże.

9. Faktura z załącznikiem w sesji interaktywnej (kod 415)

Wysyłka faktur z załącznikami jest dozwolona wyłącznie w trybie wsadowym i wymaga wcześniejszego zgłoszenia tej opcji w usłudze e-Urząd Skarbowy. Jedyny wyjątek to korekta techniczna faktury offline, którą można przesłać w sesji interaktywnej.

10. Błąd semantyki dokumentu (kod 450)

Kod 450 dotyczy reguł, których sama schema nie wychwyci. Typowe przypadki to faktura korygująca bez kompletnego bloku DaneFaKorygowanej, odwołanie do numeru KSeF faktury, która w systemie nie istnieje, oraz niespójne bloki warunkowe: zaznaczony znacznik procedury bez wypełnienia pól, które ten wybór czyni obowiązkowymi.

Warto pamiętać, że KSeF nie weryfikuje faktury merytorycznie. Nie sprawdzi, czy stawka VAT jest właściwa dla danego towaru. Sprawdza kompletność i spójność struktury.

Co zrobić, gdy faktura wróciła z błędem

Odrzucona faktura nie ma numeru KSeF, więc nie jest fakturą ustrukturyzowaną i nie podlega korekcie. Poprawiasz plik i wysyłasz ponownie pod tym samym numerem.

Osobna ścieżka dotyczy faktur wystawionych w trybie offline. Jeśli taka faktura trafiła już do kontrahenta z kodami QR, a KSeF ją odrzucił z powodu technicznego, MF przewidziało korektę techniczną. Wysyłasz poprawiony plik o tej samej treści, wskazując w polu hashOfCorrectedInvoice skrót SHA-256 pierwotnego, odrzuconego dokumentu. System wiąże oba dokumenty, dzięki czemu stary kod QR przekierowuje klienta do poprawionej faktury.

Korekta techniczna ma dwa ograniczenia: nie służy do zmiany treści faktury i nie rozwiązuje problemów z uprawnieniami.

Checklista przed wysyłką

1. Plik zapisany w UTF-8 bez BOM, bez instrukcji przetwarzania XML.

2. Nagłówek: kodSystemowy="FA (3)", wersjaSchemy="1-0E", WariantFormularza=3, DataWytworzeniaFa nie wcześniejsza niż 2025-09-01.

3. Wszystkie NIP jako 10 cyfr bez myślników i prefiksu, z poprawną sumą kontrolną.

4. P_1 nie jest datą z przyszłości względem momentu wysyłki.

5. Kwoty z kropką dziesiętną, maksymalnie dwa miejsca po przecinku, bez zer wiodących.

6. Numer P_2 nieużyty wcześniej dla tego NIP i tego rodzaju faktury.

7. Rozmiar pliku poniżej 1 000 000 bajtów, a z załącznikami poniżej 3 000 000 bajtów.

8. Uprawnienia do wystawiania w kontekście danego NIP aktywne i niewygasłe.

9. Walidacja pliku względem oficjalnego XSD wykonana lokalnie, przed wysyłką.

Podsumowanie

Większość odrzuceń w KSeF nie wynika z nieznajomości przepisów, tylko z drobnych rozbieżności formatu: BOM, przecinek zamiast kropki, myślnik w NIP, ponowiona wysyłka po timeoucie. Lokalna walidacja względem schematu FA(3) wyłapuje je, zanim dokument w ogóle opuści system.

Biurko waliduje wygenerowany XML względem oficjalnego XSD przed wysyłką wsadową i w trybie offline, tłumaczy kody błędów KSeF na komunikaty wskazujące konkretne pole i zapisuje pełną historię komunikacji z MF przy każdej fakturze. Duplikaty rozpoznaje i wiąże z pierwotnym numerem KSeF zamiast zgłaszać fałszywy błąd.

Załóż darmowe konto na biurko.io i sprawdź, jak wygląda wysyłka do KSeF, gdy błąd widać przed jej wykonaniem, a nie po.

FAQ

Co oznacza kod 440 w KSeF? Duplikat faktury. System znalazł już w bazie dokument o tej samej kombinacji NIP sprzedawcy, rodzaju faktury i numeru. Unikalność jest sprawdzana globalnie i utrzymywana przez 10 pełnych lat od końca roku wystawienia. Sprawdź, czy poprzednia wysyłka nie zakończyła się jednak sukcesem.

Czy można skorygować fakturę odrzuconą przez KSeF? Nie. Odrzucona faktura nie otrzymała numeru KSeF, więc nie jest fakturą ustrukturyzowaną i nie podlega korekcie. Poprawiasz plik i wysyłasz go ponownie. Wyjątkiem są faktury offline, dla których przewidziano korektę techniczną.

Dlaczego faktura przeszła na środowisku testowym, a na produkcji została odrzucona? Najczęściej przez sumę kontrolną NIP. KSeF weryfikuje ją wyłącznie na środowisku produkcyjnym. Na teście fikcyjny NIP zgodny ze wzorcem przechodzi, na produkcji ten sam plik zostaje odrzucony.

Czym różni się kod 430 od 450? Kod 430 to błąd weryfikacji pliku: kodowanie, struktura XML, niezgodność ze schemą. Kod 450 to błąd semantyki, czyli reguł biznesowych wewnątrz poprawnego strukturalnie dokumentu, na przykład korekty bez kompletnych danych faktury korygowanej.

Czy KSeF sprawdza poprawność stawek VAT na fakturze? Nie. System weryfikuje zgodność ze schemą, unikalność, daty, NIP i uprawnienia. Za merytoryczną poprawność stawek, kwot i danych kontrahenta odpowiada wystawca. Przyjęcie faktury przez KSeF nie sanuje błędu merytorycznego.