Zmiany w JPK-VAT: Dane kontrahentów muszą być fit

W styczniu 2018 r. obowiązek składania szczegółowej informacji o rozliczeniach podatku od towarów i usług w pliku JPK_VAT będzie dotyczył wszystkich bez wyjątku podatników VAT i obejmie ponadmilionową rzeszę mikroprzedsiębiorców. Perspektywa regularnego pozyskiwania ogromnej ilości danych od tak licznej grupy podmiotów budzi szereg obaw.

Czy mikroprzedsiębiorcy będą w stanie spełnić wymagania dotyczące raportowania JPK_VAT? Czy wydajność infrastruktury resortu finansów (bramka JPK, narzędzia analizy danych) sprosta nowym wyzwaniom, tj. pobieraniu i analizie szczegółowych informacji od tak dużej rzeszy podmiotów? Czy wobec tego istnieje możliwość „odchudzenia" plików JPK_VAT, tj. bezstratnego (z perspektywy resortu finansów) zmniejszenia ilości informacji przekazywanych w plikach JPK_VAT?

Toczący się proces konsultacyjny w sprawie zmian w plikach JPK_VAT to dobra okazja, aby zastanowić się nad tym, gdzie leży granica pomiędzy informacjami, które muszą być zawarte w tych plikach, a tymi, które wydają się nadmiarowe, lub wręcz zbędne. Patrząc na aktualną wersję pliku JPK_VAT, właściwe wydaje się przyjrzenie w szczególności danym dotyczącym kontrahentów (dostawców i nabywców) podatników, szukając w tym obszarze możliwych opcji zmniejszenia wolumenu przekazywanych danych, przy zachowaniu możliwości jednoznacznej identyfikacji kontrahenta przez administrację skarbową przy badaniu plików JPK.

Zbędne dane adresowe

Obecnie podatnicy składający plik JPK_VAT są zobowiązani do wykazywania (dla każdej faktury lub wiersza) szczegółowej informacji o dostawcy lub nabywcy, tj.

- jego numeru identyfikacji podatkowej,

- pełnej nazwy oraz

- pełnego adresu siedziby.

Powstaje pytanie, czy ten pakiet danych jest konieczny do jednoznacznej identyfikacji kontrahenta? Z perspektywy administracji skarbowej, numer NIP lub VAT-UE przypisany do danego dostawcy lub nabywcy jednoznacznie go identyfikuje. Szczegółowe informacje o nazwie podatnika i jego (aktualnym) adresie znajdują się przecież w bazach, do których dostęp mają organy podatkowe. Dane te bowiem są obligatoryjnie wypełniane w zgłoszeniach rejestracyjnych (lub aktualizujących dane) dla potrzeb VAT, składanych przez podmioty gospodarcze. Mało tego, informacje te są dostępne w rejestrach KRS oraz bazach Głównego Urzędu Statystycznego. Z kolei w przypadku podmiotów z innych krajów UE, dane dotyczące nazwy i adresu podatników są dostępne poprzez System Wymiany Informacji Podatkowej VIES.

Nie ma więc potrzeby pokazywania w plikach JPK_VAT w szczególności danych adresowych kontrahentów, bowiem dostęp do nich administracja skarbowa może uzyskać poprzez powiązanie numeru NIP lub VAT-UE wskazanego w plikach z danymi tych podmiotów znajdujących się w dostępnych rejestrach publicznych. Dzięki mechanizmowi „dociągania" danych adresowych z publicznych rejestrów administracja skarbowa zapewni spójność i aktualność tych danych. Są to zalety niemożliwe do uzyskania w przypadku bazowania na informacjach dostarczonych z systemów finansowych podatników (nie ma pewności czy przechowywane w systemach informacje są aktualne, ponadto tożsame dane kontrahentów mogą być prezentowane w różny sposób w systemach różnych podatników).

W przypadku rezygnacji w kolejnej wersji JPK_VAT z konieczności pokazywania danych adresowych dostawców i nabywców korzyści dla administracji skarbowej są więc ewidentne.

Spójrzmy ponadto na aspekt czysto techniczny, analizując „ciężar" informacji o adresie:

- Po pierwsze, same pola do prezentacji adresu mają długość do 256 znaków, i siłą rzeczy zazwyczaj są wypełniane „po brzegi".

- Po drugie, plik JPK ma „płaską" strukturę.

Co to w praktyce oznacza, obrazuje poniższy przykład.

Przykład

Podatnik A składający plik JPK_VAT w zakresie sprzedaży wystawia miesięcznie ok. 20 tys. faktur, przy czym 95 proc. z nich wystawianych jest na rzecz jednego kontrahenta B, o nazwie C i adresie DDD. Oznacza to, że dane adresowe (przypomnijmy – do 256 znaków) kontrahenta B powielane są w pliku JPK ponad 19 tys. razy! Czy to powielenie tożsamej informacji ma jakikolwiek dodatkowy walor informacyjny dla administracji skarbowej? Nie. Jedynym efektem prezentacji tych danych jest „spuchnięty" plik JPK.

- Po trzecie wreszcie, w przypadku zakupów objętych mechanizmem odwrotnego obciążenia, informacje o fakturze (w tym informacje o adresie dostawcy) muszą być powielone, tj. zaprezentowane zarówno w sekcji dla podatku naliczonego, jak i należnego. Wyobraźmy sobie więc, że powyższy przykład dotyczy nie sprzedaży, a zakupów objętych odwrotnym obciążeniem (np. importu usług). Wówczas w pliku mielibyśmy do czynienia z informacją o tożsamym adresie, powieloną 38 tys. razy!

Z jednej strony, konieczność umieszczania danych w każdym wierszu znacząco powiększa objętość pliku, a z drugiej – nie wnosi żadnej dodatkowej wartościowej informacji. Nietrudno dostrzec, że eliminacja konieczności wprowadzania adresów znacząco zmniejszyłaby rozmiary plików, które trafiają na serwery Ministerstwa Finansów, w konsekwencji optymalizując proces odbioru i przetwarzania plików JPK.

Usunięcie adresu z listy obowiązkowych informacji pokazywanych w pliku JPK_VAT zmniejszyłoby także pracochłonność przygotowania plików po stronie podatników. Zwłaszcza, że dostępność szczegółowych informacji adresowych w systemach księgowych bywa ograniczona.

Co w zamian

Koncepcja eliminacji z JPK_VAT danych adresowych kontrahenta i bazowanie w tym zakresie na informacjach dostępnych w publicznych rejestrach (KRS, GUS, VIES, dane podatników przechowywane w bazach administracji skarbowej) dobrze sprawdzi się w przypadku pozyskiwania danych adresowych polskich podatników (posługujących się numerem NIP) lub podmiotów zarejestrowanych dla potrzeb VAT w innych krajach UE (tu z pomocą przychodzi baza VIES).

Natomiast w przypadku wykazywania transakcji dokonywanych z podmiotami z krajów trzecich (np. eksport lub import towarów, świadczenie usług na rzecz / od kontrahenta spoza UE), mogą pojawić się w praktyce trudności z ustaleniem kraju siedziby takiego kontrahenta. Ani numer identyfikacyjny, ani nazwa kontrahenta nie pozwolą w tych przypadkach na jednoznaczne ustalenie kraju siedziby kontrahenta. Należy sobie także odpowiedzieć na pytanie, czy administracji skarbowej potrzebny jest w tym zakresie pełny adres? Dla weryfikacji klasyfikacji transakcji dla potrzeb VAT wystarczy wszak ustalenie kraju, w którym kontrahent ma swoją siedzibę. Mając tę informację oraz nazwę kontrahenta, organy podatkowe mogę też zwrócić się z prośbą do władz skarbowych danego kraju o dostarczenie szczegółowych informacji o kontrahencie.

W tych przypadkach przydatne może się okazać rozszerzenie informacji w pliku JPK_VAT o jednoznaczne i spójne oznaczenie siedziby kraju kontrahenta. Pomysł ten zresztą wskazany został przez resort finansów w piśmie z 7 lipca br. zawiadamiającym o rozpoczęciu konsultacji w sprawie zmiany w plikach JPK. Oznaczenie kraju kontrahenta mogłoby być informacją zastępującą dane adresowe kontrahentów. Wystarczyłoby wskazanie dwu- lub trzyznakowego oznaczenia kraju według powszechnych standardów (np. wskazany przez Ministerstwo Finansów standard okodowania ISO), przez co przyrost wolumenu informacji w plikach JPK_VAT nie byłby zbyt duży. Warto również podkreślić, że informacje o kodzie kraju kontrahenta są zazwyczaj dostępne w systemach finansowych przedsiębiorców.

Zafiksowanie na prefiksach

Pozostając w tematyce danych kontrahentów pokazywanych w pliku JPK_VAT, warto przeanalizować wzmiankowany przez resort finansów (w ramach procesu konsultacyjnego) pomysł odrębnego wykazywania prefiksu (pierwszych dwóch liter) numerów VAT kontrahentów. Pomysł ten wydaje się nietrafiony i spowoduje wykazywanie nadmiarowej, niepotrzebnej informacji. Należy bowiem zauważyć, że prefiks numeru VAT kontrahentów zarejestrowanych dla potrzeb transakcji wewnątrzunijnych może być (i w praktyce jest) uwzględniany w polach przeznaczonych do wykazywania numeru identyfikacyjnego dostawcy lub nabywcy, jako integralny element tego numeru. Z kolei w przypadku polskich numerów NIP czy numerów identyfikacyjnych podmiotów z krajów trzecich, takie dodatkowe pole w ogóle nie byłoby wypełniane. W efekcie mielibyśmy znowu do czynienia z dodatkowym polem bez praktycznego zastosowania, lub przeznaczonym do wykazania informacji powielonej i nadmiarowej.