Obowiązek E-Rechnung w Niemczech: wystawianie faktur ustrukturyzowanych z własnych systemów od 1 stycznia 2027

Od 1 stycznia 2027 niemiecka firma, której obrót w 2026 przekroczył 800 000 euro, nie może już wysłać innej niemieckiej firmie faktury papierowej ani w PDF. Faktura musi być ustrukturyzowaną e-fakturą: plikiem danych zbudowanym według europejskiej normy EN 16931. Od 1 stycznia 2028 próg znika, a zasada obejmuje każdą firmę, z kilkoma wąskimi wyjątkami.

Dla małej firmy oznacza to aktualizację oprogramowania. Dla firmy, której faktury powstają we własnym systemie rozliczeniowym, w pakiecie branżowym albo w ERP dostosowywanym przez piętnaście lat, to projekt informatyczny, a do terminu zostało około trzynastu tygodni. Ten artykuł jest dla tej drugiej grupy.

Co mówi ustawa

Definicja znajduje się w § 14 UStG: faktura „die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”. Format musi być zgodny z normą europejską w rozumieniu dyrektywy 2014/55/UE (w praktyce z EN 16931) albo uzgodniony między stronami, pod warunkiem że wymagane dane da się poprawnie i w całości wyodrębnić do postaci zgodnej z tą normą. PDF się nie kwalifikuje, nawet najstaranniej przygotowany.

Obowiązek obejmuje dostawy na rzecz innej firmy, gdy obie strony mają siedzibę w Niemczech. Okres przejściowy reguluje § 27 Abs. 38 UStG:

• Dostawy dokonane w 2025 i 2026 można jeszcze fakturować na papierze albo, za zgodą odbiorcy, w innym formacie elektronicznym, o ile faktura zostanie wysłana do 31 grudnia 2026.
• Dostawy dokonane w 2027 korzystają z tego samego ułatwienia do 31 grudnia 2027, ale tylko wtedy, gdy łączny obrót wystawcy w poprzednim roku kalendarzowym nie przekroczył 800 000 euro.
• EDI niespełniające normy można stosować dalej dla dostaw dokonanych w 2027, za zgodą odbiorcy, niezależnie od wielkości firmy.

Trzy szczegóły mają większe znaczenie, niż się wydaje.

Próg liczy się według obrotu z poprzedniego roku. Twoja sytuacja w 2027 zależy od wyniku za 2026, którego nikt nie pozna dokładnie przed zamknięciem ksiąg. Jeśli jesteś choćby w pobliżu 800 000 euro, buduj tak, jakbyś był powyżej.

Ułatwienie kończy się na dacie wysłania. Czytana dosłownie, pierwsza reguła przejściowa przestaje obejmować papier i PDF 31 grudnia 2026, nawet dla prac wykonanych w 2026. Jeśli jesteś powyżej progu i fakturujesz z dołu, faktura wysłana w pierwszym tygodniu stycznia za pracę z grudnia już musi być ustrukturyzowana. Potwierdź to z doradcą podatkowym, ale nie planuj startu na połowę stycznia.

Niektóre faktury pozostają poza zakresem: faktury dla konsumentów, faktury transgraniczne, faktury na małe kwoty do 250 euro brutto, bilety pełniące funkcję faktury, faktury od Kleinunternehmer (małych przedsiębiorców korzystających ze zwolnienia) oraz dostawy zwolnione na podstawie § 4 Nr. 8 do 29 UStG.

Nie znamy żadnego projektu ustawy, który przesuwałby te daty. Planuj tak, jakby się utrzymały.

Odbiór obowiązuje od 2025. Nowością jest wystawianie.

Od 1 stycznia 2025 każda niemiecka firma musi umieć odbierać e-faktury. FAQ Federalnego Ministerstwa Finansów o e-fakturach mówi bez ogródek, czego to wymaga: „Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.” Wystarczy skrzynka pocztowa.

Warto zwrócić uwagę na jedno zdanie w samym § 14: tam, gdzie obowiązuje e-faktura, zgoda odbiorcy nie jest wymagana. Niemiecki klient biznesowy nie może odmówić przyjęcia Twojej faktury ustrukturyzowanej.

Wystawianie to inny problem. Przy odbiorze narzędzie czyta cudzy plik. Przy wystawianiu autorem jest Twój system: jeśli dane są błędne u źródła, nikt dalej w łańcuchu ich nie naprawi, a faktura, która nie przejdzie walidacji u klienta, czeka niezapłacona.

Kto dostanie to w aktualizacji

Wprost: jeśli jesteś małą firmą fakturującą z DATEV, lexoffice, sevDesk albo podobnego pakietu, format dostarcza producent. Sprawdź dane podstawowe (numer VAT UE, adresy klientów, dane bankowe), włącz funkcję i wyślij fakturę testową. Nie potrzebujesz projektu ani firmy programistycznej.

Podobnie jest z popularnym ERP, który pozostał blisko standardu: wynik dostarcza producent albo partner wdrożeniowy, a praca sprowadza się do konfiguracji i testów.

Reszta artykułu dotyczy firm, których faktury powstają w kodzie, który same posiadają, albo w kodzie, którego nikt już nie utrzymuje:

• silniki rozliczeniowe platform subskrypcyjnych, marketplace'ów i przedsiębiorstw użyteczności publicznej, które wystawiają faktury programowo i w dużych ilościach;
• oprogramowanie branżowe dla hurtu, budownictwa, logistyki czy serwisu terenowego, którego producent jest mały, powolny albo już nie istnieje;
• systemy ERP, w których wydruk faktury lata temu przepisano na własne programy drukujące, szablony raportów albo korespondencję seryjną na koniec miesiąca.

Formaty: EN 16931, XRechnung i ZUGFeRD

EN 16931 to norma europejska. Definiuje semantyczny model faktury (pola, ich znaczenie, które są obowiązkowe i reguły biznesowe między nimi) i wiąże go z dwiema składniami XML: UBL 2.1 i UN/CEFACT CII.

XRechnung to niemiecka specyfikacja oparta na EN 16931, utrzymywana przez KoSIT: czysty XML w jednej z dwóch składni, wymagany przez organy publiczne i równie ważny między firmami. Według strony KoSIT o XRechnung wersja 3.0 obowiązuje od 1 lutego 2024 i pozostanie w mocy co najmniej do 31 lipca 2027. Wstępną wersję 4.0 opublikowano we wrześniu 2026, a wydanie ostateczne spodziewane jest wiosną 2027. Start nastąpi na wersji 3.0, a aktualizacja w ciągu pierwszego roku.

ZUGFeRD to format hybrydowy: plik PDF/A-3 z osadzonym XML w składni CII. Ludzie czytają PDF, maszyny czytają XML. We Francji ten sam format nazywa się Factur-X, a technicznie oba są identyczne. FeRD opublikował wersję 2.5.2 4 sierpnia 2026. ZUGFeRD występuje w profilach (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED), a FAQ ministerstwa akceptuje ZUGFeRD od wersji 2.0.1 „mit Ausnahme der Profile MINIMUM und BASIC-WL”.

W fakturze hybrydowej liczy się XML. FAQ nazywa część ustrukturyzowaną „führender Teil”, czyli częścią wiodącą. Jeśli PDF i XML się różnią, błędny jest PDF.

Dla większości niemieckich wystawców B2B rozsądnym domyślnym wyborem jest ZUGFeRD w profilu EN 16931, żeby klienci, którzy wciąż czytają faktury wzrokiem, mogli robić to dalej, a do tego XRechnung dla organów publicznych i każdego, kto o nią poprosi. Oba formaty powinny powstawać z jednego wewnętrznego obiektu faktury, a nie z dwóch ścieżek w kodzie.

Co musi się zmienić w Twoim systemie

Faktura staje się danymi, a nie układem strony

Wiele starszych systemów buduje fakturę w chwili wydruku: tekst sklejany w szablonie, sumy liczone w raporcie, adnotacja o VAT jako zakodowany na sztywno akapit. Nic z tego nie przetrwa zderzenia z EN 16931. Potrzebny jest zapisany obiekt faktury z każdym polem, z którego generowane są zarówno XML, jak i PDF.

Pola, których zwykle brakuje albo które są błędne:

• Dane stron. Adresy ustrukturyzowane z kodami krajów ISO oraz numer VAT UE albo numer podatkowy. Adresy zapisane jako jeden blok tekstu trzeba rozbić.
• Data dostawy lub okres świadczenia usługi, przechowywane jako dane, a nie jako zdanie w nagłówku.
• Jednostki. Każda ilość potrzebuje kodu z zalecenia UN/ECE nr 20 (H87 dla sztuki, KGM dla kilograma, DAY dla dnia). „Stk.” i „pauschal” trzeba zmapować.
• VAT. Każda pozycja ma kategorię i stawkę VAT. Faktura ma jedno zestawienie VAT dla każdej kombinacji kategorii i stawki, a sumy muszą się zgadzać dokładnie, przy dwóch miejscach po przecinku. Systemy zaokrąglające VAT w każdej pozycji tu polegną.
• Adnotacje o zwolnieniu i odwrotnym obciążeniu. Zdanie na dole PDF zamienia się w kod kategorii VAT i przyczynę zwolnienia.
• Płatność. Forma płatności, IBAN i warunki w postaci ustrukturyzowanej.
• Odwołania. Numer zamówienia albo referencja nabywcy, według której dział rozrachunków klienta paruje faktury. Jeśli nigdy jej nie zapisywano, zacznij ją zbierać teraz.

Częstą przeszkodą są pozycje czysto tekstowe („dostawa zgodnie z ustaleniami”). W fakturze ustrukturyzowanej pozycja to pozycja do zafakturowania, więc taki tekst należy do uwag.

Korekty, noty i samofakturowanie

FAQ mówi wprost: tam, gdzie obowiązuje e-faktura, korekta też musi być e-fakturą, z typem faktury przewidzianym dla korekty. W EN 16931 korekta wskazuje fakturę pierwotną po numerze i dacie wystawienia, więc system musi przechowywać to powiązanie jako dane.

Uwaga na słownictwo. W niemieckim prawie VAT „Gutschrift” to faktura wystawiona przez nabywcę w ramach samofakturowania, na podstawie wcześniejszej umowy (§ 14 Abs. 2 UStG). To, co po angielsku nazywa się credit note (obniżka ceny albo anulowanie), jest korektą. Wiele systemów używa jednego typu dokumentu dla obu przypadków. Rozdziel je przed mapowaniem, a jeśli samofakturujesz dostawców, traktuj te dokumenty jako faktury wystawiane przez Twój system.

Faktura końcowa może wymieniać wcześniejsze płatności częściowe w załączniku, o ile część ustrukturyzowana się do niego odwołuje; FAQ potwierdza, że tak pozostanie po 2027.

Walidacja, zanim cokolwiek wyjdzie

KoSIT publikuje otwartoźródłowy walidator, który sprawdza XML względem schematów i reguł Schematron, z publiczną konfiguracją dla XRechnung. Działa z wiersza poleceń, jako demon HTTP albo jako biblioteka. Umieść go na ścieżce wysyłki: każda faktura jest walidowana przed wysłaniem, a błąd trafia do kolejki z wyznaczonym właścicielem, z informacją, które pole naruszyło którą regułę.

W przypadku ZUGFeRD waliduj osadzony XML według reguł swojego profilu, osobno sprawdź kontener PDF/A-3 i upewnij się, że PDF pokazuje te same sumy co XML.

Przesyłanie

Ustawa, jak mówi FAQ, „sieht keinen bestimmten Weg vor”: nie przewiduje żadnego konkretnego kanału. E-mail z załączonym plikiem jest w porządku. Podobnie API, portal do pobierania, współdzielony magazyn danych w ramach grupy albo (to przykład samego ministerstwa) pendrive. Peppol nie jest wymagany w krajowym B2B w Niemczech.

Praca inżynierska dotyczy każdego klienta osobno: adres do faktur, preferowany format i zapis tego, co wysłano dokąd. Ponowienie po nieudanej wysyłce przenosi ten sam dokument z tym samym numerem faktury. Dwa numery dla jednej dostawy to problem podatkowy, a nie informatyczny.

Archiwizacja

Co najmniej część ustrukturyzowaną trzeba przechowywać „unversehrt in seiner ursprünglichen Form”, nienaruszoną, w pierwotnej postaci, a § 14b UStG ustala okres przechowywania na osiem lat od końca roku wystawienia. Przechowuj dokładnie te bajty, które wysłano, razem z hashem. Nie planuj odtwarzania faktur z bazy danych w przyszłości: do tego czasu zmienią się i dane, i kod. To samo dotyczy otrzymanych e-faktur.

Plan na okres od października do grudnia 2026

Trzynaście tygodni wystarczy na skupiony projekt, jeśli dane źródłowe są w przyzwoitym stanie. Nie wystarczy na wymianę systemu rozliczeniowego.

Tygodnie 1 i 2: inwentaryzacja i decyzje. Spisz każde miejsce, w którym powstaje faktura, łącznie z ręcznymi korektami, fakturami końcowymi projektów i arkuszem dla jednego dużego klienta. Porównaj obrót z 2026 z progiem. Wybierz domyślny format i zdecyduj, czy budujesz generator sam, czy przekazujesz dane faktur do API dostawcy usług e-fakturowania.

Tygodnie od 2 do 4: analiza luk w danych. Zmapuj trzy miesiące prawdziwych faktur, pole po polu, na EN 16931. Zaznacz, czego brakuje, co musi stać się kodem i co jest liczone inaczej. Tu widać rzeczywistą skalę projektu.

Tygodnie od 4 do 9: budowa. Obiekt faktury, mapowanie, generowanie XML i PDF/A-3, walidator na ścieżce wysyłki, kolejka błędów i archiwum. Równolegle ktoś porządkuje dane podstawowe i zbiera od klientów adresy do faktur.

Tygodnie od 9 do 11: odtworzenie i pilotaż. Przepuść faktury z ostatnich trzech miesięcy przez nowy generator i zwaliduj każdą z nich. Potem uruchom pilotaż z kilkoma chętnymi klientami i zapytaj, czy ich systemy czytają te pliki.

Tygodnie od 11 do 13: zamrożenie i instrukcja operacyjna. Zamroź zmiany w grudniu. Zapisz, kto odpowiada za kolejkę błędów, jak wystawia się korektę i co się dzieje, gdy klient odrzuci fakturę. Styczniowe faktury za pracę z grudnia już podlegają obowiązkowi.

Styczeń 2027. Start i codzienna obserwacja kolejki przez pierwsze zamknięcie miesiąca i pierwszą deklarację VAT.

Przez cały 2027. Zaplanuj przejście na XRechnung 4.0, zanim wersja 3.0 przestanie obowiązywać, i przeprowadź spółki z grupy poniżej progu przed 1 stycznia 2028.

Jeśli zaczynasz późno, tnij automatyzację, a nie poprawność wyniku: najpierw zautomatyzuj typy faktur o dużym wolumenie, a rzadkie dokumenty przez kilka tygodni wysyłaj ręcznie przez narzędzie do e-fakturowania.

Gdzie szukać pomocy

Budujemy połączenie między systemem, który generuje Twoje faktury, a formatem, którego wymaga prawo: zmiany modelu danych, mapowanie, walidację, przesyłanie i archiwum, w Twoim kodzie i razem z Twoim zespołem. Jak przebiegają takie projekty, opisuje nasza usługa integracji e-fakturowania; jeśli obowiązek wypada w środku zmiany ERP, zobacz modernizację ERP. Szerszy kalendarz znajdziesz w naszym przewodniku po zgodności cyfrowej UE 2026.

Jesteśmy inżynierami, a nie doradcami podatkowymi: pytania o zakres obowiązku należą do Twojego Steuerberatera, a my budujemy pod jego odpowiedź. Napisz nam, co dziś generuje Twoje faktury i mniej więcej ile wychodzi ich co miesiąc: office@c9group.dev.