Polska firma może dziś poprawnie wystawić fakturę w KSeF, a jednocześnie nie mieć rozwiązania pozwalającego sprawnie dostarczyć jej ustrukturyzowaną wersję kontrahentowi z Niemiec, Belgii czy Francji. I odwrotnie: przedsiębiorstwo podłączone do Peppol może bez problemu wymieniać dokumenty z zagranicznym partnerem, ale nadal musi osobno spełnić polskie obowiązki związane z Krajowym Systemem e-Faktur.
To nie jest różnica czysto techniczna. KSeF jest polskim systemem podatkowym, natomiast Peppol jest międzynarodową siecią wymiany ustrukturyzowanych dokumentów elektronicznych. Nad nimi pojawia się jeszcze trzeci poziom: unijny pakiet ViDA – VAT in the Digital Age, który od 1 lipca 2030 r. zasadniczo zmieni zasady e-fakturowania i raportowania części transakcji B2B wewnątrz Unii Europejskiej.
Najczęstszy błąd wdrożeniowy polega dziś na założeniu, że skoro firma „ma już KSeF”, to temat europejskiego e-fakturowania jest zamknięty. Nie jest. System przygotowany wyłącznie pod FA(3) może za kilka lat wymagać kolejnej przebudowy, jeżeli nie potrafi obsłużyć danych i formatów używanych w europejskim modelu faktury elektronicznej.
KSeF rozwiązuje polski obowiązek podatkowy, Peppol rozwiązuje problem wymiany dokumentów
Od 1 lutego 2026 r. obowiązek wystawiania faktur przez KSeF objął podatników, których wartość sprzedaży wraz z VAT przekroczyła w 2024 r. 200 mln zł. Od 1 kwietnia 2026 r. obowiązek objął zasadniczo pozostałych przedsiębiorców. Najmniejsze firmy korzystają z przejściowego odroczenia: jeżeli miesięczna sprzedaż dokumentowana fakturami nie przekracza 10 000 zł brutto, obowiązek wystawiania faktur w KSeF został przesunięty do 1 stycznia 2027 r.
Istotna różnica: obowiązek odbierania faktur przez KSeF działa szerzej już od 1 lutego 2026 r. Dlatego nawet przedsiębiorca, który jeszcze korzysta z czasowego wyłączenia z obowiązku wystawiania faktur, nie powinien traktować KSeF jako tematu „na później”.
Polska faktura ustrukturyzowana działa obecnie według struktury FA(3). Jest to plik XML zgodny ze schematem określonym dla KSeF. W praktyce aplikacja finansowo-księgowa lub ERP:
- przygotowuje dane faktury,
- tworzy XML zgodny z FA(3),
- przesyła dokument do API KSeF 2.0,
- odbiera odpowiedź systemu i numer KSeF,
- zapisuje status dokumentu,
- umożliwia pobranie lub prezentację faktury.
W trybie online faktura ustrukturyzowana jest co do zasady uznawana za wystawioną w dniu jej przesłania do KSeF, przy zachowaniu szczegółowych warunków dotyczących daty wskazanej na dokumencie. Dla odbiorcy korzystającego z KSeF istotna jest natomiast data przydzielenia fakturze numeru identyfikacyjnego KSeF.
Peppol działa inaczej.
Nie jest centralną europejską bazą faktur ani „unijnym KSeF”. Jest siecią umożliwiającą wymianę dokumentów pomiędzy organizacjami podłączonymi za pośrednictwem certyfikowanych operatorów, czyli Peppol Access Points.
Model Peppol określa się często jako four-corner model:
- dostawca tworzy dokument w swoim systemie,
- jego Access Point wysyła dokument,
- Access Point odbiorcy przyjmuje go z sieci,
- system odbiorcy importuje fakturę.
Firma nie musi więc mieć bezpośredniej integracji technicznej z każdym klientem osobno. Wystarczy dostęp do sieci przez operatora obsługującego Peppol.
Do faktur wykorzystywana jest m.in. specyfikacja Peppol BIS Billing 3.0, oparta na europejskim modelu semantycznym EN 16931. Dokument zawiera dane w ustrukturyzowanej postaci, najczęściej wykorzystującej składnię UBL. To zupełnie inny model niż polski XML FA(3), mimo że część danych biznesowych — numer faktury, sprzedawca, nabywca, waluta, stawki VAT, wartości pozycji czy kwota do zapłaty — oczywiście się pokrywa.
I tu zaczyna się problem projektowy.
Jeżeli system księgowy przechowuje wyłącznie pola potrzebne do wygenerowania FA(3), samo dopisanie „eksportu Peppol” może nie wystarczyć. Trzeba sprawdzić, czy aplikacja posiada dane odpowiadające europejskiemu modelowi semantycznemu, poprawnie obsługuje identyfikatory stron, kody państw, waluty, jednostki miary, sposoby płatności, zwolnienia z VAT oraz referencje do dokumentów.
Nie należy więc mapować Peppol bezpośrednio na plik FA(3). Lepsza architektura polega na utrzymywaniu jednego pełnego modelu danych faktury w ERP, z którego generowane są osobno:
- FA(3) dla KSeF,
- Peppol BIS Billing dla wymiany sieciowej,
- PDF lub wizualizacja dla użytkownika,
- inne formaty wymagane przez lokalny system kontrahenta.
To podejście kosztuje więcej na początku, ale eliminuje sporą część późniejszych przeróbek.
ViDA od 2030 r. zmieni transgraniczne B2B bardziej niż kolejna wersja formatu faktury
Pakiet VAT in the Digital Age został formalnie przyjęty przez Unię Europejską 11 marca 2025 r., a jego rozwiązania są wprowadzane etapami. Dla przedsiębiorstw prowadzących handel wewnątrz UE najważniejsza data dotycząca e-fakturowania to 1 lipca 2030 r.
Od tego dnia nowe Digital Reporting Requirements – DRR obejmą określone transgraniczne transakcje B2B wewnątrz Unii. System będzie bazował na ustrukturyzowanych fakturach elektronicznych i raportowaniu danych transakcyjnych.
To nie będzie tylko zamiana PDF na XML.
ViDA zmienia sam sposób projektowania procesu fakturowania. Faktura elektroniczna w rozumieniu nowych przepisów ma być dokumentem wystawionym, przesłanym i odebranym w ustrukturyzowanym formacie umożliwiającym automatyczne przetwarzanie.
PDF wysłany e-mailem takiego warunku sam w sobie nie spełnia.
Dla transakcji objętych nowym systemem faktury elektroniczne będą musiały odpowiadać europejskiemu standardowi e-fakturowania i przewidzianym dla niego składniom. Państwa członkowskie zachowają więcej swobody w zakresie rozwiązań stosowanych do części transakcji krajowych, ale dla operacji transgranicznych kierunek jest jasny: dane mają być interoperacyjne na poziomie europejskim.
Do tego dochodzą znacznie krótsze terminy.
W przypadku wskazanych transakcji transgranicznych faktura będzie musiała zostać wystawiona nie później niż 10 dni od zdarzenia powodującego powstanie obowiązku podatkowego. Dla odpowiednich zaliczek termin będzie liczony od ich otrzymania.
Jeszcze ważniejsza jest logika raportowania. Dane dotyczące określonych dostaw mają być przekazywane dla każdej transakcji indywidualnie, a przy standardowym modelu wystawienia faktury moment raportowania zostaje powiązany z chwilą, w której faktura jest wystawiana lub powinna zostać wystawiona.
To jakościowa zmiana w stosunku do modelu, w którym księgowość może kilka dni później uzupełnić brakujące dane i dopiero następnie przygotować raport okresowy.
Po wejściu DRR błąd powstały na początku procesu — przykładowo nieprawidłowy numer VAT UE kontrahenta, błędna kwalifikacja transakcji albo brak wymaganej informacji o reverse charge — będzie trzeba wyłapać przed wysłaniem dokumentu, a nie podczas zamknięcia miesiąca.
Zmienia się również podejście do zgody odbiorcy. W przypadku faktury elektronicznej zgodnej z europejskim standardem jej wystawienie podatnikowi lub odpowiedniej osobie prawnej nie będzie zasadniczo wymagało wcześniejszej akceptacji odbiorcy dla transakcji objętych nowymi zasadami.
Jest też data dalsza, ale ważna z punktu widzenia Polski: 1 stycznia 2035 r. Do tego czasu państwa posiadające krajowe obowiązki cyfrowego raportowania transakcji w czasie rzeczywistym mają dostosować swoje systemy do unijnego modelu.
Nie oznacza to jednak, że KSeF zostanie zastąpiony Peppol albo zniknie w 2030 lub 2035 r. Takiego wniosku z ViDA wyciągać nie można. Regulacje wyznaczają standard interoperacyjności i zasady raportowania, natomiast krajowa architektura techniczna nadal pozostaje osobnym zagadnieniem.
Podobnie nie ma podstaw, żeby twierdzić, że ViDA nakazuje firmom używanie Peppol. Peppol jest bardzo istotnym mechanizmem wymiany zgodnym z europejskim kierunkiem e-fakturowania, ale nie jest w ViDA ustanowiony jako jedyna obowiązkowa sieć transportowa.
To rozróżnienie powinno trafić do specyfikacji projektu. Inaczej firma może kupić rozwiązanie opisane hasłem „ViDA ready”, które w praktyce obsługuje jedynie jeden kanał wysyłki.
Jak zbudować system, którego nie trzeba będzie przebudować przed 2030 r.
Najrozsądniejszy projekt nie zaczyna się od wyboru operatora Peppol. Zaczyna się od mapy transakcji.
Trzeba rozdzielić co najmniej:
- polskie B2B,
- polskie B2C,
- krajowe transakcje wyłączone lub obsługiwane według szczególnych zasad,
- WDT,
- WNT,
- transgraniczne usługi B2B z reverse charge,
- sprzedaż do kontrahentów posiadających zagraniczny numer VAT,
- transakcje realizowane przez zagraniczny oddział lub stałe miejsce prowadzenia działalności,
- faktury dla sektora publicznego.
Dopiero potem można projektować routing dokumentów.
W praktyce firma działająca w kilku krajach powinna dążyć do modelu:
ERP → wspólny model danych faktury → walidacja podatkowa → konwersja do właściwego formatu → odpowiedni kanał wysyłki → potwierdzenie techniczne → archiwizacja statusu.
W Polsce kanałem może być KSeF. Dla części zagranicznych klientów — Peppol. Inny kontrahent może czasowo wymagać własnego EDI. Do 2030 r. te kanały będą funkcjonowały równolegle.
Pierwszy techniczny test powinien dotyczyć nie samego wysyłania faktury, lecz mapowania danych FA(3) ↔ EN 16931/Peppol BIS Billing.
Trzeba sprawdzić szczególnie:
- identyfikatory podatkowe sprzedawcy i nabywcy,
- adres elektroniczny odbiorcy,
- kod kraju,
- walutę faktury,
- walutę rozliczenia VAT,
- kategorie i stawki VAT,
- oznaczenie reverse charge,
- numery rachunków płatniczych,
- termin i warunki płatności,
- identyfikatory pozycji,
- jednostki miary,
- rabaty i dopłaty na poziomie pozycji oraz całej faktury,
- powiązania faktury korygującej z dokumentem źródłowym.
Nie wszystkie systemy ERP przechowują te dane w sposób wystarczająco uporządkowany. To jedna z najbardziej irytujących części wdrożenia: problem wychodzi często dopiero przy pierwszej walidacji pliku. Faktura wygląda poprawnie w PDF, księgowanie działa, wartości VAT są prawidłowe, ale dokument strukturalny zostaje odrzucony, bo brakuje kodu, identyfikatora albo relacja między polami nie spełnia reguły biznesowej.
Dlatego przed podpisaniem umowy z dostawcą platformy e-fakturowania warto poprosić nie o prezentację slajdów, lecz o test na prawdziwych dokumentach firmy. Dobrą próbą jest zestaw co najmniej kilkunastu faktur zawierających nietypowe sytuacje: kilka stawek VAT, korektę, zaliczkę, reverse charge, rabat, fakturę walutową oraz kontrahentów z różnych państw.
Drugim testem jest obsługa błędów. Integracja musi odpowiadać na konkretne pytania:
- co dzieje się po odrzuceniu faktury,
- czy użytkownik widzi przyczynę błędu,
- kto może poprawić dokument,
- czy ponowne wysłanie nie tworzy duplikatu,
- gdzie przechowywany jest numer KSeF i identyfikator dokumentu Peppol,
- czy system potrafi ustalić, którym kanałem dokument faktycznie dotarł do klienta,
- jak obsługiwane są niedostępność sieci i tryby awaryjne.
Najgorszy wariant to integracja, która potrafi wysłać XML, ale nie posiada porządnego mechanizmu kontroli jego dalszego statusu. Przy kilkudziesięciu tysiącach faktur miesięcznie ręczne sprawdzanie wyjątków przestaje być realne.
Koszt projektu również trzeba liczyć inaczej niż cenę samego Access Pointu. W małej organizacji usługa Peppol może być częścią abonamentu programu finansowego lub platformy integracyjnej. W średnich i dużych firmach większą część budżetu pochłaniają zwykle mapowanie danych, integracja z ERP, testy, obsługa wyjątków i proces zmian wersji specyfikacji, a nie samo przesłanie dokumentu.
Przy wyborze dostawcy trzeba więc pytać nie tylko „ile kosztuje faktura”, ale również:
- czy cena obejmuje odbiór dokumentów,
- czy jest miesięczny abonament lub minimalny wolumen,
- ile kosztuje podłączenie kolejnej spółki albo kraju,
- kto utrzymuje mapowania po zmianach KSeF i Peppol,
- czy dostępne jest API,
- jakie są limity wywołań,
- jaki jest SLA,
- jak długo przechowywane są logi i komunikaty techniczne,
- czy dane można łatwo wyeksportować po zmianie operatora.
Przed 2030 r. największym ryzykiem nie jest brak jednej konkretnej funkcji. Jest nim uzależnienie całego procesu fakturowania od jednego formatu albo jednego kanału transportowego. KSeF, Peppol i ViDA należy traktować jako trzy różne warstwy: krajowy obowiązek podatkowy, sieć wymiany dokumentów oraz unijne reguły e-fakturowania i raportowania.
FAQ: KSeF, Peppol i ViDA w praktyce
Czy Peppol zastępuje KSeF?
Nie. KSeF jest polskim systemem e-fakturowania wynikającym z krajowych przepisów VAT. Peppol jest siecią wymiany ustrukturyzowanych dokumentów między organizacjami. Firma może potrzebować obu rozwiązań równocześnie.
Czy faktura wysłana przez Peppol automatycznie trafia do KSeF?
Nie należy tego zakładać. Musi istnieć odpowiednia integracja techniczna i procesowa. Sam fakt korzystania z Access Pointu Peppol nie oznacza automatycznego wykonania obowiązku wobec KSeF.
Czy faktura FA(3) jest tym samym dokumentem co Peppol BIS Billing 3.0?
Nie. FA(3) jest polską strukturą logiczną wykorzystywaną przez KSeF. Peppol BIS Billing 3.0 bazuje na europejskim modelu EN 16931 i używa innych zasad struktury oraz walidacji. Dane można mapować pomiędzy formatami, ale nie są one tożsame.
Czy ViDA zacznie obowiązywać dopiero w 2030 r.?
Nie. Pakiet jest wdrażany etapami. Z punktu widzenia transgranicznego e-fakturowania B2B najważniejszym terminem jest jednak 1 lipca 2030 r., kiedy wejdą nowe wymogi DRR dla określonych transakcji wewnątrzunijnych.
Czy ViDA oznacza obowiązek korzystania z Peppol?
Nie. ViDA wprowadza wymagania dotyczące faktury ustrukturyzowanej, europejskiego standardu oraz raportowania danych, ale nie ustanawia Peppol jako jedynej obowiązkowej sieci przesyłania faktur.
Czy PDF wysłany e-mailem będzie fakturą elektroniczną w rozumieniu nowych zasad ViDA?
Sam PDF nie spełnia definicji ustrukturyzowanej faktury elektronicznej pozwalającej na automatyczne przetwarzanie danych. System musi obsługiwać wymagany format strukturalny.
Od czego zacząć przygotowania, jeżeli KSeF już działa w firmie?
Od audytu danych, nie od kupowania kolejnej platformy. Weź rzeczywiste faktury WDT i transgranicznych usług B2B, rozpisz dane dostępne w ERP i sprawdź ich mapowanie do EN 16931 oraz Peppol BIS Billing. Jeżeli dziś informacje potrzebne do europejskiej faktury są wpisywane tylko w opisach, uwagach albo ręcznie dopisywane do PDF, właśnie ten błąd trzeba usunąć jako pierwszy. Dopiero po uporządkowaniu modelu danych ma sens wybór Access Pointu, middleware albo nowej platformy e-fakturowania. Więcej informacji na: https://finansowa-wiedza.pl
