: co zmienia od 2026 r. i dlaczego importerzy muszą przestawić procesy
Od
Najważniejszy sygnał dla importerów jest prosty: od 2026 r. proces raportowania trzeba traktować jak zintegrowany łańcuch danych, a nie jednorazowe zadanie działu compliance. Omnibus podnosi znaczenie prawidłowego przypisywania ładunków do właściwych kategorii i emisji oraz wymaga, aby dane wejściowe były możliwie jednolite i mierzalne (np. w zakresie wolumenów, klasyfikacji towarów i identyfikacji dostaw). Jeżeli dziś firma raportuje na podstawie rozproszonych arkuszy lub danych z kilku systemów, to w kolejnych okresach rozliczeniowych może się to okazać wąskim gardłem.
Dlaczego importerzy muszą przestawić procesy już teraz? Po pierwsze, cykl przygotowania raportu CBAM jest uzależniony od informacji od wielu interesariuszy: sprzedawców, przewoźników, działu zakupów, magazynu oraz księgowości. Po drugie, wzmacnia oczekiwania dotyczące
W efekcie od 2026 r. firmy powinny podejść do jak do projektu procesowego: mapują przepływ danych, ustanawiają zasady kontroli jakości i przygotowują personel oraz systemy do bardziej rygorystycznych standardów. Jeżeli decyzje dotyczące taryf/klasyfikacji i wyliczeń emisji zapadają „po fakcie”, raportowanie przestaje być przewidywalne — a koszty korekt i ryzyko zgodności rosną. Ten rozdział artykułu pokazuje, na czym importerzy muszą się skoncentrować, aby uniknąć chaosu w 2026 r. i wejść w nowy model CBAM z procesami, które będą działać powtarzalnie.
7 kluczowych zmian w raportowaniu ładunków po Omnibusie: obowiązki, progi i nowe pola danych
Od 2026 r. pakiet porządkuje i jednocześnie rozszerza obowiązki raportowe importerów, co w praktyce oznacza konieczność doprecyzowania, co, kiedy i jak ma trafić do raportów CBAM. Najważniejsza zmiana dotyczy podejścia do danych: firma ma nie tylko raportować emisje w sposób zgodny z zasadami, lecz również zapewnić spójność między informacją handlową (np. kody towarów i wolumeny) a komponentem środowiskowym (np. wysokości emisji oraz sposób ich wyliczania). W efekcie rośnie rola działów odpowiedzialnych za import, księgowość oraz compliance — bo to właśnie oni muszą “spiąć” raportowanie w jeden, audytowalny proces.
Istotnym elementem Omnibusu są progi i obowiązki zależne od rodzaju przepływu, które wpływają na to, kiedy importer musi przygotować pełne dane, a kiedy może korzystać z uproszczeń. W praktyce oznacza to, że klasyfikacja ładunków oraz sposób raportowania nie może być “szacunkowy” ani w pełni uznaniowy — decyzje o zakresie obowiązków muszą wynikać z konkretnych danych wejściowych i prawidłowej kwalifikacji towarów. Dla importerów to sygnał, by już na etapie przygotowania danych rozbić proces na reguły: które deklaracje wymagają pełnej dokumentacji, a które podlegają innym zasadom.
Kolejna kluczowa grupa zmian dotyczy nowych pól danych i wymogów formalnych w raportach (oraz tego, jak te dane mają być prezentowane i powiązane z innymi elementami zgłoszenia). Importerzy powinni założyć, że w kolejnych wersjach procesu raportowego rośnie liczba informacji, których kompletność i poprawność będzie weryfikowana, a także znaczenie precyzyjnych identyfikatorów: od danych identyfikujących przesyłki i towary, po parametry niezbędne do obliczeń. Dlatego “przemodelowanie” formularzy w systemach i dostosowanie mapowań z ERP/planerów importu staje się jednym z priorytetów — szczególnie tam, gdzie dziś raporty powstają ręcznie albo na podstawie niespójnych arkuszy.
Warto też pamiętać, że Omnibus wzmacnia praktyczny wymiar odpowiedzialności: nawet jeśli formularz raportu jest wypełniany “na końcu”, to błędy wynikające z nieprawidłowych danych źródłowych (np. niespójnych wolumenów, błędnych kodów towarów czy nieadekwatnych podstaw wyliczeń) mogą przełożyć się na konieczność korekt i ryzyko niezgodności. Z perspektywy importerów kluczowe staje się więc zbudowanie systemu pracy, który minimalizuje ryzyko pomyłek jeszcze przed złożeniem raportu — ponieważ nowe lub zmienione elementy raportowania sprawiają, że każdy brak w danych może mieć większą wagę niż wcześniej.
Jak przygotować dane i systemy: matryca danych (stawki, emisje, kody towarów) oraz kontrola jakości przed złożeniem raportu
Od 2026 r. efektywne raportowanie w ramach będzie w dużej mierze zależeć od tego, czy importerzy potrafią „zmapować” dane z całego łańcucha operacyjnego do wymaganych pól w zgłoszeniach. Kluczowym krokiem jest zbudowanie matrycy danych, która łączy kody towarów (CN/PRODCOM lub właściwe kody referencyjne), stawki i parametry emisji oraz dane o ilościach i pochodzeniu (zgodnie z logiką CBAM). W praktyce oznacza to stworzenie jednego, spójnego modelu: od dokumentów handlowych i specyfikacji produktu, przez logikę klasyfikacji, aż po sposób przypisania wartości emisji dla danego towaru i dostawy.
W matrycy nie może zabraknąć również warstwy „wrażliwej na błędy”: stawek, współczynników, jednostek miary oraz wersji danych środowiskowych (np. źródeł wartości emisji – standardowych lub na podstawie danych rzeczywistych). Warto zaprojektować strukturę tak, aby system automatycznie walidował podstawowe zależności (np. czy kod towaru ma przypisaną właściwą metodę wyznaczania emisji, czy jednostka ilości zgadza się z jednostką wymaganą w raporcie, czy stawki lub dane referencyjne nie są przeterminowane). Dzięki temu ograniczysz ręczne poprawki i zmniejszysz ryzyko rozbieżności między klasyfikacją towaru w systemie celnym a tym, co trafia do raportu CBAM.
Równie istotna jest kontrola jakości przed złożeniem raportu, rozumiana jako zestaw testów i procedur weryfikacyjnych jeszcze w środowisku roboczym. Najlepiej sprawdza się podejście „bramek” (gate checks): najpierw kompletność danych (czy wszystkie przesyłki/dostawy mają kompletne atrybuty), potem zgodność formalna (czy pola spełniają reguły zakresu, formaty i słowniki), a na końcu walidacja obliczeń (czy wyliczone emisje i wartości całkowite są spójne z logiką matrycy i przyjętymi źródłami danych). Dobrą praktyką jest też wprowadzenie rejestru zmian: kto i kiedy modyfikował klasyfikację, stawki, dane emisji lub parametry raportu, oraz dlaczego—co ułatwi audyt oraz szybkie wykrycie przyczyny błędu.
Na koniec, przygotowanie danych i systemów warto oprzeć o cykl iteracyjny: uruchom próbne wyliczenia na historycznych importach, porównaj wyniki z dotychczasowymi raportami lub wewnętrznymi kalkulacjami i dopiero potem „uszczelnij” matrycę o brakujące przypadki brzegowe. Jeśli w tym momencie zauważysz, że część danych pochodzi z kilku źródeł (ERP, system celny, dokumenty od dostawców), zaplanuj reguły priorytetu danych i harmonizację słowników (np. nazwy towarów, kody, jednostki). To właśnie te elementy decydują o tym, czy proces raportowania będzie stabilny i powtarzalny—bez nerwowych korekt na ostatnią chwilę.
Korekty w rozliczeniach i ryzyko błędów: najczęstsze pułapki w klasyfikacji, wyliczeniach i raportach weryfikowanych
Jednym z największych wyzwań po wejściu w życie pakietu są korekty w rozliczeniach oraz wynikające z nich ryzyko błędów. W praktyce importerzy muszą liczyć się z sytuacjami, w których pierwotnie przyjęte dane okażą się niepełne lub niezgodne z wymogami: np. zmieni się dostęp do informacji od dostawców, zostaną skorygowane wskaźniki emisji (w całym łańcuchu) albo okaże się, że zastosowano nieprawidłową interpretację zasad przypisywania emisji do towaru. To oznacza, że raport nie może być „jednorazowym” zadaniem księgowym — musi być procesem cyklicznego weryfikowania, zwłaszcza na etapie przygotowania i po publikacji danych do rozliczeń.
Najczęstsza pułapka dotyczy klasyfikacji towarów i tym samym poprawności danych wejściowych do wyliczeń. Błędy w kodach (np. CN/HS), rozbieżności w opisie towaru między dokumentami przewozowymi a dokumentami handlowymi lub zbyt szerokie uogólnienia w przypisaniu parametrów mogą prowadzić do przypisania niewłaściwych stawek lub metod wyliczeń. Drugi obszar ryzyka to wyliczenia oparte o emisje: nieprawidłowe zastosowanie czynników emisyjnych, niezgodna z wymogami baza danych (np. brak spójności między wartościami z różnych źródeł) albo błędne przeliczenia w zależności od jednostek (kg/t/tony) — to typowe powody różnic między wersją roboczą raportu a ostatecznym rozliczeniem. W konsekwencji importer naraża się nie tylko na korekty techniczne, ale też na konieczność wyjaśniania przyczyn rozbieżności w audytowalnym trybie weryfikacji.
Szczególnie istotne jest ryzyko błędów w raportach weryfikowanych. W tym obszarze problemem bywa brak pełnej ścieżki dowodowej — czyli sytuacje, gdy dane są „liczone”, ale nie da się ich jednoznacznie odtworzyć na podstawie dokumentów i wersji źródłowych. Równie częstym błędem jest nieprzystosowanie procedur do korekt: firma uwzględnia zmiany dopiero po przygotowaniu finalnych plików, nie utrzymuje historii wersji wyliczeń, a odpowiedzialność za korekty jest rozproszona między zespołami (logistyka, podatki/finanse, compliance, dane od dostawców). W efekcie pojawiają się niespójności: inna klasyfikacja w systemie magazynowym niż w CBAM, inna metoda wyliczeń w arkuszach niż w narzędziu raportującym, a także rozbieżności między wartościami użytymi do deklaracji a tymi, które potem są weryfikowane.
W praktyce najlepszą ochroną przed korektami i błędami jest podejście „zaprojektowane pod kontrolę”: już na etapie wyliczeń warto przewidzieć warianty korekt danych wejściowych (np. aktualizacje emisji lub korekty kodów towarów) oraz ustalić, kiedy i przez kogo wprowadza się zmiany. Kluczowe jest też wdrożenie prostych mechanizmów kontroli jakości, które wykryją typowe odchylenia (np. skoki emisji względem wcześniejszych partii, nietypowe różnice jednostek, brak zgodności opisów towarów z dokumentacją). Dzięki temu importerzy mogą ograniczyć ryzyko kosztownych poprawek i zmniejszyć prawdopodobieństwo, że weryfikator zakwestionuje elementy raportu, których nie da się obronić w formie audytowalnych dowodów.
Strategia wdrożenia na 90 dni: harmonogram działań, zakres odpowiedzialności w firmie i checklisty zgodności
Strategia wdrożenia na 90 dni powinna zaczynać się od uporządkowania odpowiedzialności i zamrożenia „źródeł prawdy” dla danych. W praktyce oznacza to powołanie jednego właściciela procesu (tzw. process owner) – zwykle w obszarze compliance lub podatków/CBAM – oraz powołanie zespołu międzyfunkcyjnego: działu taryf (klasyfikacja towarów i kody CN), finansów (wyliczenia i rozliczenia), logistyki/łańcucha dostaw (dane o ładunkach), IT (integracje i jakość danych) oraz kontroli wewnętrznej/audytu (testy i ścieżka dowodowa). Kluczowe jest ustalenie, kto zatwierdza dane wejściowe, kto przelicza wyniki i kto ponosi odpowiedzialność za zgodność przed złożeniem raportu.
W ujęciu harmonogramu warto podzielić działania na trzy etapy. Etap 1 (dni 1–30): diagnoza i projekt danych – inwentaryzacja importów objętych CBAM, przegląd obecnego sposobu zbierania informacji (np. masy, pochodzenia, kodów towarów, wskaźników emisji/ustaleń dla produktu), mapowanie braków oraz projekt matrycy danych dla stawek/emisji i ich powiązań z dokumentami. Etap 2 (dni 31–60): budowa i test – implementacja w systemach (np. reguły walidacji, automatyczne pobieranie pól, logika korekt), przygotowanie zestawów testowych dla typowych scenariuszy (błędy klasyfikacji, braki w danych, różne warianty pochodzenia) oraz przeprowadzenie próbnego raportowania na wybranych ładunkach. Etap 3 (dni 61–90): walidacja, procedury i gotowość operacyjna – uruchomienie formalnych procesów zatwierdzania, test ścieżki dowodowej (audit trail), szkolenia użytkowników oraz finalne „zamknięcie” checklist zgodności przed pierwszym właściwym raportowaniem po Omnibusie.
Żeby uniknąć chaosu, przygotuj checklisty zgodności i przypisz je do ról w firmie. Przykładowa lista kontrolna powinna obejmować: (1) weryfikację poprawności i kompletności danych podstawowych (kody towarów, parametry ładunku, dane o emisjach/ustaleniach), (2) potwierdzenie, że reguły wyliczeń są zgodne z przyjętą logiką CBAM (spójność stawek, jednostek, zasad przypisań), (3) kontrolę spójności między dokumentami źródłowymi a raportem (zgodność masy i opisów produktów, zgodność z transakcjami i datami), (4) walidację wyjątków (korekty, zmiany w klasyfikacji, przypadki niepełnych danych) oraz (5) potwierdzenie, że raport przechodzi testy jakości (np. kompletność pól wymaganych, brak rozbieżności, poprawność formatów). Dobrą praktyką jest też wprowadzenie „okna kontroli” – np. 3–5 dni przed terminem – na finalną weryfikację i akceptację przez uprawnione osoby.
Na koniec warto zadbać o ciągłość procesu: dokumentację decyzji (dlaczego przyjęto takie kody/ustalenia i na jakiej podstawie), wzorce odpowiedzi na najczęstsze rozbieżności oraz instrukcje dla zespołów wprowadzających dane. Dzięki temu wdrożenie w 90 dni nie kończy się „jednorazową konfiguracją”, lecz zamienia w powtarzalny, kontrolowany mechanizm raportowania – ograniczając ryzyko błędów, braków i kosztownych korekt po złożeniu deklaracji.