Walidacja e-faktury i prawidłowe odczytywanie raportu z walidacji

Walidator sprawdza e-fakturę kolejno pod kątem trzech zestawów reguł i odnotowuje każdą rozbieżność w raporcie z walidacji.

Schemat XML składni

E-faktura zgodna z EN 16931 występuje w jednej z dwóch składni: UBL lub UN/CEFACT CII. Wszystkie popularne specyfikacje użycia opierają się na tych dwóch składniach, na przykład XRechnung, ZUGFeRD i Peppol BIS Billing 3.0.

Schemat XML składni określa, które elementy są dozwolone, w jakiej kolejności występują i jaki mają typ danych.

Błędy schematu nie mają identyfikatora reguły. Parser XML zgłasza je z własnymi kodami, na przykład cvc-complex-type.2.4.a dla elementu w miejscu, w którym schemat go nie oczekuje.

W przypadku ZUGFeRD plik CII jest osadzony w pliku PDF. Walidator sprawdza część XML. W razie rozbieżności z częścią graficzną to ona jest rozstrzygająca, zgodnie z pismem BMF z 15 października 2025 r. w sprawie wprowadzenia obowiązkowej e-faktury.

Reguły biznesowe EN 16931

Reguły biznesowe sprawdzają dane e-faktury pod kątem błędów logicznych, na przykład czy pola obowiązkowe są wypełnione i czy sumy do siebie pasują. Europejski Komitet Normalizacyjny (CEN) publikuje te reguły jako pliki Schematron na GitHubie, osobno dla UBL i dla CII.

Po prefiksie identyfikatora reguły rozpoznają Państwo rodzaj kontroli. Reguły z BR i liczbą sprawdzają pola obowiązkowe i ich liczbę, BR-CO sprawdza obliczenia i zależności między polami, BR-CL sprawdza listy kodów, a BR-DEC miejsca po przecinku w kwotach. Reguły takie jak BR-S, BR-AE czy BR-IC sprawdzają dane dotyczące poszczególnych kategorii VAT.

Pliki CEN zawierają ponadto reguły specyficzne dla składni. Reguły z prefiksem UBL-CR zgłaszają na przykład ostrzeżenie, gdy plik UBL zawiera elementy nienależące do modelu danych EN 16931.

Reguły XRechnung i Peppol BIS Billing 3.0

XRechnung i Peppol BIS Billing 3.0 to specyfikacje użycia normy EN 16931, w języku fachowym nazywane CIUS (Core Invoice Usage Specification). Narzucają dodatkowe pola i uzupełniają EN 16931 o własne reguły. CIUS nie może wprowadzać nowych pól danych.

Reguły XRechnung zaczynają się od BR-DE i pochodzą od niemieckiego Urzędu Koordynacji Standardów IT (Koordinierungsstelle für IT-Standards, KoSIT). Peppol BIS Billing 3.0 dodaje reguły z prefiksami PEPPOL-EN16931 i PEPPOL-COMMON oraz reguły specyficzne dla poszczególnych krajów.

Identyfikator specyfikacji w BT-24 określa, która specyfikacja użycia obowiązuje dla pliku. Walidator KoSIT na podstawie tego identyfikatora wybiera odpowiedni scenariusz kontroli. Błędny lub nieaktualny identyfikator może więc sprawić, że plik zostanie sprawdzony pod kątem innych reguł lub odrzucony.

Czego walidacja nie sprawdza

Walidator nie rozpoznaje, czy stawka podatku pasuje do świadczenia ani czy opis świadczenia jest wystarczający.

Według niemieckiego Federalnego Ministerstwa Finansów wszystkie obowiązkowe dane wymagane przepisami o VAT muszą znajdować się w ustrukturyzowanej części e-faktury. Samo odesłanie do załącznika z opisem świadczenia nie wystarcza. Nazwa pozycji typu „patrz załącznik” w BT-153 mimo to przechodzi walidację, ponieważ żadna reguła nie ocenia treści tego pola.

KoSIT i Forum Faktury Elektronicznej Niemcy (Forum elektronische Rechnung Deutschland, FeRD) opublikowały tabelę, która przyporządkowuje obowiązkowym danym wymaganym przez niemiecką ustawę o VAT odpowiednie pola BT. Na podstawie tej tabeli mogą Państwo ustalić, które obowiązkowe dane Państwa oprogramowanie powinno zabezpieczyć własnymi kontrolami wiarygodności.

Każdy wpis w raporcie z walidacji zawiera z reguły cztery informacje.

Identyfikator reguły

Identyfikator reguły, taki jak BR-CO-15 lub BR-DE-2, odsyła do reguły w dokumentacji danego zestawu reguł.

Poziom ważności

Walidator oznacza każdy komunikat jako błąd lub ostrzeżenie. W regułach Peppol błędy nazywane są fatal. Samo ostrzeżenie z reguły nie prowadzi do odrzucenia. Niektóre walidatory wyświetlają ponadto wskazówki, czyli zalecenia dotyczące poprawnego wdrożenia bez wpływu na wynik. Walidator KoSIT na końcu raportu zaleca przyjęcie lub odrzucenie dokumentu.

Peppol często wprowadza nowe reguły najpierw jako ostrzeżenie i w późniejszym wydaniu podnosi je do rangi błędu. W wersji 3.0.21 na przykład reguły PEPPOL-COMMON-R052 i PEPPOL-COMMON-R053 zmieniły się z ostrzeżeń w błędy, jak podają informacje o wydaniu Peppol BIS Billing 3.0.

Lokalizacja

Lokalizacja to wyrażenie XPath wskazujące element XML, którego dotyczy komunikat. Ten sam numer BT znajduje się w UBL i CII w różnych miejscach. Kwota faktury z VAT (BT-112) znajduje się w UBL w elemencie cbc:TaxInclusiveAmount pod cac:LegalMonetaryTotal, a w CII w elemencie ram:GrandTotalAmount pod ram:SpecifiedTradeSettlementHeaderMonetarySummation.

W przypadku reguł porównujących kilka pól lokalizacja często wskazuje element nadrzędny. Wartość, która wywołuje komunikat, znajdą Państwo wtedy na podstawie treści komunikatu.

Treść komunikatu

Treść komunikatu opisuje regułę i zwykle podaje numery BT, których dotyczy. Komunikat do BR-CO-15 mówi na przykład, że kwota faktury z VAT (BT-112) musi być równa sumie kwoty faktury bez VAT (BT-109) i kwoty VAT (BT-110).

Od wersji 3.0.21 treści reguł Peppol zaczynają się od identyfikatora reguły.

Długi raport z walidacji często wynika z kilku nielicznych przyczyn.

Grupa reguł często już wskazuje, w którym miejscu Państwa oprogramowania należy wprowadzić korektę.

Błędy schematu bez identyfikatora reguły

Przyczyną jest kolejność elementów, przestrzeń nazw lub błędny typ danych w eksporcie. Korektę wprowadza się w funkcji eksportu, jednorazowo dla wszystkich klientów.

BR z liczbą

Przyczyną jest pole obowiązkowe, które nie zostało zmapowane lub jest puste w danych podstawowych. Korektę wprowadza się w mapowaniu lub przy polu obowiązkowym w interfejsie.

BR-CO i BR-DEC

Przyczyną są sumy, zaokrąglenia, rabaty i dopłaty na poziomie dokumentu. Korektę wprowadza się w logice obliczeń przy tworzeniu faktury.

BR-CL

Przyczyną jest nieaktualny lub własny kod, na przykład dla jednostek miary lub krajów. Korektę wprowadza się w listach kodów w Państwa oprogramowaniu.

BR-S, BR-AE, BR-IC i inne kategorie

Kategoria VAT, stawka podatku i podstawa zwolnienia do siebie nie pasują. Korektę wprowadza się w logice podatkowej i w danych podstawowych artykułów.

UBL-CR

Eksport zawiera elementy UBL spoza modelu danych EN 16931. Korektę wprowadza się w funkcji eksportu.

BR-DE

Brakuje danych kontaktowych sprzedawcy, danych płatności lub referencji nabywcy. Korektę wprowadza się zwykle w danych podstawowych Państwa klientów.

PEPPOL-EN16931 i PEPPOL-COMMON

Brakuje adresu elektronicznego lub identyfikator ma błędny format. Korektę wprowadza się w danych podstawowych i w zarządzaniu identyfikatorami Peppol ID.

Brak referencji nabywcy w XRechnung (BR-DE-15)

Reguła BR-DE-15 zgłasza brak referencji nabywcy w BT-10. W fakturach do administracji publicznej znajduje się tam identyfikator Leitweg-ID urzędu. Dla faktur B2B według niemieckiego Federalnego Ministerstwa Finansów na potrzeby VAT wystarczy symbol zastępczy, taki jak „-”, jeśli odbiorca faktury nie podaje własnego oznaczenia. Państwa oprogramowanie może więc w fakturach B2B wstępnie wypełniać to pole symbolem zastępczym, który Państwa klienci mogą nadpisać.

Różnice zaokrągleń w VAT (BR-S-09)

Reguła BR-S-09 porównuje kwotę VAT kategorii stawki podstawowej z iloczynem podstawy opodatkowania i stawki podatku. Jeśli Państwa oprogramowanie zaokrągla VAT dla każdej pozycji i sumuje kwoty, suma może od tego odbiegać. Przy wielu pozycjach odchylenie może przekroczyć tolerancję dopuszczaną przez regułę. Dlatego kwotę podatku należy obliczać dla każdej kategorii z podstawy opodatkowania i stawki podatku, tak jak przewiduje reguła.

Walidacja powinna znaleźć się w pięciu miejscach Państwa oprogramowania i procesu deweloperskiego.

Przed wysyłką

Państwa oprogramowanie powinno walidować każdą e-fakturę bezpośrednio po jej utworzeniu i wstrzymywać wysyłkę w razie błędów. Państwa klienci niewiele zrozumieją z identyfikatora reguły czy wyrażenia XPath. Dlatego reguły, które klienci mogą sami poprawić, warto przełożyć na wskazówkę przy danym polu formularza. Wskazówka do BR-DE-6, czyli numeru telefonu osoby kontaktowej sprzedawcy w BT-42, może brzmieć na przykład „Prosimy podać numer telefonu do kontaktu”.

Błędów wynikających z Państwa mapowania lub logiki obliczeń klient nie może usunąć. Takie błędy powinny trafiać jako wewnętrzna informacja do Państwa zespołu.

Przy odbiorze

Państwa oprogramowanie powinno walidować także przychodzące e-faktury i pokazywać wynik przy dokumencie. Plik oryginalny należy przechowywać w niezmienionej postaci, a raport z walidacji jako osobny dokument obok niego. Niemieckie Federalne Ministerstwo Finansów wymaga, aby przynajmniej ustrukturyzowana część e-faktury była przechowywana w nienaruszonej, oryginalnej postaci.

Jeśli faktura przychodząca zawiera błędy, Państwa klient może zażądać od wystawcy faktury korygującej. Państwa oprogramowanie może wspierać ten krok, na przykład przygotowanym zapytaniem do wystawcy, które zawiera raport z walidacji.

W testach automatycznych

Warto utworzyć zbiór faktur testowych, który obejmuje Państwa rodzaje faktur wraz z ich kodami, na przykład 380 dla faktury i 384 dla faktury korygującej. Należy też uwzględnić każdą kategorię VAT, z której korzystają Państwa klienci. Do tego dochodzą rabaty i dopłaty oraz każda składnia generowana przez Państwa oprogramowanie. Warto też dodać celowo błędne pliki i sprawdzić, czy walidator je odrzuca.

Walidator KoSIT to program open source uruchamiany z wiersza poleceń, który można włączyć do potoku budowania (build pipeline). KoSIT udostępnia ponadto zestaw testów z przykładowymi fakturami, który dobrze nadaje się jako punkt wyjścia dla własnego zbioru.

Po każdej aktualizacji zestawów reguł

Zestawy reguł zmieniają się także bez nowego numeru wersji. KoSIT regularnie publikuje dla XRechnung 3.0.2 pakiety (bundles) z poprawkami błędów, ostatnio w wersji z 31 sierpnia 2026 r.. XRechnung 3.0 obowiązuje co najmniej do 31 lipca 2027 r.

Wersja wstępna specyfikacji XRechnung 4.0 ukazała się 15 września 2026 r. Wyraźnie nie jest przeznaczona do zastosowań produkcyjnych, lecz daje Państwu wczesny przegląd nowych i zmienionych funkcjonalności. Wersja finalna ukaże się prawdopodobnie wiosną 2027 r. wraz z komponentami technicznymi.

OpenPeppol regularnie publikuje nowe wydania Peppol BIS Billing 3.0, w ostatnich latach każdorazowo w maju i listopadzie. Wersja 3.0.21 została opublikowana 20 maja 2026 r. i obowiązuje od 17 sierpnia 2026 r.

Dla każdego wydania warto zaplanować stały termin, w którym zbiór testowy zostanie zwalidowany według nowych reguł. W każdym raporcie z walidacji należy odnotować, z jaką wersją walidatora i zestawu reguł powstał. Dzięki temu można odtworzyć wynik także wtedy, gdy reguły w międzyczasie się zmieniły. Na potrzeby przejścia na XRechnung 4.0 Państwa środowisko testowe powinno móc sprawdzać obie wersje równolegle.

Analiza raportów z walidacji dla wszystkich klientów

Jeśli Państwa oprogramowanie generuje e-faktury dla wielu klientów, opłaca się analizować raporty z walidacji łącznie dla wszystkich klientów. Jeśli ten sam identyfikator reguły nagle pojawia się u wielu klientów, przyczyna leży prawdopodobnie w mapowaniu lub w nowym zestawie reguł. Jeśli występuje tylko u jednego klienta, przyczyna leży raczej w jego danych podstawowych.

Kroki opisane w tym artykule mogą Państwo w całości wdrożyć samodzielnie. Jednorazowy nakład pracy jest niewielki, ale stały już nie: zestawy reguł, listy kodów i konfiguracje kontroli zmieniają się kilka razy w roku, a każda zmiana musi trafić do Państwa testów, wysyłki i planowania wydań.

Walidację, wysyłkę i utrzymanie zestawów reguł można więc także przekazać certyfikowanemu Peppol Access Pointowi, takiemu jak InvoiceRails.

Walidator e-faktur do pojedynczych kontroli

Bezpłatny walidator e-faktur InvoiceRails sprawdza pliki XML w UBL i CII oraz hybrydowe faktury PDF, bez logowania. Automatycznie rozpoznaje składnię, wersję i profil, w tym XRechnung, Peppol BIS Billing 3.0, ZUGFeRD, Factur-X i inne profile EN 16931. Następnie waliduje plik względem schematu XML oraz reguł Schematron i reguł biznesowych rozpoznanego profilu. Raport z walidacji można pobrać jako PDF lub udostępnić linkiem, na przykład gdy Państwa dział wsparcia omawia z klientem odrzuconą fakturę.

API InvoiceRails w Państwa oprogramowaniu

InvoiceRails to certyfikowany przez OpenPeppol Peppol Access Point fino data services. Państwa oprogramowanie łączy się z InvoiceRails przez REST API i za jego pośrednictwem wysyła i odbiera e-faktury dla dowolnej liczby klientów, na życzenie jako white label.

API oferuje walidację jako osobny endpoint, również z automatycznym rozpoznawaniem profilu. Państwa oprogramowanie może dzięki temu sprawdzać e-faktury bezpośrednio po ich utworzeniu. Każdy komunikat w odpowiedzi zawiera identyfikator reguły, poziom ważności, treść komunikatu i lokalizację jako XPath. Państwa oprogramowanie może zapisać identyfikator walidacji przy fakturze i ponownie pobierać wynik przez co najmniej 90 dni.

InvoiceRails waliduje każdy plik, który Państwa oprogramowanie wysyła przez Peppol, także bez tego wywołania. Państwa oprogramowanie musi wcześniej sprawdzić, jakie formaty obsługuje odbiorca.

InvoiceRails sprawdza także przychodzące e-faktury i przekazuje Państwa oprogramowaniu plik oryginalny wraz z odczytanymi danymi faktury. Webhook informuje Państwa oprogramowanie o każdej zmianie statusu doręczenia.

Po stronie Państwa oprogramowania pozostaje przyporządkowanie pól z Państwa modelu danych, zrozumiałe wskazówki w Państwa interfejsie oraz kontrole wiarygodności dla obowiązkowych danych, których nie obejmuje żadna reguła.