ViDA: co powinien wpisać do roadmapy technologicznej e-commerce na 2027?

Dla średniego polskiego e-commerce, który planuje dalszą ekspansję w Unii Europejskiej, oznacza to konieczność szerszego spojrzenia na technologię VAT. ViDA nie musi być traktowane jako pojedynczy projekt compliance, którego celem jest wdrożenie kolejnego formatu raportowania albo kolejnej integracji. Z perspektywy architektury znacznie rozsądniej potraktować te zmiany jako impuls do budowy interoperacyjnej warstwy VAT, która potrafi połączyć dane sprzedażowe, fakturowanie, płatności, logistykę, ruchy magazynowe i raportowanie podatkowe. To rekomendacja technologiczna, a nie wymóg zapisany w samych przepisach, ale dobrze odpowiada kierunkowi zmian: kolejne etapy ViDA będą wymagały coraz bardziej uporządkowanych, strukturalnych i możliwych do ponownego wykorzystania danych. Jeśli dziś informacje o jednej transakcji są rozproszone pomiędzy kilkoma systemami i trudno odtworzyć ich pełną historię, kolejne obowiązki będą tylko zwiększać koszt integracji i kontroli. Dlatego w roadmapie na 2027 rok warto zapisać nie tylko obsługę aktualnych zmian, ale przede wszystkim budowę fundamentu technologicznego, który będzie można rozwijać w 2028, 2030 i w kolejnych latach.

Najpierw: co właściwie zmienia ViDA dla e-commerce?

Trzy filary ViDA

ViDA, czyli VAT in the Digital Age, to pakiet zmian wdrażanych etapami przez wiele lat, a z perspektywy przedsiębiorcy prowadzącego e-commerce najłatwiej uporządkować go wokół trzech głównych obszarów. Pierwszy to Digital Reporting Requirements, czyli cyfrowe wymogi raportowania, które mają doprowadzić do bardziej szczegółowego i szybszego przekazywania danych o określonych transakcjach, zwłaszcza transgranicznych B2B. Drugi filar dotyczy gospodarki platformowej. W tym przypadku warto jednak zachować precyzję, bo najbardziej charakterystyczne nowe zasady deemed supplier nie odnoszą się do wszystkich marketplace’ów sprzedających towary. Obejmują przede wszystkim platformy pośredniczące w krótkoterminowym wynajmie zakwaterowania oraz drogowym transporcie pasażerskim, które w określonych przypadkach mają być traktowane jako dostawcy dla celów VAT. Dla klasycznego e-commerce towarowego platformy nadal pozostają ważnym elementem zmian, ale przede wszystkim ze względu na rozwiązania powiązane z OSS, IOSS, ewidencjami i obowiązkami informacyjnymi, a nie z powodu objęcia całego sektora jednym nowym reżimem deemed supplier.

Trzeci filar to Single VAT Registration. Jego celem nie jest stworzenie jednej uniwersalnej rejestracji VAT, która zastąpi wszystkie lokalne numery VAT w całej Unii. Chodzi raczej o dalsze rozwinięcie istniejącego ekosystemu OSS i IOSS oraz szersze wykorzystanie mechanizmu reverse charge, tak aby w określonych modelach transakcyjnych ograniczyć liczbę sytuacji, w których przedsiębiorca musi rejestrować się lokalnie do VAT. W praktyce obejmuje to między innymi rozszerzenie OSS, nowe podejście do transferów własnych towarów oraz obowiązkowy reverse charge w określonych przypadkach. Dla firmy e-commerce planującej ekspansję ważne jest właśnie to rozróżnienie. ViDA może ograniczyć część lokalnych obowiązków rejestracyjnych, ale ich całkowicie nie eliminuje. To oznacza, że zarządzanie statusem rejestracji VAT, miejscem magazynowania towaru, krajem wysyłki i właściwą procedurą nadal pozostanie kluczową częścią operacji podatkowych.

Dlaczego roadmapa na 2027 nie może kończyć się na 2027?

Najłatwiej zrozumieć znaczenie 2027 roku, patrząc na najważniejsze kamienie milowe ViDA z perspektywy e-commerce: 2025 2027 2028 2030 2035. Od 14 kwietnia 2025 roku państwa członkowskie mogą, na warunkach określonych w nowych przepisach, wprowadzać obowiązkowe krajowe e-fakturowanie. Tego samego dnia ViDA weszła w życie i zaczęły obowiązywać również pierwsze zmiany, w tym rozwiązania wzmacniające kontrolę IOSS. Od 1 stycznia 2027 roku zaczną działać kolejne doprecyzowania legislacyjne i część usprawnień Single VAT Registration, ale ich wpływ technologiczny jest relatywnie ograniczony w porównaniu z następnym etapem. Kluczowa zmiana systemowa zaczyna się 1 lipca 2028 roku. Wtedy mają wejść główne elementy SVR, w tym rozszerzenie OSS, odrębny moduł OSS dla transferów własnych towarów, czyli Transfer of Own Goods, oraz obowiązkowy reverse charge w określonych sytuacjach, gdy dostawca nie jest zidentyfikowany do VAT w państwie opodatkowania.

Kolejny duży moment przypada na 1 lipca 2030 roku. Od tej daty dla określonych transgranicznych transakcji B2B w UE zaczną obowiązywać zharmonizowane cyfrowe wymogi raportowania, czyli DRR, oparte na e-fakturowaniu. To ważna zmiana, ponieważ ciężar przesunie się jeszcze bardziej w stronę danych transakcyjnych dostępnych w sposób strukturalny i gotowy do szybkiego raportowania. Następny istotny termin to 1 stycznia 2035 roku. Do tego czasu istniejące krajowe systemy cyfrowego raportowania transakcyjnego objęte przepisami ViDA mają zostać dostosowane do unijnego modelu i standardów. Formalny harmonogram zawiera również inne daty, ale dla przedsiębiorcy budującego roadmapę technologiczną najważniejsze jest zrozumienie samej sekwencji: po stosunkowo niewielkich zmianach w 2027 roku następuje znacznie poważniejszy etap w 2028 roku, a później przejście do bardziej zharmonizowanego raportowania transakcyjnego od 2030 roku.

To właśnie dlatego roadmapa technologiczna na 2027 rok nie powinna być projektowana wyłącznie wokół obowiązków przypadających na ten konkretny rok. Jeśli firma potraktuje każde kolejne wymaganie jako osobny projekt, może szybko zbudować architekturę złożoną z wielu nakładających się integracji, wyjątków i ręcznych procesów. W 2027 roku stosunkowo mały wpływ zmian na systemy może wręcz tworzyć fałszywe poczucie, że ViDA nie wymaga jeszcze większych inwestycji technologicznych. Tymczasem właśnie wtedy jest najlepszy moment, żeby uporządkować model danych i zależności między sprzedażą, fakturą, płatnością, magazynem i logistyką, zanim pojawi się presja związana z kolejnymi terminami. Nie chodzi o to, żeby już dziś implementować wszystkie rozwiązania przewidziane na 2030 rok, ale żeby nie budować systemów w sposób, który za dwa lub trzy lata utrudni ich dostosowanie do nowych wymogów.

W praktyce architektura rozwijana w 2027 roku powinna być na tyle elastyczna, aby obsłużyć kilka kolejnych fal zmian bez konieczności przebudowy podstawowych procesów sprzedażowych. To oznacza między innymi możliwość oddzielenia reguł VAT od kanału sprzedaży, korzystania ze wspólnego modelu danych przy różnych formatach e-fakturowania, przechowywania historii decyzji podatkowych i łączenia danych o sprzedaży z ruchem towaru. Ponownie, nie są to obowiązki sformułowane wprost w ViDA, ale wnioski architektoniczne wynikające z kierunku reformy. Jeżeli firma planuje w tym samym czasie ekspansję do kolejnych państw UE, nowe magazyny albo rozwój sprzedaży B2B, takie podejście staje się jeszcze ważniejsze. Zamiast pytać, jaki pojedynczy system trzeba wdrożyć pod ViDA, lepiej zapytać, czy dane i integracje projektowane w 2027 roku będą nadal użyteczne po 1 lipca 2028 roku i po 1 lipca 2030 roku.

Czy ViDA w ogóle jest „dla mnie”?

ViDA powinno być wysoko na Twojej roadmapie, jeśli…

ViDA powinno znaleźć się wysoko na roadmapie technologicznej przede wszystkim wtedy, gdy Twój e-commerce przestał być biznesem działającym w jednym kraju i jednym modelu operacyjnym. Jeżeli sprzedajesz do klientów w kilku państwach UE, korzystasz z OSS lub IOSS, przechowujesz towar w zagranicznych magazynach albo łączysz sprzedaż własną z marketplace’ami i zewnętrznym fulfillmentem, liczba zależności podatkowych szybko rośnie. Sam marketplace nie oznacza przy tym, że sprzedawcę towarów obejmują nowe zasady ViDA dotyczące gospodarki platformowej. Jego znaczenie w tym kontekście jest bardziej praktyczne: kolejny kanał sprzedaży lub operator logistyczny może dodatkowo rozproszyć dane o zamówieniu, kliencie i przepływie towaru. Znaczenie ma już nie tylko kraj klienta, ale również miejsce rozpoczęcia i zakończenia transportu, lokalizacja zapasu, status odbiorcy, właściwy numer VAT, używana procedura oraz sposób udokumentowania transakcji. Jeszcze większa złożoność pojawia się wtedy, gdy firma obsługuje jednocześnie B2C i B2B. Dwa zamówienia na ten sam produkt wysłane z tego samego magazynu mogą wymagać innej kwalifikacji podatkowej, innych danych i innego sposobu raportowania.

Szczególnie wyraźnym sygnałem, że temat powinien stać się priorytetem, jest rozproszenie informacji pomiędzy wieloma systemami. Jeżeli system sprzedażowy przechowuje zamówienie, rozwiązanie fakturowe wystawia dokument, operator płatności zna przebieg płatności, a informacje o wysyłce i magazynie znajdują się jeszcze gdzie indziej, problemem nie jest sama liczba narzędzi. Problem zaczyna się wtedy, gdy nie można szybko i jednoznacznie połączyć danych potrzebnych do wyjaśnienia rozliczenia. Jeśli przy korekcie, kontroli albo zamknięciu okresu trzeba ręcznie ustalać, z którego magazynu wyszedł towar, jaki status miał klient w chwili transakcji, której rejestracji VAT użyto i na jakiej podstawie zastosowano określoną procedurę, firma ma już technologiczny dług w obszarze VAT. ViDA może ten dług uwidocznić, ponieważ kolejne etapy reformy przesuwają rozliczenia w stronę danych bardziej ustrukturyzowanych, spójnych i dostępnych szybciej niż w tradycyjnym modelu opartym głównie na okresowym raportowaniu.

Kiedy presja może być mniejsza?

Presja związana z ViDA może być mniejsza w firmie, która prowadzi sprzedaż wyłącznie krajową, nie utrzymuje zapasu poza Polską i nie realizuje transgranicznych transakcji B2B ani B2C. Taki przedsiębiorca nie będzie w takim samym stopniu wystawiony na zmiany dotyczące OSS, IOSS, transferów własnych towarów czy przyszłego unijnego raportowania transgranicznego B2B. Jeżeli cały przepływ towaru zaczyna się i kończy w Polsce, a model sprzedaży jest stosunkowo prosty, część problemów charakterystycznych dla rozwijającego się e-commerce międzynarodowego po prostu się nie pojawia. Nie oznacza to jednak braku projektów cyfrowych w VAT. Dla polskiego przedsiębiorcy niezależnie od ViDA trzeba uwzględnić także krajowe obowiązki, przede wszystkim KSeF. Mniejsza ekspozycja na poszczególne elementy ViDA nie jest więc równoznaczna z możliwością odłożenia cyfryzacji procesów podatkowych na później.

ViDA nie prowadzi też do sytuacji, w której wszystkie państwa członkowskie od jednego dnia działają według identycznego modelu. Krajowe systemy e-fakturowania i cyfrowego raportowania mogą funkcjonować i rozwijać się jeszcze przed pełnym uruchomieniem unijnych DRR w 2030 roku. Dla firmy działającej obecnie wyłącznie w Polsce ma to jeszcze jeden praktyczny wymiar: ekspansja może zmienić jej model VAT znacznie szybciej niż technologię. Uruchomienie sprzedaży do nowych państw, otwarcie zagranicznego magazynu albo wejście mocniej w B2B może w ciągu kilku miesięcy dołożyć nowe procedury, rejestracje i źródła danych. Jeśli takie działania są już elementem strategii wzrostu, warto przygotować podstawy wcześniej, zamiast po uruchomieniu nowego rynku odkrywać, że systemy nie przechowują informacji potrzebnych do prawidłowej kwalifikacji i późniejszego odtworzenia transakcji.

Co naprawdę powinno znaleźć się w roadmapie technologicznej na 2027?

Centralny model danych VAT: jedna spójna historia transakcji

Najważniejsze pytanie, jakie warto postawić zespołom technologicznym i finansowym, brzmi: czy potrafisz odtworzyć podatkową historię jednej transakcji od checkoutu do deklaracji? Nie chodzi o możliwość znalezienia samej faktury albo sprawdzenia stawki VAT przypisanej do zamówienia. Pełna historia powinna pozwalać ustalić, jakie zamówienie było źródłem transakcji, jakie dokumenty zostały wystawione i później skorygowane, gdzie rozpoczął i zakończył się transport towaru, z jakiego magazynu zrealizowano sprzedaż, jaki status miał klient oraz jaki numer VAT został użyty. W przypadku B2B warto przechowywać nie tylko sam VAT ID, ale również moment jego weryfikacji i rezultat tej weryfikacji. Do tego dochodzą informacje o właściwej rejestracji VAT sprzedawcy, zastosowanej procedurze, podstawie opodatkowania oraz danych logistycznych potrzebnych do potwierdzenia okoliczności dostawy. Dane o płatności mogą być dodatkowo przydatne przy uzgodnieniach i korektach, ale nie należy traktować ich jako uniwersalnego rdzenia przyszłego raportowania DRR.

W wielu rosnących e-commerce’ach takie informacje już istnieją, ale są rozproszone. ERP może pozostawać właściwym źródłem danych księgowych, WMS źródłem informacji o ruchu magazynowym, system sprzedażowy źródłem danych o zamówieniu, a kolejne narzędzia mogą odpowiadać za fakturę, płatność lub transport. Celem nie musi więc być budowa jednej wielkiej bazy, do której zostanie przeniesione wszystko. Znacznie ważniejsze jest stworzenie wspólnego modelu, w którym wiadomo, jak poszczególne dane są ze sobą powiązane, który system jest źródłem konkretnej informacji i jak odtworzyć kompletną historię transakcji niezależnie od kanału sprzedaży. Połączenie tych danych daje firmie możliwość odtworzenia i zweryfikowania podatkowej historii transakcji, nawet jeżeli jej elementy fizycznie pozostają w różnych systemach. W roadmapie na 2027 rok warto więc potraktować jako osobny projekt uporządkowanie identyfikatorów, relacji, źródeł danych i statusów pomiędzy zamówieniem, fakturą, magazynem, transportem oraz rozliczeniem podatkowym.

Nie przechowuj tylko wyniku. Przechowuj powód

Jednym z najważniejszych założeń takiego modelu jest odejście od zapisywania wyłącznie końcowego rezultatu decyzji podatkowej. Informacja, że w danej transakcji zastosowano określoną stawkę VAT, jest potrzebna, ale sama nie wyjaśnia, dlaczego system wybrał właśnie taki sposób rozliczenia. Dla późniejszego audytu, korekty albo analizy dużo bardziej użyteczne jest zachowanie przesłanek decyzji. System powinien więc pozwalać ustalić, z jakiego państwa wysłano towar, gdzie zakończył się transport, jaki status miał klient, jaki numer VAT został użyty i jaki był wynik jego weryfikacji, z jakiej procedury skorzystano oraz które rejestracje sprzedawcy miały znaczenie dla danej sprzedaży. W ten sposób firma nie przechowuje jedynie wyniku w rodzaju „VAT 19%”, ale również kontekst, który doprowadził do takiego wyniku. Przy rosnącej liczbie rynków jest to znacznie bardziej odporne rozwiązanie niż poleganie na pojedynczym kodzie podatkowym zapisanym na dokumencie.

Warto przechowywać także wersję reguły, która została zastosowana w chwili transakcji. Ta sama kombinacja danych wejściowych może prowadzić do innego wyniku podatkowego dla transakcji dokonanej w innym okresie, jeśli w międzyczasie zmienią się przepisy lub zasady konfiguracji systemu. Bez informacji o wersji reguły po kilku latach trudno może być ustalić, czy historyczne rozliczenie odpowiadało zasadom obowiązującym w momencie sprzedaży. Taka informacja jest szczególnie cenna przy korektach, audytach oraz ponownym odtwarzaniu sposobu rozliczenia historycznej transakcji. Z technologicznego punktu widzenia różnica jest zasadnicza: zamiast systemu, który potrafi powiedzieć jedynie „jaki VAT zastosowano”, powstaje model, który pozwala również odpowiedzieć „dlaczego zastosowano właśnie taki VAT i według jakich zasad obowiązujących w tamtym czasie”.

Effective dating: reguła musi mieć nie tylko wersję, ale również okres obowiązywania

Samo wersjonowanie reguł nie wystarczy, jeśli system nie wie, od kiedy dana wersja powinna być stosowana. Dlatego w modelu danych warto uwzględnić effective dating, czyli przypisanie regułom okresów obowiązywania. Dla każdej istotnej zasady system powinien potrafić określić, od jakiej daty obowiązywała, do jakiej daty była właściwa oraz według jakiego stanu prawnego należy oceniać transakcję. Ma to szczególne znaczenie przy ViDA, ponieważ reforma jest wdrażana etapami, a kolejne zmiany przypadają między innymi na 1 stycznia 2027 roku, 1 lipca 2028 roku i 1 lipca 2030 roku. Firma nie będzie więc funkcjonowała w jednym stabilnym modelu, który pewnego dnia zostanie zastąpiony nowym. Przez kilka lat poszczególne elementy procesu będą zmieniały się w różnych terminach, a system musi umieć poprawnie przypisać transakcję do zasad obowiązujących właśnie wtedy.

Praktyczny problem pojawia się przy korektach wykonywanych długo po pierwotnej sprzedaży. Jeśli silnik podatkowy zna wyłącznie aktualną konfigurację, może być trudno odtworzyć sposób, w jaki transakcja powinna była zostać oceniona w chwili jej powstania. Effective dating pozwala oddzielić moment przetwarzania danych od momentu, którego dotyczą. Dzięki temu system może zachować historię zmian bez nadpisywania wcześniejszej logiki i umożliwiać odtworzenie rozliczenia według właściwego stanu prawnego. Dla przedsiębiorcy oznacza to mniejsze ryzyko, że każda większa zmiana regulacyjna będzie wymagała tworzenia wyjątków w kodzie albo ręcznego rekonstruowania dawnych zasad. W roadmapie na 2027 rok warto więc myśleć nie tylko o tym, jakie reguły VAT system ma obsługiwać, ale również kiedy każda z nich ma obowiązywać.

Fakturowanie data-first: PDF przestaje być dobrym centrum architektury fakturowania

Przez lata w wielu firmach e-commerce faktura była traktowana przede wszystkim jako dokument: coś, co trzeba wygenerować, zapisać, wysłać klientowi i przechować. Przy e-fakturowaniu i przyszłych DRR takie podejście staje się coraz mniej wystarczające. Od 1 lipca 2030 roku zharmonizowane cyfrowe wymogi raportowania dla określonych transgranicznych transakcji B2B w UE będą oparte na e-fakturach w ustrukturyzowanym formacie umożliwiającym automatyczne i elektroniczne przetwarzanie danych. Dla architektury systemów oznacza to zmianę punktu ciężkości: zamiast traktować wizualny dokument jako centralny obiekt procesu, warto budować fakturowanie wokół uporządkowanego zestawu danych. Taki model powinien zawierać informacje o sprzedawcy i nabywcy, pozycjach faktury, kwotach, stawkach, podstawach opodatkowania, walutach, datach i wymaganych identyfikatorach. Równolegle wewnętrzny model podatkowy powinien zachowywać kwalifikację transakcji i przesłanki, na których została oparta. PDF nadal może pełnić ważną funkcję użytkową i archiwalną, ale nie powinien być źródłem, z którego system próbuje później odzyskiwać dane potrzebne do automatycznego przetwarzania.

W roadmapie na 2027 rok warto więc zaplanować rozwiązanie, w którym jeden spójny wewnętrzny model faktury może być mapowany na różne formaty oraz wymagania krajowe, bez przebudowy podstawowego procesu sprzedażowego za każdym razem, gdy pojawia się nowa specyfikacja. Nie oznacza to, że wszystkie państwa będą korzystały z identycznego interfejsu czy tego samego workflow. Firma powinna natomiast potrafić obsłużyć transmisję e-faktury, korekty oraz statusy i komunikaty zwrotne wymagane przez konkretny system krajowy albo kanał wymiany. Z perspektywy audytowalności i odporności procesu warto dodatkowo zachowywać oryginalny komunikat strukturalny, identyfikator transmisji, moment wysyłki, odpowiedź systemu zewnętrznego i historię statusów. Do tego dochodzą mechanizmy stricte techniczne: kolejki, ponawianie transmisji, monitoring oraz idempotencja, która przy błędzie lub timeoutcie pomaga uniknąć niezamierzonego ponownego wysłania albo utworzenia duplikatu tego samego dokumentu.

Najczęstszy błąd

Typowa reakcja na nowe wymagania dotyczące e-faktur brzmi: „dodamy generator odpowiedniego formatu, kiedy będzie trzeba”. To podejście jest kuszące, ponieważ sprowadza problem do dobrze znanego zadania integracyjnego. Firma ma dane w obecnych systemach, więc wystarczy zbudować moduł, który zamieni je na wymagany komunikat. Problem polega na tym, że generator nie naprawi brakujących, niespójnych albo historycznie nieudokumentowanych informacji. Jeżeli w systemach źródłowych nie ma jednoznacznego kraju rozpoczęcia transportu, statusu nabywcy właściwego dla momentu transakcji, odpowiedniego numeru VAT sprzedawcy albo prawidłowego powiązania pomiędzy dokumentem pierwotnym i korektą, nowy format jedynie przeniesie te problemy dalej. Podobnie jest z VAT ID nabywcy. Sam zapisany numer nie mówi jeszcze, czy i kiedy został zweryfikowany, dlatego przy transakcjach B2B dużo bardziej użyteczne jest przechowywanie numeru wraz z wynikiem i momentem weryfikacji.

Projekt e-fakturowania powinien więc zaczynać się nie od pytania „jaki format będziemy generować?”, ale od sprawdzenia, czy wszystkie dane potrzebne do prawidłowego wystawienia dokumentu i jego podatkowej kwalifikacji są kompletne, jednoznaczne i dostępne we właściwym momencie procesu. Kraj rozpoczęcia transportu może być na przykład kluczowy dla ustalenia sposobu opodatkowania, nawet jeśli nie jest obowiązkowym polem każdej e-faktury. To pokazuje, dlaczego trzeba rozróżnić strukturę samego dokumentu od szerszego modelu danych podatkowych. Jeżeli oba są dobrze uporządkowane, przejście na kolejny format krajowy staje się przede wszystkim problemem mapowania i integracji. Jeżeli podstawowe dane są niespójne, każdy nowy rynek tworzy kolejną warstwę wyjątków. Wtedy koszt e-fakturowania rośnie nie dlatego, że struktury techniczne są szczególnie trudne, lecz dlatego, że firma próbuje rozwiązać na etapie generowania dokumentu problemy, które powstały wcześniej w checkoutcie, katalogu produktów, logistyce albo systemach finansowych.

Oddziel logikę VAT od checkoutu, ERP i kanałów sprzedaży

W wielu e-commerce’ach logika podatkowa powstawała etapami razem z rozwojem firmy. Część reguł działa w checkoutcie, część w ERP, inne w systemie fakturowym, a jeszcze inne są skonfigurowane osobno dla poszczególnych kanałów sprzedaży. Przy niewielkiej liczbie rynków taki układ może funkcjonować przez lata, ale wraz z ekspansją rośnie liczba miejsc, w których ta sama decyzja podatkowa jest podejmowana albo powielana. Dlatego w roadmapie technologicznej na 2027 warto rozważyć wydzielenie niezależnej warstwy VAT decisioning, która na podstawie danych wejściowych określa sposób podatkowego potraktowania transakcji. Nie musi to oznaczać zakupu jednego centralnego narzędzia ani przeniesienia całej wiedzy podatkowej do jednej aplikacji. Chodzi przede wszystkim o zasadę architektoniczną: ta sama transakcja powinna podlegać tej samej logice kwalifikacji niezależnie od tego, czy pochodzi ze sklepu własnego, marketplace’u, kanału B2B czy innego systemu sprzedażowego.

W takiej warstwie warto rozdzielić dwa blisko powiązane, ale nieidentyczne problemy. Pierwszy to tax determination, czyli ustalenie, gdzie i według jakiego mechanizmu dana transakcja podlega VAT: jaka jest właściwa jurysdykcja, jaki jest typ transakcji, jaki podmiot i rejestracja VAT sprzedawcy powinny zostać użyte oraz jaka procedura znajduje zastosowanie. Drugi to tax content lub rate determination, czyli ustalenie, jaka stawka wynika z klasyfikacji konkretnego produktu lub usługi w danym kraju. Przy kilkuset lub kilku tysiącach SKU klasyfikacja produktowa może wymagać osobnego modelu danych i własnego procesu utrzymania. Dopiero połączenie obu warstw pozwala wyznaczyć stawkę, podstawę opodatkowania oraz dane potrzebne na fakturze i w raportowaniu. Warto jednocześnie zapisywać zastosowaną regułę, jej wersję i okres obowiązywania, czyli effective dating, aby decyzję można było później odtworzyć zgodnie z zasadami obowiązującymi w momencie transakcji.

Dlaczego to ma znaczenie biznesowe?

Oddzielenie logiki VAT od systemów operacyjnych ogranicza koszt i ryzyko kolejnych zmian regulacyjnych oraz rozwojowych. Jeżeli ta sama reguła jest zaszyta niezależnie w checkoutcie, ERP, module fakturowym i kilku integracjach kanałowych, każda zmiana wymaga ustalenia, gdzie znajduje się jej kolejna implementacja, kto odpowiada za jej aktualizację i czy wszystkie systemy zaczną stosować nowe zasady w tym samym momencie. Przy modelu, w którym warstwa decyzyjna jest wydzielona, sama logika kwalifikacji podatkowej może zostać zmieniona centralnie i udostępniona pozostałym systemom jako spójny wynik. Nie eliminuje to zmian wymaganych w innych komponentach, ponieważ nowy przepis może wymagać dodatkowego pola w checkoutcie, innej struktury faktury, nowych danych wejściowych albo zmian raportowania. Ogranicza jednak ryzyko utrzymywania kilku niezależnych implementacji tej samej reguły podatkowej i wynikających z tego rozbieżności.

Z perspektywy przedsiębiorcy korzyść staje się szczególnie widoczna w momencie wejścia na kolejny rynek, uruchomienia nowego magazynu albo rozwoju sprzedaży B2B. W dobrze zaprojektowanym modelu nowy kanał nie powinien odtwarzać całej logiki VAT od początku. Powinien dostarczyć warstwie decyzyjnej odpowiednie dane wejściowe, a następnie wykorzystać wynik w procesie cenowym, fakturowaniu i dalszym raportowaniu. Dotyczy to również wyboru właściwej rejestracji VAT sprzedawcy, ponieważ firma może równolegle posiadać lokalne numery wynikające chociażby z magazynowania towaru i jednocześnie korzystać z procedur takich jak OSS dla innych transakcji. ViDA nie nakazuje budowy osobnego silnika podatkowego, ale wieloetapowy charakter zmian sprawia, że centralizacja logiki, jej wersjonowanie i effective dating są rozsądnym sposobem na ograniczenie kosztu przyszłych dostosowań. Im więcej rynków, magazynów, kanałów i kategorii produktowych obsługuje firma, tym większą wartość ma możliwość zmiany zasad bez szukania tej samej logiki w kilku niezależnych systemach.

OSS i IOSS: 2027 to nie rok na kosmetyczną aktualizację

Zmiany przypadające na 1 stycznia 2027 roku mają według Komisji relatywnie niewielki wpływ na systemy IT, ale dla e-commerce sam 2027 może być znacznie ważniejszy jako rok przygotowania danych i logiki przed głównymi reformami Single VAT Registration z 1 lipca 2028 roku. W 2027 pojawiają się przede wszystkim doprecyzowania dotyczące OSS i IOSS, a w określonych modelach również rozszerzenie OSS, między innymi na wybrane dostawy B2C związane z e-chargingiem. Dla typowego sprzedawcy internetowego większe znaczenie może mieć jednak uporządkowanie sposobu, w jaki obecny system kwalifikuje transakcje. Szczególną uwagę warto zwrócić na sposób obliczania unijnego progu 10 000 euro dotyczącego wewnątrzwspólnotowej sprzedaży towarów na odległość. Od 2027 roku jeszcze istotniejsze staje się prawidłowe rozróżnienie sprzedaży wysyłanej z państwa członkowskiego, w którym przedsiębiorca jest ustanowiony, od sprzedaży realizowanej z zapasu znajdującego się w innym państwie UE. Przy kilku magazynach sama kombinacja kraju klienta i produktu nie wystarcza. System musi znać również rzeczywisty kraj rozpoczęcia wysyłki.

Ten sam audyt warto rozszerzyć na procedury OSS i IOSS oraz lokalne rejestracje VAT, które nie powinny być traktowane wyłącznie jako aktualna konfiguracja firmy. System powinien wiedzieć, w jakim okresie przedsiębiorca korzystał z określonej procedury, jaka rejestracja była właściwa dla danej transakcji i od kiedy obowiązywał konkretny status. Ma to szczególne znaczenie dla IOSS, gdzie okres ważności danych identyfikacyjnych jest istotny również w procesie importowym. Podobnie należy podejść do korekt: system powinien zachowywać powiązanie korekty z pierwotną transakcją i okresem rozliczeniowym, którego dotyczy, a następnie stosować zasady właściwe dla danego rodzaju korekty. W przypadku IOSS warto również wprowadzić operacyjny punkt kontroli kompletności danych jeszcze przed przekazaniem zamówienia do dalszej obsługi logistycznej. Nie jest to nowy obowiązek powstający dopiero w 2027 roku, lecz dobra praktyka end-to-end, której znaczenie rośnie wraz ze wzmacnianiem mechanizmów kontroli IOSS i powiązania danych sprzedażowych z importem.

W praktyce backlog na 2027 rok powinien więc obejmować także uzgadnianie całego procesu od zamówienia do rozliczenia. Zamówienie, faktura, płatność, deklaracja i dane logistyczne nie muszą znajdować się w jednym systemie, ale firma powinna być w stanie wykazać ich wzajemne powiązania. Płatność nie jest centralnym elementem każdego obowiązku wynikającego z ViDA i nie powinna być przedstawiana jako taki, jednak w procesach operacyjnych pomaga wykrywać różnice pomiędzy sprzedażą, wystawionymi dokumentami i późniejszym rozliczeniem. Im więcej rynków, walut, magazynów i kanałów obsługuje firma, tym większa wartość takich automatycznych uzgodnień. Celem nie jest stworzenie kolejnego raportu do ręcznej kontroli, lecz możliwość wykrycia sytuacji, w której na przykład sprzedaż znalazła się w systemie zamówień, ale zabrakło jej w odpowiedniej deklaracji albo dane logistyczne wskazują inne miejsce rozpoczęcia wysyłki niż to, na którym oparto kwalifikację VAT.

Projektuj identyfikowalność order-to-parcel

W przypadku e-commerce importowego szczególnie użytecznym założeniem architektonicznym jest możliwość przejścia od konkretnej pozycji zamówienia do konkretnej przesyłki, danych celnych i sposobu rozliczenia w IOSS. Nie jest to nazwany wprost wymóg ViDA dotyczący modelu danych przedsiębiorcy, lecz praktyczna odpowiedź na fakt, że IOSS łączy dwa różne procesy. Po jednej stronie znajduje się sprzedaż, pobranie VAT i deklaracja IOSS, a po drugiej konkretny import, zgłoszenie celne i przesyłka. Jeżeli zamówienie zostanie podzielone na kilka paczek, część towaru zostanie ponownie nadana albo klient zwróci tylko wybrane pozycje, system powinien nadal pozwalać ustalić, które towary były powiązane z którą przesyłką i jak zostały potraktowane podatkowo. Najbezpieczniej myśleć o tej relacji na poziomie pozycji zamówienia, a nie wyłącznie całego koszyka.

Nie oznacza to potrzeby przechowywania pełnego śladu każdego wydarzenia logistycznego. Istotniejsze jest zachowanie stabilnych relacji między danymi, które pozwolą połączyć sprzedaż z fizycznym przepływem towaru. W modelu danych warto rozróżniać między innymi kraj wysyłki, kraj przeznaczenia i kraj importu, ponieważ różne typy transakcji mogą mieć różną strukturę logistyczno-podatkową. Dla WSTO kraj rozpoczęcia i zakończenia transportu znajdują się w UE, podczas gdy w przypadku IOSS wysyłka zaczyna się typowo poza Unią, a import następuje w jednym z państw członkowskich. Dlatego order-to-parcel powinno być cechą własnego modelu danych firmy, a nie efektem ubocznym integracji z konkretnym przewoźnikiem czy operatorem fulfillmentu. Dostawców można zmieniać, natomiast zdolność do połączenia zamówienia, towaru, przesyłki i sposobu rozliczenia powinna pozostać niezależna od wybranego partnera technologicznego.

Stwórz ledger ruchów własnego towaru

Dla przedsiębiorstwa, które utrzymuje zapas w kilku państwach UE, korzysta z zewnętrznego fulfillmentu albo regularnie przesuwa towar pomiędzy magazynami, ruchy własnego zapasu powinny być traktowane jako osobny strumień danych podatkowych. Już dziś przemieszczenie własnych towarów pomiędzy państwami członkowskimi może powodować skutki VAT mimo braku sprzedaży do zewnętrznego klienta, a od 1 lipca 2028 roku ma zacząć działać nowa procedura szczególna OSS dla transferów własnych towarów, czyli Transfer of Own Goods scheme. Z tego powodu na roadmapie na 2027 warto umieścić ledger ruchów własnego towaru: spójny rejestr pozwalający ustalić, co zostało przemieszczone, przez jaki podmiot, z którego miejsca do którego i w jakim czasie. Sam fizyczny ruch nie wystarcza do prawidłowej kwalifikacji podatkowej. Trzeba również wiedzieć, kto jest właścicielem towaru i w jakich okolicznościach odbywa się transfer.

Taki ledger powinien zachowywać magazyn źródłowy i docelowy, właściciela towaru, datę wysyłki, datę przyjęcia oraz — tam, gdzie jest to potrzebne — datę właściwą dla rozliczenia VAT. Warto powiązać ruch również z dokumentami transportowymi, potwierdzeniem przyjęcia i wartością przenoszonego towaru, ponieważ przyszła procedura TOOG operuje między innymi wartością stanowiącą podstawę opodatkowania transferowanych towarów. Ważne jest również, aby sam ruch miał własny identyfikator. Jeżeli system pokazuje tylko, że w magazynie A ubyło 100 sztuk, a w magazynie B przybyło 100 sztuk, nie daje to jeszcze pewności, że oba zdarzenia dotyczą tego samego transferu ani że zachowano dane potrzebne do jego podatkowej oceny. Przy rozbudowanej sieci fulfillmentowej takie rozbieżności szybko przestają być problemem magazynowym, a zaczynają wpływać na poprawność rozliczeń.

Ledger musi też radzić sobie z sytuacjami, które nie pasują do prostego scenariusza wysyłki z punktu A do punktu B. Zwrot może trafić do innego magazynu niż ten, z którego towar pierwotnie wysłano. Część przesyłki może zostać zniszczona albo utracona, towar może pojechać do naprawy lub przepakowania, a operator logistyczny może przenieść zapas do innego centrum bez sprzedaży do klienta. Nie oznacza to, że każda taka operacja automatycznie wywołuje identyczne skutki podatkowe ani że każdy cross-border warehouse movement należy traktować jako standardowy transfer własnych towarów. Właśnie dlatego system powinien rejestrować fakty dotyczące ruchu, zamiast od razu sprowadzać każde zdarzenie do jednego kodu podatkowego. Dopiero wiarygodne dane o właścicielu, celu ruchu, lokalizacji, datach i okolicznościach pozwalają właściwie zakwalifikować zdarzenie i uzgodnić je później z danymi magazynowymi oraz rejestrem używanym w rozliczeniach VAT.

Dlaczego 2027, skoro ważne zmiany zaczynają się w 2028?

Nowa procedura szczególna OSS dla transferów własnych towarów ma zacząć działać 1 lipca 2028 roku, więc z czysto regulacyjnego punktu widzenia można byłoby uznać, że projekt technologiczny również może poczekać. Problem polega na tym, że wdrożenie poprawnej ewidencji ruchów nie sprowadza się do dodania jednego pola przed wejściem nowych zasad. W praktyce WMS, ERP, system fulfillmentowy i rozwiązania księgowe mogą używać różnych definicji magazynu, innych identyfikatorów transferu oraz odmiennych momentów uznawanych za wysyłkę i przyjęcie. Dane mogą się również różnić ilościowo, jeżeli w jednym systemie ruch zostanie zapisany w momencie wydania z magazynu, a w drugim dopiero po fizycznym przyjęciu. Rok 2027 daje przestrzeń na wykrycie takich problemów na rzeczywistych przepływach, zanim nowa procedura stanie się częścią bieżących rozliczeń.

Nie chodzi przy tym o konieczność raportowania w przyszłej procedurze TOOG całej wieloletniej historii wcześniejszych transferów. Wartość wcześniejszego rozpoczęcia projektu jest przede wszystkim operacyjna: firma może przez kilka kwartałów sprawdzić, czy dane są kompletne, czy transfery dają się jednoznacznie łączyć pomiędzy systemami, jak obsługiwane są wyjątki i czy wartości oraz daty pozostają spójne. Dzięki temu 1 lipca 2028 roku nie jest pierwszym dniem, w którym przedsiębiorca próbuje ustalić, jak naprawdę działa jego przepływ magazynowy. W dobrze zaprojektowanej roadmapie 2027 jest więc rokiem budowy i testowania modelu danych oraz procesu, natomiast 2028 staje się momentem wykorzystania przygotowanej infrastruktury w nowym sposobie rozliczania transferów własnych towarów.

Przygotuj B2B na DRR, zanim DRR stanie się obowiązkowe

2030 nie oznacza: zacznij w 2030. Od 1 lipca 2030 roku dla określonych transgranicznych transakcji B2B w UE zaczną obowiązywać zharmonizowane cyfrowe wymogi raportowania oparte na e-fakturowaniu. Z punktu widzenia technologii ważniejszy od samej daty jest jednak sposób, w jaki zmieni się rytm pracy z danymi. Informacje o transakcji będą musiały być dostępne w bardziej ustrukturyzowanej formie i udostępniane w modelu raportowania transakcyjnego w czasie zbliżonym do rzeczywistego, zamiast dopiero w tradycyjnym cyklu okresowego raportowania. Dlatego już w 2027 roku warto zacząć mierzyć czas od zdarzenia biznesowego istotnego dla wystawienia faktury do momentu, w którym firma posiada kompletny zestaw danych potrzebnych do poprawnego wystawienia dokumentu. Taki wewnętrzny miernik nie wynika wprost z ViDA, ale bardzo szybko pokaże, gdzie naprawdę powstają opóźnienia: czy dane kontrahenta przychodzą za późno, czy brakuje informacji logistycznych, czy może faktura czeka na ręczną decyzję finansów.

Drugim elementem powinno być uporządkowanie jakości danych B2B jeszcze przed finalizacją procesu. W transakcjach, dla których status nabywcy i ważność jego numeru VAT UE mają znaczenie dla kwalifikacji VAT, warto przechowywać nie tylko sam numer, lecz także wynik weryfikacji, moment jej wykonania i źródło sprawdzenia. Dzięki temu po kilku miesiącach można odtworzyć stan informacji, na którym system oparł decyzję podatkową. Równolegle warto przygotować kolejki zdarzeń dla najważniejszych zmian, takich jak utworzenie zamówienia, aktualizacja danych nabywcy, wystawienie faktury, korekta czy zmiana statusu transakcji, a także niezmienialny dziennik pozwalający później prześledzić historię procesu. To nie są rozwiązania wymagane przez ViDA, lecz sposoby na osiągnięcie poziomu audytowalności i szybkości potrzebnego w docelowym modelu. Wewnętrzne SLA mogą dodatkowo określać, jak szybko sprzedaż, finanse, logistyka i obsługa klienta mają dostarczyć informacje potrzebne do zamknięcia podatkowej historii transakcji.

Jak może wyglądać „próba generalna” przed 2030?

Wyobraźmy sobie polską firmę, która sprzedaje towar z magazynu w Polsce do klienta biznesowego w Czechach. Zamiast czekać na obowiązkowe DRR, przedsiębiorca może już wcześniej przeprowadzać taki proces według docelowej dyscypliny danych. Przy przyjęciu zamówienia system zapisuje dane nabywcy i jego numer VAT UE, a wynik weryfikacji numeru pozostaje zachowany wraz z datą, godziną i źródłem sprawdzenia. Warstwa podatkowa ustala charakter transakcji na podstawie kompletu przesłanek właściwych dla danej dostawy, w tym miejsca rozpoczęcia i zakończenia transportu oraz statusu kontrahenta. Gdy pojawia się moment biznesowy istotny dla wystawienia faktury, system sprawdza kompletność danych, generuje dokument z danych strukturalnych i wiąże go z zamówieniem oraz odpowiednimi informacjami logistycznymi. Jeśli później następuje korekta, pozostaje ona jednoznacznie powiązana z dokumentem pierwotnym i historią zastosowanej reguły.

Taka próba nie oznacza raportowania danych do przyszłego systemu DRR przed jego uruchomieniem ani symulowania interfejsu, którego szczegóły techniczne mogą jeszcze ewoluować. Jej celem jest sprawdzenie, czy organizacja potrafi działać w rytmie, którego od 2030 roku będzie wymagał nowy model raportowania. Firma może mierzyć, ile czasu mija od pojawienia się zdarzenia istotnego dla fakturowania do uzyskania kompletnego dokumentu, jaki procent transakcji wymaga ręcznego uzupełnienia, jak często weryfikacja VAT ID odbywa się dopiero po sprzedaży i w ilu przypadkach dane logistyczne nie zgadzają się z informacjami wykorzystanymi do kwalifikacji podatkowej. To praktyczny sposób na sprawdzenie, czy dane są gotowe wystarczająco wcześnie, aby e-faktura i późniejsze raportowanie nie zależały od miesięcznego zamknięcia księgowego. Jeżeli taki test w 2027 roku ujawni kilkanaście punktów ręcznej ingerencji, przedsiębiorca ma jeszcze czas, aby usuwać je stopniowo przed wejściem DRR.

Co stanie się, jeśli tego nie zrobisz?

Zaczniesz doklejać kolejne integracje do złego fundamentu

Najbardziej prawdopodobny problem nie polega na tym, że firma pewnego dnia całkowicie przestanie być w stanie wystawić fakturę. Znacznie częstszy scenariusz jest mniej spektakularny, ale dużo droższy w dłuższej perspektywie: każde kolejne wymaganie będzie obsługiwane osobnym projektem. Jeden kraj będzie potrzebował nowego mapowania, inny dodatkowej integracji, kolejna procedura osobnej logiki, a następny kanał sprzedaży własnego zestawu wyjątków. Jeśli każdy z tych projektów powstaje bez wspólnego modelu danych i bez uporządkowanej logiki VAT, firma zaczyna utrzymywać kilka wersji tej samej wiedzy podatkowej w różnych miejscach. Z czasem coraz trudniej ustalić, która implementacja jest właściwa, gdzie należy dokonać zmiany i czy wszystkie systemy zaczęły stosować nową regułę w tym samym momencie.

Koszt takiej architektury rośnie szczególnie szybko w czasie ekspansji. Dodanie kolejnego rynku przestaje oznaczać jedną zmianę konfiguracji, a zaczyna uruchamiać serię zależnych projektów w systemie sprzedaży, fakturowaniu, finansach i logistyce. Testy stają się trudniejsze, ponieważ trzeba sprawdzać te same scenariusze w kilku implementacjach, a wyjątki zaczynają się wzajemnie nakładać. Rośnie również zależność od konkretnych systemów, ponieważ wiedza podatkowa zostaje zaszyta bezpośrednio w ich konfiguracji. W efekcie przedsiębiorca może formalnie spełniać kolejne obowiązki, ale za każdym razem płacić coraz więcej za dostosowanie. To dokładne przeciwieństwo skalowalnej roadmapy: firma rozwija compliance, lecz równocześnie zwiększa koszt każdej następnej zmiany.

Nie będziesz wiedzieć, która wersja danych jest prawdziwa

Rozproszenie danych jest łatwe do zaakceptowania, dopóki wszystkie systemy pokazują mniej więcej to samo. Problem pojawia się w chwili, gdy zamówienie wskazuje jeden kraj wysyłki, system fakturowy ma inną wartość, a dane logistyczne pokazują jeszcze trzeci przebieg zdarzenia. Przy niewielkiej skali ktoś z zespołu finansowego może ręcznie sprawdzić dokumenty i ustalić właściwy wariant. Przy kilkudziesięciu tysiącach transakcji miesięcznie taki model szybko przestaje działać. Jeszcze trudniej jest, gdy rozbieżność wychodzi na jaw dopiero po kilku miesiącach. Wtedy trzeba ustalić nie tylko, jaka informacja jest prawidłowa obecnie, ale również jaka była dostępna w momencie, kiedy system podejmował pierwotną decyzję podatkową.

Przy korekcie albo audycie największym problemem może więc nie być brak samego raportu. Znacznie poważniejszy jest brak możliwości odtworzenia dlaczego transakcję rozliczono w określony sposób. Jeśli firma zachowała tylko końcową stawkę i dokument, ale nie ma informacji o kraju rozpoczęcia transportu, statusie klienta, wykorzystanej rejestracji VAT, wyniku weryfikacji numeru i wersji reguły, która podjęła decyzję, zespół musi rekonstruować historię z wielu źródeł. Taka rekonstrukcja jest kosztowna i podatna na błędy. ViDA nie wymaga stworzenia jednej centralnej bazy, ale im większe znaczenie zyskują strukturalne dane i szybsze raportowanie, tym mniej bezpieczny staje się model, w którym prawda o transakcji istnieje dopiero po ręcznym połączeniu kilku różnych eksportów.

Operacje magazynowe zaczną generować podatkowe niespodzianki

Dla firmy rozwijającej sieć magazynów jednym z najbardziej ryzykownych obszarów jest sytuacja, w której logistyka skaluje się szybciej niż ewidencja VAT. Nowy magazyn albo operator fulfillmentu jest często wdrażany przede wszystkim z myślą o czasie dostawy, dostępności produktów i kosztach transportu. Tymczasem przemieszczenie własnego zapasu między państwami może mieć konsekwencje podatkowe nawet wtedy, gdy nie dochodzi jeszcze do sprzedaży klientowi. Jeżeli system magazynowy rejestruje jedynie zmianę ilości, a nie pełną historię transferu, zespół finansowy może dowiedzieć się o istotnym ruchu dopiero przy uzgadnianiu miesiąca. Im więcej centrów logistycznych i operatorów, tym trudniej ręcznie rekonstruować takie zdarzenia.

Od 1 lipca 2028 roku zacznie obowiązywać nowa procedura szczególna dla transferów własnych towarów, ale jej obsługa nadal będzie zależała od jakości informacji o rzeczywistych przepływach. Bez spójnego ledgeru firma może mieć problem z połączeniem wysyłki i przyjęcia, ustaleniem właściciela towaru, wartości transferu albo rozróżnieniem zwykłego przesunięcia od sytuacji szczególnej, takiej jak naprawa, zwrot czy zniszczenie. Najgorszy moment na odkrycie takich braków to moment uruchamiania obsługi nowej procedury w środowisku produkcyjnym. Jeżeli 2027 zostanie wykorzystany do testowania procesu na bieżących ruchach magazynowych, błędy można naprawiać stopniowo. Jeśli temat zostanie odłożony, nowe zasady podatkowe mogą nałożyć się na nieuporządkowaną logistykę i stworzyć problem, którego nie da się rozwiązać jedną zmianą w konfiguracji.

E-fakturowanie stanie się projektem ratunkowym

Firma, która utożsamia przygotowanie do cyfrowego VAT z możliwością wygenerowania właściwego formatu faktury, może bardzo późno odkryć, że sam generator jest najmniejszą częścią problemu. Technicznie można stworzyć mapowanie do kolejnej struktury, ale nie można poprawnie wypełnić danych, których nie ma w systemach źródłowych. Jeśli status kontrahenta został ustalony dopiero po sprzedaży, miejsce wysyłki nie jest jednoznaczne, dokument pierwotny nie ma trwałego związku z korektą, a właściwa rejestracja VAT wynika z ręcznej wiedzy księgowego, e-fakturowanie szybko przestaje być projektem integracyjnym. Staje się projektem naprawy danych, procesów i odpowiedzialności organizacyjnej realizowanym jednocześnie pod presją ustawowego terminu.

W takim scenariuszu każda kolejna specyfikacja krajowa albo wymagany komunikat w szerszym środowisku cyfrowego VAT ujawnia następne braki. Zespół IT zaczyna dodawać walidacje na końcu procesu, finanse tworzą ręczne obejścia, a operacje poprawiają dane już po wystawieniu dokumentu. To kosztowny sposób modernizacji, ponieważ problemy pojawiają się najpóźniej, czyli w momencie, w którym ich naprawa jest najtrudniejsza. Model data-first odwraca tę logikę. Najpierw firma pilnuje jakości informacji powstających przy sprzedaży, kwalifikacji podatkowej i logistyce, a dopiero potem mapuje je do konkretnej struktury dokumentu. Jeśli tego nie zrobi wcześniej, wdrożenie e-fakturowania może ujawnić cały dotychczasowy dług danych w tym samym czasie.

Nie pozwól, żeby deadline prawny stał się również deadline’em architektonicznym

Największym zagrożeniem związanym z odkładaniem prac do 2030 roku jest kumulacja projektów, które powinny być realizowane niezależnie i znacznie wcześniej. Firma może wtedy jednocześnie próbować uporządkować model danych, poprawić jakość VAT ID, wydzielić logikę podatkową, zintegrować dane logistyczne, dostosować fakturowanie do nowych struktur i przygotować proces raportowania. Każde z tych zadań osobno jest wykonalne. Problem powstaje, gdy wszystkie zaczynają zależeć od siebie i muszą zostać wykonane pod ten sam termin. Wtedy każdy brak danych w checkoutcie blokuje fakturę, każdy problem magazynowy wpływa na kwalifikację VAT, a każda zmiana w regułach wymaga ponownego testowania kilku systemów.

Dlatego największym ryzykiem ViDA nie jest to, że firma nie wygeneruje właściwego pliku. Znacznie poważniejsze jest to, że kilka lat wcześniej nie zbuduje danych i procesów potrzebnych do wygenerowania go poprawnie. Jeżeli w 2027 roku przedsiębiorca uporządkuje model transakcji, okresy obowiązywania reguł, identyfikatory, zależności pomiędzy sprzedażą i logistyką oraz sposób powstawania faktury, późniejsze etapy pozostaną projektami dostosowawczymi. Jeżeli tego nie zrobi, 2030 pozostanie deadline’em prawnym, ale jednocześnie stanie się momentem wymuszonej modernizacji architektury VAT. A to zwykle oznacza mniej czasu na testy, więcej rozwiązań tymczasowych i większe ryzyko, że compliance będzie wdrażane kosztem bieżącej działalności oraz planów dalszej ekspansji.

Jak ustawić priorytety w roadmapie na 2027?

P1 — fundament, bez którego reszta nie działa

Najwyższy priorytet powinny dostać elementy, bez których każda kolejna zmiana będzie tylko dokładaniem następnej warstwy do istniejącego chaosu. Dlatego P1 warto zbudować wokół wspólnego modelu danych VAT, ustrukturyzowanego fakturowania, warstwy integracyjnej oraz ledgeru magazynów i transferów własnego towaru. Żaden z tych elementów nie jest wprost wymagany przez ViDA jako konkretny wzorzec architektoniczny, ale razem tworzą rozsądną odpowiedź na reformę wdrażaną etapami przez kilka lat. Wspólny model danych powinien pozwalać odtworzyć jedną spójną historię transakcji niezależnie od tego, czy dane źródłowe znajdują się w ERP, WMS, systemie sprzedażowym czy rozwiązaniu fakturowym. Fakturowanie ustrukturyzowane powinno natomiast opierać się na danych możliwych do ponownego wykorzystania i mapowania na różne wymagania krajowe, zamiast na dokumencie wizualnym będącym końcowym źródłem informacji.

Do tej samej grupy należy warstwa integracyjna, która oddziela wewnętrzny model transakcji od konkretnych systemów krajowych, kanałów wymiany i operatorów. Nie oznacza to rezygnacji z lokalnych adapterów czy mapowań, bo poszczególne państwa mogą nadal wymagać różnych implementacji technicznych. Chodzi o to, aby każda taka integracja nie stawała się osobnym systemem podatkowym z własną wersją logiki. Równie ważny jest ledger ruchów własnego towaru, szczególnie jeśli firma korzysta z kilku magazynów, fulfillmentu albo planuje dalszą ekspansję logistyczną. Bez wiarygodnych danych o tym, gdzie znajduje się towar, kto jest jego właścicielem i kiedy nastąpiło przemieszczenie, trudno przygotować się do zmian w Single VAT Registration, w tym do procedury dotyczącej transferów własnych towarów, czyli TOOG. W praktyce P1 odpowiada więc na jedno pytanie: czy firma posiada dane i integracje wystarczająco solidne, aby kolejne zmiany podatkowe dało się wdrażać na istniejącym fundamencie, a nie za każdym razem od początku.

P1 nie powinien jednak powstawać w oderwaniu od tego, co później trafi do P2. Model danych i automatyzacja decyzji podatkowych warto projektować wspólnie, nawet jeśli wdrażane są w innej kolejności. Już podczas projektowania wspólnego modelu trzeba wiedzieć, jakie decyzje VAT system będzie musiał podejmować i jakie dane będą do tego potrzebne. Jeśli zespół zbuduje najpierw „uniwersalny” model bez uwzględnienia okresów ważności rejestracji, wyników walidacji VAT ID, danych o transferach własnego towaru czy przesłanek kwalifikacji podatkowej, może szybko odkryć, że piękna architektura nie obsługuje realnych scenariuszy. Dlatego praktyczna kolejność powinna brzmieć: projektuj P1 i P2 razem, ale wdrażaj najpierw dane i integracje, a dopiero później automatyzację reguł.

P2 — automatyzacja decyzji i kontroli

Na drugim poziomie warto rozwijać bardziej zaawansowaną automatyzację logiki podatkowej. Tutaj kluczowa jest warstwa VAT decisioning, która pozwala w spójny sposób określać jurysdykcję, typ transakcji, właściwą rejestrację sprzedawcy, procedurę VAT i wynikającą z niej kwalifikację. Równie istotne jest wersjonowanie reguł wraz z okresem ich obowiązywania, czyli effective dating. Przy wieloetapowym harmonogramie zmian system nie może po prostu nadpisywać starej konfiguracji nową. Musi być w stanie odtworzyć, według jakich zasad rozliczono transakcję z poprzedniego okresu oraz prawidłowo zastosować zasady właściwe dla jej późniejszej korekty. To rozróżnienie jest ważne, ponieważ sama korekta nie zawsze polega na mechanicznym ponownym użyciu dokładnie tej samej reguły historycznej. Sposób jej ujęcia może zależeć od charakteru zmiany i zasad proceduralnych właściwych dla danego schematu.

W bardziej rozwiniętej architekturze warto też rozdzielać tax determination od ustalania stawki dla konkretnego produktu lub usługi. Pierwsza warstwa odpowiada na pytanie, gdzie i według jakiego mechanizmu transakcja podlega VAT, druga natomiast określa, jaka stawka ma zastosowanie do danego SKU w danej jurysdykcji. Przy dużym katalogu produktowym i wielu państwach te dwa problemy mogą wymagać różnych danych, właścicieli procesu i sposobu utrzymania. Do P2 warto zaliczyć również automatyczne uzgodnienia transakcji rozliczanych w OSS i IOSS oraz workflow B2B przygotowany pod przyszłe DRR. Uzgodnienia powinny wykrywać rozbieżności pomiędzy zamówieniem, fakturą, rozliczeniem i danymi logistycznymi, natomiast workflow B2B powinien pilnować jakości danych istotnych dla kwalifikacji, w tym statusu nabywcy, wyniku i czasu weryfikacji VAT ID oraz danych o przepływie towaru.

Nie oznacza to, że firma już w 2027 roku powinna symulować finalny mechanizm DRR. Szczegóły techniczne wdrożenia nadal są rozwijane, więc budowanie systemu pod hipotetyczny przyszły interfejs byłoby ryzykowne. Znacznie ważniejsze jest przygotowanie organizacji do pracy na danych dostępnych wystarczająco wcześnie, spójnych między systemami i możliwych do automatycznej kwalifikacji. P2 ma więc zamienić fundament z P1 w proces, który potrafi podejmować i kontrolować decyzje w sposób powtarzalny. Nie chodzi o automatyzację dla samej automatyzacji, ale o ograniczenie liczby sytuacji, w których identyczna transakcja jest interpretowana inaczej w zależności od kanału sprzedaży albo systemu, który akurat ją przetwarza.

P3 — obserwowalność compliance

Trzeci poziom to obserwowalność, czyli zdolność do szybkiego zauważenia, że dane albo decyzje zaczynają odbiegać od oczekiwanego modelu. W wielu firmach problemy podatkowe stają się widoczne dopiero przy zamknięciu miesiąca, przygotowaniu deklaracji albo korekcie. Przy większej skali jest to zbyt późny moment, dlatego warto zbudować dashboard pokazujący braki danych, opóźnienia i błędy według kraju, kanału sprzedaży, magazynu czy typu transakcji. Taki widok powinien odpowiadać na pytania operacyjne: ile transakcji B2B wymagających weryfikacji VAT ID nie ma udokumentowanego wyniku tej weryfikacji, w ilu przypadkach brakuje informacji o miejscu rozpoczęcia wysyłki tam, gdzie wpływa ono na kwalifikację VAT, które magazyny generują najwięcej rozbieżności oraz jaki odsetek faktur wymaga ręcznego uzupełnienia danych.

Do tego dochodzą alerty jakości danych i monitoring opóźnień oparty na wewnętrznych SLA. Jeżeli firma zakłada, że określony zestaw danych powinien być kompletny w ciągu kilku godzin od konkretnego zdarzenia biznesowego, system może sygnalizować brak zanim problem dotrze do e-faktury albo deklaracji. Taki czas nie jest terminem wynikającym z ViDA, lecz wewnętrznym miernikiem gotowości procesu. P3 nie naprawi złego modelu danych i nie zastąpi prawidłowej logiki podatkowej, dlatego nie powinien być realizowany przed P1 i P2. Jest jednak warstwą, która pozwala zobaczyć, czy wcześniejsze inwestycje rzeczywiście działają w produkcji. Dla zarządu ma to dodatkową wartość: zamiast ogólnego komunikatu, że „compliance działa”, można zobaczyć mierzalne wskaźniki jakości i ocenić, które rynki, magazyny albo kanały tworzą największe ryzyko przed kolejną falą ekspansji.

Czego nie wpisywać do roadmapy jako „rozwiązania ViDA”

Pierwszym błędem jest potraktowanie ViDA jako serii niezależnych projektów krajowych. Poszczególne państwa mogą rzeczywiście wymagać innych integracji, adapterów i mapowań, dlatego nie da się uniknąć lokalnych komponentów. Problem zaczyna się dopiero wtedy, gdy każdy z nich powstaje jako osobny system podatkowy z własnym modelem danych i własną wersją reguł. Taka architektura pozwala szybko „zamknąć” jeden rynek, ale później podnosi koszt każdej kolejnej zmiany. Znacznie bezpieczniejszym modelem jest wspólna warstwa danych i podatkowej kwalifikacji, nad którą działają lokalne adaptery dopasowane do konkretnych wymagań. Dzięki temu różnice krajowe pozostają tam, gdzie rzeczywiście są potrzebne, zamiast przenikać do checkoutu, ERP, fakturowania i logistyki.

Drugim fałszywym rozwiązaniem jest sam generator docelowego formatu e-faktury, niezależnie od tego, czy będzie to XML czy inna struktura. Poprawny technicznie komunikat nie oznacza jeszcze poprawnej kwalifikacji VAT. Jeśli dane źródłowe są niepełne, status kontrahenta nie został właściwie zapisany, kraj wysyłki jest niejednoznaczny, a korekta nie ma trwałego związku z dokumentem pierwotnym, sam format jedynie przeniesie te problemy dalej. Dlatego warto rozdzielić zgodność syntaktyczną od poprawności biznesowej i podatkowej. System może wygenerować dokument zgodny ze schematem, który mimo to zawiera nieprawidłowe dane albo opiera się na błędnej kwalifikacji. Najpierw musi istnieć spójny model danych i proces, który dostarcza właściwe informacje we właściwym momencie. Dopiero potem format staje się problemem integracyjnym.

Trzecim błędem jest założenie, że marketplace albo operator fulfillmentu dostarczy kompletny zestaw informacji potrzebnych do rozliczeń VAT. Zewnętrzny kanał może być bardzo dobrym źródłem części danych, a w określonych modelach platforma może również przejmować część obowiązków podatkowych. Firma nadal musi jednak wiedzieć, za które elementy kwalifikacji i dokumentacji sama odpowiada oraz jakie dane powinna zachować także wtedy, gdy część obowiązków realizuje platforma. Marketplace może znać zamówienie, operator logistyczny ruch przesyłki, a WMS lokalizację zapasu, lecz żaden z tych systemów nie musi zawierać całej historii potrzebnej przedsiębiorcy do własnych rozliczeń. Jeśli relacje pomiędzy danymi istnieją tylko wewnątrz konkretnego kanału lub integracji, zmiana partnera może oznaczać utratę istotnego fragmentu kontekstu.

Nie warto również odkładać danych magazynowych na 2028 rok tylko dlatego, że wtedy zaczyna się główny etap zmian Single VAT Registration związany z transferami własnych towarów. Wdrożenie prawidłowego ledgeru wymaga wcześniejszego sprawdzenia, czy WMS, ERP i system fulfillmentowy używają zgodnych identyfikatorów, dat i definicji transferu. Rok 2027 daje możliwość przetestowania tego na rzeczywistych ruchach bez presji nowego procesu rozliczeniowego. Podobnie błędne byłoby założenie, że europejska harmonizacja usunie wszystkie lokalne różnice i za kilka lat wystarczy jeden format albo jeden wspólny interfejs. ViDA wyznacza wspólny kierunek, ale przez długi czas firmy będą działać w środowisku, w którym krajowe systemy e-fakturowania i raportowania współistnieją z kolejnymi etapami unijnych zmian. Dlatego najbezpieczniejszym celem nie jest architektura „pod jeden format UE”, lecz architektura odporna na różnice: wspólny model danych, konfigurowalne mapowania, wersjonowane reguły i integracje, które można zmieniać bez przebudowy całego procesu.

Checklista CTO / Head of E-commerce: co powinno być gotowe do końca 2027?

Na koniec warto sprowadzić całą roadmapę do kilku pytań kontrolnych. Nie chodzi o to, żeby do 31 grudnia 2027 roku mieć wdrożone wszystkie rozwiązania potrzebne na 2030 rok. 31 grudnia 2027 roku nie jest terminem regulacyjnym wynikającym z ViDA — to proponowany punkt kontrolny roadmapy technologicznej przed głównymi zmianami przypadającymi na 2028 i 2030 rok. Dobra checklista powinna więc badać nie tylko zgodność techniczną, ale także jakość danych, audytowalność decyzji VAT, odporność integracji i zdolność organizacji do szybkiego reagowania na zmiany. Jeśli na kilka z poniższych pytań odpowiedź brzmi dziś „nie wiemy” albo „zależy od systemu”, to właśnie tam najprawdopodobniej znajduje się najważniejszy backlog na 2027 rok.

• Czy mamy spójny model danych VAT, który pozwala odtworzyć pełną historię transakcji, nawet jeśli dane źródłowe pozostają w kilku różnych systemach?
• Czy dla każdej transakcji potrafimy odtworzyć przesłanki istotne dla jej kwalifikacji VAT, takie jak — zależnie od przypadku — miejsce rozpoczęcia i zakończenia transportu, status nabywcy, właściwa rejestracja sprzedawcy, zastosowana procedura, wersja reguły i okres jej obowiązywania?
• Czy faktura powstaje z danych ustrukturyzowanych, a nie z dokumentu wizualnego będącego głównym źródłem informacji?
• Czy logika VAT jest możliwie niezależna od konkretnego kanału sprzedaży, tak aby transakcja nie była kwalifikowana inaczej wyłącznie z powodu odmiennej implementacji tej samej logiki w danym kanale?
• Czy potrafimy odtworzyć historyczny stan rejestracji i procedur VAT, w tym okres, w którym dana lokalna rejestracja, procedura OSS lub IOSS albo inny sposób rozliczenia były właściwe dla określonych transakcji?
• Czy potrafimy śledzić ruch własnego towaru między magazynami, łącznie z właścicielem towaru, datami wysyłki i przyjęcia, wartością oraz wyjątkami w rodzaju zwrotu, zniszczenia czy naprawy?
• Czy potrafimy regularnie uzgadniać transakcje rozliczane w OSS i IOSS z zamówieniami, fakturami, danymi logistycznymi i — tam, gdzie ma to znaczenie operacyjne — płatnościami?
• Czy w transakcjach B2B, dla których ważność VAT ID wpływa na kwalifikację VAT, przechowujemy numer, wynik weryfikacji, moment sprawdzenia i źródło tej weryfikacji?
• Czy mierzymy czas od zdarzenia biznesowego istotnego dla fakturowania do momentu, w którym firma posiada kompletny zestaw danych pozwalający wystawić poprawną fakturę?
• Czy integracje z systemami zewnętrznymi są odporne na błędy, timeouty i czasową niedostępność, a ponowienie transmisji nie powoduje niezamierzonych duplikatów?
• Czy potrafimy dostosować mapowanie faktury lub raportowania do nowych wymagań bez przebudowy całego procesu sprzedażowego, podatkowego i logistycznego?

Jeśli odpowiedź na większość tych pytań jest twierdząca, firma nie musi mieć jeszcze gotowego „systemu pod ViDA”, żeby być dobrze przygotowaną. Znacznie ważniejsze jest to, że posiada już mechanizmy pozwalające wdrażać kolejne zmiany bez utraty kontroli nad danymi. Jeśli natomiast możliwość odtworzenia tych informacji zależy od wiedzy pojedynczych osób, ręcznych eksportów, arkuszy albo wyjątków zaszytych w kilku aplikacjach, warto potraktować to jako sygnał ostrzegawczy. W 2027 roku największą wartość daje nie perfekcyjna automatyzacja każdego możliwego scenariusza, lecz usunięcie miejsc, w których firma nie potrafi jednoznacznie odpowiedzieć, skąd pochodzi dana podatkowa, dlaczego zastosowano określoną regułę, jaki stan rejestracji obowiązywał w momencie transakcji i jak informacja przechodzi od sprzedaży do faktury oraz rozliczenia.

Podsumowanie: w 2027 budujesz nie „ViDA compliance”, ale zdolność do zmian

Najważniejszy wniosek z całej roadmapy jest prosty: 2027 powinien być rokiem porządkowania danych i architektury, od 1 lipca 2028 roku fundament ten będzie potrzebny przy głównych zmianach Single VAT Registration, w tym procedurze dla transferów własnych towarów, a od 1 lipca 2030 roku przy uruchomieniu DRR dla objętych nimi transgranicznych transakcji B2B. Nie oznacza to budowania już dziś kompletnego rozwiązania pod wszystkie wymagania, które zaczną obowiązywać później. Chodzi o coś bardziej praktycznego: systemy rozwijane teraz nie powinny utrudniać wdrażania przyszłych obowiązków. Jeśli firma planuje w tym samym czasie ekspansję do nowych państw, nowe magazyny, większy udział B2B albo kolejne kanały sprzedaży, ten warunek staje się szczególnie ważny. Każdy nowy rynek dołożony do nieuporządkowanej architektury zwiększa późniejszy koszt jej naprawy.

W 2027 roku warto więc inwestować przede wszystkim w zdolność do odtworzenia historii transakcji, pracę na danych ustrukturyzowanych, wersjonowanie reguł, effective dating, historyczny stan rejestracji i procedur VAT, identyfikowalność ruchów towaru oraz separację logiki podatkowej od poszczególnych kanałów sprzedaży. Nie wszystkie te rozwiązania są wymagane bezpośrednio przez ViDA i nie powinny być tak przedstawiane. Są natomiast odpowiedzią na kierunek, w którym zmienia się europejski VAT: więcej danych ustrukturyzowanych na poziomie transakcji, raportowanie bliżej momentu transakcji, rosnące znaczenie e-fakturowania, kolejne etapy Single VAT Registration oraz jednoczesne funkcjonowanie różnych systemów krajowych. W takiej rzeczywistości najbardziej ryzykowną architekturą jest ta, która działa tylko przy obecnym zestawie wymagań i musi być ręcznie przebudowywana przy każdej kolejnej zmianie.

Firmy, które potraktują ViDA jak następny projekt integracyjny do odhaczenia, będą najprawdopodobniej reagować na każdą falę zmian osobno: osobna poprawka dla fakturowania, osobna dla magazynów, kolejna dla OSS, następna dla B2B i raportowania. Firmy, które wykorzystają ten moment do przebudowy warstwy VAT, mogą osiągnąć coś znacznie cenniejszego niż zgodność z jednym pakietem regulacyjnym. Zyskają architekturę, w której nowe przepisy oznaczają przede wszystkim zmianę reguł, mapowań i procesów, a nie kolejne zaczynanie od zera. Nie wyeliminuje to potrzeby dodawania nowych danych, integracji czy funkcji, gdy zmienią się wymagania, ale ograniczy ryzyko, że każda taka zmiana wymusi przebudowę całego środowiska. Dla średniego e-commerce planującego ekspansję to właśnie ta zdolność do zmian może okazać się najważniejszym efektem roadmapy technologicznej na 2027 rok.