XRechnung, ZUGFeRD i BIS Billing 3.0 – jakie formaty e-faktur powinno obsługiwać Państwa oprogramowanie

EN 16931 opisuje semantyczny model danych. Określa, jakie dane zawiera faktura i jak są ze sobą powiązane, na przykład numer faktury jako BT-1 czy referencję nabywcy jako BT-10. Sama norma nie jest formatem pliku.

Do technicznego odwzorowania dopuszcza dwie składnie: UBL i UN/CEFACT CII. Obie odwzorowują ten sam model semantyczny, ale różnią się nazwami elementów i budową. Oprogramowanie, które wczytuje tylko UBL, nie może automatycznie przetworzyć faktury CII, nawet jeśli jest ona zgodna z normą.

Dla wdrożenia decyduje to o nakładzie pracy na utrzymanie. Dwa równoległe mapowania oznaczają, że każdą zmianę reguł trzeba wprowadzać w dwóch miejscach. Kto zamiast tego raz odwzoruje dane na model semantyczny normy i z niego generuje obie składnie, przy każdej zmianie modyfikuje tylko jedno miejsce.

Przy odbiorze przychodzący plik jest odwrotnie najpierw odwzorowywany na model semantyczny, a stamtąd przenoszony do Państwa modelu danych.

Ponad normą znajdują się odmiany krajowe i specyficzne dla sieci, w standardzie nazywane Core Invoice Usage Specification, w skrócie CIUS. CIUS zawęża normę. Sprawia, że pola opcjonalne stają się obowiązkowe, wyklucza inne i wprowadza własne reguły Schematron. Odmiany wykraczające poza zakres normy nazywa się rozszerzeniami (extension).

Niezależnie od składni i odmiany e-faktura występuje albo jako czysty plik XML, albo jako PDF/A-3 z osadzonym plikiem XML. Dla drugiego przypadku przyjęło się określenie format hybrydowy.

XRechnung to CIUS normy EN 16931 utrzymywana przez niemiecki Urząd Koordynacji Standardów IT (Koordinierungsstelle für IT-Standards), w skrócie KoSIT. Występuje w obu składniach. Nie ma komponentu wizualnego, plik to czysty XML.

XRechnung jest wymagana dla faktur do niemieckiej administracji federalnej. Faktura jest adresowana za pomocą identyfikatora Leitweg-ID, podawanego w zestawie danych jako referencja nabywcy.

Kanał składania zależy od odbiorcy. W grę wchodzą portale ZRE i OZG-RE lub Peppol Access Point. W B2B identyfikator Leitweg-ID nie odgrywa roli. Tam XRechnung jest tylko jednym z kilku dopuszczalnych profili.

Obecnie obowiązuje wersja 3.0.2. Dla XRechnung 4.0, czyli wdrożenia normy EN 16931 w wersji z 2026 r., istnieje już wersja wstępna. Finalna wersja XRechnung 4.0 zostanie prawdopodobnie opublikowana wiosną 2027 r.

ZUGFeRD umieszcza plik XML w składni CII w pliku PDF/A-3. Człowiek widzi PDF, a oprogramowanie odczytuje XML.

Specyfikacja przewiduje kilka profili o różnym zakresie danych, od MINIMUM do EXTENDED.

MINIMUM i BASIC WL nie zawierają pełnej faktury i nie spełniają normy. Od profilu EN 16931, w starszych wersjach nazywanego COMFORT, część ustrukturyzowana jest zgodna z normą. Państwa oprogramowanie powinno odczytywać profil przy imporcie i traktować pliki z MINIMUM lub BASIC WL odrębnie, na przykład poprzez ręczną kontrolę.

Factur-X jest technicznie w dużej mierze tożsamy z ZUGFeRD.

ZUGFeRD ma sens przede wszystkim tam, gdzie Państwa klienci wystawiają faktury odbiorcom, którzy nadal sprawdzają faktury wizualnie. Przy tym prawnie rozstrzygający jest wyłącznie osadzony XML. Jeśli PDF i XML się różnią, zgodnie z pismem BMF z 15 października 2025 r. pierwszeństwo mają dane z części ustrukturyzowanej.

Proces zatwierdzania, który sprawdza tylko PDF, może więc zatwierdzić fakturę, której rozstrzygająca treść brzmi inaczej.

Przy wysyłce Państwa oprogramowanie powinno generować PDF i XML z tego samego zestawu danych, aby nie rozjechały się ze sobą. Przy odbiorze powinno do kontroli budować własny widok z XML, zamiast wyświetlać dołączony PDF. Niemieckie Federalne Ministerstwo Finansów również zaleca samodzielną wizualizację części XML.

Peppol BIS Billing 3.0 to również CIUS normy EN 16931, oparta na UBL 2.1. OpenPeppol wyspecyfikował go jako własny format do wymiany faktur i not uznaniowych przez sieć.

Oprócz reguł normy wprowadza własne reguły Schematron. Plik może przejść walidację względem EN 16931, a mimo to nie spełnić reguły Peppol. Często dotyczy to list kodów lub pól, które sieć definiuje węziej niż norma.

Specyfikacja jest rozwijana w kolejnych wersjach. Kto waliduje samodzielnie, powinien sprawdzać, czy jego zestawy reguł są aktualne.

W dłuższej perspektywie Peppol zmierza w stronę PINT, międzynarodowo uzgodnionej podstawy dla profili faktur poza Europą. Dla wdrożenia w Niemczech nic to obecnie nie zmienia.

Dla tych faktur Państwa oprogramowanie musi umieć generować XRechnung. Identyfikator Leitweg-ID odbiorcy należy do zestawu danych faktury jako pole obowiązkowe i jest podawany w XRechnung jako referencja nabywcy (BT-10). Jeśli go brakuje lub znajduje się w niewłaściwym polu, portal odbiorczy odrzuca fakturę.

Ustawa wymaga faktury zgodnej z EN 16931 i pozostawia format otwarty. Dopuszczalne są XRechnung, ZUGFeRD od profilu EN 16931, a także Peppol BIS Billing. Prawnie rozstrzygający pozostaje przy tym osadzony XML. Jeśli PDF i XML się różnią, odbiorca może sprawdzać inne dane niż te, które obowiązują prawnie.

Przedsiębiorstwa w Niemczech muszą od 1 stycznia 2025 r. być w stanie odbierać e-faktury zgodne z EN 16931. Dla e-faktury zgodnej z normą nadawca nie potrzebuje więc zgody odbiorcy, nawet jeśli ten preferuje określony format.

Obie strony muszą uzgodnić jedynie kanał przesyłania i formaty spoza normy. W praktyce uzgodniony kanał należy więc do danych podstawowych danego partnera biznesowego.

Oprócz Peppol BIS Billing 3.0 przez sieć Peppol można przesyłać także XRechnung, a od marca 2025 r. również ZUGFeRD jako plik hybrydowy. Typy dokumentów, które odbiorca zarejestrował w usłudze katalogowej, pokazują, jakie formaty przyjmuje. Przed wysyłką Państwa oprogramowanie musi odpytać tę rejestrację i wybrać odpowiedni format. Do pojedynczych kontroli wyszukiwarka Peppol ID pokazuje to bez logowania.

W bieżącej eksploatacji Państwa oprogramowanie powinno wysyłać to zapytanie automatycznie przed wysyłką, albo bezpośrednio przez usługi katalogowe SML i SMP, albo przez API Państwa Peppol Access Pointu. Na tej podstawie ustalany jest format obsługiwany przez obie strony, a następnie w tym formacie generowana jest e-faktura.

Faktury przychodzące docierają w formacie wybranym przez nadawcę. Państwa oprogramowanie powinno więc odczytywać obie składnie, UBL i CII, a tym samym także XRechnung w obu wariantach. Do tego dochodzą ZUGFeRD i Factur-X jako pliki hybrydowe, a gdy tylko Państwa klienci zaczną otrzymywać faktury z zagranicy, także profile stosowane w tych krajach.

Każdy przychodzący plik zawiera identyfikator odmiany, z której korzysta. W UBL znajduje się on w elemencie cbc:CustomizationID, w CII w parametrze kontekstu wytycznych. Państwa oprogramowanie powinno odczytać ten identyfikator w pierwszej kolejności, ponieważ od niego zależy, które reguły walidacji mają zastosowanie i jak plik zostanie przeniesiony do Państwa modelu danych.

Niektóre Peppol Access Pointy wykonują ten krok za Państwa. Sprawdzają przychodzący plik, odczytują dane faktury i przekazują je wraz z plikiem oryginalnym jako jednolity zestaw danych.

Państwa oprogramowanie powinno w pełni obsłużyć odbiór przed wysyłką, czyli obie składnie i formaty hybrydowe, ponieważ Państwa klienci muszą już dziś być w stanie odbierać e-faktury.

Wysyłka staje się dla Państwa klientów obowiązkowa w dwóch etapach: od 1 stycznia 2027 r. przy łącznym obrocie w poprzednim roku powyżej 800 000 euro, a od 1 stycznia 2028 r. dla wszystkich pozostałych krajowych transakcji B2B w Niemczech.

Kto zaczyna od składni CII, może za jej pomocą generować XRechnung w wariancie CII i ZUGFeRD. UBL staje się potrzebny, gdy tylko odbiorcy w sieci Peppol oczekują Peppol BIS Billing 3.0, ponieważ ten format wymaga UBL.

Wszystkie obowiązkowe dane wymagane przepisami o VAT muszą znajdować się w ustrukturyzowanej części e-faktury w postaci nadającej się do automatycznego przetwarzania. Dotyczy to także opisu świadczenia. Odesłanie do załącznika, dokumentu dostawy lub linku nie zastępuje pola obowiązkowego. Podstawą są FAQ niemieckiego Federalnego Ministerstwa Finansów dotyczące e-faktury oraz pismo BMF z 15 października 2025 r..

Przyczyna leży w budowie e-faktury. W formatach hybrydowych, takich jak ZUGFeRD, wiodące są dane w XML, a PDF jest tylko widokiem. Informacja widoczna wyłącznie w PDF nie jest więc brana pod uwagę.

Jeśli w części ustrukturyzowanej brakuje obowiązkowej informacji, faktura jest uznawana za nieprawidłową, a prawo odbiorcy do odliczenia VAT naliczonego może być zagrożone. Państwa klienci zauważą to najpóźniej wtedy, gdy partnerzy biznesowi zaczną z tego powodu odrzucać faktury.

Wiele szablonów faktur przenosi obowiązkowe dane jako bloki tekstu, które pojawiają się tylko w PDF. Często dotyczy to opisu świadczenia, na przykład „zgodnie z ofertą 2026-114”, okresu świadczenia w stopce faktury oraz informacji o odwrotnym obciążeniu (przeniesieniu obowiązku podatkowego na nabywcę).

W modelu danych każda z tych informacji powinna mieć własne pole, z którego wypełniany jest XML. Okres świadczenia należy do pól okresu rozliczeniowego (BG-14), a informacja o odwrotnym obciążeniu do kategorii podatku z podstawą zwolnienia (BT-120 i BT-121).

Walidacja techniczna sprawdza, czy pola obowiązkowe normy są obecne i formalnie poprawnie wypełnione. Nie rozpoznaje, czy opis świadczenia jest wystarczający z punktu widzenia VAT. Faktura może więc przejść kontrolę, a mimo to zawierać obowiązkową informację w niewystarczającej postaci.

Dokumenty dostawy, zestawienia godzin i inne dokumenty towarzyszące fakturze można osadzić w e-fakturze jako załącznik, w EN 16931 za pomocą grupy dokumentów dodatkowych (BG-24). Zastępuje to osobną wysyłkę i utrzymuje fakturę oraz dowód w jednym pliku.

XRechnung jest sprawdzana względem dwóch zestawów reguł: reguł EN 16931 i dodatkowych reguł KoSIT. Dla Peppol BIS Billing 3.0 obowiązuje to samo z regułami OpenPeppol. Sama kontrola względem normy mówi więc w ograniczonym stopniu, czy odbiorca przyjmie plik. Państwa oprogramowanie powinno walidować według zestawu reguł odmiany, której oczekuje odbiorca.

KoSIT i OpenPeppol regularnie publikują nowe wersje swoich zestawów reguł z dostosowanymi listami kodów i regułami Schematron. Jeśli Państwa oprogramowanie nie aktualizuje zestawów reguł, mogą zostać odrzucone faktury, które dotychczas były przyjmowane. Odrzucenie pochodzi wtedy od odbiorcy, ale przyczyna leży we własnym, nieaktualnym zestawie reguł.

Do testów w trakcie rozwoju pojedyncze pliki można sprawdzić bezpłatnym walidatorem e-faktur względem EN 16931 i reguł Peppol. Do automatycznej kontroli w eksploatacji InvoiceRails oferuje walidację także przez API, względem EN 16931 i profili takich jak XRechnung, ZUGFeRD i Peppol BIS Billing. Raport z walidacji wykazuje osobno błędy, ostrzeżenia i wskazówki.

Mapowanie buduje się raz, ale stojące za nim reguły walidacji mogą zmieniać się kilka razy w roku. Następna większa zmiana jest już w drodze: XRechnung 4.0 i norma EN 16931 w wersji z 2026 r.

Wersja z 2026 r. opiera się na UBL 2.5. W zgodnych implementacjach z UBL 2.5 można korzystać dopiero wtedy, gdy CEN opublikuje zaktualizowane powiązanie składni (syntax binding). Do tego czasu obowiązują istniejące powiązania oparte na UBL 2.1. Dostawcy mogą więc przygotować przejście, ale jeszcze go nie wdrożyć.

Kto samodzielnie buduje połączenie, przejmuje to utrzymanie na stałe. Obejmuje ono aktualizowanie mapowań dla obu składni, list kodów i reguł Schematron oraz śledzenie harmonogramów wersji KoSIT, FeRD, OpenPeppol i CEN. Jest to wykonalne, ale pochłania czas deweloperski, którego brakuje we własnym produkcie.

Alternatywnie utrzymanie formatów można zlecić Peppol Access Pointowi. InvoiceRails, certyfikowany przez OpenPeppol Access Point fino data services, obsługuje przez API ponad 60 formatów, w tym XRechnung, ZUGFeRD i Factur-X, i na bieżąco utrzymuje reguły walidacji oraz aktualizacje formatów.

Dostawcy jednorazowo integrują wysyłkę i odbiór i udostępniają tę funkcję dowolnej liczbie swoich klientów, na życzenie pod własną marką. Odwzorowanie własnych danych faktur na interfejs pozostaje po stronie dostawcy, podobnie jak pola obowiązkowe we własnym modelu danych.

Jak dostawcy oprogramowania co do zasady wprowadzają e-fakturę do własnego produktu, przeczytają Państwo w artykule o e-fakturze dla dostawców oprogramowania.