Identyfikacja nadużyć w rozliczaniu podatku VAT. Z wykorzystaniem IDEA CaseWare

Transkrypt

1 Identyfikacja nadużyć w rozliczaniu podatku VAT Z wykorzystaniem IDEA CaseWare

2 Już niebawem wszystkie firmy będą musiały przekazywać fiskusowi bardzo szczegółowe dane finansowo-księgowe i handlowe. Wszystkie dane będą przesyłane według jednolitego formatu elektronicznego. To ogromnie ułatwi i przyspieszy kontrole i da dodatkowe wpływy do budżetu. Dotychczas było tak, że jeśli fiskus chciał przebadać firmę, to wysyłał do niej kontrolę, która oglądała dokumenty, faktury i księgi rachunkowe. Jednolity Plik Kontrolny (JPK), bo tak to się nazywa, ma ruszyć już 1 lipca 2016 r. Ma pomóc w walce z luką w VAT. Z wyliczeń jednej z firm doradczych wynika, że różnica między tym, co hipotetycznie z tego podatku powinno wpłynąć do budżetu państwa, a tym, co do niego wpływa - urosła w 2015 r. do 53 mld zł. To 3 proc. polskiego PKB. Dzięki rozwiązaniu z zastosowaniem jednolitego pliku model kontroli całkowicie się zmieni i znacznie przyspieszy. Ale aby skutecznie przetwarzać tak dużą liczbę danych z wszystkich przedsiębiorstw konieczne jest skuteczne i szybkie narzędzie informatyczne. Pracownicy audytu i kontroli powinni szczególnie docenić rozwiązanie o nazwie IDEA. Na przykładzie rejestru transakcji kupna-sprzedaży z różnych firm wskażemy jak łatwo i intuicyjnie wychwycić błędy w naliczaniu VAT, a także zidentyfikować fikcyjne faktury służące do wyłudzenia podatku VAT. W tym celu zaimportujemy rejestr transakcji podatku VAT pochodzący z różnych przedsiębiorstw. Przykładowa postać takiej bazy może być taka jak zaprezentowana poniżej. W pierwszej kolumnie mamy wskazaną oznaczenie przedsiębiorstwa od którego pochodzi raport. W kolumnie sprzedający i kupujący mamy wskazane oznaczenie naszych przedsiębiorstw. Przydatna dla naszej analizy jest również informacja o numerze faktury. W 2

3 dalszej części mamy szczegółowe informacje o kwocie brutto, netto, oraz stawce i wartości podatku VAT. Do celów naszej analizy konieczne będzie zebranie pozyskanych z przedsiębiorstw rejestrów kupna-sprzedaży do jednej wspólnej bazy. W tym celu wybieramy moduł o nazwie Append a następnie wskazujemy interesujące nas raporty. W jednej chwili wszystkie transakcje przedsiębiorstw zostały zebrane do wspólnej bazy. Teraz z naszej bazy oddzielimy transakcje które zostały odpowiednio zadeklarowane przez stronę kupującą i stronę sprzedającą. W tym celu klikamy na moduł o nazwie Direct, a następnie w edytorze równań wskazujemy jako kryterium: ŹRÓDŁO_PLIKU == SPRZEDAJĄCY Tak uzyskujemy wszystkie raporty pozyskane od wystawcy faktury. Dla strony kupującej postępujemy analogicznie przy czym tym razem w edytorze równań wskazujemy jako kryterium: ŹRÓDŁO_PLIKU == KUPUJĄCY 3

4 Przechodzimy do identyfikacji transakcji, które zostały zadeklarowane przez sprzedawcę, ale równocześnie nie mają odzwierciedlenia po stronie kupującego. Takie operacje mogą być przesłanką istnienia oszustw podatkowych mających na celu wyłudzenie podatku VAT. W tym celu otwieramy uzyskaną przed chwilą bazę transakcji od strony kupujących, a następnie uruchamiamy moduł Join. W oknie dialogowym wskazujemy z jaką bazą połączymy. Klikamy więc na przycisk Select, a następnie wskazujemy zadeklarowane operacje strony sprzedającej. Opisujemy również sposób łączenia obu tabel poprzez kliknięcie na przycisk Match. Tutaj wskazujemy na trzy pary łączenia, każdorazowo łączymy obie bazy według kolumny sprzedawcy, kupującego i numeru faktury. A ponieważ interesują nad takie transakcje, które zadeklarowano po stronie kupującego, a nie odnotowano po stronie sprzedającego więc dodatkowo zaznaczymy opcję Records with no secondary math. 4

5 W ten oto intuicyjny sposób zidentyfikowaliśmy dwie faktury, które zostały zadeklarowane po stronie kupującego, gdy równocześnie po stronie sprzedającego takich transakcji nie odnotowano. Jak widzimy firma A zadeklarowała transakcje kupna na łączną kwotę PLN dla której przypisany jest łączna kwota podatku naliczonego VAT w kwocie PLN. W tej sytuacji nasz przedsiębiorca może żądać od Urzędu Skarbowego uzyskania zwrotu podatku naliczonego. A ponieważ zidentyfikowane transakcje nie zostały zadeklarowane po stronie sprzedającego istnieją silne przesłanki d stwierdzenia, że mamy do czynienia z próbą wyłudzenia podatku VAT. 5

6 Oprogramowanie IDEA umożliwia identyfikacje nie tylko brakujących par transakcji kupnasprzedaży, ale również wyszukanie błędnie wyliczonego podatku. W tym celu ponownie otwieramy uzyskane zestawienie transakcji strony kupującej, a następnie uruchamiamy moduł join według poniższego schematu 6

7 Tym razem opcja Match only umożliwiła połączenie transakcji zadeklarowanych po stronie kupującego z odpowiednio przypisanymi transakcjami po stronie sprzedającego. Na koniec nie pozostaje nam nic innego jak błyskawicznie zidentyfikować błędne kwoty podatku. Uzyskujemy to poprzez zastosowanie modułu Direct, oraz użycie prostego wzoru na niezgodność podatku VAT zgodnie z poniższym slajdem: Jak widzimy w dwóch przypadkach zidentyfikowano po stronie sprzedającego i kupującego różne stawki i kwoty podatku VAT. Analogiczne badania możemy także wykonać dla sprawdzenia zgodności kwot brutto i netto, ale również jeżeli takie kolumny będą dostępne dla dat transakcji, przedmiotu umowy kupna-sprzedaży itp. 7

8 Pamiętajmy by tego typu analizy wykonywać na wydajnym oprogramowaniu analitycznym. W grę wchodzą setki milionów transakcji z tysięcy firm, to sprawia że narzędzie musi sprostać wysokim wymogom obliczeniowym. Bez wątpienia przedstawione oprogramowanie IDEA spełnia oczekiwanie użytkowników a dodatkowo dzięki możliwości rejestracji badań za pomocą intuicyjnych w obsłudze skryptów pozwala zaoszczędzić czas użytkowników i zautomatyzować proces badawczy do jednego kliknięcia. 8