Wiadomość została wysłana.
Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.
Formularz został pomyślnie przesłany.
Więcej informacji można znaleźć w skrzynce pocztowej.
24 sierpnia 2026 r.
Czas czytania: 10 minut

Niemieckie wymogi dotyczące e-faktur mogą sprawić, że znany proces fakturowania nagle zacznie wydawać się znacznie większym projektem IT. Jeśli Twój system ERP już działa sprawnie, ostatnią rzeczą, jakiej byś chciał, jest przebudowa go tylko po to, by obsługiwał kolejny format faktur.
Dlatego zacząłbym od tego, co już masz. Niektóre systemy ERP mogą generować ustrukturyzowane e-faktury za pomocą wbudowanych modułów, interfejsów API lub komponentów dostosowanych do konkretnego kraju. Inne nadal generują standardowe pliki PDF i wymagają dodatkowego etapu konwersji. Gdy już wiesz, na jakim etapie jest Twój system, znacznie łatwiej jest wybrać konfigurację ZUGFeRD, która spełnia wymagania bez wprowadzania niepotrzebnych zmian w podstawowym procesie fakturowania.

Jako wizjonerski architekt, Dmitry wypełnia lukę między surową innowacją a komercyjną rentownością. Nadzoruje plan rozwoju technologicznego firmy, zapewniając, że każde rozwiązanie jest zbudowane na stosie, który rozwiązuje bezpośredni ból biznesowy.
ZUGFeRD to hybrydowy format faktury elektronicznej. Faktura w formacie ZUGFeRD łączy w sobie czytelny dla człowieka dokument PDF/A-3 z osadzonymi danymi w formacie XML o ustrukturyzowanej strukturze, które oprogramowanie księgowe może przetwarzać bezpośrednio.
Plik XML zawiera określone dane faktury, takie jak informacje o sprzedawcy i nabywcy, pozycje faktury, kody taxe, sumy, szczegóły płatności oraz numery referencyjne. W przypadku niemieckiej e-faktury wybrana wersja i profil standardu ZUGFeRD mają równie duże znaczenie, co sam plik.
ZUGFeRD obejmuje pięć głównych profili oraz profil referencyjny XRECHNUNG, które różnią się zarówno zakresem danych, jak i przeznaczeniem regulacyjnym. W przypadku typowego niemieckiego wdrożenia B2B opartego na normie EN 16931 zazwyczaj zaczynam od profilu EN 16931, a następnie przechodzę do profilu EXTENDED, gdy proces biznesowy wymaga dodatkowych danych strukturalnych.
| Profil | Co obejmuje | Sytuacja w Niemczech |
|---|---|---|
| MINIMUM | Podstawowe informacje dotyczące kupującego, sprzedającego, sum i podatków | Nie została uznana za kompletną fakturę zgodnie z UStG |
| BASIC WL | Informacje księgowe na poziomie nagłówka bez pozycji faktury | Nie została uznana za kompletną fakturę zgodnie z UStG |
| BASIC | Podzbiór normy EN 16931 dotyczący prostszych faktur | Uznana za kompletną fakturę zgodnie z UStG |
| EN 16931, dawniej COMFORT | Pełny wzór faktury zgodny z normą EN 16931 | Uznawana za kompletną fakturę zgodną z UStG oraz najczęściej wybierane rozwiązanie do standardowego fakturowania elektronicznego zgodnego z przepisami UE |
| ROZSZERZONE | Norma EN 16931 wraz z dodatkowymi danymi dotyczącymi bardziej złożonych procesów biznesowych | Uznana za kompletną fakturę zgodnie z UStG |
| XRECHNUNG | Profil referencyjny oparty na wymaganiach dotyczących faktury XRechnung KoSIT | Ma to znaczenie przede wszystkim w przypadkach, w których obowiązują wymogi dotyczące XRechnung, zwłaszcza w relacjach B2G |
FeRD wyraźnie zaleca stosowanie normy EN 16931 w przypadku faktur elektronicznych zgodnych z przepisami UE. Niemieckie Federalne Ministerstwo Finansów stwierdza również, że standard ZUGFeRD w wersji 2.0.1 lub nowszej spełnia niemieckie wymagania dotyczące faktur elektronicznych, z wyjątkiem poziomów MINIMUM i BASIC-WL.
Wybór profilu powinien więc nastąpić na wczesnym etapie. Wybranie profilu „MINIMUM” tylko dlatego, że zawiera on podstawowe kwoty, nie sprawia na przykład, że dokument ten staje się zgodną z przepisami niemiecką e-fakturą.
Nie traktowałbym tego jako zasady, zgodnie z którą każda niemiecka faktura musi być sporządzona w formacie ZUGFeRD. Zakres stosowania nadal zależy od rodzaju transakcji. Faktury B2C, niektóre transakcje zwolnione z obowiązku stosowania tego formatu, faktury o niskiej wartości oraz inne szczególne przypadki mogą podlegać odmiennym zasadom.
Standardowy plik PDF zawiera informacje przeznaczone głównie do odczytu przez człowieka. Strukturalna faktura elektroniczna zawiera również pola w formacie nadającym się do odczytu maszynowego, zdefiniowane dla oprogramowania księgowego.
Ktoś może zobaczyć:
Faktura o ustalonej strukturze rozdziela poszczególne wartości, dzięki czemu oprogramowanie rozpoznaje, która kwota stanowi podstawę opodatkowania, a która stanowi podatek VAT, sumę brutto oraz kwotę do zapłaty.
To rozróżnienie pozwala systemom ERP i księgowym przetwarzać faktury bez konieczności odtwarzania ich treści na podstawie tekstu zawartego w pliku PDF lub układu strony.
Przed wdrożeniem konwertera należy sprawdzić, czy system ERP oferuje już funkcje e-fakturowania dostosowane do danego kraju, interfejsy API lub moduły dokumentowe.
Zazwyczaj istnieją trzy sposoby:
Na przykład w środowiskach SAP można korzystać z funkcji dostosowanych do konkretnego kraju za pośrednictwem rozwiązania SAP Document and Reporting Compliance. Inne systemy ERP lub systemy niestandardowe mogą wymagać oprogramowania pośredniczącego (middleware) lub oddzielnej usługi konwersji.
Samodzielny konwerter ma zatem największy sens w sytuacji, gdy brakuje odpowiedniej natywnej obsługi lub zmiana podstawowej aplikacji rozliczeniowej wiązałaby się z niepotrzebnym ryzykiem projektowym.
W przypadku procesu opartego na plikach PDF przebieg konwersji może wyglądać następująco:
W miarę możliwości ustrukturyzowane dane z systemu ERP stanowią lepsze źródło informacji niż wartości odtworzone na podstawie pliku PDF. Formaty JSON, XML, CSV, rekordy baz danych lub dane z interfejsu API pozwalają zachować znaczenie pól faktury i ograniczają błędy interpretacyjne.
Tworzenie pliku XML wymaga prawidłowego mapowania semantycznego. Konwerter musi zidentyfikować, co oznacza każda wartość na fakturze, i umieścić ją w odpowiednim polu strukturalnym.
Cena jest prosta. Pozostałe pola wymagają szerszego kontekstu: identyfikatory sprzedawcy i kupującego, rodzaj faktury, kategorie podatkowe, kody jednostek miary, ulgi, opłaty, numery referencyjne, warunki płatności, informacje o dostawie oraz zestawienie podatku VAT – wszystkie te elementy mogą mieć wpływ na zawartość pliku XML.
| Wartość faktury | Termin z normy EN 16931 |
|---|---|
| Numer faktury | BT-1 |
| Data wydania | BT-2 |
| Waluta | BT-5 |
| Nazwa sprzedawcy | BT-27 |
| Nazwa nabywcy | BT-44 |
| Kwota netto z linii | BT-131 |
| Suma bez VAT | BT-109 |
| Łączna kwota VAT | BT-110 |
| Łącznie z VAT | BT-112 |
| Kwota do zapłaty | BT-115 |
Większość prac wdrożeniowych dotyczy właśnie tego modelu danych i związanych z nim procedur walidacji. System musi poprawnie mapować dane źródłowe, generować poprawny kod XML, pakować go do formatu PDF/A-3 oraz zapewnić spójność obu reprezentacji.
Sprawdziłbym fakturę w kilku etapach:
Na przykład:
Konwerter powinien obliczać i porównywać te wartości, a nie kopiować sformatowane ciągi znaków z pliku PDF.
Po osadzeniu pliku XML sprawdziłbym również poprawność gotowego pliku PDF/A-3. Etap pakowania powoduje zmiany w dokumencie, więc sprawdzenie samego pliku źródłowego w formacie PDF nie obejmuje ostatecznego wyniku.
Przed wysłaniem porównałbym numery faktur, daty, strony umowy, walutę, wartości pozycji, informacje podatkowe, sumy, dane dotyczące płatności oraz numery referencyjne w plikach PDF i XML.
Możemy pomóc w ocenie Państwa obecnej konfiguracji systemu ERP, zdefiniowaniu odpowiedniego przepływu danych faktur oraz wdrożeniu e-fakturowania w oparciu o systemy, z których już Państwo korzystają.
Wiadomość została wysłana.
Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.