Co można zrobić w SAP, żeby podatki były łatwiejsze?
Przedsiębiorcy, szczególnie ci prowadzący działalność o charakterze globalnym, wykorzystują systemy klasy ERP (zintegrowane systemy zarządzania) pozwalające na zarządzenie procesami związanymi pośrednio i bezpośrednio z prowadzoną działalnością gospodarczą, np. magazyn, produkcja, sprzedaż, zakup, HR czy finanse. Dzięki zastosowaniu globalnych rozwiązań spółki mają jednolite podejście w procesie raportowania danych finansowych do grupy czy stosują jednolitą politykę magazynową, co pozwala w łatwy sposób porównywać wyniki w różnych krajach. Niestety ujednolicone podejście biznesowe posiada także swoje wady – trudność ich dostosowania do lokalnych wymogów, szczególnie prawno-podatkowych.
Prowadzenie działalności gospodarczej od zawsze związane jest z podejmowaniem ryzyka. Jednak w ostatnich kilku latach pojawił się dodatkowy czynnik ryzykotwórczy, mianowicie częstotliwość zmian podatkowych oraz konieczność ciągłego uwzględniania ich w procesach biznesowych, np. proces weryfikacji kontrahenta przez dokonaniem transakcji. Dlatego najważniejsze jest, by minimalizować poziom ryzyka. W przypadku obszaru technologicznego ryzyko można ograniczyć na wiele sposobów.
Pierwszych z nich jest wdrożenie dodatkowych aplikacji/modułów w systemie (znajdują się one w odrębnym namespace) i nie ingerują w zasadnicze rozwiązanie ERP. Co istotne, rozwiązania takie nie wymuszają zmian w ustawieniach podstawowych, a jedynie bazują na danych oraz parametrach już istniejących w systemie. Innymi słowy, dodatkowe narzędzia będą pobierały informacje z podstawowej bazy danych, ale nie będą ich modyfikowały. Narzędzia takie pozwalają na dostosowane do indywidualnych potrzeb klienta. Oczywiście implementacja dodatkowych aplikacji wymaga uprzedniej analizy funkcjonujących w przedsiębiorstwie procesów biznesowych oraz źródeł danych je odzwierciedlających w systemie ERP. Weryfikacja procesów w systemie z reguły przeprowadzana jest przez dostawcę systemu ERP oraz przedsiębiorcę – interdyscyplinarne zespoły specjalistów z zakresu prawa podatkowego oraz specjalistów IT. Taki model współpracy gwarantuje dostarczenie rozwiązania bezpiecznego nie tylko od strony programistycznej, ale również od strony prawnopodatkowej.
W teorii wdrożenie dodatkowych aplikacji wygląda bardzo dobrze. Jak jednak jest w praktyce? Aby lepiej to zobrazować, wypada omówić współistnienie dodatkowych aplikacji i rozwiązania głównego – ich plus oraz minusy – na podstawie realnych przykładów.
Problematyka niedopasowania systemów globalnych do wymogów krajowych nie jest tylko problemem polskich przedsiębiorców, czego najlepszym przykładem są wymogi dotyczące składania deklaracji VAT czy odmienne założenia dotyczące okresowego przekazywania danych z ksiąg podatkowych w formacie XML. Każdy kraj unijny przygotował własny wzór deklaracji odzwierciedlający bieżące potrzeby organów podatkowych, a tym samym brakuje możliwości zastosowania globalnego podejścia w zakresie raportowania podatkowego. W związku z czym w każdym kraju unijnym niezbędne jest wykorzystywanie obok standardowego – globalnego rozwiązania dodatkowych aplikacji/raportów pozwalających na zaraportowanie i sprawdzenie danych zgodnie z wymogami konkretnego ustawodawcy. Przedstawiony problem zostanie omówiony na przykładzie polskiego porządku prawnego. W ostatnich kilku latach ustawodawca wprowadził zmiany podatkowe mające na celu otrzymywanie danych od podatników w ustrukturyzowanej formie (m.in. digitalizacja deklaracji i sprawozdań podatkowych, wprowadzenie JPK czy wprowadzenie nowych deklaracji ALK-1).
Posłużymy się raportem, jaki muszą składać przedsiębiorcy w okresach miesięcznych lub kwartalnych – czyli plików JPK_V7M/JPK_V7K. Obecna wersja ewidencji VAT, którą należy składać do szefa KAS, obliguje przedsiębiorców do przekazywania informacji nie tylko o stronach transakcji, ich wartościach oraz datach, ale także do oznaczania grup GTU, procedur czy typów dokumentów. Informacje takie przed październikiem 2020 r. nie były przechowywane w systemach finansowo-księgowych. Tym samym wprowadzony przez MF wymóg wymusił na przedsiębiorcach przechowywanie nowych informacji, które standardowo nie są przechowywane w tabelach systemowych, lub wykorzystanie dostępnych w systemie informacji. Aby sprostać nowym wymogom, można było wykorzystać pola istniejące w systemach finansowo-księgowych, ale dotychczas nieużywane, np. pozwalając na wpisanie oznaczeń grup GTU czy procedur. Na tej podstawie program odczytywał dane z pola i odpowiednio oznaczał dokument w raporcie JPK. Alternatywnie można było utworzyć nowe pole lub zakładki w dokumencie księgowym, które pozwalałyby na wskazanie nowych informacji.
W przypadku gdy firma nie miała możliwości dodania nowych funkcjonalności na poziomie księgowania dokumentu, alternatywą były dodatkowe raporty, w których użytkownik mógł manualnie oznaczyć transakcje gospodarcze wszystkimi procedurami podatkowymi, którym podlegała. Oczywiście takie rozwiązanie wydaje się słuszne w przypadku transakcji, które występują sporadycznie i nie posiadają specyficznych parametrów, które jednoznacznie wyróżniałyby rodzaj procedury dla JPK.
Manualne oznaczanie dokumentów jest swego rodzaju wyjściem awaryjnym dla systemów, w których trudno przeprowadzić automatyzację przy wykorzystaniu istniejących parametrów oraz schematów księgowań.
Innym rozwiązaniem była implementacja dodatkowych aplikacji do generowania JPK V7M/JPK_V7K, które bazowały na danych istniejących w systemach, co nie wymuszało na przedsiębiorcach konieczności zmian w systemie głównym. Poprzez wykorzystanie parametrów stosowanych w dotychczasowych procesach biznesowych można było dokonać prawidłowych oznaczeń w raporcie VAT. Na przykład do oznaczenia grup GTU można było się posłużyć indeksem magazynowym sprzedanego wyrobu/towaru, numerem kodu CN lub PKWiU. Do oznaczenia pozostałych procedur w JPK V7M/JPK V7K można było wykorzystać m.in.: numery kont księgowych, rodzaje dowodów księgowych, grupy odbiorców (np. dla transakcji z jednostkami powiązanymi), formy płatności (np. dla MPP) czy inne dane parametry, charakterystyczne dla danej procedury. Oczywiście często zdarzało się, że były to połączenia kliku parametrów, a kombinacji pobierania i łączenia danych było naprawdę wiele. Aplikacje do generowania JPK musiały zatem być elastyczne, tak aby dawały się dostosować do indywidualnych potrzeb klienta oraz wymagań systemów źródłowego. Niekiedy dla automatyzacji procesu prawidłowego oznaczania dokumentów w JPK V7M/JPK V7K firmy decydowały się na utworzenie nowych parametrów w systemie, takich jak: rodzaj dowodu księgowego, konto księgi głównej, indeks materiałowych lub kod podatku, jednoznacznie wskazujących na typ transakcji gospodarczej.
Przy implementacji narzędzi do raportowania JPK pojawiały się również wyzwania związane z posiadaniem przez firmy dodatkowych systemów zewnętrznych np. systemów billingowych, z których dane należało połączyć z danymi z systemu głównego. Zatem aplikacje do generowania JPK, powinny umożliwiać import danych z systemów zewnętrznych (np. poprzez import pliku w formacie CSV) i połączenie ich z danymi z systemu centralnego w jeden plik XML. Systemy billingowe również musiały zostać dostosowane do nowych wytycznych MF, ponieważ dane z nich pochodzące musiały zawierać informacje wymagane w schemie. Przy wprowadzeniu JPK_V7M okazało się, że nie tylko spełnienie wymagań nowego schematu VAT stanowi wyzwanie, lecz także sposób wysłania XML. Dotychczasowa bramka MF, Klient 2.0, została wyłączona. Nowa internetowa platforma wprowadziła ograniczenie w pojemności wysyłanych plików XML do 100 MB, co uniemożliwiło skorzystanie z niej przez duże firmy. Na szczęście MF dostarczyło specyfikację techniczna, która pozwoliła na budowę narzędzia do wysyłki raportów JPK. Wysyłka plików JPK bezpośrednio z systemu ERP ułatwia prace zespołom podatkowych, jednak największe znaczenie ma fakt, iż system ERP stanowi jednocześnie repozytorium danych wszystkich wysłanych plików do szefa KAS oraz dokumentów UPO. Działy księgowo-finansowe w łatwy sposób mogą pobrać i sprawdzić statusy wysłanych plików XML za poszczególne okresy rozliczeniowe.
Oczywiście JPK stanowi jeden z wielu przykładów rozwiązań informatycznych, które powinny być wdrożone w programach typu ERP, by wspierały one funkcję podatkową w przedsiębiorstwie. Innym przykładem realizacji obowiązków podatkowych w Polsce bezpośrednio w SAP mogą być rozwiązania do weryfikacji statusu numeru rachunku bankowego na białej liście podatników VAT czy chociażby automatyczna weryfikacja numerów VAT kontrahentów. Dodatkowo aplikacja taka może zostać rozbudowa o kolejne funkcjonalności, takie jak weryfikacja danych kontrahenta w bazie VIES, CEIDG czy nawet GUS oraz pobranie z nich danych teleadresowych naszych kontrahentów. Każda z małych funkcjonalności wdrożona w systemie finansowo-księgowym pozwala na zwiększenie bezpieczeństwa podatkowego i rozliczeń, minimalizuje pracę manualną i jednocześnie eliminuje element błędu związanego z ręczną weryfikacją danych. Realizacja nowych obowiązków prawnopodatkowych nie musi wiązać się z rewolucją w systemie do zarządzania przedsiębiorstwem. Niekiedy wystarczą dane, które znajdują się w naszych systemach i wykorzystujemy je w codziennej pracy.
Dlatego też warto zastanowić się nad wdrożeniem rozwiązań, które adresują m.in. wymagania w zakresie należytej staranności VAT, jak również pozwalają na jak najszerszą automatyzację procesów podatkowych. Co istotne, ważne by wdrażane rozwiązanie bazowało nie tylko na wiedzy IT, ale także odzwierciedlało wymogi prawne.