Podstawowym celem stawianym sobie przez każdą organizację w odniesieniu do księgowości jest zapewnienie zgodności własnych procedur z wymogami prawa oraz standardami księgowymi. Każde działanie w obszarze rachunkowości podlega mniej lub bardziej szczegółowym regulacjom, narzucającym pewien schemat działania i wyznaczającym obszar bezpiecznych zachowań. Tradycyjna księgowość wykształciła pewne rozwiązania, których celem było zagwarantowanie autentyczności zapisów księgowych, ich integralności oraz zapobieganie nadużyciom.

Innymi słowy, rachunkowość to nie tylko zbiór zasad dotyczących księgowania (ujmowania) operacji gospodarczych, lecz również reguły gwarantujące autentyczność poszczególnych zapisów. Wynika to z faktu, że punktem wyjścia do obliczania zarówno wyniku księgowego, jak i podatkowego, jest właśnie pojedynczy zapis, którego zmiana mogłaby bezpośrednio wpłynąć na sporządzane kalkulacje. Dlatego niezbędne było stworzenie takich metod, które prowadziłyby do maksymalizacji bezpieczeństwa danych, przy jednoczesnej minimalizacji dodatkowych nakładów pracy.

Istota dziennika

Jednym ze sposobów kontrolowania rozliczeń księgowych przedsiębiorcy jest dziennik. W ustawie o rachunkowości pojawia się on dwanaście razy, łącznie w pięciu artykułach, z czego siedem razy jest przywołany w art. 14, traktującym właśnie o dzienniku. To stosunkowo rzadko, zwłaszcza biorąc pod uwagę jak wiele problemów powoduje dziennik w obrębie Jednolitego Pliku Kontrolnego.

Dziennik jest niczym innym jak zestawieniem wszystkich zapisów księgowych. Za jego powstaniem stoi bardzo prosty cel: zagwarantowanie, że przedsiębiorca nie będzie dowolnie wprowadzał i następnie wykreślał poszczególne zapisy. W związku z tym ustanowiono zasadę, zgodnie z którą w dzienniku należy ujmować wszystkie zdarzenia gospodarcze, przy czym każde następne powinno być numerowane w kolejności, bez pomijania żadnego z numerów. Tym samym, w przypadku wykreślenia zapisu z dziennika powstaje prosta do identyfikacji luka. Jeżeli księgowań są tysiące, ukrycie (czyli de facto wykreślenie) jednego z nich wymagałoby poprawienia każdego kolejnego księgowania.

Oprócz dziennika wprowadzono też inne rozwiązania, jak chociażby storno, które umożliwia oficjalne wykreślenie zapisu. Niemniej, zastosowanie któregokolwiek z tych rozwiązań wymaga odnotowania w dzienniku. Pozostaje więc ślad, który umożliwia identyfikację zapisu, i jego datę, pokazuje chronologię zdarzeń i umożliwia powiązanie zapisu z odpowiednim dokumentem. W informatycznym żargonie dziennik nazwalibyśmy „logiem zmian" o niezwykle istotnej roli.

Dziennik powstał kilkaset lat temu. Stanowił część tzw. metody włoskiej księgowości, czyli najstarszej ze szkół rachunkowości, która wywodzi się z północnych republik Italii. Pierwotnie miał postać skórzanej księgi z ponumerowanymi stronami, co uniemożliwiało wyrwanie kartek. Księgowy wpisywał dane zdarzenie, a drugi raz ten sam wpis odnotowywał w dzisiejszym odpowiedniku księgi głównej. Co więcej, zdarzenie gospodarcze w dzienniku nie było ujmowane w postaci samych liczb. Obowiązkiem księgowego było stworzenie sentencji, w której miał opisać istotę samej transakcji.

Wraz z pojawieniem się coraz bardziej nowoczesnych metod księgowania, dziennik ewoluował. Jego rola się jednak nie zmieniła: wciąż stanowi gwarancję niezmienności zapisów.

Wymogi przewidziane prawem

Zgodnie z ustawą o rachunkowości, poszczególne zapisy księgowe ujmowane są równocześnie w dwóch miejscach. Pierwszym jest dziennik, a drugim konto księgi głównej, na którym należy ująć zapis zarejestrowany uprzednio lub równocześnie w dzienniku. W obu miejscach zapisy ujmowane są chronologicznie, przy czym słowo to ma nieco odmienne znaczenie w odniesieniu do każdego z nich.

Chronologia w przypadku dziennika oznacza kolejne ujmowanie wszystkich zapisów, natomiast w przypadku konta księgi głównej chronologią objęte są tylko zapisy w ramach tego samego konta. Tym samym, dziennik zawiera chronologię wszystkich zapisów, natomiast konto ujmuje tylko te transakcje gospodarcze, które w swojej istocie powinny zostać na nim zaksięgowane.

Z punktu widzenia procesów cyfryzacji, dotychczas istniał tylko jeden przepis, który bezpośrednio łączył dziennik z wymogami stawianymi programom komputerowym. Mowa tu o art. 14 ust. 4 ustawy o rachunkowości, zgodnie z którym „Przy prowadzeniu ksiąg rachunkowych przy użyciu komputera zapis księgowy powinien posiadać automatycznie nadany numer pozycji, pod którą został wprowadzony do dziennika, a także dane pozwalające na ustalenie osoby odpowiedzialnej za treść zapisu".

Geneza tego przepisu wypływa z konieczności znalezienia alternatywy dla dotychczasowych, papierowych rozwiązań. W przypadku tradycyjnego dziennika funkcję gwarancyjną spełniały dotychczas rubryki i wiersze, z których każdy musiał zostać zapełniony i osobno ponumerowany. Brak możliwości przesuwania poszczególnych wierszy, dodawania pól czy tworzenia kolumn skutkował tym, że nie istniała potrzeba wprowadzania dodatkowych zabezpieczeń.

Cyfryzacja dziennika

Przeniesienie dziennika do rzeczywistości cyfrowej wymusiło znalezienie rozwiązania, które zastąpi dotychczasowe, tradycyjne sposoby zabezpieczania dziennika. Program komputerowy operuje na wirtualnej bazie danych, która jest uporządkowanym zbiorem informacji. Problem polega na tym, że nie musi to oznaczać porządku w klasycznym rozumieniu.

Konstrukcje programów komputerowych opierają się na zbiorach logicznych uporządkowanych według pewnych z góry narzuconych reguł. Najlepszym przykładem takiego uporządkowania może być system księgowy, który posiada osobny moduł zakupów i sprzedaży. Transakcje przenoszone są do księgi głównej za pomocą paczek, czyli zbiorów danych zagregowanych według klucza daty. Oznacza to, że jedna paczka zawiera dane pochodzące z danego okresu, na przykład jednej godziny lub jednego dnia.

Skomplikowane systemy księgowe stały się już codziennością w większych przedsiębiorstwach. Ustawodawca stanął więc przed wyzwaniem znalezienia rozwiązania, które zapewni integralność danych również przy wielomodułowych rozwiązaniach.

Jednolity Plik Kontrolny

1 lipca 2016 r. wprowadzono obowiązek przekazywania na żądanie organów podatkowych Jednolitego Pliku Kontrolnego dla ksiąg rachunkowych. Wymogi stawiane tam przed dziennikiem okazały się trudne do spełnienia. Ministerstwo Finansów oczekuje zaraportowania w strukturze JPK_KR zbiorów danych, jak mogłoby się wydawać, łatwych do wyciągnięcia z systemu. Jednak w praktyce to tylko pozory.

Z logicznej struktury JPK_KR wynika, że w sekcji Dziennik struktury Księgi Rachunkowe podatnik jest obowiązany do zaraportowania jedenastu odrębnych pozycji, podczas gdy z ustawy o rachunkowości nie wynika wprost zakres danych, które powinny być ujmowane w dzienniku. Takie rozwiązanie wprowadziło konsternację wśród wielu przedsiębiorców. Zaskoczenie spotęgował brak oparcia tego wymogu w regulacjach rangi ustawowej.

Podstawową trudnością okazała się konieczność ujmowania w dzienniku danych, które często agregowane są w wielu tabelach w bazach danych programów księgowych. Wiele problemów stworzyła też konieczność podania takich podstawowych danych jak chociażby numer dziennika.

Numer dziennika

Przytoczona powyżej regulacja zawarta w art. 14 ust. 4 ustawy o rachunkowości narzuca podatnikowi obowiązek:

a) automatycznego nadawania numeru każdego kolejnego zapisu oraz

b) wskazanie osoby odpowiedzialnej za wpis.

Już na tym etapie pojawiły się problemy praktyczne, które do dnia publikacji struktury JPK Księgi Rachunkowe nie były eksponowane.

Problem z numeracją pozycji w dzienniku pojawia się nie tylko na gruncie modułowości programów księgowych, choć tam jest on najlepiej widoczny. W programach modułowych pojawia się również kwestia wskazania osoby odpowiedzialnej za wpis. O ile bowiem agregacja danych do paczek przenoszonych pomiędzy modułami odbywa się zazwyczaj w trybie dziennym, co wyklucza problem daty (ponieważ każda paczka zawiera dane dotyczące tego samego dnia), o tyle w ramach jednej paczki mogą być zawarte pozycje wprowadzone do systemu przez różne osoby. Nie dość tego, często systemy księgowe oznaczają takie paczki, zaimportowane do księgi głównej, jako wprowadzone do systemu przez użytkownika wirtualnego (importera).

W związku z tym zagadnieniem pojawia się także pytanie o możliwość powiązania paczki z numerem dowodu księgowego (art. 14 ust. 2 ustawy o rachunkowości). Brak jest w tym zakresie jednoznacznych odpowiedzi Ministerstwa Finansów. Co więcej, z logicznego i prawnego punktu widzenia, przedsiębiorca musi mieć możliwość powiązania konkretnej pozycji w dzienniku ze specyficznym dowodem księgowym, który jest podstawą dla tego zapisu. W przypadku modułowości programy księgowe udostępniają możliwość szybkiego sprawdzenia zawartości paczki, poprzez wprowadzenie w odpowiednim module numeru takiej paczki. Z punktu widzenia JPK, nie ma miejsca na wprowadzenie takich danych, ponieważ struktura wymaga zero-jedynkowych odpowiedzi i jasnego udostępniania danych.

Podobny problem pojawia się w odniesieniu do trzech rodzajów dat, które należy podać wraz z każdą pozycją dziennika: Daty Operacji, Daty Księgowania i Daty Dowodu Księgowego. Z perspektywy systemów księgowych, dysponując numerem dziennika podatnik może w prosty sposób, za pomocą odpowiednich komend, wywołać tabele zawierające każdą z tych trzech dat. Wątpliwości pojawiają się w momencie, w którym wszystkie trzy daty należy ująć w jednej tabeli.

Konstrukcja bazy danych programów księgowych polega na wyodrębnieniu różnych tabel zawierających określone dane. Pomiędzy nimi występują tzw. klucze łączące dane w jedną całość. Zazwyczaj takim kluczem jest numer dokumentu, często tożsamy z numerem dziennika. Oznacza to, że część danych może być zawarta w jednej tabeli, a część w innej. Trzy daty, wymagane przez plik JPK, mogą być ujęte w dwóch różnych tabelach jednego systemu.

Aby stworzyć plik JPK_KR, należy wyodrębnić te tabele (zazwyczaj za pomocą odrębnych transakcji), następnie zidentyfikować wymagane dane tak, aby na końcu skompilować je w jednej tabeli. O ile przy kilkudziesięciu, czy nawet kilkuset transakcjach takie rozwiązanie nie sprawia większych kłopotów, o tyle w obliczu konieczności zaraportowania setek tysięcy, czy nawet dziesiątek milionów transakcji, nie ma możliwość stworzenia takich kompilacji ręcznie.

Michał Jezierski, menedżer w Zespole Tax Management Consulting Deloitte Doradztwo Podatkowe

Wszystkie opisane w artykule problemy mają swoje źródło w dotychczasowym braku szczegółowych regulacji dotyczących poszczególnych instytucji księgowych. Nałożyło się na to wprowadzenie Jednolitego Pliku Kontrolnego dla ksiąg rachunkowych, który ma być raportowany według określonej struktury. Co więcej, Ministerstwo Finansów nie ograniczyło zakresu wymaganych danych. Wręcz przeciwnie – rozszerzyło go w sposób wykraczający poza logikę dostępnych na rynku rozwiązań księgowych.

W rezultacie podatnicy muszą niejednokrotnie dostosowywać swoje systemy źródłowe, szukać nowych możliwości i sięgać po dodatkowe rozwiązania, których celem jest kompilowanie olbrzymich ilości danych. Niezmiennie, w kontekście tej i pozostałych struktur, pojawiają się pytania: czy docelowo coś zostanie zmienione w zakresie obowiązków raportowych oraz czy Ministerstwo Finansów precyzyjnie określi swoje oczekiwania? Trzeba jednak pamiętać, że każde nowoczesne rozwiązanie wymaga okresu przejściowego, w trakcie którego przeprowadzane są szeroko zakrojone testy. Wydaje się, że w przypadku pliku JPK właśnie teraz mamy do czynienia z takim sprawdzianem. Efektem może być zmiana struktury w taki sposób, aby z jednej strony zapewnić większą efektywność kontroli, z drugiej zaś umożliwić podatnikom prostsze i szybsze zbieranie wymaganych danych.