Sprawdzono: czerwiec 2026. Daty wejścia w życie obowiązkowego e-fakturowania są wrażliwe na zmiany, a kilka z nich już wcześniej przesuwano, poniższe terminy traktuj jako kierunek, nie jako pewnik. Zanim podejmiesz działania, potwierdź aktualną datę, format i próg dla każdego ze swoich rynków z księgowym albo właściwym krajowym organem podatkowym. To praktyczne omówienie, nie porada prawna ani podatkowa.

Oto część, w której najczęściej mylą się sprzedawcy korzystający z PrestaShop: wysłanie faktury PDF e-mailem to nie e-fakturowanie. PDF, nawet schludny, poprawny pod kątem VAT i wygenerowany prosto z panelu administracyjnego, jest obrazem faktury przeznaczonym do odczytu przez człowieka. Prawdziwa faktura elektroniczna to ustrukturyzowany plik danych (zwykle XML), który system odczytuje, waliduje i księguje bezpośrednio w oprogramowaniu księgowym, przesyłany kanałem zatwierdzonym przez administrację publiczną. Tych dwóch rzeczy nie można stosować zamiennie, a w całej Europie definicja prawna coraz wyraźniej zmierza w stronę tej drugiej. Włochy już ją egzekwują. Francja, Niemcy, Polska i Hiszpania mają konkretne daty w kalendarzu. Jeśli sprzedajesz B2B na którykolwiek z tych rynków, to jest termin zgodności, a nie temat „kiedyś może”.

Ten przewodnik odpowiada na jedno konkretne pytanie: które kraje europejskie wymagają e-fakturowania, od kiedy, w jakim formacie, i co Twój sklep PrestaShop musi zrobić, aby być gotowy. Nie chodzi tu o projektowanie faktury PDF (to omawia personalizacja faktur w PrestaShop) ani o stawki VAT oraz OSS/IOSS (to opisuje VAT w UE). Chodzi o jedną rzecz, której e-fakturowanie naprawdę od Ciebie wymaga: czyste, kompletne, ustrukturyzowane dane faktury oraz ścieżkę do przesłania ich właściwym kanałem.

Faktura cyfrowa a e-faktura, różnica, która decyduje o wszystkim

Jeśli pomylisz się tutaj, każda kolejna decyzja też będzie błędna. Poniższa tabela pokazuje całe zagadnienie zgodności w miniaturze.

Faktura cyfrowa (PDF)Faktura elektroniczna (e-faktura)
FormatPDF, przygotowany dla człowiekaUstrukturyzowany XML (albo hybrydowy PDF+XML) zgodny z określonym standardem (EN 16931)
Odczytywana przezCzłowiekaSystem, walidowana i księgowana automatycznie
DostarczenieZałącznik e-mailPlatforma rządowa albo certyfikowana sieć (SDI, KSeF, PDP…)
Zgodna ustrukturyzowana e-faktura?Nie. PDF może być fakturą elektroniczną w ogólnym rozumieniu VAT, ale nie jest zgodną ustrukturyzowaną e-fakturą dla wymogów EN 16931/clearanceTak

Co to oznacza dla Twojego sklepu? PrestaShop w standardzie tworzy lewą kolumnę. Każde zamówienie generuje PDF przez AdminPdfController i klasę HTMLTemplateInvoice (classes/pdf/HTMLTemplateInvoice.php), renderowany z szablonu w pdf/invoice.tpl. Taki PDF jest zupełnie poprawną fakturą cyfrową, ale w krajach z obowiązkiem e-fakturowania sam w sobie nie jest zgodną fakturą elektroniczną. Zadanie polega na zamknięciu tej luki, a prawie cała praca sprowadza się do upewnienia się, że dane na fakturze są kompletne i poprawne, bo format ustrukturyzowany nie wybacza brakujących pól.

Kraj po kraju: kto wymaga, od kiedy i w jakim formacie

Daty i progi w tym obszarze się zmieniają, kilka już raz przesunięto, dlatego traktuj harmonogram jako kierunek i potwierdź dokładną datę oraz format dla swoich rynków z księgowym albo krajowym organem podatkowym, zanim zaczniesz działać. To, co nie budzi wątpliwości, to kierunek: każda duża gospodarka UE zmierza do obowiązkowego ustrukturyzowanego e-fakturowania.

KrajStatus / kluczowe datyFormatKanał transmisji
WłochyObowiązkowe od 2019 r. (B2B, B2C i B2G); w 2024 r. rozszerzone na podatników ryczałtowych/małych podatnikówFatturaPA (XML)SDI (Sistema di Interscambio)
FrancjaWdrażanie etapowe: najpierw zdolność odbioru i wystawianie przez duże przedsiębiorstwa, potem obowiązek wystawiania dla wszystkich firm (obecnie celowany na okolice 2026–2027, potwierdź, bo francuskie terminy już raz przesunięto)Factur-X (hybrydowy PDF/XML), UBL, CIIPDP, Plateforme de Dématérialisation Partenaire (certyfikowane platformy)
NiemcyOdbiór faktur B2B obowiązkowy od stycznia 2025 r.; wystawianie wchodzi etapami według obrotu do ok. 2027–2028XRechnung (XML) i ZUGFeRD (hybrydowy)Zdecentralizowany, wymiana bezpośrednia albo przez dostawców usług
PolskaKSeF obowiązkowy dla B2B, wdrożenie etapowe, duzi podatnicy od lutego 2026 r., pozostali od kwietnia 2026 r. (te daty już wcześniej się zmieniały; potwierdź aktualny harmonogram)Ustrukturyzowany XML (schemat FA_VAT)KSeF (Krajowy System e-Faktur)
HiszpaniaObowiązek B2B „Crea y Crece”, etapowany według wielkości firmy, przepisy wykonawcze wciąż oczekiwane w momencie przegląduFacturae jest ugruntowany dla B2G; obowiązek B2B czeka na przepisy wykonawcze i może obejmować ustrukturyzowane formaty zgodne z Facturae oraz interoperacyjność platform, potwierdź aktualne hiszpańskie zasady przed wdrożeniemPlatformy publiczne + prywatne
BelgiaObowiązek B2B zaplanowany na 2026 r.Peppol BIS (EN 16931)Sieć Peppol
RumuniaRO e-Factura obowiązkowa dla B2B i B2GUstrukturyzowany XML (EN 16931)Platforma RO e-Factura

Z tej tabeli warto wyciągnąć dwa wzorce. Po pierwsze, prawie każdy nowy format jest wariantem EN 16931, wspólnego unijnego standardu semantycznego, więc inwestycja w czyste, kompletne dane działa ponad granicami, nawet jeśli opakowania plików się różnią. Po drugie, w większości wdrożeń odbiór poprzedza wystawianie: pierwszy termin, który Cię dotknie, to zwykle obowiązek odbierania ustrukturyzowanych faktur od dostawców, czyli temat zakupowo-księgowy, a nie coś generowanego przez część sprzedażową sklepu.

Kierunek ogólnounijny: ViDA

Żaden z tych systemów krajowych nie jest jednorazowym wyjątkiem. To przygotowanie do VAT in the Digital Age (ViDA), unijnej inicjatywy mającej ustandaryzować e-fakturowanie i wprowadzić cyfrowe raportowanie niemal w czasie rzeczywistym dla transakcji wewnątrz UE, z wymogami dotyczącymi faktur ustrukturyzowanych planowanymi na drugą połowę tej dekady. Praktyczny wniosek dla właściciela sklepu: format krajowy, który wdrożysz teraz, jest etapem pośrednim, a nie ślepą uliczką, bo wszystkie zbiegają się wokół tego samego rdzenia EN 16931. Doprowadzenie danych faktury do porządku to trwała inwestycja; warstwa transmisji to część, którą najpewniej zlecisz na zewnątrz.

Czego to faktycznie wymaga od Twojego sklepu PrestaShop

Pulpit numeracji faktur i korekt w PrestaShop z licznikami audytu
Zgodne e-fakturowanie zaczyna się od czystej, sekwencyjnej numeracji dokumentów obejmującej faktury i korekty.

Gdy odłożysz akronimy na bok, e-fakturowanie wymaga od Ciebie trzech konkretnych rzeczy. Tylko pierwsza jest naprawdę zadaniem sklepu, i właśnie tam dochodzi do większości problemów.

1. Jakość danych faktury (to 90% pracy)

Systemy ustrukturyzowanego e-fakturowania od razu odrzucają faktury z brakującymi albo źle sformatowanymi polami. Po drugiej stronie nie ma człowieka, który wzruszy ramionami i poprawi błąd. Plik FatturaPA bez numeru VAT nabywcy nie trafia do wyjaśnienia; po prostu wraca. Podstawowym zadaniem jest więc upewnienie się, że każda faktura PrestaShop zawiera pełny zestaw pól EN 16931:

  • Identyfikatory VAT/podatkowe sprzedawcy i nabywcy, a w B2B identyfikator nabywcy musi być obecny i poprawny. PrestaShop przechowuje je w adresie (vat_number oraz company i siret/dni, gdzie ma to zastosowanie), ale są uzupełniane tylko wtedy, gdy formularz zamówienia o nie pyta i je walidujesz.
  • Kompletne ustrukturyzowane adresy, ulica, kod pocztowy, miasto, kod kraju, każde w osobnym polu (XML oczekuje ich oddzielnie, a nie jako jednego swobodnego bloku tekstu).
  • Rozbicie podatku według pozycji i stawek. Łączny VAT musi zgadzać się z sumami częściowymi dla poszczególnych stawek, i właśnie tutaj niedbała konfiguracja podatków potrafi zaboleć. Jeśli stawki i reguły nie są uporządkowane, plik ustrukturyzowany nie przejdzie walidacji; konfiguracja podatków w PrestaShop pokazuje, jak naprawić to u źródła.
  • Unikalny kolejny numer faktury. Z wyjaśnionymi lukami tam, gdzie wymaga tego lokalne prawo albo praktyka księgowa. Wiele systemów podatkowych wymaga unikalnej kolejnej numeracji, ale to, czy sekwencja musi być absolutnie bez luk, zależy od kraju i zasad księgowych, a systemy walidacji XML zazwyczaj nie odrzucają faktury wyłącznie dlatego, że brakuje innego numeru. Domyślny licznik PrestaShop działa per sklep i resetuje się albo rozgałęzia w sposób, który zaskakuje sprzedawców; szerzej omawia to personalizacja numerów faktur i zamówień.
  • Jasne opisy produktów, kody i warunki płatności, ogólne opisy pozycji oraz brakujące dane płatności/banku to częste przyczyny odrzuceń.

I co z tego? Jeśli Twoje faktury już teraz zbierają i walidują numery VAT nabywców, mają czyste rozbicie podatków według stawek i są numerowane kolejno, jesteś w większości gotowy na e-fakturowanie niezależnie od tego, do którego krajowego kanału ostatecznie się podłączysz, bo każdy z tych kanałów chce tych samych danych bazowych. Tu właściwe moduły naprawdę odciążają sklep: Financial Revolution tworzy faktury z kompletnym zestawem pól oczekiwanym przez europejskie wymogi zgodności, Invoice Number wymusza ścisłą kolejną numerację, której wymagają te systemy, a Automatic EU VAT Checker waliduje numery VAT nabywców w VIES podczas składania zamówienia, dzięki czemu błędny numer nie trafi na fakturę, która za chwilę zostałaby odrzucona maszynowo. Korzyścią nie jest abstrakcyjna „zgodność”, tylko to, że dane faktury są czyste zanim termin wymusi działanie, a nie dopiero po fakcie.

2. Konwersja formatu (generowanie XML)

Czyste dane z PrestaShop nadal muszą stać się plikiem FatturaPA, XRechnung, Factur-X albo KSeF XML. Są dwie realistyczne drogi dojścia do tego punktu, a dla większości sprzedawców właściwa jest druga:

Krajowy moduł PrestaShopZewnętrzny dostawca e-fakturowania
Co robiGeneruje krajowy XML wewnątrz PrestaShopPobiera dane faktury i tworzy + przesyła plik za Ciebie
Najlepszy, gdyObsługujesz jeden lub dwa rynki i masz przewidywalny wolumenDziałasz w kilku krajach albo nie chcesz sam utrzymywać zgodności formatów
KompromisAktualizacje przy każdej zmianie schematu są po Twojej stronieOpłata za fakturę, ale dostawca śledzi zmiany schematów

3. Transmisja

Plik musi następnie przejść zatwierdzonym kanałem, włoskim SDI, polskim KSeF, francuską siecią PDP, siecią Peppol dla Belgii i innych krajów. Bezpośrednia integracja z tymi systemami jest naprawdę złożona i mocno oparta na certyfikatach, dlatego zdecydowanie najczęstszym modelem wśród małych i średnich sprzedawców jest przekazanie transmisji pośrednikowi (często temu samemu, który robi konwersję formatu) za opłatą od faktury. Odpowiedzialność Twojego sklepu kończy się na dostarczeniu poprawnych danych; ich zadaniem jest przesłać je właściwym kanałem i zwrócić potwierdzenie.

B2C: w większości jeszcze nie, ale nie zakładaj, że tak zostanie

Dzisiaj obowiązki dotyczą przede wszystkim B2B (i B2G). Większość faktur B2C jest zwolniona albo uproszczona, z ważnym wyjątkiem Włoch, gdzie obowiązek obejmuje już sprzedaż konsumencką. Pragmatyczne podejście jest proste: nawet tam, gdzie e-fakturowanie B2C nie jest od Ciebie wymagane, utrzymywanie jakości danych na standardzie gotowym pod strukturę nie kosztuje Cię nic dodatkowo, a ewentualne przyszłe rozszerzenie B2C na jednym z Twoich rynków będzie zmianą konfiguracji, nie akcją awaryjną. Pamiętaj też, że sprzedaż konsumentom na odległość ma własne obowiązki dokumentacyjne niezależnie od e-fakturowania, zobacz przepisy dotyczące sprzedaży na odległość.

Twój plan działania

Nie musisz rozwiązywać wszystkich krajów naraz. Musisz znać swoją ekspozycję i uporządkować dane, dokładnie w tej kolejności.

  • Przypisz swoje rynki B2B do terminów. Wypisz kraje, w których faktycznie wystawiasz faktury B2B, a potem przypnij aktualną datę i format dla każdego z nich. Najbliższe: Włochy (już działa), potem Francja, Niemcy, Polska, Hiszpania.
  • Zrób audyt danych faktur już teraz. Weź dziesięć ostatnich faktur B2B i sprawdź, czy każde z powyższych pól EN 16931 jest obecne i poprawne. Luki znalezione dzisiaj to odrzucenia, które zobaczyłbyś w dniu uruchomienia obowiązku.
  • Napraw dane u źródła. Waliduj numery VAT nabywców podczas składania zamówienia, uporządkuj reguły podatkowe i zabezpiecz kolejną numerację, to trzy zadania, dzięki którym każdy dalszy format zadziała. Wspomniane moduły robią dokładnie to z poziomu panelu administracyjnego, bez angażowania programisty.
  • Wybierz konwersję + transmisję dla każdego rynku. Moduł krajowy, jeśli masz jeden lub dwa rynki i gotowość do pilnowania aktualizacji schematów; pośrednik, jeśli masz ich kilka albo wolisz tego nie utrzymywać.
  • Porozmawiaj z księgowym. Powinien już śledzić dokładne daty i progi dla Twojej sytuacji, ten przewodnik mówi, o co pytać, a nie co składać.
  • Sprawdzaj harmonogram dwa razy w roku. Kilka z tych dat wciąż jest finalizowanych i już wcześniej się zmieniało; przypomnienie w kalendarzu jest lepsze niż pośpiech w ostatniej chwili.

Najczęściej zadawane pytania

Czy poprawny pod kątem VAT PDF, który PrestaShop już wysyła e-mailem, nie wystarczy?

Nie w kraju z obowiązkiem e-fakturowania. Taki PDF to faktura cyfrowa, obraz dla człowieka. Zgodna faktura elektroniczna we Włoszech, Francji, Polsce i pozostałych krajach to ustrukturyzowany plik XML (często oparty na EN 16931), walidowany przez system i przesyłany przez platformę rządową albo certyfikowaną sieć. PrestaShop natywnie tworzy PDF; zamiana go w wymagany plik ustrukturyzowany to luka, którą musisz zamknąć, i w większości jest to praca nad jakością danych.

Kiedy dokładnie e-fakturowanie staje się obowiązkowe we Francji i w Polsce?

Kierunek jest pewny, ale precyzyjne daty nie, oba harmonogramy już wcześniej się przesuwały. Według tego przeglądu Francja celuje w okolice lat 2026–2027 (etapowo, najpierw odbiór i duże przedsiębiorstwa), a polski KSeF jest wdrażany etapami: duzi podatnicy od lutego 2026 r., pozostali od kwietnia 2026 r. Traktuj to jako punkty planowania, nie gwarancje: zanim zbudujesz coś wokół tych terminów, potwierdź aktualną datę i próg dla swojej sytuacji z księgowym albo krajowym organem podatkowym (DGFiP we Francji, Ministerstwo Finansów / KAS w Polsce).

Czy potrzebuję modułu PrestaShop generującego XML, czy zewnętrznego dostawcy?

To zależy od skali. Jeden lub dwa rynki, przewidywalny wolumen i gotowość do utrzymywania aktualizacji schematów: krajowy moduł generujący XML wewnątrz PrestaShop może się sprawdzić. Kilka rynków albo brak ochoty na śledzenie zmian formatów: najczęściej wybiera się zewnętrznego dostawcę e-fakturowania, który pobiera dane, tworzy plik i obsługuje transmisję za opłatą od faktury. W obu wariantach prawdziwym zadaniem sklepu są czyste dane, które zasilają ten proces.

Jaki jest najczęstszy powód odrzucenia ustrukturyzowanej e-faktury?

Brakujący albo nieprawidłowy numer VAT nabywcy na fakturze B2B, a zaraz potem sumy podatku, które nie zgadzają się z sumami częściowymi według stawek. Po drugiej stronie nie ma człowieka, który to poprawi, plik wraca. Walidacja numerów VAT w VIES podczas składania zamówienia (tak, aby zły numer nigdy nie trafił na fakturę) i czyste reguły podatkowe usuwają dwa największe źródła odrzuceń w dniu startu obowiązku.

Sprzedaję tylko B2C, czy mogę to wszystko zignorować?

W większości tak, na razie, z wyjątkiem Włoch, gdzie obowiązek obejmuje już sprzedaż konsumencką. Rozsądniej jest jednak mimo wszystko utrzymywać dane faktur w standardzie gotowym na strukturę: nie kosztuje to nic dodatkowo, a każde przyszłe rozszerzenie B2C na Twoich rynkach zmienia w korektę konfiguracji zamiast awarii. Potwierdź też własną sytuację z doradcą, zakres B2C to jeden z elementów, które nadal się zmieniają.

E-fakturowanie nie jest najbardziej ekscytującą pozycją na liście właściciela sklepu, ale ma cechę, której ekscytujące tematy często nie mają: twardy termin. Sprzedawcy, którzy wpadają w kłopoty, zwykle nie są tymi, którzy późno zaczęli temat transmisji, to problem dostawcy, który da się kupić w tydzień. To ci, których bazowe dane faktur były bałaganem i którzy rano w dniu wejścia obowiązku odkryli, że połowie faktur B2B brakuje prawidłowego numeru VAT nabywcy albo numeracja nie trzyma się porządku. Doprowadź dane do porządku, gdy wciąż jest to opcjonalne, a termin, kiedy nadejdzie, będzie czyimś problemem operacyjnym.

Powiązane przewodniki

Udostępnij ten wpis:
David Miller

David Miller

Założyciel, mypresta.rocks

David Miller to specjalista PrestaShop z ponad dekadą praktycznego doświadczenia i założyciel mypresta.rocks, studia programistycznego z Tychów. Tworzy i utrzymuje katalog 152 modułów PrestaShop, w tym 21 pakietów „Revolution" obejmujących SEO, checkout, bezpieczeństwo, wydajność, marketing, wyszukiwanie, wsparcie i operacje magazynowe, które każdego dnia usprawniają realne sklepy, testowanych na PrestaShop 1.7.8, 8.x i 9.x. Sprawuje również opiekę nad sklepami produkcyjnymi generującymi miliony rocznego obrotu, dlatego jego pracę ocenia się po realnej sprzedaży, a nie po wersjach demo. Jego doświadczenie obejmuje pełen zakres e-commerce, wydajność, bezpieczeństwo, SEO i marketing, oraz wykracza poza PrestaShop, sięgając WooCommerce, Shopify i systemów tworzonych na zamówienie. Na blogu pisze o technicznej stronie PrestaShop: co platforma naprawdę robi pod maską, co psuje się na produkcji i które rozwiązania faktycznie się sprawdzają.

Komentarze

Brak komentarzy. Bądź pierwszy!
Spodobał Ci się ten artykuł?

Otrzymuj nasze najnowsze porady, przewodniki i aktualizacje modułów prosto na swoją skrzynkę.

Możesz zrezygnować w każdej chwili. W tym celu należy odnaleźć szczegóły w naszej informacji prawnej.

Ładowanie...
Do góry