Uwagi do propozycji zmian oraz rozbudowy schemy JPK_VAT
2017-08-09
Przedstawione uwagi odnoszą się do krótkoterminowych i długoterminowych celów zmian w zakresie raportowania JPK_VAT, uwzględniając potencjalne korzyści lub zagrożenia dla wszystkich uczestników procesu (podatnicy, dostawcy rozwiązań Ministerstwo Finansów/organy podatkowe), związane z konkretnymi propozycjami w tym zakresie.
Zastrzeżenia dotyczą problematyki ograniczonej dostępności pewnych danych w systemach księgowych podatników, uwzględniając dotychczasowe doświadczenia przedsiębiorców w obszarze raportowania JPK_VAT, oraz zebrane w trakcie wdrożeń rozwiązań informatycznych dla potrzeb JPK_VAT. Z drugiej strony, bierzemy pod uwagę potrzeby administracji skarbowej w zakresie zwiększenia efektywności czynności sprawdzających i kontroli plików JPK_VAT.
1. Cezury obowiązywania wersji schemy JPK_VAT
Mając na uwadze planowane wprowadzenie kolejnej, trzeciej wersji schemy JPK_VAT, należy rozważyć wprowadzenie wiążących zasad stosowania cezur (zakresu czasowego) obowiązywania danej wersji schemy JPK_VAT.
Wniosek ten ma związek z okolicznościami wprowadzenia wersji 2 schemy pliku JPK_VAT w styczniu 2017 r. Według pierwotnych założeń (ogłoszonych m. in. Broszurze Informacyjnej dot. JPK_VAT (2)), druga (rozszerzona) wersja pliku JPK_VAT miała obowiązywać w stosunku do rozliczeń dokonywanych od momentu publikacji schemy (od stycznia 2017 r.). Dla okresów wcześniejszych (lipiec - grudzień 2016 r.) obowiązywała wersja 1 struktury (z założeniem stosowania tej wersji również w stosunku do korekt rozliczeń sprzed stycznia 2017 r.).
W praktyce, w wyniku dokonanych w styczniu 2017 r. zmian technicznych wyłączono możliwość przesyłania plików JPK_VAT w wersji 1, wymuszający tym samym bezwarunkowe stosowanie wersji drugiej schemy JPK_VAT. W efekcie, wersja 2 schemy JPK_VAT miała zastosowanie nie tylko do bieżącego raportowania plików JPK_VAT za okresy od stycznia 2017 r., ale też - retrospektywnie - do korekty okresów rozliczeniowych, w których stosowano wcześniej obowiązującą wersję 1 schemy JPK_VAT. Taka zmiana skutkowała istotnymi komplikacjami w procesie przygotowywania korekt JPK_VAT za okresy lipiec-grudzień 2016 r., z wykorzystaniem np. oprogramowania komercyjnego lub rozwiązań wewnętrznych.
W przypadku formularzy deklaracji podatkowych (w tym deklaracji VAT), kolejne publikowane wersje mają zastosowanie od pierwszego okresu sprawozdawczego, dla którego zostały opracowane oraz okresów przyszłych, aż do momentu opracowania kolejnej wersji deklaracji. Tym samym, w przypadku np. dokonywania korekt rozliczeń VAT za okres przeszły, stosuje się formularz aktualny dla danego okresu korygowanego (formularz historyczny), a nie aktualnie obowiązujący dla bieżących rozliczeń.
Powyższe zasady, powinny znaleźć analogiczne zastosowanie w odniesieniu do kolejnych wersji pliku JPK_VAT (oraz innych schem JPK), tj. w przypadku opublikowania przez Ministerstwo Finansów w styczniu 2018 r. nowej (trzeciej) wersji schemy JPK_VAT nowa wersja powinna mieć zastosowanie dla raportowania VAT za okresy od stycznia 2018 r. Korekty JPK_VAT za okresy sprzed stycznia 2018 r., powinny być prezentowane na wersji poprzedniej wersji, obowiązującej w danym, korygowanym okresie (tj. wersji drugiej).
2. Dodanie do struktury pozycji dotyczącej kwoty nadwyżki podatku naliczonego z poprzedniej deklaracji; odpowiednik pozycji 42 „Kwota nadwyżki z poprzedniej deklaracji" z deklaracji VAT-7
Pierwotnym założeniem wprowadzenia obowiązków w zakresie Jednolitego Pliku Kontrolnego było odzwierciedlenie za jego pomocą deklaracji VAT. Niestety przy obecnej wersji struktury JPK_VAT, odzwierciedlenie kwot zadeklarowanych w deklaracji VAT-7 nie jest możliwe. Wynika to z faktu, że obecna struktura nie jest dostosowana do obecnie obowiązującej deklaracji VAT-7. Oznacza to, że struktura JPK_VAT(2) nie zawiera wszystkich pól, które zawiera deklaracja VAT-7. Jednym z takim pól jest pole 42 „Kwota nadwyżki z poprzedniej deklaracji". W praktyce oznacza to, że jeśli u podatnika występuje kwota, którą deklaruje w omawianym polu w deklaracji, nie może jej zaprezentować w pliku JPK_VAT(2). W konsekwencji suma podatku naliczonego wykazana w polu <tns:PodatekNaliczony> w JPK_VAT(2) nie odpowiada kwocie zadeklarowanej w pozycji 51 „Razem kwota podatku naliczonego do odliczenia". Zgodnie z obecnymi zaleceniami Ministerstwa Finansów, kwota wykazana w JPK_VAT(2) w polu <tns:PodatekNaliczony> powinna zawierać jedynie sumę pozycji wykazanych w polach K_44 i K_46. Konsekwencją jest to, że jeżeli podatnik zadeklarował kwotę w pozycji 42 „Kwota nadwyżki z poprzedniej deklaracji" w deklaracji VAT-7, nie jest ona ujmowana - w przeciwieństwie do deklaracji VAT-7 - w polu <tns:PodatekNaliczony> w JPK_VAT(2), a należy zaznaczyć, że pole to z założenia powinno być odzwierciedleniem pozycji 52 „Razem kwota podatku naliczonego po odliczeniach" w VAT-7. Finalnie, kwota podatku naliczonego, która została zadeklarowana w deklaracji VAT-7 nie odpowiada kwocie wykazanej jako podatek naliczony
w JPK_VAT(2).
Rekomendujemy, aby przy aktualizacji struktury JPK_VAT(2) dodać nowe pole „K_42", które będzie odpowiednikiem pola 42 „Kwota nadwyżki z poprzedniej deklaracji" zawartego w deklaracji VAT-7. Pozwoli to na faktyczne odzwierciedlenie w JPK_VAT kwot zadeklarowanych w deklaracji VAT-7. Dzięki dodaniu nowego pola „K_42", kwota wykazana w polu <tns:PodatekNaliczony> w JPK_VAT(2) będzie odpowiadała kwocie zadeklarowanej w polu 52 „Razem kwota podatku naliczonego po odliczeniach" w VAT-7. W rezultacie, przesyłany plik JPK_VAT będzie faktycznie odzwierciedleniem deklaracji VAT-7 składanej za tożsamy okres.
3. Brak obowiązku wskazywania adresu kontrahenta w sytuacji, kiedy wskazano nazwę oraz NIP tego kontrahenta
Obecna wersja struktury JPK_VAT(2) zawiera - zarówno w sekcji dotyczącej podatku należnego jak i podatku naliczonego - pole <tns:AdresKontrahenta>. Pole to jest obowiązkowe, zatem nieuzupełnienie go spowoduje, że plik będzie niekompletny. Uzupełnianie przedmiotowego pola w JPK_VAT(2) jest często problematyczne i czasochłonne dla podatników. Wynika to chociażby z faktu, że dane, które trafiają finalnie do pliku JPK_VAT(2), są rozproszone w dwóch lub kilku bazach danych.
Rekomendujemy, aby w sytuacji, kiedy podatnik w przekazywanym JPK_VAT wskaże nazwę oraz numer NIP (lub jego odpowiednik w przypadku kontrahentów z zagranicy), wskazywanie adresu kontrahenta nie było obowiązkowe. Zatem w sytuacji, kiedy pole <tns:NrKontrahenta> i <tns:NazwaKontrahenta> zostaną uzupełnione faktycznymi danymi kontrahenta, pole <tns:AdresKontrahenta> nie byłoby polem obligatoryjnym. Pole może pozostać obligatoryjne w sytuacji, kiedy podatnik nie wypełni jednego z pól: <tns:NrKontrahenta> i <tns:NazwaKontrahenta. Wprowadzenie takiego rozwiązania pozwoliłoby podatnikom zaoszczędzić kłopotów oraz czasu podczas generowania plików JPK_VAT.
4. Zmiany danych nagłówka JPK_VAT
Zgodnie z pkt 2 rozdziału III Zawiadomienia MF, rozważane jest usuniecie z danych nagłówkowych pliku JPK_VAT informacji o numerze REGON podatnika. Naszym zdaniem, pole to jest zbędne w procesie raportowania pliku JPK_VAT. Także za zbędne uważamy wykazywanie pozostałych informacji adresowych podatnika.
Należy podkreślić, że w odniesieniu do formularzy deklaracji VAT (VAT-7, VAT-UE), już w 2013 r. zrezygnowano z prezentacji danych adresowych podatnika, ograniczając się do wskazania jego numeru NIP, nazwy, formy prawnej oraz kodu urzędu skarbowego. Wskazanie numeru NIP podatnika, jego nazwy oraz identyfikatora urzędu skarbowego, pozwala administracji skarbowej na jednoznaczną identyfikację podatnika składającego plik JPK_VAT. Z kolei ustalenie danych adresowych jest możliwe w oparciu o informacje gromadzone w bazach urzędowych, na podstawie zgłoszeń rejestrujących/aktualizujących dane podatnika (VAT-R, NIP-2, NIP-7, CEIDG-1 itd.).
Podsumowując, w naszej ocenie, wystarczające jest wskazane w danych nagłówkowych pliku JPK_VAT następujących informacji: Numer NIP podatnika, nazwa podatnika, okres sprawozdawczy, którego dotyczy plik JPK_VAT, kod kraju podatnika (w przypadku podmiotów zagranicznych zarejestrowanych dla celów VAT w Polsce), cel złożenia, data utworzenia pliku JPK_VAT oraz identyfikator Urzędu Skarbowego, do którego składany jest plik JPK_VAT.
5. Kod celu złożenia pliku JPK_VAT
Pozytywnie oceniamy (wskazaną w pkt III.1 Zawiadomienia MF) propozycję rozszerzenia oznaczeń celu złożenia pliku JPK_VAT w sposób umożliwiający numerację kolejnych korekt plików JPK.
Obecnie, w polu tym istnieje możliwość wprowadzenia wartości „1" (złożenie po raz pierwszy pliku JPK_VAT za dany okres) lub „2", (oznaczenie korekty pliku JPK_VAT), przy czym brak jest możliwości oznaczenia kolejno składanych korekt rozliczeń VAT. Dla umożliwienia identyfikacji kolejnych korekt plików JPK_VAT Ministerstwo Finansów proponuje wprowadzenie znaczników korekt plików JPK_VAT za dany okres, np. 2 - korekta, 3 - następna korekta, itd.
W naszej ocenie propozycja Ministerstwa pozwoli na usprawnienie kontroli wykonywanych przez administrację skarbową. Jednocześnie, dla większej przejrzystości rekomendujemy modyfikację numeracji kodów w taki sposób, aby numer odpowiadał kolejnej korekcie rozliczeń.
W takim przypadku plik pierwotny mógłby być oznaczony np. kodem „0" albo znakiem alfanumerycznym (np. „P" - pierwotny), z korekty (według kolejności) kolejnymi numerami („1", „2", „3") lub kodami alfanumerycznymi (np. „K1", „K2", „K3")
6. Prefiks numeru NIP / nr VAT-UE oraz kod kraju kontrahenta
W pkt III.2 Ministerstwo Finansów proponuje rozszerzenie zakresu danych ujawnianych w pliku JPK_VAT o: (a) prefiks numeru NIP lub VAT kontrahenta / dostawcy oraz (b) kod kraju siedziby kontrahenta / dostawcy np. według jednego ze standardów ISO (np. 3166-1 alfa-2),
W odniesieniu do prefiksu numery NIP lub VAT kontrahenta / dostawcy, informacje te są wykazywane już w obecnej wersji schemy JPK_VAT w polu dla numeru kontrahenta lub dostawcy, wraz z pozostałą części numeru identyfikacji podatkowej (prefiks jako element integralny np. unijnego numeru VAT). Stąd, w naszej ocenie nie ma potrzeby raportowania prefiksu numeru NIP / VAT-UE w dodatkowym polu.
Pozytywnie oceniamy propozycję dodania oznaczenia kodu kraju kontrahenta / dostawcy według jednolitej nomenklatury. Uwidocznienie tej informacji może przyczynić się do zwiększenia efektywności kontroli poprawności klasyfikacji transakcji dla celów VAT (zarówno w ramach czynności sprawdzających realizowanych przez władze skarbowe, jak i autokontroli rozliczeń, dokonywanych przez podatników). Wskazanie kodu ISO kraju dostawcy lub kontrahenta może ułatwić identyfikację dostawców lub nabywców z krajów trzecich (spoza Polski i spoza Unii Europejskiej), w przypadku których informacje ujawnione w polu dla numeru identyfikacji podatkowej mogą okazać się niewystarczające do ustalenia (zwłaszcza w przypadku sekcji dla podatku naliczonego) klasyfikacji VAT transakcji (np. ustalenia, czy mamy do czynienia z importem towarów lub importem usług spoza UE).
7. Termin płatności, data i sposób płatności
a) Termin płatności
W pkt I in fine oraz pkt III.3. in fine pisma Ministerstwa Finansów wskazana została propozycja rozszerzenia zakresu danych w pliku JPK_VAT o termin płatności, co „(...) mogłoby przyspieszyć badanie prawidłowości rozpoznawania obowiązku podatkowego w niektórych, szczególnych transakcjach".
W naszej ocenie proponowane rozszerzenie nie jest wskazane i prowadziłoby do nieproporcjonalnie dużego obciążenia administracyjnego po stronie podatników, w stosunku do korzyści MF z dostępu do informacji o terminie płatności przy ewentualnej kontroli prawidłowości rozpoznania obowiązku podatkowego. Należy podkreślić, że w świetle obecnie obowiązujących przepisów ustawy o VAT, powiązanie momentu powstania obowiązku podatkowego w VAT należnym z upływem terminu płatności faktury przewidziane jest w przypadkach określonych w art. 19 ust. 5 pkt 4 w powiązaniu z art. 19 ust. 7 i art. 106i ust. 4 ustawy o VAT, tj.:
- świadczenia usług telekomunikacyjnych, dostawy tzw. „mediów", usług najmu, dzierżawy, leasingu i podobnych, ochrony osób lub mienia, dozoru, obsługi prawnej i biurowej oraz dystrybucji energii i gazu przewodowego (art. 19 ust. 5 pkt 4 ustawy o VAT);
- jeżeli podatnik nie wystawił faktury w terminie dopuszczalnym, ale dla dostawy został określony termin płatności (np. w umowie) lub gdy podatnik wystawił fakturę, dla której termin płatności przypada przed datą wystawienia tej faktury (art. 106i ust. 4 w powiązaniu z art. 19 ust. 7 i ust. 5 pkt 4 ustawy o VAT).
Jak wynika z powyższej analizy, termin płatności miałby znaczenie dla momentu powstania obowiązku podatkowego jedynie w bardzo wyjątkowych okolicznościach (zaniechanie wystawienia faktury w określonym terminie lub wystawienie faktury po upływie terminu płatności dla niej) i tylko w odniesieniu do ściśle określonego, wąskiego katalogu czynności opodatkowanych. W efekcie dla zdecydowanej większości przypadków transakcji ujmowanych w pliku JPK_VAT (niespełniających powyższych warunków), ujawniany termin płatności nie miałby znaczenia dla oceny prawidłowości rozpoznania momentu powstania obowiązku podatkowego.
Jednocześnie, należy mieć na względzie praktycznie problemy z dostępem tego rodzaju informacji. Termin płatności często nie jest dostępny z poziomu modułów księgowych systemów ERP, lecz (zwykle jako warunek płatności, a nie termin) na poziomie danych podstawowych kontrahenta lub informacji o kontrakcie /zleceniu. Zdaniem naszych Klientów, niezbędne dla potrzeb spełniania tego wymogu zmiany w systemach finansowych byłyby nieproporcjonalnie kosztowne.
Mając na względzie potencjalnie wysokie koszty procesu dostosowania systemów do takiego dodatkowego wymogu, jak również ograniczone możliwości wykorzystania tej informacji
w kontekście badania momentu powstania obowiązku w podatku VAT należnym, w ocenie Deloitte nie jest wskazane wprowadzanie tego dodatkowego typu informacji do pliku JPK_VAT.
b) Data i sposób płatności
W piśmie Ministerstwa Finansów przedstawiono propozycję uwzględnienia w plikach JPK_VAT informacji o sposobie płatności, z czego można też wywnioskować potrzebę uwzględniania także daty (utrzymania lub uiszczenia) płatności. W naszej ocenie nie jest wskazane wprowadzanie tego dodatkowego typu informacji do pliku JPK_VAT.
Przede wszystkim należy mieć na względzie, że w przypadku podatników niestosujących tzw. metody kasowej rozliczenia podatku VAT, data płatności ma ograniczony wpływ na moment powstania obowiązku w podatku VAT należnym[1], czy prawa do odliczenia VAT naliczonego. Co więcej, w momencie składania pliku JPK_VAT za dany okres sprawozdawczy faktury w dużej mierze nie są jeszcze uregulowane (efekt stosowania dłuższych terminów płatności), stąd data zapłaty często byłaby pusta. Uwzględnienie takiej danej w zakresie raportowania JPK_VAT rodziłoby też pytanie, czy w przypadku finalnego uregulowania faktury, należy składać korekty plików JPK_VAT za przeszły okres sprawozdawczy (korekta mająca na celu ujęcie daty zapłaty, nieujawnionej w momencie składania pliku pierwotnego).
Dodatkowo, istnieje problem ograniczonego dostępu do ww. danych w systemach księgowych. Zmiany w systemach księgowych niezbędne dla potrzeb spełniania takiego dodatkowego wymogu mogłyby być nieproporcjonalnie kosztowne.
Mając na względzie powyższe, w naszej ocenie nie jest wskazane wprowadzanie daty i sposobu zapłaty do katalogu informacji ujawnianych w pliku JPK_VAT.
8. Rodzaj transakcji
Ministerstwo Finansów zasugerowało możliwość dodania do struktury plików JPK_ VAT informacji o oznaczeniu rodzaju transakcji. Dla oceny przydatności / zasadności wprowadzenia tej modyfikacji, istotne jest w pierwsze kolejności ustalenie typu informacji, która miałaby zostać uwidoczniona
w takim polu.
Jeżeli przez „rodzaj transakcji" rozumieć należy oznaczenie klasyfikacji transakcji dla potrzeb VAT (np. import usług, wewnątrzwspólnotowe nabycie towarów itp.), wówczas taka informacja może okazać się przydatna dla potrzeb kontroli plików JPK_VAT, w szczególności w odniesieniu do zapisów w sekcji dla podatku naliczonego (gdzie na podstawie alokacji kwot do pól „K" nie można wprost ustalić kategorii VAT transakcji, nawet posiłkując się informacją o NIP dostawcy).
Natomiast, jeżeli intencją Ministerstwa Finansów jest rozszerzenie danych raportowanych w pliku JPK_VAT o opis przedmiotu transakcji (tj. rodzajową nazwę towaru lub usługi, będącej przedmiotem obrotu opodatkowanego), taką propozycję oceniamy negatywnie. Oznaczałoby to konieczność raportowania informacji w pliku JPK_VAT w rozbiciu na pozycje faktury (zarówno sprzedażowe jak
i zakupowe - każdy towar / usługa musiałaby być pokazywana w oddzielnym wierszu). To rodzi istotne problemy praktyce i wiązałoby się z koniecznością istotnego przemodelowania rozwiązań informatycznych dedykowanych do obsługi sprawozdawczości VAT z uwzględnieniem plików JPK_VAT.
9. Dokumenty transportowe
W odniesieniu do wskazanych w piśmie MF propozycji uwzględniania w pliku JPK_VAT dodatkowych danych procesów logistycznych związanych z dokonywaniem sprzedaży towarów, takich jak np. dane (numer) dokumentów transportowych, pragniemy podkreślić, że w praktyce najczęściej tego typu dodatkowe informacje nie są rejestrowane bezpośrednio w systemach księgowych, stąd też mogą pojawić się istotne trudności w generowaniu raportów uwzględniających np. numer dokumentu transportowanego przyporządkowanego do danej faktury. Śledzenie procesu wysyłki
i ewidencjonowanie dowodów zrealizowania transport to procesy zazwyczaj realizowane poza środowiskiem systemów księgowych, z wykorzystaniem zewnętrznych źródeł i baz danych. Często też tego typu informacje są generowane i przechowywane w formie papierowej. Konieczność raportowania takich informacji wymagałaby często praco- i kosztochłonnego dostosowania systemów księgowych. Stąd, w naszej ocenie nie jest wskazane rozszerzenie zakresu raportowania w pliku JPK_VAT o numer dokumentu transportowego.
10. Data sprzedaży dla faktur zakupu i sprzedaży
a) Data sprzedaży dla faktur zakupu
W pkt III. 2 Zawiadomienia, wskazano propozycję rozszerzenia schemy JPK_VAT o datę sprzedaży dla otrzymywanych przez podatnika faktur zakupowych, wskazując, że jest to informacja konieczna dla prawidłowego określenia momentu powstania prawa do odliczenia podatku naliczonego.
Omawianą propozycję oceniamy negatywnie, mając na względzie zarówno kwestie praktyczne związane z dostępnością takiej informacji, jak i jej faktyczną przydatność takiej dodatkowej informacji w kontekście weryfikacji momentu odliczenia VAT naliczonego.
Zarówno specyfikacje systemów księgowych, jak i doświadczenia podatników potwierdzają, że zakres danych rejestrowanych w systemach księgowych w przypadku faktur zakupowych jest ograniczony w porównaniu do zakresu danych o fakturach sprzedażowych, dostępnych w takich systemach.
W większości systemów księgowych przy rejestrowaniu faktur zakupowych w modułach finansowych wprowadzane są informacje w zakresie niezbędnym do zaksięgowania transakcji i jej rozliczenia dla potrzeb rachunkowo-podatkowych. Często też w systemach brak jest możliwości odrębnego (od daty dokumentu, daty księgowania czy tzw. daty VAT) rejestrowania daty sprzedaży (określonej przez dostawcę) dla faktury zakupowej.
Należy również podkreślić, że w przypadku rejestrowania faktur zakupowych, nabywca nie ma (w przeciwieństwie do faktur sprzedażowych) pewności co do rzetelności danych umieszczanych przez dostawcę. W szczególności, jeżeli dostawca nie ujawni daty sprzedaży, nabywca nie ma pewności czy jest to zaniechanie ze strony dostawcy, czy też skutek wystawienia faktury w dacie zbieżnej z datą sprzedaży (w tym przypadku nie ma konieczności podawania odrębnie daty sprzedaży na fakturze).
Oceniając przydatność daty sprzedaży z faktury zakupowej dla potrzeb weryfikacji momentu odliczenia podatku VAT naliczonego, warto nadmienić, że zgodnie z zasadą określoną w art. 86 ust. 10 i nast. Ustawy o VAT, prawo do odliczenia podatku VAT naliczonego powstaje w momencie, w którym powstaje obowiązek podatkowy u dostawcy (co do zasady - data sprzedaży), ale nie wcześniej niż w momencie otrzymania faktury przez nabywcę. W praktyce, stosując modelowy obieg faktur, podatnicy odliczają VAT dopiero będąc w posiadaniu faktur (a więc po ich otrzymaniu,
w momencie księgowania), który to moment najczęściej występuje po dokonaniu sprzedaży przez dostawcę (i jest zbliżony bardziej do daty księgowania faktury w systemie).
Ewentualna rejestracja daty sprzedaży z faktury zakupowej w pliku JPK_VAT mogłaby mieć znaczenie wyłącznie dla potrzeb ustalenia, czy podatnik nie dokonał przedwczesnego odliczenia podatku VAT. Należy podkreślić, że taki test może być wykonany tylko wtedy, gdy data sprzedaży istnieje (została określona przez dostawcę) i jest rzetelna, (co trudno ocenić nabywcy). Ponieważ, musiałoby by być to pole fakultatywne (nie zawsze dostawca podaje datę sprzedaży), użyteczność takiej informacji w kontekście identyfikacji zbyt wczesnego odliczenia VAT naliczonego, byłaby ograniczona. Podobny test można wykonać, za podstawę przyjmując datę dowodu zakupu (datę faktury) - po pierwsze dlatego, że data faktury jest w wielu przypadkach zbieżna lub zbliżona do daty dokonania dostawy,
a po drugie - w przeciwieństwie do daty sprzedaży, data wystawienia faktury jest zawsze znana, powszechnie dostępna w systemach księgowych, oraz stanowi obligatoryjny element informacji
o fakturach w obecnej wersji pliku JPK_VAT.
Reasumując, negatywnie oceniamy propozycję uwzględnienia w pliku JPK_VAT daty sprzedaży dla faktur zakupowych. Koszty i konsekwencje wprowadzenia takiego obowiązku po stronie podatników byłyby nieproporcjonalne do potencjalnych korzyści płynących z dostępu do takiej informacji z poziomu pliku JPK_VAT. Rolę przypisywaną dacie sprzedaży w kontekście weryfikacji prawa do odliczenia VAT z faktur zakupowych, pełnić mogą zbliżone daty dowodu sprzedaży (data wystawienia faktury, obecna już w pliku JPK_VAT), poprzez porównanie ich z datą otrzymania faktury lub datą księgowania (której wprowadzenie do pliku JPK_VAT proponujemy poniżej) oraz okresem za który generowany jest plik JPK_VAT.
b) Data sprzedaży dla faktur sprzedaży
W obecnej wersji pliku JPK_VAT, podatnicy zobowiązani są do wykazywania daty sprzedaży towarów/usług w sekcji dla podatku należnego. Jest to pole warunkowo opcjonalne, tj. podatnicy nie są zobowiązani do raportowania tej informacji tylko w przypadku gdy data sprzedaży jest tożsama z datą wystawienia faktury sprzedaży.
Ponadroczne praktyczne doświadczenia w obszarze raportowania dla potrzeb JPK_VAT wskazują na istotne trudności w dochowaniu wymogu uwidacznia daty sprzedaży w sekcji dla podatku należnego. Są one związane zarówno z problematyką ograniczonej dostępności tych danych w modułach finansowych systemów ERP, jak wątpliwościami w zakresie zasad wypełniania tego pola odpowiednią datą w pewnych szczególnych przypadkach.
W modułach systemów księgowych dedykowanych do raportowania dla potrzeb rachunkowości, podatków czy plików JPK_VAT często brak jest dostępu do informacji odpowiadające dacie sprzedaży. Popularne systemy klasy ERP pozwalają na raportowanie w modułach finansowych informacji o dacie faktury, dacie jej zaksięgowania, dacię ujęcia dla celów rozliczeń VAT (tzw. data VAT), ale nie udostępniają informacji logistycznych (np. daty wydania). Uwzględnienie realnej daty sprzedaży wymaga często dokonywania nadmiernych (nieproporcjonalnych) nakładów pracy i kosztów, celem wygenerowania dodatkowych raportów wiążących dane z modułu księgowego z danymi z modułów odpowiedzialnych za procesy logistyczne lub fakturowanie.
Dodatkowo, istnieją istotne wątpliwości co do prawidłowości raportowania informacji w tym polu, w szczególności w przypadku faktur korygujących (czy stosować tutaj datę sprzedaży określoną dla pierwotnej transakcji czy datę bieżącą, i czy przyczyna korekty może mieć wpływ na wyznaczenie właściwej daty sprzedaży), lub faktur (w tym faktury korygujących) zbiorczych (które odwołują się do wielu dostaw o różnych datach sprzedaży).
W kontekście merytorycznej weryfikacji plików JPK_VAT i kontroli wykonywanych w tym zakresie, data sprzedaży może mieć znaczenie przy weryfikacji momentu rozpoznania obowiązku podatkowego w podatku VAT należnym, niemniej jednak tego typu testy można wykonać (przy pewnych założeniach) również w oparciu o (obligatoryjną w obecnej wersji schemy JPK_VAT) datę dowodu sprzedaży czy datę księgowania transakcji (której wprowadzenie rekomendujemy poniżej).
Mając na względzie powyższe, postulujemy usunięcie w nowej wersji schemy JPK_VAT pola dedykowanego do rejestrowania daty sprzedaży w sekcji dla podatku należnego.
11. Data księgowania transakcji
W kontekście planowanych zmian w strukturze plików JPK_VAT można rozważyć dodanie informacji o dacie księgowania faktury.
Data księgowania może stanowić substytut daty wpływu faktury zakupu w pliku JPK_VAT (jako data fizycznie najbardziej zbliżona do daty wpływu faktury) w przypadkach, gdy data wpływu (jako pole opcjonalne w JPK_VAT) nie jest uzupełniania. Analogicznie, data księgowania po stronie podatku należnego może pełnić funkcję subsydiarną wobec daty sprzedaży, która jest polem nieobligatoryjnym, i której dostępność z poziomu raportów systemów księgowych często jest ograniczona.
Uwzględnienie w pliku JPK_VAT daty księgowania może być pomocne przy identyfikacji tych faktur/transakcji, które były podstawą złożenia korekty rozliczeń VAT za dany okres sprawozdawczy (jeżeli data księgowania dla transakcji przypada później niż termin na złożenie deklaracji za dany okres, to mamy do czynienia z transakcjami, z powodu których składane są korekty deklaracji).
Należy również podkreślić, że data księgowania jest podstawowym kryterium generowania danych w pliku JPK_KR, oraz jest w tej schemie ujawniana. Uwzględnienie też informacji również w pliku JPK_VAT pozwoli na korzystanie z daty księgowania jako jednego z parametrów kluczowych analizy porównawczej pomiędzy plikami JPK_VAT oraz JPK_KR.
Uwzględniając potrzeby Ministerstwa Finansów w zakresie zwiększenia efektywności kontroli danych w plikach JPK_VAT, w naszej ocenie można rozważyć dodanie daty księgowania faktury do sekcji dla podatku należnego i naliczonego pliku JPK_VAT.
12. Zmiana funkcji schemy JPK_VAT (przejęcie funkcji deklaracji VAT)
Pozytywnie oceniamy zasygnalizowaną w Zawiadomieniu MF koncepcję likwidacji w dłuższej perspektywie czasowej obowiązku składania deklaracji VAT-7 i przejęciu jej roli przez plik JPK_VAT.
Obecnie podatnicy składają trzy główne typy deklaracji (VAT-7, VAT-UE oraz VAT-27), zawierające na poziomie agregatów informacje odpowiadające dokładnie danym, prezentowanym na poziomie transakcyjnym w składanych za ten same okresy sprawozdawcze plikach JPK_VAT. Likwidacja obowiązku składania deklaracji VAT-7, VAT-UE, VAT-27 może przyczynić się do zmniejszenie pracochłonności comiesięcznego raportowania podatkowego w firmach.
W naszej ocenie likwidacja obowiązków sprawozdawczych na rzecz składania rozszerzonej wersji pliku JPK_VAT powinna przebiegać stopniowo. W pierwszej kolejności można by rozważyć likwidację obowiązku składania deklaracji VAT-27 oraz VAT-UE już od 1 stycznia 2018 r.
W chwili obecnej dane prezentowane w pliku JPK w zakresie dostaw, dla których podatnikiem jest nabywca są tożsame z danymi (zagregowanymi per kontrahent) w deklaracji VAT-27. Z kolei w przypadku deklaracji VAT-UE, jedyną informacją, której brakuje w obecnej wersji schemy JPK_VAT jest oznaczenie tzw. transakcji trójstronnej w roli tzw. pośrednika (art. 136 ustawy o VAT). W przypadku dodania tego oznaczenia na poziomie wierszy w nowej wersji schemy JPK_VAT (której publikacja planowana jest na 1 stycznia 2018 r.), brak jest w naszej ocenie potrzeby składania deklaracji VAT-UE i VAT-27, ze względu na powielenie danych.
Należy jednocześnie mieć na względzie, że obowiązek składania deklaracji VAT-UE wynika z przepisów art.262-266 Dyrektywy Rady 2006/112/WE z dnia 28 listopada 2006 r. w sprawie wspólnego systemu podatku od wartości dodanej. Co prawda dane uwidaczniane w pliku JPK_VAT w zakresie transakcji wewnątrzwspólnotowych są bardziej szczegółowe niż informacje wymagane przez ww. przepisy Dyrektywy, niemniej jednak dyskusyjne pozostaje, czy w związku z koniecznością comiesięcznego przedkładania plików JPK_VAT, Państwo Członkowskie mogłoby zrezygnować z nakładania na podatników obowiązku składania dodatkowo informacji podsumowującej.
Likwidację obowiązku składania deklaracji VAT-7 można rozważyć po rozbudowie schemy JPK_VAT (w szczególności sekcji podsumowującej) w taki sposób, aby podatnicy mieli możliwość pozyskania szybkiego dostępu do zagregowanych danych wpływających na rozliczenia VAT, bez konieczności analizy poszczególnych transakcji uwidacznianych w głównej części pliku JPK_VAT. W tym celu proponujemy rozszerzenie sekcji podsumowującej pliku JPK_VAT o:
- sumy kontrolne częściowe (odpowiednio sumy kwot netto i VAT) dla każdego pola typu „K"
- suma kontrola ogółem dla kwoty netto po stronie podatku należnego
- pole edytowalne, umożliwiające wprowadzenie/pobranie kwoty podatku VAT naliczonego z przeniesienia z poprzedniego okresu rozliczeniowego
- pola do rejestracji kwot do zwrotu oraz trybu zwrotu (zwykły, przyśpieszony)
- kalkulowane automatycznie po wprowadzeniu ww. danych kwoty: (i) nadwyżki podatku naliczonego nad należny; (ii) nadwyżki podatku do przeniesienia na kolejny okres oraz (iii) kwoty wpłaty do urzędu skarbowego.
Pragniemy podkreślić, że ewentualne przejęcie przez plik JPK_VAT funkcji i roli deklaracji VAT, powinno się wiązać z odpowiednimi zmianami legislacyjnymi, w tym z obowiązkiem przeniesienia do ustawy podatkowej oraz rozporządzeń szczegółowych informacji i wymogów dotyczących zakresu informacji wykazywanych w pliku JPK_VAT (obecnie zakres obowiązków sprawozdawczych w tym zakresie wynika ze specyfikacji technicznej schemy XML).
13. Inne uwagi
Uważamy za uzasadnione wprowadzenie narzędzia, które umożliwiałoby podatnikom samodzielną walidację/weryfikację JPK w zakresie raportowanych numerów NIP dostawców przed wysyłką JPK do MF. Obecne rozwiązanie dostępne na stronach MF umożliwia zweryfikowanie pojedynczego dostawcy. Zważywszy na ilość transakcji, obecne rozwiązanie nie jest wystarczające. Obecnie widoczne jest, że w ramach weryfikacji JPK organy podatkowe głównie skupiają się na weryfikacji kontrahentów podatników. Wychodząc więc naprzeciw oczekiwaniom podatników i przyczyniając się do skutecznej, efektywnej analizy danych przez nich samych, naszym zdaniem, MF powinno przede wszystkim rozważyć rozszerzenie funkcjonalności JPK o weryfikację numerów NIP na etapie wysyłki JPK przez podatnika. Wprowadzenie takiego rozwiązania byłoby korzystne dla organów podatkowych (zmniejszenie nakładu pracy, mniejsza liczba wezwań) oraz dla budżetu państwa (ewentualna korekta VAT odliczonego od nie podatnika VAT w wyniku samokontroli przez podatnika).
Konfederacja Lewiatan
KL/345/112/1340/PP/2017
[1] z wyjątkiem transakcji wymienionych w art. 19a ust. 5 pkt 1 i 2 oraz 19a ust. 8 Ustawy o VAT, w przypadku, których obowiązek podatkowy powstaje w momencie otrzymania całości lub części zapłaty
