Walidacja poprawności faktur KSeF przed wysłaniem pliku XML
Walidacja poprawności faktur KSeF przed wysyłką powinna obejmować zgodność pliku XML ze schematem FA(3) oraz kontrolę danych biznesowych. Od 1 lutego 2026 r. KSeF sprawdza zgodność faktury ze strukturą FA(3) i uprawnienia wystawcy, ale przejście kontroli technicznej nie gwarantuje przyjęcia dokumentu. Jeśli system wykryje błąd, faktura może zostać odrzucona i wymaga poprawy przed ponowną wysyłką.
Poprawny wygląd pliku XML nie gwarantuje, że zawiera on spójne dane. Błąd może dotyczyć struktury, formatu pola albo informacji biznesowych, takich jak kwoty czy dane kontrahenta. Dlatego przed wysyłką warto sprawdzić dokument i wiedzieć, jak odczytać komunikat zwrotny, zamiast wielokrotnie ponawiać tę samą próbę.
W tym artykule dowiesz się, co KSeF weryfikuje, jak lokalnie porównać plik XML ze schematem XSD FA(3) i które błędy można wychwycić przed wysyłką. Wyjaśniamy też, co oznacza odrzucenie faktury oraz jak ustalić, czy problem leży w danych, pliku czy samej warstwie wysyłkowej. Dzięki temu łatwiej przygotujesz dokument do poprawnej obsługi w KSeF.
Spis treści
Czym jest walidacja faktur ustrukturyzowanych?
Walidacja sprawdza, czy faktura XML spełnia wymagania techniczne i zawiera spójne dane. Aby zweryfikować plik, porównaj go z właściwym schematem XSD FA(3), a następnie przejrzyj raport walidacji i dane faktury.
Zgodność XML ze schematem FA(3)
Sprawdzenie zgodności XML z FA(3) polega na porównaniu struktury pliku z określonym schematem XSD. Walidator wskazuje, czy wymagane elementy są obecne, prawidłowo umieszczone i zapisane w oczekiwanym formacie. To ważne, bo nawet poprawne wartości nie pomogą, jeśli dokument ma błędną hierarchię pól. W KSeF od 1 lutego 2026 r. obowiązuje schemat FA(3). Użycie właściwej wersji pozwala uniknąć błędów wynikających z niezgodnej struktury.
Kontrola techniczna i biznesowa
Kontrola techniczna ocenia strukturę i format pliku, a biznesowa sprawdza sens oraz spójność danych. XML może przejść test XSD, a jednocześnie zawierać nieprawidłową kwotę VAT albo dane nabywcy wymagające poprawy. KSeF nie sprawdza, czy NIP należy do właściwego kontrahenta, ani nie wykonuje obliczeń matematycznych VAT. Pozytywny wynik techniczny nie zastępuje więc weryfikacji wartości, pozycji i danych stron transakcji.
Merytoryczna weryfikacja faktury
Weryfikacja merytoryczna pozwala ocenić, czy faktura zawiera elementy wymagane przez ustawę o VAT i odpowiada danej transakcji. Sprawdź, czy kwoty netto, VAT i brutto są ze sobą zgodne oraz czy stawka pasuje do pozycji. Pola opcjonalne również mogą wymagać uzupełnienia, gdy przepisy przewidują je w konkretnej sytuacji. Taka kontrola wychwytuje nieścisłości, których sam test XSD nie wykryje.
Przy kontroli płatności sprawdź kwotę brutto, sposób zapłaty oraz rachunek bankowy. Wykaz VAT może być jednym z elementów weryfikacji rachunku. Osobno oceń, czy faktura wymaga mechanizmu podzielonej płatności (MPP). Businesscheck sprawdza ten obowiązek dla faktur o wartości powyżej 15 000 zł brutto. Sama zgodność XML nie rozstrzyga, czy zastosowano prawidłowe oznaczenia płatności ani czy dane rachunku odpowiadają danym kontrahenta.
Wprowadź także podwójną kontrolę wewnętrzną. Najpierw porównaj fakturę z dokumentami źródłowymi, takimi jak zamówienie lub umowa. Następnie zestaw dane źródłowe z wygenerowanym XML-em. Sprawdź NIP, daty, kwoty, stawki VAT i każdą pozycję. Taki podział ułatwia ustalenie, czy błąd powstał podczas wprowadzania danych, mapowania pól czy tworzenia pliku. Nie poprawiaj wyłącznie komunikatu walidatora. Znajdź przyczynę w danych lub konfiguracji i usuń ją.
W praktyce walidacja poprawności faktur KSeF przed wysyłką obejmuje więc dwa poziomy. Najpierw sprawdź, czy plik odpowiada FA(3), potem oceń jego treść biznesową i merytoryczną. Zachowaj raport kontroli, aby łatwiej odtworzyć, które błędy wykryto i jak je poprawiono. Dzięki temu akceptacja techniczna nie będzie mylona z potwierdzeniem prawidłowości całej faktury.
Co sprawdza KSeF przy przyjmowaniu faktury?
KSeF weryfikuje plik pod kątem wymagań technicznych i formalnych, ale przygotowanie faktury wymaga również kontroli danych biznesowych. Sprawdź kompletność pól, format zapisu oraz zgodność informacji o stronach i uprawnieniach.
Kompletność i poprawność pól
Kontrola formalna sprawdza, czy wymagane pola faktury są wypełnione i zapisane we właściwych miejscach. Brak wartości albo błędne przypisanie danych może zatrzymać przyjęcie dokumentu. Przed wysyłką przejrzyj dane sprzedawcy i nabywcy, daty, pozycje oraz podsumowania. Uwzględnij też pola opcjonalne, jeśli przepisy wymagają ich w danej sytuacji.
Formaty dat, kwot i NIP
W FA(3) daty zapisuje się w formacie ISO YYYY-MM-DD, a NIP powinien zawierać dokładnie 10 cyfr. Te formaty pomagają systemowi odczytać dane bez pomyłek, dlatego sprawdź je w pliku, nie tylko na podglądzie faktury. Porównaj także wartości netto, VAT i brutto. Kwota netto powiększona o VAT powinna równać się kwocie brutto.
Weryfikacja danych stron i uprawnień
Porównaj dane sprzedawcy i nabywcy z dokumentami źródłowymi, a także sprawdź, czy osoba wysyłająca ma odpowiednie uprawnienia. Poprawny format NIP nie potwierdza, że numer należy do właściwego kontrahenta. Zestaw NIP z umową, zamówieniem lub kartoteką kontrahenta, a następnie upewnij się, że wysyłkę wykonuje osoba uprawniona w KSeF.
Aby sprawdzić fakturę przed wysłaniem, połącz walidację XML z kontrolą danych biznesowych. Użyj walidatora zgodnego z FA(3), przeanalizuj raport błędów i porównaj wskazane pola z danymi w systemie źródłowym. Integracje z API KSeF można testować w środowisku testowym, a do próbnych wysyłek służy sandbox udostępniony przez Ministerstwo Finansów.
Przygotowanie do obowiązkowego korzystania z KSeF przebiega etapami: obowiązek rozpoczął się 1 lutego 2026 r. dla dużych podatników, których obrót w 2024 r. przekroczył 200 mln zł, oraz dla odbioru faktur przez wszystkich podatników. Dla pozostałych podatników VAT, w tym MŚP i jednoosobowych działalności gospodarczych, rozpoczął się 1 kwietnia 2026 r. Dla podatników zwolnionych z VAT z miesięczną sprzedażą poniżej 10 tys. zł ma rozpocząć się 1 stycznia 2027 r.
Jeśli zastanawiasz się, jakich narzędzi użyć, zacznij od walidatora XSD i kontroli reguł biznesowych. Integrację przetestuj w środowisku testowym KSeF. Taki zestaw pozwala wykryć nieprawidłowe formaty, braki i problemy z mapowaniem przed wysyłką produkcyjną.
Odrzucenie oznacza, że faktura nie otrzymuje numeru KSeF-ID; popraw dane wskazane w komunikacie i prześlij dokument ponownie. Od 1 stycznia 2027 r. kary za błędy w fakturach KSeF mogą wynieść do 100% VAT albo do 18,7% wartości brutto, a minimalna kara ma wynosić 500 zł. Dlatego sprawdzaj zarówno terminy wysyłki, jak i treść faktury, zanim trafi do KSeF.
Techniczna walidacja plików XML według struktury FA(3)
Techniczna walidacja sprawdza, czy plik XML faktury odpowiada wymaganiom struktury FA(3). Wynik pozwala wykryć błędy składni, układu i formatu, zanim dokument trafi do KSeF.
Składnia i struktura XML
Sprawdzenie składni XML polega na ocenie, czy dokument ma prawidłową postać i zachowuje wymaganą hierarchię elementów. Ma to znaczenie, bo brak zamknięcia znacznika lub błędna przestrzeń nazw mogą uniemożliwić odczyt całego pliku. Uruchom walidator XSD dla FA(3), a następnie odczytaj raport. Może wskazać konkretny element, jego lokalizację oraz przyczynę błędu.
Wymagane pola dokumentu
Kontrola wymaganych pól porównuje zawartość faktury z elementami przewidzianymi w FA(3). Dzięki temu wykryjesz brak danych, nieprawidłowy typ wartości albo element umieszczony w złym miejscu. Sprawdź również ograniczenia pól opisowych. W FA(3) klucz i wartość elementu DodatkowyOpis mogą mieć po 256 znaków, a StopkaFaktury może wystąpić maksymalnie 3 razy.
Weryfikuj limity całego dokumentu, nie tylko pojedynczych pól. FA(3) dopuszcza maksymalnie 10 000 elementów DodatkowyOpis na fakturę. Pole StopkaFaktury może zawierać do 3500 znaków. Przekroczenie limitu może spowodować błąd walidacji, nawet jeśli tekst pozostaje czytelny dla sprzedawcy. Program generujący XML powinien tworzyć plik według aktualnej struktury, zamiast polegać na ręcznym składaniu znaczników.
Przydatny raport techniczny rozdziela błędy według ich przyczyny. Najczęściej dotyczą:
brak wymaganego elementu albo nieprawidłową kolejność pól;
wartość niezgodną z typem danych przewidzianym w FA(3);
błędną przestrzeń nazw, która utrudnia rozpoznanie elementu;
przekroczenie limitu znaków lub liczby powtarzanych elementów.
Poprawiaj wskazany problem w danych źródłowych lub narzędziu, które tworzy dokument. Ponowne przesłanie tego samego XML-a nie zmieni jego struktury ani formatu. Jeśli komunikat API KSeF wskazuje konkretny element, porównaj go z odpowiadającym mu polem w systemie źródłowym. Dzięki temu łatwiej ustalisz, czy błąd powstał podczas wprowadzania danych, mapowania pól czy generowania pliku.
Poprawność techniczna oznacza, że XML spełnia reguły schematu, ale nie potwierdza jeszcze biznesowej poprawności faktury. Po walidacji sprawdź więc, czy dokument odpowiada danym transakcji. Podczas wdrażania integracji z systemem Ministerstwa Finansów testuj generowanie i wysyłkę w środowisku testowym. Pozwoli to wykryć problemy z formatem lub mapowaniem przed uruchomieniem procesu produkcyjnego.
To, że błąd ujawnia się podczas wysyłki do KSeF, nie oznacza od razu usterki programu wysyłkowego. Przyczyną może być niepoprawna zawartość dokumentu źródłowego. Odpowiedź API KSeF na błąd walidacji może zawierać szczegóły wskazujące miejsce i powód odrzucenia dokumentu.
Błędy dotyczące struktury XML, mapowania pól lub danych biznesowych zwykle wymagają poprawy w systemie źródłowym albo integratorze. Samo ponawianie wysyłki nie usuwa ich przyczyny. Powiąż wskazane miejsce z danymi, na podstawie których utworzono dokument, aby skorygować właściwe źródło problemu, zamiast traktować ponowienie jako rozwiązanie.
Lokalna walidacja XML przed wysyłką do KSeF
Włącz kontrolę lokalną do codziennego obiegu faktur, zamiast traktować ją jako jednorazowy test. Największą różnicę przynosi stały moment weryfikacji i jasna procedura dla całego zespołu.
Lokalne sprawdzanie pliku XML
Ustal, że kontrolujesz końcowy plik przeznaczony do wysyłki, a nie wcześniejszy podgląd. Dzięki temu sprawdzasz dokument, który faktycznie opuści system firmy. Przygotuj krótką instrukcję określającą, kto uruchamia kontrolę, gdzie zapisuje wynik i jak oznacza fakturę gotową do dalszej obsługi.
Przy regularnej pracy zapisuj wyniki kontroli wraz z wersją pliku i datą jego wygenerowania. Ułatwi to odtworzenie procesu, gdy trzeba będzie ustalić, którą wersję dokumentu sprawdzono. Nie nadpisuj plików roboczych kopią po poprawkach. Rozdziel dokumenty sprzed kontroli i po niej, aby uniknąć wysłania wcześniejszej wersji.
Przygotuj zestaw własnych przypadków testowych. Uwzględnij fakturę z kilkoma pozycjami, korektę oraz dokument z dodatkowymi opisami. Po zmianie ustawień eksportu ponownie sprawdź te same przykłady. Porównanie wyników pokaże, czy aktualizacja wpłynęła na generowanie XML, zanim zmiana obejmie codzienną pracę zespołu.
Lokalna kontrola zgodności z XSD
Przypisz używaną definicję FA(3) do procesu generowania i kontroli dokumentów. W ten sposób osoby wprowadzające zmiany w ustawieniach nie będą korzystać z różnych wersji reguł. Przy aktualizacji konfiguracji odnotuj, czego dotyczyła zmiana i które próbki zostały ponownie sprawdzone. To porządkuje wdrożenie i ułatwia analizę różnic między kolejnymi eksportami.
Traktuj kontrolę jako stały etap procesu, a nie zadanie wykonywane dopiero po wystąpieniu problemu. Możesz ustalić wewnętrzną zasadę, że dokument nie trafia do wysyłki, dopóki osoba odpowiedzialna nie odnotuje zakończenia sprawdzenia. Przy większej liczbie faktur podziel pracę według źródła danych lub rodzaju dokumentu. Ułatwi to wykrycie, czy problem pojawia się w konkretnym formularzu albo ustawieniu eksportu.
Praktyczny przebieg pracy może wyglądać tak:
Wygeneruj końcowy plik XML z zatwierdzonych danych.
Uruchom lokalną kontrolę przed przekazaniem faktury do wysyłki.
Zapisz wynik i powiąż go z właściwą wersją dokumentu.
Po zmianie konfiguracji ponownie sprawdź przygotowane przypadki testowe.
Tak zorganizowany proces zapewnia zespołowi czytelny zapis wykonanych czynności. Gdy pojawi się rozbieżność, łatwiej ustalić, czy dotyczy pojedynczej faktury, konkretnego formularza czy zmiany w sposobie eksportu. Wykorzystaj tę wiedzę do aktualizacji instrukcji i przykładów testowych, aby kolejne kontrole odzwierciedlały rzeczywisty sposób pracy firmy.
Walidacja faktury względem schematu XSD FA(3)
Przy pracy ze schematem liczy się nie tylko końcowy komunikat walidatora, ale też sposób diagnozowania błędu. Traktuj raport jak ślad prowadzący od konkretnego fragmentu XML do ustawienia lub danych, które go utworzyły. Ta metoda pomaga odróżnić problem pojedynczego dokumentu od usterki wspólnej dla całego procesu.
Zacznij od sprawdzenia, czy walidator używa właściwej definicji. Przykładowo próba sprawdzenia faktury według FA(2), zamiast FA(3), może ujawnić niezgodności wynikające z użycia niewłaściwego schematu. Potem otwórz wskazany element w raporcie i porównaj jego nazwę oraz położenie z odpowiadającym mu fragmentem XML. Nie zmieniaj wielu pól naraz. Pojedyncza korekta ułatwia ocenę, czy diagnoza była trafna.
Komunikaty walidatora często wskazują rodzaj rozbieżności, ale nie podają gotowego sposobu jej naprawy. Brak elementu kieruje uwagę na generowanie dokumentu lub warunki jego tworzenia. Nieoczekiwana wartość może wynikać z danych wejściowych albo przekształcenia stosowanego przez system. Jeśli problem dotyczy znacznika lub jego położenia, sprawdź szablon XML. Zapisz treść komunikatu i identyfikator dokumentu, aby móc odtworzyć analizę.
Przy większej liczbie faktur sprawdź, czy błąd powtarza się w różnych dokumentach. Ten sam komunikat w wielu plikach może wskazywać na wspólne ustawienie lub zmianę w generatorze. Pojedynczy przypadek częściej kieruje uwagę na konkretną fakturę lub jej dane. Zestawienie wyników pozwala określić zakres problemu bez przypadkowego poprawiania całej serii dokumentów.
Po zmianie konfiguracji ponownie sprawdź zarówno fakturę, która zgłosiła błąd, jak i inne dokumenty tworzone w tym samym procesie. Upewnij się, że korekta nie zmieniła fragmentów, których komunikat nie dotyczył. Zachowaj raport sprzed poprawki i wynik po niej. Taki zapis tworzy historię diagnozy i pomaga szybciej rozpoznać podobną sytuację w przyszłości.
Gdy walidacja jest częścią szerszego procesu przygotowania faktur, poznaj pełną obsługę faktur KSeF z automatyzacją dekretacji AI. Może to być naturalny kolejny krok, jeśli chcesz uporządkować obsługę dokumentów i ograniczyć ręczne czynności przy ich przetwarzaniu.
Walidacja techniczna nie zastępuje kontroli obliczeń ani danych biznesowych. KSeF nie wykonuje obliczeń matematycznych, dlatego faktura z błędnie wyliczonym VAT względem kwoty netto może przejść walidację techniczną. Brak błędu w raporcie nie potwierdza więc prawidłowości wartości na fakturze. Przed wysyłką sprawdź dokument lokalnie, zarówno względem XSD, jak i reguł biznesowych. Kontrola może objąć sumy, NIP oraz rachunek w wykazie VAT. Rozdzielenie tych sprawdzeń ułatwia ustalenie, czy problem dotyczy struktury XML, czy treści dokumentu. Jeśli plik jest zgodny ze schematem, ale nie przechodzi kontroli biznesowej, szukaj przyczyny w danych i sposobie ich wyliczenia, a nie wyłącznie w układzie znaczników.
Zwróć uwagę także na format dat. W schemacie faktury KSeF należy podawać je w formacie ISO YYYY-MM-DD. Sprawdź datę w gotowym XML-u, ponieważ format widoczny w systemie źródłowym może różnić się od zapisanego w pliku. Ręczne tworzenie XML-a zwiększa ryzyko pomyłek w strukturze i zgodności ze schematem, dlatego warto używać programu, który generuje XML automatycznie. Po wygenerowaniu dokumentu nadal wykonaj lokalną kontrolę: automatyzacja ogranicza błędy zgodności, ale nie zastępuje sprawdzenia danych ani reguł biznesowych. W razie niezgodności popraw dane źródłowe lub ustawienia generatora, a następnie ponownie sprawdź plik przed wysyłką. Dzięki temu walidacja techniczna i kontrola biznesowa uzupełniają się, zamiast być traktowane jako to samo sprawdzenie.
Make It Mine: Odczyt dokumentów (OCR)
Make It Mine wspiera obsługę dokumentów za pomocą Odczytu dokumentów (OCR) i Obiegu dokumentów. OCR, czyli Optical Character Recognition, to technologia rozpoznawania tekstu w zeskanowanych dokumentach i obrazach. Odczyt ułatwia przekazywanie danych do dalszej obsługi, a obieg pomaga uporządkować ich przepływ w firmie.
Przy obsłudze faktur KSeF możesz skorzystać również z pełnej obsługi tych dokumentów z automatyzacją dekretacji AI. Rozwiązanie łączy obsługę faktur KSeF z automatyczną dekretacją. Odczyt dokumentów wspiera pracę z dokumentami, a kontrola XML pozostaje odrębnym etapem.
Skontaktuj się z Make It Mine, aby porozmawiać o obsłudze dokumentów i faktur KSeF w Twojej firmie.
Utrwal kontrolę jako stały etap pracy
Włącz walidację poprawności faktur KSeF przed wysyłką do powtarzalnego procesu, a nie jednorazowego testu. Ustal, kto analizuje komunikaty, poprawia dane i ponownie sprawdza dokument. Zapisuj powracające błędy i ich źródła. Gdy ten sam problem pojawi się ponownie, zweryfikuj sposób wprowadzania danych albo mapowanie pól. Taka praktyka pomaga usprawniać obsługę kolejnych faktur.
Potraktuj obsługę dokumentów jako jeden przepływ: od przygotowania, przez weryfikację, po dalsze przetwarzanie. Wykorzystaj nowoczesne narzędzia do automatyzacji księgowości, OCR, integracji z KSeF oraz elektronicznego obiegu dokumentów. Dobierz rozwiązanie do sposobu, w jaki faktury trafiają do Twojej firmy, i do etapów, na których najczęściej pojawiają się błędy.
Skontaktuj się z Make It Mine, aby porozmawiać o usprawnieniu obsługi dokumentów w Twojej firmie. Zacznij od procesu, który najbardziej obciąża codzienną pracę, i krok po kroku wprowadź w nim więcej porządku.
Najczęstsze pytania o walidację faktur KSeF
Co dzieje się, gdy reguła wykryje błąd?
KSeF zwraca komunikat o błędzie, a odrzucona faktura nie otrzymuje numeru KSeF-ID. Odczytaj szczegóły odpowiedzi i ustal, czy problem dotyczy zawartości pliku, danych biznesowych czy samej wysyłki. Jeśli dokument jest poprawny, a komunikat wskazuje na autoryzację lub połączenie, sprawdź konfigurację zamiast zmieniać fakturę. Po usunięciu przyczyny ponów wysyłkę i zachowaj statusy oraz odpowiedzi systemu.
Czy wystarczy, że mój XML przechodzi walidację XSD?
Nie. Pozytywny wynik XSD potwierdza zgodność struktury, ale nie każdej informacji na fakturze. Plik może spełniać wymagania schematu, choć NIP nabywcy przypisano do niewłaściwego kontrahenta albo kwoty są niespójne. Po teście technicznym porównaj więc dokument z zamówieniem lub umową. Sprawdź również dane stron, wartości oraz reguły biznesowe właściwe dla transakcji.
Dlaczego sprawdzanie faktur ustrukturyzowanych jest ważne?
Kontrola przed wysyłką pomaga wykryć rozbieżności, zanim dokument zostanie odrzucony i będzie wymagał poprawy. Ma to znaczenie również dla obiegu informacji w firmie: dział sprzedaży może przygotować fakturę, a inna osoba zatwierdzić dane przed wysyłką. Ustal jasny podział odpowiedzialności i zachowuj historię korekt. Dzięki temu łatwiej ustalić, na którym etapie powstał problem, i zapobiec jego powtórzeniu.
Jak można przygotować się do walidacji?
Przygotuj aktualną strukturę FA(3), dane źródłowe kontrahentów i dokumenty potwierdzające transakcję. Ustal też, kto może wysyłać faktury oraz kto analizuje błędy. Przed uruchomieniem procesu sprawdź kilka typowych przypadków, na przykład fakturę z wieloma pozycjami i dokument z polem zależnym od rodzaju transakcji. Zapisz wyniki testów, aby później porównać je z komunikatami KSeF.
Jak przebiega proces testowania e-faktur?
Testowanie rozpocznij od wygenerowania pliku XML z danych faktury. Następnie uruchom walidację względem XSD i sprawdź błędy oraz ostrzeżenia w raporcie. Po poprawkach wygeneruj plik ponownie, zamiast edytować sam podgląd. Testując integrację, wyślij próbny dokument w środowisku testowym KSeF i prześledź odpowiedź API. Zapisz wynik, status oraz wersję danych użytych w teście.
Jakie pola i dane są obowiązkowe w fakturze KSeF według aktualnej struktury FA(3)?
Wymagane elementy wynikają ze struktury FA(3), a zakres danych zależy od rodzaju dokumentu i okoliczności transakcji. Schemat określa, gdzie umieścić pola i w jakim formacie je zapisać. Sprawdź dane sprzedawcy i nabywcy, informacje o pozycjach, daty oraz wartości. Pola warunkowe lub opcjonalne uzupełnij, gdy wymagają tego przepisy albo sytuacja opisana na fakturze.
Jakie błędy powodują odrzucenie faktury przez KSeF i jak je poprawić?
Odrzucenie mogą spowodować błędy struktury, brak wymaganych danych, nieprawidłowy format pola lub problem z uprawnieniami osoby wysyłającej. Potraktuj komunikat jako wskazówkę do diagnozy, a nie zachętę do ponawiania tej samej próby. Porównaj wskazany element z dokumentem źródłowym i sprawdź mapowanie w systemie. Jeśli przyczyną jest połączenie albo autoryzacja, popraw ustawienia wysyłki bez zmieniania prawidłowych danych faktury.
Jak testować faktury w środowisku testowym i przedprodukcyjnym KSeF?
W środowisku testowym sprawdzaj zarówno generowanie XML, jak i komunikację z API KSeF. Używaj przykładowych dokumentów, w tym plików z celowo nieprawidłowym polem, aby poznać odpowiedź systemu. Oddziel testy od wysyłek produkcyjnych i czytelnie oznaczaj użyte dane. Dokumenty przesłane do środowiska testowego nie wywołują skutków podatkowych. Po testach zachowaj raporty i komunikaty do analizy.
Komentarze