Blog

Blockchain Q&A#2 – Jaką technologią jest blockchain?

[Kto pyta nie błądzi]

Wiele popularnych tekstów o blockchain traktuje go jak technologię (zamiennie, system), w domyśle, gotowy do wdrożenia, o pewnych stałych cechach. Konsekwentnie, wielu zainteresowanych tematem jest przekonanych, że za takiego blockchaina, za jego utrzymanie i rozwój odpowiada jakaś jedna organizacja, ewentualnie firma. Czy tak jest naprawdę?

[Czym w sumie jest blockchain]

W sumie, aby odpowiedzieć na powyżej sformułowane pytanie należałoby zacząć od tego co jest istotą pierwszego blockchain, zaimplementowanego w ramach Bitcoin. W końcu, od tego się zaczęło.

W tym miejscu sprawa jest prosta. Istotą pierwszego blockchain jest oczywiście decentralizacja rejestru danych oraz dekoncentracja władzy nad siecią wymiany informacji. Temu właśnie służy koncepcja rozproszonego rejestru transakcji (Distributed Ledger), dzięki której rejestr ten jest dość odporny na zniszczenie i zmianę danych w nim zawartych (o tym jak to jest osiągane – w innym wpisie). Dodatkowo, to rozproszenie niesie za sobą określone konsekwencje w zakresie zarządzania siecią i jej nadzorowania.

Zmiana w zakresie zarządzania / funkcjonowania wyraża się to w likwidacji instytucji centralnej sieci w dotychczasowym rozumieniu. W świecie przed blockchain przyjęło się, że tzw. instytucje takiego czy innego zaufania, zazwyczaj za wynagrodzeniem, zajmują się utrzymywaniem scentralizowanego rejestru transakcji i mają monopol na mówienie „swojej” sieci co jest prawdą (czyli co ma być w rejestrze danych zapisane) oraz monopol na wprowadzanie tych zmian. Przy okazji dbają o bezpieczeństwo takiej sieci oraz dokonują autentykacji i autoryzacji stron transakcji.

Przy czym, Twórcom pierwszego blockchain nie zależało na likwidacji tych „prerogatyw” centralnej instytucji (serwera). Zależało im raczej na ich odpodmiotowieniu, tj. przeniesieniu na barki zdecentralizowanego i „random’owego” mechanizmu kryptograficznego oraz na ułożeniu na nowo podziału ról pomiędzy użytkownikami sieci. Oczywiście, przy okazji wykształciły się nowe ośrodki władzy w, tym razem, zdecentralizowanej sieci – górnicy i deweloperzy. Ale to także materiał na oddzielną opowieść.

W ten sposób powstało coś co obecnie nazywamy instynktownie blockchain’em. Niemniej, wracając do tytułowego pytania – nie ma, jak się okazuje, czegoś takiego jak jeden system / technologia blockchain. Wynika to z samej istoty tego arcyciekawego konstruktu, który jest zbiorem znanych pomysłów, mechanizmów i schematów po raz pierwszy w tak ciekawy sposób łącznie zastosowanych przez osobę lub osoby ukrywające się pod pseudonimem Satoshi Nakamoto. Blockchaina w wydaniu domniemanego Japończyka można sobie zatem wyobrazić jako ideę wyjściową, na którą składają się trzy warstwy (czyli blockchain jest jak Shrek, który z kolei był jak cebula ale wołał być jak tort):

1.     {Warstwa postulatywna vel architektoniczna} – cele, parametry i cechy podstawowe danego pomysłu na sieć opartą blockchain (tutaj do wyboru: stopień decentralizacji, rozproszony rejestr, komunikacja peer-to-peer, zastosowana kryptografia, zasady konsensusu, stopień odejścia od idei centralnego serwera),

2.     {Warstwa technologiczna} – Konkretna implementacja obejmująca wybrany zestaw celów i cech danego blockchaina zamkniętych w konkretnej technologii możliwej do implementacji w warunkach produkcyjnych ,

3.     {Warstwa wdrożeniowa} – Praktyczna, wdrożona i uruchomiona instancja danej implementacji blockchaina.

[Diabeł tkwi w szczegółach]

W tym miejscu należałoby nałożyć powyższy obraz teoretyczny na krajobraz blockchainowy jaki mamy na realnym rynku.

I tak, w Warstwie postulatywnej jest tak naprawdę zestaw cech i celów, które dany blockchain może w różnym stopniu adresować. Są to przede wszystkim wspomniane i wieczne:

  • Decentralizacja,
  • Działanie w sieci peer-to-peer,
  • Zdecentralizowany rejestr
  • Odporność na utratę i zmianę danych w rejestrze czyli zastosowana kryptografia.

Wybór wszystkich lub niektórych z powyższych (albo w ograniczonym zakresie) powoduje, że na etapach implementacji czy instancji, będziemy mieli do czynienia tak naprawdę z bardzo różnymi postaciami blockchain. A zatem, w Warstwie postulatywnej tak naprawdę dokonujemy wyborów analitycznych co do architektury przyszłego blockchain.

Mając za sobą fazę kluczowych decyzji, można płynnie przejść do fazy implementacji blockchaina (Warstwa technologiczna). Tutaj z kolei czeka nas świadomy wybór już czysto, jak sama nazwa wskazuje, technologiczny. W zależności bowiem od tego co wybierzemy sobie z Warstwy postulatywnej, ukierunkowuje nas to na wybór blokchain np. w wydaniu podobnym do BitcoinEthereum (różnice między tymi dwoma są momentami fundamentalne) czy też implementacji blockchaina prywatnego (permissioned), pozbawionego takiej cechy jak decentralizacja funkcji centralnej (brzmi jak masło maślane ale jednak).

W tym momencie (i trochę na marginesie) warto powiedzieć pokrótce czym się różni blockchchain publiczny (np. Bitcoin) od implementacji blockchaina prywatnego (permissioned).

Otóż, wracając do możliwych architektur sieci, mogą być one klasyfikowane ze względu na zadania centralnego węzła. I tak:

  • Sieci scentralizowane zawierają ściśle określone centrum, które odpowiada zarówno za przechowywanie danych, jak i wprowadzenie modyfikacji do bazy danych (większość obecnie znanych sieci),
  • Sieci o charakterze hybrydowym, w których przechowywanie danych jest zdecentralizowane (w trybie do odczytu kopie bazy danych synchronizują wszystkie węzły w sieci ale prawa modyfikacji ma tylko centralny węzeł). Tutaj przykładem mogą być niektóre sieci blockchain typu permissioned,
  • Wreszcie, sieci, w których dokonano decentralizacji pełnej, zarówno funkcji utrzymywania bazy danych, jak i jej modyfikacji (Bitcoin).

W sposób oczywisty, sieć nr 3 jest najmniej podatna na włamanie zewnętrzne czy nadużycia wewnętrzne. Jednocześnie jednak, stworzenie w niej mechanizmu programistycznego (kryptograficznego), który napędza i zarządza procesem zdecentralizowanego dodawania transakcji do rejestru (konsensus, w przypadku Bitcoin, jest to proof of work) jest właśnie emanacją funkcji centralnego węzła w sieci. Idąc dalej, mechanizm ten ma swoją wymierną cenę w postaci koniecznej do zaangażowania mocy obliczeniowej i, co za tym idzie, energii, potrzebnej do działania danej sieci. Dlatego mówi się, że blockchain w wydaniu publicznym bywa bardzo nieekologiczny i… relatywnie wolny. Jest to jednak cena za decentralizację systemu, decentralizację i podział władzy w niej oraz wysoki poziom bezpieczeństwa i pewności. Coś za coś… Choć oczywiście są inne mechanizmy (proof of stake) oraz eksperymenty, który klasyczne zdecentralizowane implementacje blockchain uczynią wydajnymi na poziomie systemów scentralizowanych bez utraty wcześniej wymienionych jego przymiotów. W tym obszarze blockchain jest w efekcie obszarem rozwojowym i na efekty tego rozwoju należy z dużymi nadziejami nadziejami oczekiwać. Połączenie zalet sieci rozproszonych i scentralizowanych – to byłaby prawdziwa rewolucja.

Przechodząc z wreszcie do Warstwy wdrożeniowej warto powiedzieć, że dana implementacja blockchain może posiadać wiele praktycznie wdrożonych instancji. I tak, np. Ethereum ma kilka instancji, które różni np. to, że niektóre z nich mają funkcje testowe, inne produkcyjne (instancje są ważne z perspektywy smart contracts) . Wreszcie, właściwie każdy chętny ma możliwość w danej implementacji blokchaina stworzyć swoje prywatne instancje (sieci) blockchain. Choćby dla celów edukacyjnych. Albo po to, aby stworzyć własną kryptowalutę/tokeny, które, być może, podbiją świat.

Od strony bardziej technicznej, każdą z instancji implementacji blockchain’a wyróżnia zestaw unikalnych cech. Są nimi przede wszystkim identyfikator danej sieci (instancji) oraz tzw. genesis block (blok początkowy).To także zagadnienia warte oddzielnego omówienia.

[Finis coronat opus]

Czas na końcowe podsumowanie. A zatem, czy i jaką technologią jest blockchain? Moim zdaniem blockchain w najbardziej ogólnym sensie, to pewna pojemna idea, która mieści w sobie kwestię decentralizacji sieci i rozproszonego rejestru danych, które to decentralizacje są możliwe dzięki, m. in. kryptografii.

Blokchain staje się technologią kiedy zaczynamy mówić o nim mniej ogólnie i pojawiają się takie słowa jak blockchain publiczny, prywatny czy też nazwy takie jak Ethereum.

Z wdrożoną zaś technologią mamy do czynienia na poziomie instancji, czyli praktycznej implementacji dokonanej do określonych celów.

Read More

Blockchain Q&A

Achieving systematic and sensible knowledge of blockchain phenomenon isn’t simple, especially when we start and we don’t have an ambition to read numerous white papers in this field. At this stage of development of the concept (for some reasons I would avoid the word „technology” which I try to explain later) an appropriate quantity of regular courses, certification and training is still lacking on the market. Actually, the things that we have, and a person who is hungry for new knowledge will find here, are two extremes. Already mentioned, sometimes strongly hermetic white papers, written by development and general and full of clichés and simplifications information. An ambitious and novice blockchain bread eater doesn’t have an easy task in such information society. Initially, at least.

Guided by the above remark and my own experience I considered that already gained knowledge is worth sharing (at last the more enthusiasts and adopters will be, the better). Regular writing Q&A about blockchain and issues associated with it is the idea. At the same time, I would like to fill in the gap between hermetic and development and newspaper, circular and popular knowledge. In other words, passed knowledge within the present inaugurated Q&A is supposed to present the old and good approach of happy medium.

The objective of the regularly updated cycle is another challenge. Not only does it result from the limitations of human nature, which might be lazy but also from the fact that the world of blockchain is constantly changing (it is estimated that thousands of white papers on this topic appear on the net per month). Finally, last but not least, formulating questions itself, so that answers to them contribute anything to knowledge of the potentially interested, is also a challenge.

Speaking of relevant and sensible questions, this raises the issue, which question/problem of Q&A cycle we should start from. Initially, the question „what blockchain actually is” seemed to be obvious to me. However, thinking of it for the second, third and another time, I reminded, that blockchain didn’t come into being autonomously as a goal itself. It was a resultant of entirely separate project. This in turn takes us to 2008 and leads once again to ask a cliched question about the relationship between blockchain and Bitcoin. And by the way it will work out, I hope, to answer the question what blockchain is to a certain extent. Therefore, the first question, in a separate entry, will be about the relation between two big „b” phenomena of contemporary internet. The answer will be neither short nor one of those, which can be quickly found in easily available sources of information.

Finally, attention, an organizational comment. While writing about blockchain, willy-nilly quite a lot specialized terminology must be used. In Q&A cycle, there is no place and point explaining it in an extended way, at the moment of the first appearance. A plenty of them will deserve to have a separate entry. Such key concepts are intended for a discussion in future entries they will be appropriately marked and we will go back to them later.

*****

Zdobycie systematycznej i sensownej wiedzy o fenomenie blockchain, zwłaszcza gdy zaczynamy i nie mamy, jeszcze, ambicji czytania licznych white papers z tej dziedziny, nie jest proste. Na tym etapie rozwoju tego konceptu (z pewnych względów unikałbym słowa “technologia” czego powody za jakiś czas postaram się wyjaśnić) brakuje jeszcze na rynku odpowiedniej ilości regularnych kursów, certyfikacji czy szkoleń. To co mamy to właściwie osoba głodna nowej wiedzy znajdzie to dwie skrajności. Wspomniane już, czasem mocno hermetyczne white papers, pisane przez deweloperów oraz informacje obiegowe, ogólne, pełne klisz i uproszczeń. Ambitny aczkolwiek początkujący zjadacz blockchainowego chleba nie ma w takim środowisku informacyjnym łatwego zadania. Przynajmniej na początku.

Kierując się powyższym spostrzeżeniem i własnymi doświadczeniami uznałem, że wiedzą już zdobytą warto się podzielić (w końcu im więcej entuzjastów i adopterów, tym lepiej). Pomysłem na to jest regularne pisanie Q&A na temat blockchaina i kwestii z nim związanych. Jednocześnie działaniem tym chciałbym wypełnić lukę między wiedzą hermetyczną i deweloperską oraz gazetową, obiegową i popularną. Innymi słowy, wiedza przekazywana w ramach niniejszym inaugurowanego Q&A ma prezentować podejście starego i dobrego złotego środka.

Kolejnym wyzwaniem jest przy tym zamierzenie, aby cykl ten był regularnie aktualizowany. Wyzwanie wynika nie tylko z ograniczeń natury ludzkiej, która bywa leniwa, ale także z faktu, że świat blockchain stale się zmienia (szacuje się, że miesięcznie pojawia się w sieci tysiące white papers na ten temat). Wreszcie, last but not least, wyzwaniem jest samo formułowanie pytań tak, aby odpowiedzi na nie cokolwiek wnosiły do wiedzy potencjalnie zainteresowanych. Dlatego, mam nadzieję, że nie będzie zbytnią śmiałością, aby prosić ewentualnych czytelników o pomysły jakie obszary funkcjonowania blockchain mogłyby stać się częścią niniejszego Q&A.

Skoro mowa o trafnych i sensownych pytaniach, powstaje jeszcze kwestia od jakiego pytania / problemu cykl Q&A zacząć. Początkowo oczywiste wydawało mi się pytanie „czym właściwie jest blockchain”. Niemniej, myśląc o tym po raz drugi, trzeci i kolejny, przypomniałem sobie , że blockchain nie powstał autonomicznie jako cel sam w sobie. Był wypadkową zupełnie innego przedsięwzięcia. To z kolei przenosi nas w 2008 r. i każe po raz kolejny zadać wyświechtane pytanie o relację blockchain i Bitcoin. A przy okazji uda się mam nadzieję odpowiedzieć do pewnego stopnia na pytanie czym jest sam blockchain. A zatem, pierwszym pytaniem, w oddzielnym od tego wpisie, będzie to o relację dwóch wielkich “b” zjawisk współczesnego internetu. Odpowiedź nie będzie krótka ani nie będzie jedną z tych, które można szybko znaleźć w łatwo dostępnych źródłach informacji.

Na koniec uwaga uwaga organizacyjna. Pisząc o blockchain chcąc nie chcąc trzeba używać sporo specjalistycznych terminów. W cyklu będącym Q&A nie będzie jednak sensu i miejsca aby je wyjaśniać w rozbudowany sposób od razu, w momencie pierwszego pojawienia się . Wiele z nich bowiem będzie zasługiwać na odrębny wpis. Takie kluczowe pojęcia przeznaczone do omówienia w przyszłych wpisach będą więc stosownie zaznaczane i będziemy do nich szczegółowo wracać później.

Read More

[Genesis]

First of all, it should be remembered that blockchain did not come into being in the particular form of implementation, but as the element of larger project, Bitcoin. Therefore, it was designed as something that was supposed to support the functioning of first crypto-currency. This is extremely important because it means that blockchain in its DNA has very strong relations with the mechanism and the idea of crypto-currency. It, thus, might be challenging for designers to use blockchain to other than crypto-currency purpose.

Funny thing, embedding blockchain into Bitcoin resulted (for some time) in fact that almost each speaker at many events associated with blockchain, found himself or herself compelled to begin with cliché that blockchain isn’t Bitcoin. Well, that sounds sensibly and professionally, so why not.

However, it is a classic simplification. Let’s therefore try to sort information with a complicated bond of both „b” terms out. Let’s start from the introduction of another important word, which is an „implementation”. Therefore, from now on we say: „Bitcoin is the first implementation of blockchain”.

[An egg or a hen?]

The issue here is a bit more complicated and touches the old dilemma of what was first, an egg (blockchain) or a hen (Bitcoin). In this case, the hen was first. Namely, the creation of Bitcoin didn’t look like that someone set up an IT construct as a base for numerous future implementations and call it blockchain. And later, someone else (Nakamoto) took that blockchain, used it and built upon it a “thing” called Bitcoin.

Frankly, it was quite the opposite. The conceptional starting point was to create of something that is known today as the most popular cryptographic currency, whose aim was supposed to meet a few principal and ideological requirements (one must remember that Bitcoin was being formed in response to financial crisis)

The said requirements are as follows:

1.       decentralization, i.e. the lack of central institution, distributing trust and maintaining a certain network and, on the top of that, having a monopoly for the modification of entries in the central database and the verification of participants’ identity and their access to the network,

2.      the distributed register of data (Distributed Ledger), making highly probable data unchangeability in the register by using the cryptographic mechanisms,

3.      participants’ equality (peer-to-peer) in the network while at the same time diversifying their roles (the division of developers, miners and users; by the way, it reminds to some extent checks and balances mechanism built into a well-designed political system).

Therefore, the first blockchain isn’t / wasn’t uniform technology, but an innovative compound of a few already existing concepts (for instance, cryptography applied in blockchain existed before blockchain). Additionally, a compound made for a specific purpose. Blockchain isn’t, consequently, generic upfront designed technology aimed at e.g. easy implementation and re-usage. It results in, after having noticed by internet society general advantages of this new idea, existing different implementations of blockchain. These implementations try very often with success to address limitations and constraints of the very first implementation. The limitations in the sense, that something that was an advantage in currency context, often used to become an obstacle in other business cases. Nevertheless, the limitations of blockchain will be discussed in details in a separate entry.

[Evolve or die]

While analyzing the current classification of various blockchain shapes, its evolution from the internal and supplementary concept to more generic usages is more visible. This will be a separate subject of analysis, in which we will trace back the division of blockchain into, simplifying, open and permissioned ones.

Here comes an interesting fact. You can ask yourself a question how much blockchain is in Bitcoin. It turns out that, from the point of view the document constituting Bitcoin… not so much. It’s worth checking. In Bitcoin whitepaper blockchains appears… only once and as a „chain of blocks” (page 7 from https://bitcoin.org/bitcoin.pdf). Here is a quotation.

The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction

Not very promising, considering the fundamental phenomenon which blockchain appears to be nowadays. Let’s also take a notion of the context of this text passus. It’s interesting whether Satoshi Nakamoto predicted later career of blockchain as a being separated from Bitcoin.

Summing up, blockchain formed to become a backbone, a framework of a specific crypto-currency. Which means, that it has certain features, which make it sometimes difficult to adapt to other use cases. However, the overall potential of the idea behind „chain of blocks” was quickly recognized. That is how blockchain’s global career commenced as an being distinct from crypto-currency use case and started its evolution toward multitude if implementations and applications.

At the end, a few useful links:

[As a reminder – the terms in bold will be discussed in separate entries.]

The entry inaugurating the whole Blockchain Q&A cycle can be found here: https://www.linkedin.com/pulse/blockchain-qa-ernest-frankowski/

——————————————————————————————————

[Genesis]

Przede wszystkim należy pamiętać, że blockchain pojawił się po raz pierwszy w postaci konkretnej implementacji, tj. jako element projektu Bitcoin. A zatem, został pomyślany jako coś co miało wesprzeć funkcjonowanie konkretnej kryptowaluty. Jest to bardzo ważne bo oznacza to, że blockchain w swoim DNA ma bardzo silne związki z mechanizmem i ideą kryptowalut. Dla projektantów innych niż krytpowalutowe zastosowań blockchain’a, bywa to sporym wyzwaniem.

Fakt wbudowania blockchain w Bitcoin miał poza tym taki skutek, że na “imprezach” związanych z blockchain niemalże każdy prelegent uznawał za stosowne zacząć mantrą, że blockchain to nie Bitcoin. W sumie, brzmi to mądrze i profesjonalnie, więc czemu nie.

Jednak, jest to pewne uproszczenie. Spróbujmy zatem informacje o złożonej więzi obu terminów na „b” uporządkować. Zacznijmy od wprowadzenia kolejnego ważnego słowa, brzmiącego „implemetacja”. A zatem, od teraz mówimy tak: „Bitcoin jest pierwszą implementacją blockchain”.

[Jajko czy kura]

Kwestia jest oczywiście odrobinę bardziej skomplikowana i zahacza o tytułowy dylemat co było pierwsze, jajko (blockchain) czy kura (Bitcoin). W tym przypadku pierwsza była kura. Mianowicie, powstanie Bitcoina nie wyglądało tak, że ktoś kiedyś zbudował konstrukt o charakterze fundamentu dla licznych implementacji i nazwał go blockchain. A potem ktoś inny wziął tego blockchaina i zbudował z jego wykorzystaniem Bitcoina.

Sytuacja była zasadniczo odwrotna. Koncepcyjnym punktem wyjścia było stworzenie czegoś co dziś jest znane jako najpopularniejsza kryptograficzna waluta, która to idea miała spełniać kilka zasadniczych przesłanek (pamiętajmy, że Bitcoin powstawał w reakcji [w kontrze] na kryzys finansowy). W efekcie, wymyślono blockchain, który był jedną z “rzeczy” pozwalających powołać do życia idee stojące za pierwszą kryptowalutą.

Te przesłanki to oczywiście:

1.     decentralizacja, tj. brak instytucji centralnej, dystrybuującej zaufanie oraz utrzymującej daną sieć, a także mającej monopol na modyfikacje wpisów w centralnej bazie danych oraz na weryfikację tożsamości uczestników i na ich dopuszczanie do tejże sieci,

2.     rozproszony rejestr (baza) danych (Distributed Ledger), wysoce uprawdopodobniający niezmienialnosć danych w rejestrze poprzez zastosowane w nim mechanizmy kryptograficzne,

3.     równorzędność (peer-to-peer) uczestników sieci przy jednoczesnym zróżnicowaniu ich ról (podział na deweloperów, górników i użytkowników; nota bene, trochę to przypomina system blokad i równowag miedzy różnymi rodzajami władzy w dobrze zaprojektowanych systemach politycznych).

Zatem, pierwszy blockchain nie jest / nie był jakąś jednolitą technologią, a złożeniem do innowacyjnej postaci kilku konceptów cząstkowych i istniejących technologii (przykładowo, kryptografia zastosowana w blockchain istniała przecież przed blockchain). Dodajmy, złożeniem dokonanym w określonym celu. Nie jest więc blockchain, konsekwentnie, jakąś generyczną i przemyślaną pod kątem np. łatwości wdrożenia technologią. Efektem tego, po zauważeniu przez społeczność generalnych zalet tej nowej idei, zaczęły powstawać różne implementacje blockchain, próbujące często z powodzeniem adresować ograniczenia pierwszej implementacji. Ograniczenia w tym sensie, że to co było zaletą w zastosowaniu walutowym, stawało się często przeszkodą w innej sytuacji biznesowej czy faktycznej. O ograniczeniach blockchain będzie zresztą mowa w oddzielnym wpisie.

[Evolve or die]

Analizując obecną klasyfikację różnych postaci blockchain, jego ewolucja od konceptu celowego (na potrzeby “samozarządzalnej” waluty) do bardziej generycznych zastosowań będzie bardziej widoczna. Co też będzie przedmiotem oddzielnej analizy, w której prześledzimy podział blockchain na, upraszczając, publiczne i prywatne.

Tutaj pewna ciekawostka. Można sobie zadać pytanie ile konkretnie jest blockchaina w Bitcoinie. Okazuje się, że z punktu widzenia konstytuującego Bitcoin dokumentu white paper… niewiele. Warto tam zerknąć aby się o tym przekonać. W tym fundametalnym dokumencie blockchain pojawia się… tylko raz i to jako “chain of blocks” (str. 7 z https://bitcoin.org/bitcoin.pdf). Poniżej cytat.

The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction

Niewiele jak na fundamentalne, z dzisiejszego punktu widzenia, zjawisko. Do tego zwróćmy uwagę na kontekst tego fragmentu. Ciekawe czy Satoshi Nakamoto przewidywał(li) późniejszą karierę blockchain jako bytu oderwanego od Bitcoin.

Podsumowując, blockchain powstał aby wypełnić ramy działania systemu operującego alternatywną walutą. Co oznacza, że w implementacji Bitcoina ma on pewne cechy, które czynią go trudniejszym do zaadaptowania do innych zastosowań. Szybko jednak dostrzeżono ogólny potencjał pomysłu stojącego za “łańcuchem bloków”. I tak się zaczęła światowa kariera blockchaina jako bytu odrębnego od systemów kryptowalutowych i ewoluującego w kierunku wielości implementacji i wielości zastosowań.

Na koniec jeszcze kilka przydatnych adresów.

Read More

Celem poniższego tekstu jest zarysowanie procesu wprowadzania zmian w sieciach blockchain na przykładzie Bitcoin i ścierających się w tym procesie interesów różnych uczestników i użytkowników tej akurat sieci. Mechanizm ten w praktyce pokazuje, że implementacje blockchaina zaczynają mieć powoli za sobą okres rewolucyjno – romantyczny. Zaczynają zaś wytwarzać w swoim obrębie mechanizmy władzy, dominacji, obrony interesów takie same jak od zawsze występują w, nazwijmy to, “tradycyjnej” gospodarce. Jest to o tyle godne odnotowania, że blockchain (tutaj w wydaniu Bitcoin) miał być remedium na centralizację, deficyt zaufania i kilka innych bolączek jednocześnie globalnej oraz rozproszonej ekonomii. A tymczasem powoli, technologia ta i ludzie jako jej użytkownicy odtwarzają mechanizmy, które były poddane krytyce wraz z powstaniem blockchain. Osobiście nie uważam to za nic złego, a raczej za normalną drogę rozwoju wszelkich nowych idei czy systemów (każda rewolucja wytwarza nowe elity). Zresztą, każdy system (tutaj bez przymiotnika) tworzą i rozwijają ludzie ze swoimi wadami i ograniczeniami. Zatem finalnie żaden nowy pomysł nie będzie całkowicie odporny na wady (cechy) systemów, w kontrze do których powstał.

***

Sierpień 2017 r. to pamiętny miesiąc dla społeczności Bitcoin. Tego dnia aktywowano poprawkę/rozszerzenie Segregated Witness (SegWit). W mediach, także nie-branżowych) pisano o tym wiele, oczywiście koncentrując się na pewnych kliszach i powtarzaniu podstawowych informacji, że potencjalny rozmiar bloku wzrósł do 2 MB (samo to stwierdzenie jest już dużym uproszczeniem). Czasem podawano jeszcze informację, że SegWit adresuje tzw. “malleability bug”.

Więcej o tym błędzie tutaj:

https://bitcoinmagazine.com/articles/the-who-what-why-and-how-of-the-ongoing-transaction-malleability-attack-1444253640/

 

Kwestia tego buga jest sama w sobie bardzo ciekawa. Dość powiedzieć, że przyczynkiem do rozpoczęcia prac nad SegWit (w 2012 r.) było właśnie wyeliminowanie wspomnianej luki (zrobiono to przez separację sygnatury transakcji od innych danych o transakcji [stąd nazwa Separated Witness]), niosącej potencjalne zagrożenie podmiany sygnatury transakcji przez podmiot trzeci już po fakcie stworzenia sygnatury transakcji. Podmiotami mającymi możliwość takiej zamiany mogli być choćby górnicy. Dyskusja o wyeliminowaniu buga w pewnym momencie zbiegła się z kwestią zwiększenia wielkości bloku. Zwłaszcza gdy okazało się, że wspomniane zwiększenie limitu wielkości bloku wymaga załatania “malleability bug”.

Wydawałoby się więc, że SegWit to same korzyści. Niestety, okazało się, że o ile sama eliminacja buga może być zrealizowana jako tzw. soft fork*, to zwiększenie limitu bloku wymaga z kolei zmiany typu hard fork. Połączenie tych kwestii raczej kierowało cały proces całościowo w kierunku zmiany typu hard i braku kompatybilności wstecz. W tym momencie, wielu kluczowych górników zaczęło kontestować ideę SegWit.

Podstawy tej kontestacji do pewnego stopnia wyjaśniły się, trochę upraszczając całą historię, w momencie wybuchu pewnego skandalu. Mianowicie, w kwietniu 2017 r. Gregory Maxwell upublicznił informację, że chipy ASIC używane przez wielu górników mają wbudowaną implementację technologii AsicBoost. W tym momencie stało się w zasadzie jasne czemu górnicy bronią się przed poprawką. Tym brakującym elementem układanki był fakt, iż użycie AsicBoost stałoby się niemożliwe (niekomapatybilne) przy wprowadzeniu SegWit w wydaniu soft fork. Czemu miało to znaczenie? Z powodów czysto ekonomicznych. Największe kopalnie zainwestowały olbrzymie środki w sprzęt “górniczy” oparty na układach dających im przewagę w procesie wydobywania bloków. Innymi słowy, niektórzy instytucjonalni górnicy zaczęli działać jak klasyczna grupa interesu, blokując zmiany korzystne dla ogółu społeczności (wielkość bloku, załatanie buga, skalowalność), a niekorzystne (przynajmniej krótkoterminowo) dla nich i ich inwestycji. Samo w sobie nie jest to niczym zaskakującym. Niemniej, z punktu widzenia pewnego idealizmu towarzyszącego powstaniu Bitcoina (i blockchaina), daje do myślenia.

W tym przypadku historia (po wielu dodatkowych smaczkach i zwrotach akcji, włączając w to powstanie SegWit2Mb) zakończyła się swego rodzaju kompromisem, którego ucieranie się jest moim zdaniem ciekawie, a momentami porywająco opisane tutaj:

https://bitcoinmagazine.com/articles/long-road-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality/

a także trochę bardziej technicznie tutaj:

https://bitcoinmagazine.com/articles/bip91-segwit-activation-kludge-should-keep-bitcoin-whole/

Sama w sobie ta historia może być pasjonująca. To na co jednak warto dodatkowo zwrócić uwagę, to fakt, że jak w przypadku każdej rewolucji, także i ta może zacząć odtwarzać mechanizmy znane z krytykowanej przez siebie przeszłości. W tym przypadku, sieć oparta na blockchain miała stać się środowiskiem, z którego wyeliminowano tradycyjne instytucje pośredniczące (tj. pośredniczące w dystrybucji zaufania i udostępniające zasoby konieczne do utrzymania sieci/usługi). Szybko jednak nowa struktura (nie waham się powiedzieć, że także społeczna) wytworzyła swoje własne hierarchie i ośrodki decyzyjne o odpowiednio silnym głosie. Co nie przekreśla wartości tego jak ostatecznie cała ta w sumie wieloletnia dyskusja o SegWit została rozwiązana.

Powyższe jest zaledwie krótkim obrazkiem z fascynującej historii i ewolucji bardzo ciekawej technologii (mam na myśli ogólnie blockchain) i, paradoksalnie, świadectwem jej dojrzałości. Dojrzałość ta znajduje wyraz w wytworzeniu się oraz działaniu mechanizmów ścierania się interesów ale i w zdolności wypracowywania kompromisów. Jak to w życiu…

*Zasadniczo istnieją soft i hard fork. Łatwiej to wytłumaczyć zaczynając od omówienia hard fork. Obrazuje to sytuacja, w której w sieci blockchain z jakiś powodów (zamierzonych lub nie) w zbliżonym czasie zostają wykopane dwa bloki, z których każdy zapoczątkowuje równoległy łańcuch bloków (rozwidlenie). W “normalnych” okolicznościach przez pewien czas górnicy wykopują bloki do obydwu łańcuchów, aż jeden stanie się dłuższym, dominującym, a drugi zostanie osierocony. W specjalnie uruchomionym procesie hard fork, inicjuje się go po to, aby wprowadzić do blokchaina zmiany niekompatybilne z poprzednim blokami. Bywa jednak i tak, że zmiana nie zostanie zaakceptowana. Czego z kolei efektem może być rozłam w sieci i trwałe rozejście się danego blockchaina na np. dwie różne kryptowaluty. Jest to częsta geneza pojawiania się nowych kryptowalut “na korzeniu” pierwotnej. Powstaje wtedy sieć akceptująca dane zmiany i rozłamowcy, którzy chcą operować kryptowalutą typu “classic” (sprzed zmian). Bywają także rozłamy specjalnie przeprowadzone z powodów operacyjnych czy ekonomicznych (Bitcoin Gold). Oprócz wprowadzania dużych zmian i/lub inicjowania rozłamów hard fork może być niezamierzony. Ma miejsce wtedy kiedy, jak wspomniałem, dwa bloki zostały wykopane w praktyce identycznym czasie i zaczynają być punktami wyjścia dla własnych łańcuchów. W takim jednak przypadku jeden z łańcuchów w końcu zostaje osierocony, a transakcje z niego zostają unieważnione.

Jak łatwo się teraz domyślić, soft fork to także zmiana w sieci ale nie wymagająca jej podziału. A także kompatybilna wstecz. Z punktu widzenia zachowania sieci w całości, znacznie bezpieczniejsza. Z punktu widzenia zrealizowania bywa, ze trudniejsza. Kompatybilność wstecz, co dość oczywiste, przy fundamentalnych zmianach bywa trudna do zachowania i realizacji. Wtedy zaczyna się myśleć nad hard fork co oczywiście otwiera puszkę pandory w postaci potencjalnego rozłamu w przypadku braku akceptacji zmiany przez jakąś część danej społeczności.

Read More

W ostatnim czasie można było przeczytać ten oto komunikat:

http://www.akmf.pl/aktualnosci/jpk-analizator-zlecenie-realizowane-przez-spolke-na-rzecz-ministerstwa-finansow

Treść tej notki sama w sobie jest szalenie ciekawa ale jeszcze ciekawsze jest to co można przeczytać w niej między wierszami. Z punktu widzenia szybkiej i pobieżnej lektury przy kawie dowiedzieć się można, że oto organy podatkowe zyskują dostęp do rozbudowanego systemu analityki podatkowej składającego się z hurtowni danych (opisanej “info-bombastycznymi” przymiotnikami) oraz 15 (teoretycznie nie za wiele) raportów analitycznych. Jeśli jednak wczytać się w ten komunikat, można odczytać kilka informacji ukrytych między wierszami czy też stanowiących dodatkowe warstwy tej na pierwszy rzut oka suchej notatki prasowej.

Przede wszystkim nazwa “Fundament Danych” wskazuje na mocarstwowe zamierzania co do funkcji i możliwości tej hurtowni danych przygotowanej dla MF. W szczególności ma ona mieć zdolność przechowywania naprawdę dużej (big data?) ilości informacji. Wskazuje na to zamierzenie integracji w niej nie tylko repozytorium plików JPK ale i, uwaga, “danych z szeregu systemów ją zasilających”. Moim zdaniem FD zostało zbudowane tak, aby interfejsować do niej dane ze wszystkich systemów publicznych (JPK, celne, VIES, akcyzowe, e-Deklaracje, ewidencyjne [tutaj nie tylko stricte podatkowe], inne) zawierających dane przydatne analizie podatkowej.

Tylko bowiem takie podejście uzasadnia budowanie czegoś takiego jak FD (i nazywanie systemu w taki sposób). Do tego narzędzia analityczne… Jak sądzę, tutaj skorzystano być może z jednego z istniejących systemów do budowania raportów analitycznych. Takich rzeczy najczęściej nie ma sensu pisać od zera. Stąd relatywnie szybkie tempo stworzenia systemu, o którym piszą autorzy notatki.

W praktyce w postaci FD zbudowano zapewne repozytorium danych, interfejsy do wielu systemów (sprowadzajace te dane do ujednoliconej struktury w FD, umożliwiającej późniejszą analitykę) oraz wspomniane raporty.

Idąc dalej a jednocześnie pozostając przy samych raportach, w komunikacje stwierdza się, że zbudowano już ich określoną liczbę . Jak sądzę, większość z nich w zakresie VAT (to teraz “modne”). Liczba 15 jednak może też wskazywać, że pojawiły się pierwsze raporty wychodzące poza analitykę stricte dotyczącą podatku VAT. Liczba raportów oraz ich zaawansowanie deklarowane w notatce wskazują, że są one dopiero przedsmakiem (teaser-em) pełnych możliwości analitycznych nowego systemu

Reasumując, możliwości analityczne oraz fakt czym Fundament Danych jest w zakresie integracji danych z tak wielu publicznych systemów wskazują jedno. A mianowicie, powstanie tego systemu oznacza początek funkcjonowania podatników w nowej rzeczywistości podatkowej. Bo trudno inaczej nazwać nabycie przez MF zdolności stałego analizowania i porównywania olbrzymiej ilości danych pochodzących z tak wielu różnych źródeł. Dla użytkowników tych danych (osoby je “odpytujące”) pojawiają się możliwości, które powodują, że użycie określenia “sky is the limit” może mieć uzasadnienie.

Read More

Beniamin Franklin said once “(…)In this world nothing can be said to be certain, except death and taxes.”. Although it may seem well worn, the quote has not become obsolete in recent years- taxation remains a crucial element of our lives. It comes as no surprise that in an economy leaning towards using IT solutions in a vast number of sectors, from banking to logistics, the trend has also found its way into taxation. One of the key aspects of tax digitalization, and, in fact, a factor accelerating the said digitalization, are the 2005 OECD guidelines for implementing SAF-T (Standard Audit File-Tax; SAF-T in short), an international standard for electronic exchange of accounting data to national tax authorities and external auditors. The main goal of implementing SAF-T regulations is to allow cross- border tax controls and easy access to data, leading to faster and more effective audits. In consequence, electronic reporting’s long-term aim is to allow tax bodies to conduct faster and more thorough controls of taxpayers, as well as auditing more than one tax area or one taxpayer at the same time (i.e. CIT-VAT comparisons and cross industry benchmarks). In the long run, the usage of SAF-T technology should (will?) lead to identifying potential criminal activities and tax fraud. Thus, aim of this article is to present, briefly, a landscape of European SAF-T implementations.

SAF-T – What is hidden under the hood?

The SAF-T standard has been designed to embed financial data exported from a taxpayer’s accounting system in a container of a specific structure. Above is secured by applying standardized rules of layout and formatting of a container (a files), so as the information contained in it is easily readable and interpretable. Universally structured, it is meant for usage by all types of entities, both national and international and both public and private ones. However, the OECD only lays out general rules for usage of SAFT and the scope of tax information (and the required level of details) provided by SAFT lies with the implementing countries and in their sovereign decisions. Due to differing evolution of the legal systems between them, especially between countries of Western and Central Europe, SAF-T implemented in particular jurisdictions vary from country to country. Moreover, even if the basis for introducing SAF-T remains the same for each of them, the name of the system may also be different in each country, from FAIA (Fichier d’Audit Informatisé de l’Administration de l’enregistrement et des domaines) in Luxembourg to JPK in Poland (Jednolity Plik Kontrolny). Although the idea of SAF-T has been around for a number of years, the digitalization process is now gaining momentum, with a number of European states modernizing their tax systems through, among alia,  SAF-T.

Spain

The Spanish Suministro inmediato de información (SII in short) is considered the most advanced SAF-T implementation of all systems used in Western Europe, and is mandatory since 1 July 2017. The new system is a set of rules regulating the manner of reporting VAT information to Spanish tax authorities, requiring taxpayers to maintain invoice records and VAT books through the Spanish tax authority website. The main new feature of electronic VAT bookkeeping is that taxes will be declared  to the Tax Agency (AEAT) in almost real-time. In general, the entities obliged to file SII reports are large companies that achieve a turnover exceeding 6 million euro and companies listed in “REDEME”, a register of monthly tax returns. Using the SII system is optional for small and medium companies. The information presented in an SII file covers data including all issued and received invoices, cash, equity assets and the type of transaction, recorded by codes and subcodes. Information regarding invoices is detailed and requires providing the NIF number (tax identification number) as well as the date of issue and, if required, VAT adjustment data. In the first six months of mandatory SII, registering invoices is possible with an eight day delay, excluding Saturdays, Sundays and public holidays. After this time, it will be shortened to four days. In order to submit the required data, an electronic certificate is required, confirmed by the relevant tax authority. Late reporting of real-time electronic VAT ledgers will trigger a penalty of 0.5% of the missed amounts, with a minimum of EUR 300 and a maximum of EUR 6.000 per quarter.

Portugal

Referred to as SAF-T (PT), electronic tax reporting has existed in Portugal since 2008. Recently, the system has gone through a set of modifications. First, a number of codes has been added to the accounting file and this change came into force on January 1, 2017. The second change modified the SAF-T for invoices and delivery notes to enhance the quality of provided billing information, becoming obligatory on July 1, 2017. The added equivalence tables allow identification of the accounts according to the accounting standards used by the different taxpayers. All entities that pay CIT and having a registered seat or an establishment in Portugal are obliged to submit tax reporting through SAF-T (PT).The file requires complex information including data specifying the client, equivalence table, payment, supplier, product and invoice number. Not all SAF-T data is reported on a monthly basis. If a PT Tax Damages request is issued, taxpayers are obliged to export SAFT account books, which are not regularly submitted to tax authorities. It is also possible to send the exported book through other means, for example by e-mail. The SAFT (PT) file should be created using a system certified by the Portuguese tax authorities and contain data identifying the software supplier and certificate.

Luxembourg

The Luxembourg SAFT operates under the name FAIA and is in use since 2011. Based on the Luxembourg VAT law, any entity qualifying as a taxable person for VAT purposes could be required to provide a FAIA file upon request from the VAT authorities. The VAT authorities have decided to split the implementation of this FAIA file requirements in two phases. The first one applies to all taxable persons other than small businesses, those who use a simplified VAT regime and entities exempt from a Standard Chart of Accounts. In the second phase, the requirement will be extended to all taxable persons. Contrary to the aforementioned countries, submitting FAIA is only required on demand within 15 days since receiving the notice. The file does not need an electronic signature, only a referral to the issuer of the software. Failure to comply with the submission of FAIA could trigger either daily penalties up to EUR 25.000 per each day, or penalties on a lump sum basis (up to EUR 10.000 per infraction).

France

In France SAF-T is presented as FEC. In January 2018, it will be mandatory to use safe, certified programs to register all payments made by customers, including cash registers. All companies that have a registered office or an establishment are obliged to submit FEC files on demand , as there is no specified yearly, monthly or quarterly term. In addition, companies must fulfill the requirement of conducting all accounting- related matters in French. The penalty for not remitting a compliant e-file is 10% on additional tax liability (a minimum of EUR 5.000 per fiscal year) and possibility of self- assessment by the tax authority (leading to a potential 100% penalty on additional liability). Additionally, France is proposing a regulation obligating French registered companies to use certified VAT software on Business-to-Consumer (B2C) transactions, starting 1 January 2018. The proposition includes using licensed software and cash registers, although the exact requirements will be defined in the upcoming months and will cover security, archiving and transaction details. At first, only French resident businesses will be obliged to follow the new requirements but foreign providers of cash and accounting systems will have to follow and go through the accreditation process. The sanction for not following the new requirements may result in a fine up to EUR 7.000 per infringement.

Austria

SAF-T has been implemented, but is rarely required on a limited basis. All documents needed for auditing are presented in a form specified by the controlling tax authority and must be sent on demand, therefore no SAF-T reporting terms have been set.

Poland

Polish SAF-T is referred to as JPK (Jednolity Plik Kontrolny) and includes seven different types of files, the JPK_VAT file being most important (others are: JPK for invoices, JPK for warehouses, JPK with bank statements, JPK for accounting records and two JPKs for the smallest enterprises). Large, medium and small businesses are obliged to report JPK_VAT files on a monthly basis, whereas microbusinesses will have to fulfill this requirement from 1 January 2018. As for other JPK files, medium, small and micro businesses will have the obligation to submit them on demand from 1 July 2018. The definition of each entity is specified in the Act on Freedom of Business Activity (published 2 July 2004) and depends on the number of employees and yearly turnover in euros. As of 2018, governmental bodies will extend the obligation of JPK reporting to cash register receipts.

Lithuania

Electronic tax reporting was first introduced on 1 January 2016 under the name iMAS. The system consists of 7 modules, the largest of which are iEKA for cash registers, a system for electronic invoicing (iSAF) and iVAZ for freight bills. Moreover, there is an accounting system for small businesses (iAPS), iSAF-T for collecting accounting data and iKON, which monitors daily operations on Lithuanian territory. For system modeling and analysis, as well as risk management, the iMAMC system is used. From 1 January 2016 using the systems was recommended (not mandatory) but at the beginning of 2017 became obligatory for entities whose net sales exceeded 8 million euros. From 2018, it will be mandatory for companies reporting net sales over EUR 700.000and from 2019 for those, whose net sales exceed EUR 45k. SAF-T reporting is both on a monthly and on demand basis. From 29 March 2018, it is possible to report data by means of “automatic reporting”.

Czech Republic

In the Czech Republic, electronic reporting similar to SAF-T is used for VAT in the form of VAT control statements from January 2016 or the first quarter of the same year, depending on the form of tax payments. This concerns all companies registered as VAT payers, which includes those with registered offices in the Czech Republic or companies that conduct their commercial activities there and achieve turnover surpassing 1 million CZK in twelve consecutive months. In addition, companies that do not have a registered office or branch but perform consignments within the Czech Republic and do not have a VAT account are included. VAT control statements are required on a monthly or quarterly basis. Legal persons and equity groups must report the statements no later than on the 25th day after concluding each month. As for natural persons, they are obliged to file the statements on the same day they receive VAT returns, but no later than on the 25th day after the taxable period. If an error is identified in the report, the fine amounts up to CZK 30.000 for each one, if it is not explained within 5 days.

Taking taxes to the next level

In other European countries, the process of introducing technological solutions to the world of tax is an ongoing process, depending on both legal and economic circumstances. In Norway, it is voluntary for companies to use SAF-T systems and it will become obligatory starting 1 January 2018. All companies that run their accounting matters in Norway, both having registered offices and doing business will fall under the scope of the new requirements. The regulations will only exclude companies with a turnover of less than 5 million NOK (without VAT) and those that execute only a few transactions a year (unless they store data electronically). Similarly, Hungary has electronic data reporting for transactions that exceed 1 million HUF. From 1 July 2018, it will become necessary to report transactions exceeding 100,000.00 HUF. The regulations cover all companies that have a registered seat in Hungary or conduct business activities there. Other countries, such as Germany, the Netherlands and Greece do not have any SAF-T solutions (yet), but in the event of a tax investigation, companies must provide some data in electronic form, available on demand. In Belgium, using SAF-T was researched in 2011 and widely discussed, but the plans have been indefinitely postponed. Perhaps the most intriguing question is how digitizing taxes will unfold in the United Kingdom.  Published in December 2015, the “Making Tax Digital” roadmap set out the Government’s plans for digitizing the tax system and introducing real time reporting for all taxpayers. System testing is set to begin in spring 2018, and the initial goal is for companies to provide quarterly VAT reports from April 2019 . However, 2019 is also the year in which UK will officially leave the European Union, complicating the introduction of all new solutions to the legal system and the economy.

Read More

Tekst powstał we współpracy z Pawłem Hulewiczem (https://www.linkedin.com/in/pawel-hulewicz)

Poszukiwanie kolejnych źródeł, które mogłyby zapełnić państwowy skarbiec, jest zjawiskiem tak starym, jak sama idea państwa. Zmieniają się tylko sposoby ściągania pieniędzy od obywateli i przedsiębiorstw działających – dziś często tylko wirtualnie – na terytorium danego państwa.

W pierwszej połowie XX w. wydawało się, że opracowanie koncepcji podatku od towarów i usług na zawsze zlikwiduje problem ściągalności państwowych danin. Okazało się jednak, że nawet ten doskonały w teorii podatek nie ma skutku w postaci powszechnego i w miarę równego obciążenia daniną podatników. Paradoksalnie więc, obecnie jednym z głównych obszarów aktywności władz fiskalnych poszczególnych państw jest walka z tzw. luką podatkową, która narosła przez lata funkcjonowania podatku VAT. Szacuje się, że w Hiszpanii (bohaterce tego tekstu) różnica pomiędzy podatkiem od towarów i usług należnym budżetowi, a faktycznie zapłaconym przekracza 10 miliardów euro (interesujące byłoby sprawdzić jak są wyliczane takie wartości – niemniej jest to materiał na inny artykuł). W efekcie, rząd hiszpański postawił, wzorem wielu innych, na walkę z oszustwami i omijaniem przepisów, które dokonywane są na gruncie tego właśnie podatku.

Wyjątkowość hiszpańskiego rozwiązania opisanego problemu sprowadza się do tego, że kraj ten postanowił zrewolucjonizować obowiązujące od 30 lat zasady rozliczania VAT. Prace legislacyjne rozpoczęły się od wprowadzenia w 2014 r. strategii, która miała na celu usprawnienie systemu raportowania VAT, przyspieszenie zwrotu podatku oraz umożliwienie prowadzenia działań kontrolnych szybciej i bardziej efektywnie. Dziś, po trzech latach, jesteśmy świadkami wprowadzenia SII (Suministro Inmediato de InformaciónImmediate Information Sharing System), czyli raportowania danych podatkowych w czasie zbliżonym do rzeczywistego.

Rejestrowanie transakcji w wirtualnym biurze fiskusa

Ponad 62 000 hiszpańskich firm 1 lipca 2017 r. zostało objęte systemem natychmiastowej wymiany informacji z fiskusem (AEAT). SII jest obowiązkowy dla: (i) przedsiębiorstw, których obrót przekracza ok. 6,01 miliona Euro, sklasyfikowanych w Hiszpanii jako duże przedsiębiorstwa, (ii) firm należących do grup podatkowych oraz tych, (iii) które rozliczają VAT miesięcznie. Pozostali podatnicy mogą przystąpić do systemu dobrowolnie. Wystarczy, że w listopadzie poprzedzającym dany rok podatkowy złożą stosowny wniosek. Po zakończeniu roku podatkowego mogą wrócić do tradycyjnego rozliczania VAT.

SII nakłada obowiązek wysyłania do organów podatkowych informacji, które dotychczas znajdowały się w fakturach oraz księgach podatkowych:

1.  Rejestrze sprzedaży;

2.  Rejestr zakupów;

3.  Rejestrze inwestycji;

4.  Rejestrze transakcji wewnątrzwspólnotowych.

Dotychczas podatnicy mieli obowiązek prowadzenia tych rejestrów samodzielnie. Wysyłając informacje do AEAT za pośrednictwem SII, ewidencjonowaniem transakcji zajmie się urząd.

Czas zbliżony do rzeczywistego

Hiszpańskie organy podatkowe otrzymywały dotychczas zagregowane dane dotyczące transakcji, a podczas kontroli mogły zażądać od podatnika przedstawienia faktur. Teraz otrzymują te dane w czasie zbliżonym do rzeczywistego (to ta rewolucja). Począwszy od lipca 2017 r., szczegółowe dane z faktur są przesyłane do wirtualnego biura prowadzonego przez organy podatkowe w ciągu 4 dni roboczych (tj. dni kalendarzowych z wyłączeniem sobót, niedziel i dni ustawowo wolnych od pracy). Termin ten liczy się, co do zasady (są wyjątki), od dnia wystawienia faktury lub wprowadzenia jej do systemu księgowego.

Od krótkiego 4-dniowego terminu przewidziano kilka wyjątków. Dotyczą one w szczególności przypadków wystawienia faktury sprzedażowej przez podmiot trzeci lub przez odbiorcę. Istnieją również szczególne sposoby liczenia początku biegu terminu w przypadku transakcji wewnątrzwspólnotowych oraz importu. Dane dotyczące inwestycji powinny być raportowane rocznie, do 30 stycznia kolejnego roku.

Najważniejszy wyjątek dotyczy jednak wprowadzenia okresu przejściowego, który zakłada wydłużenie terminu na przekazywanie informacji do 8 dni. Będzie on obowiązywał do końca 2017 r.

Wysoki poziom szczegółowości

Nie tylko szybkość przekazywania informacji jest w koncepcji SII kluczowa. Aby zrozumieć istotę systemu i poziom szczegółowości informacji przekazywanych do fiskusa, warto poznać zakres danych, jakie od początku lipca 2017 r. podatnicy muszą na bieżąco raportować. Na tej podstawie łatwo wyobrazić sobie skalę trudności przystosowania się do nowych obowiązków.

W przypadku faktur sprzedażowych, raportowaniu podlegają:

1.  Numer i seria faktury;

2.  Data wystawienia faktury i data transakcji, jeżeli jest inna, niż data wystawienia faktury;

3.  Imię i nazwisko lub adres siedziby oraz NIF (numer identyfikacji podatkowej) wystawcy;

4.  Numer identyfikacji podatkowej w kraju, w którym znajduje się odbiorca faktury, jeżeli nie jest to Hiszpania;

5.  Podstawa opodatkowania, stawka podatku oraz kwota brutto transakcji;

6.  Typ faktury;

7.  Przyczyna wystawienia faktury (opis operacji gospodarczej);

8.  W przypadku faktur korygujących, kwoty, które są korygowane;

9.  Kategoria podatkowa transakcji której dotyczy faktura: niepodlegająca VAT, podlegająca VAT, zwolniona z VAT, dostawa towarów lub świadczenie usług;

10.              Klasyfikacja transakcji, której dotyczy faktura wystawiona zgodnie z przepisami szczególnymi.

W odniesieniu do faktur zakupowych, podatnicy muszą przekazać organom podatkowym następujące dane:

1.  Numer i seria faktury;

2.  Data wystawienia faktury i data transakcji, jeżeli jest inna, niż data wystawienia faktury;

3.  Imię i nazwisko lub adres siedziby oraz NIF (numer identyfikacji podatkowej) wystawcy;

4.  Numer identyfikacji podatkowej w kraju, w którym znajduje się odbiorca faktury, jeżeli nie jest to Hiszpania;

5.  Podstawa opodatkowania;

6.  Kwota zapłacona, podatek podlegający odliczeniu i kwota brutto;

7.  Przyczyna wystawienia faktury (opis operacji gospodarczej);

8.  Klasyfikacja operacji, której dotyczy faktura wystawiona zgodnie z przepisami szczególnymi;

9.  Informacje o VAT wynikającym z paragonów.

Webserwis przyspieszy raportowanie

W praktyce wprowadzenie SII stawia przed przedsiębiorcami dwojakie wymagania. Po pierwsze, konieczne jest wydobycie danych z faktur. Firmy, które wprowadziły elektroniczne fakturowanie, mają już dużą część tych danych w swoich systemach ERP. Pozostałe muszą wprowadzić rozwiązania, które umożliwią zbieranie informacji i odpowiednie ich przetwarzanie.

Drugi krok polega na przekazaniu danych do systemu SII. Firmy, które raportują mniejszą ilość transakcji, mogą skorzystać z formularza internetowego, do którego wprowadza się dane ręcznie. Rozwiązanie to nie nadaje się jednak dla przedsiębiorstw, które dokonują większej ilości transakcji, a więc dla większości podmiotów objętych obowiązkiem elektronicznego raportowania w SII. Dedykowanym dla nich rozwiązaniem jest serwis internetowy, z którym możliwa jest automatyzacja procesu wysyłki danych. Wystarczy „tylko” przygotować dane w pliku XML, według struktury wskazanej przez organy podatkowe. W nagłówku pliku powinny znajdować się dane dotyczące podatnika i okresu, którego dotyczy raportowanie. W dalszej kolejności w strukturze znajduje się sekcja zawierająca dane raportowane z dowodów księgowych.

Korzystanie z webserwisu pozwala na znaczącą optymalizację przetwarzania danych podatkowych – nawet w stosunku do tradycyjnego raportowania VAT. Pozwala wyeliminować błędy, które pojawiają się w przypadku ręcznego wprowadzania danych. Wymaga to jednak implementacji dedykowanych rozwiązań informatycznych do raportowania podatkowego, z których część może wymagać wprowadzenia zmian w systemie ERP, a nawet w procedurach księgowych. Jednak wybierając odpowiedniego dostawcę, wdrożenie oprogramowania może przebiec bardzo sprawnie i zaprocentować w przyszłości. Niektóre programy nie tylko automatycznie zbierają dane z faktur, przetwarzają je i tworzą plik XML, ale również wykonują szereg testów, które sprawdzają, czy w rozliczeniach nie ma błędów.

Szybszy zwrot VAT i mniej informacji podsumowujących

Pomimo pewnej ilości pracy, którą trzeba wykonać przed wdrożeniem SII, hiszpański fiskus zachęca podatników, aby korzystali z systemu, również jeśli nie są do tego zobowiązani. Podstawowa zachęta sprowadza się do zwolnienia z obowiązku prowadzenia rejestrów VAT. Użytkownicy systemu będą otrzymywali dane do rozliczenia VAT od AEAT, a termin miesięcznych i kwartalnych rozliczeń zostanie dla nich wydłużony o 10 dni. Podmioty raportujące w SII nie muszą również składać okresowych informacji podsumowujących 340, 347 i 390.

SII zakłada stworzenie repozytorium, w którym dane dotyczące tej samej transakcji zaraportowane przez kontrahentów są na bieżąco łączone. Na tej podstawie organy podatkowe wysyłają podatnikom informacje o statusie transakcji: zaakceptowana, częściowo zaakceptowana lub odrzucona. W ten sposób przedsiębiorcy dostają informację zwrotną o nieprawidłowościach jeszcze przed terminem rozliczenia podatku i mogą poprawić błędy zanim wezwie ich do tego fiskus. Skróceniu mają ulec również terminy zwrotu podatku.

Przede wszystkim zmniejszanie luki podatkowej

Nie należy jednak łudzić się, że ogromne inwestycje, jakie poczynił hiszpański rząd na wdrożenie SII, mają na celu tylko ułatwienie rozliczeń podatnikom. System ma przede wszystkim usprawnić podatkowy compliance i na bieżąco kontrolować prawidłowość raportowanych danych. Jest to również krok w kierunku zwiększenia przejrzystości transakcji. Kolejnym będzie wprowadzenie rozwiązań pozwalających na automatyczną i masową analizę transakcji w celu wykrywania i zapobiegania oszustwom podatkowym. Na to hiszpański resort finansów ma jednak jeszcze trochę czasu. W odróżnieniu od podatników, którzy począwszy od 1 lipca 2017 r. muszą przekazywać organom dane dotyczące VAT w nowej, elektronicznej formie.

Krótki termin na wdrożenie

Pomimo licznych postulatów, przesunięcie daty wdrożenia SII, np. dla poszczególnych sektorów, nie zostało wzięte pod uwagę przez hiszpański rząd. Przedstawiciele fiskusa uspokajali podatników i zapowiadali, że po wejściu w życie nowych regulacji ministerstwo będzie otwarte na indywidualne rozmowy dotyczące sytuacji wyjątkowych. Pomimo tego, przedsiębiorcy obawiają się sankcji, jakie mogą być na nich nałożone w przypadku niedotrzymania terminu raportowania w pierwszych tygodniach obowiązywania systemu. Te natomiast nie zostały zmienione wraz z wprowadzeniem SII. Kara za nieuwzględnienie faktury w rejestrze VAT to wciąż nawet 1% kwoty brutto wskazanej w tej fakturze.

Tymczasem na poziomie zarządczym często brakuje świadomości, jak poważna zmiana zachodzi właśnie w hiszpańskim systemie podatkowym. Po 30 latach przestaje obowiązywać tradycyjny model rozliczeń, a fiskus funduje podatnikom prawdziwa cyfrową rewolucję. Hiszpański urząd podatkowy prowadził program pilotażowy, podczas którego organy analizowały przygotowanie firm uczestniczących w programie do raportowania w ramach SII. Praktyczne wnioski, jakie wyciągnięto po przełożeniu teorii na realny biznes, doprowadziły w szczególności do eliminacji obowiązku składania za pomocą SII danych dotyczących pierwszego półrocza 2017 r. Pierwotnie dane te miały być dostarczone przed podatników do AEAT do końca grudnia 2017 r.

Czy to na pewno debiut?

SII to dla hiszpańskich władz skarbowych potężne narzędzie do kontroli działalności gospodarczej przedsiębiorstw. Poziom szczegółowości informacji, jakie będą przesyłane do organów podatkowych, w połączeniu z krótkim terminem na ich wprowadzenie, zmusi większość firm do zautomatyzowania procesu i znacznie skomplikuje ew. nadużycia podatkowe.

Hiszpania, która przez ponad 10 lat nie wdrożyła SAF-T ani innego szczegółowego raportowania podatkowego, wytoczyła ciężkie działa przeciwko oszustom. Nowy model rozliczania VAT plasuje ją w czołówce krajów pod względem szczegółowego wglądu w transakcje dokonywane przez podatników. Za najbardziej kontrolujący podatników kraj uważa się obecnie Brazylię. Tamtejsi przedsiębiorcy muszą dokonać urzędowej walidacji faktur przed ich wystawieniem. Nadzór jest więc pierwotny w stosunku do aktywności biznesowej. Jednak w Europie bieżąca kontrola podatków wciąż jest nowością.

Kontynentalne jurysdykcje przyglądają się z uwagą hiszpańskim rozwiązaniom, które zaskakują poziomem rozwoju technologicznego. Po otrzymaniu informacji od podatników, AEAT musi je przetworzyć i stworzyć kontrolny rejestr VAT, który zostanie przekazany podatnikom, aby na tej podstawie rozliczyli podatek.

Hiszpania nie jest jednak nowicjuszem we wprowadzaniu elektronicznych procesów. Już dwa lata wcześniej wprowadzono tam elektroniczne fakturowanie dla transakcji pomiędzy przedsiębiorcami a administracją publiczną. Znacznie skróciło to czas spędzany przez urzędników na fakturowaniu oraz pozwoliło zaoszczędzić pieniądze – szacunkowo ponad 3 euro przypadające na każdą fakturę. Czy sukces cyfryzacji podatków zostanie powtórzony wraz z wprowadzeniem SII? Na efekty podatkowego debiutu roku, za jaki można uznać raportowanie faktur w czasie zbliżonym do rzeczywistego, przyjdzie nam jeszcze poczekać.

Ważne jest także to czym jest wdrożenie SII w Hiszpanii dla innych krajów, zwłaszcza europejskich. Jest to bowiem w praktyce przykład tego jak może dalej ewoluować system komunikacji podatników z fiskusem. Być może patrząc na Hiszpanię, patrzymy tak naprawdę na swego rodzaju eksperyment, który, jeśli się powiedzie, zostanie przeszczepiony na grunt innych krajów (szczególnie europejskich). Warto więc obserwować rozwój systemu SII w Hiszpanii, ponieważ być może obserwując kraj za Pirenejami, patrzymy na naszą podatkową przyszłość. Jedno jest pewne. Na pewno władze podatkowe innych krajów będą uważnie obserwować hiszpański eksperyment.

Read More

Pewnie się powtarzam ale warto, znowu, zwrócić uwagę na ciekawe przepisy, tym razem projektowane w obszarze zapewnienia autentyczności przesyłanych e-deklaracji i e-podań. Informacja o nich pojawiła się na profilu taxCube™ pod tym adresem: https://www.linkedin.com/feed/update/urn:li:activity:6282594278602612736

Motywacja wprowadzenia nowych przepisów jest dość prozaiczna. Po prostu zmiany w przepisach unijnych.

Niemniej, sam projekt rozporządzenia jest w pewnym zakresie dokumentem dość sentymentalnym (dla mnie), ponieważ dokumentuje dalsze odchodzenie od podejścia organów Państwa wskazującego, iż jednym sensownym mechanizmem zapewniającym autentyczność i integralność w komunikacji z organami władzy publicznej jest tzw. kwalifikowany podpis elektroniczny weryfikowany kwalifikowanym certyfikatem (pojęcie ustawowe i w ustawie zdefiniowane). Do tego korowodu dziwnych pojąć można jeszcze dorzucić bezpieczne urządzenie do składania podpisu elektronicznego.

Pamiętam historyczne już i długie boje oraz dyskusje o tym, że podpis kwalifikowany “na” e-deklaracjach, na e-fakturach i na e-podaniach de facto spowalnia upowszechnienie się elektronicznych form kontaktu obywatela (podatnika) z urzędem (nie tylko podatkowym). Po latach nieprzyjmowania do wiadomości tego faktu przez stronę publiczną, rozpoczęła się stopniowa erozja monopolistycznej pozycji kwalifikowanego e-podpisu. Byliśmy świadkami powstania możliwości wysyłania e-deklaracji bez takiego podpisu czy wysyłania e-faktur zabezpieczanych nie tylko e-podpisem.

Teraz obserwujemy kolejny krok liberalizujący sferę kontaktu z urzędem, właśnie w postaci przedmiotowego projektu rozporządzenia. Warto przede wszystkim spojrzeć jak rozbudowany został katalog mechanizmów, za pomocą których można wysłać e-deklarację czy e-podanie (a precyzyjniej, opatrzyć je e-podpisem).

Paragraf 4 projektu rozporządzenia stanowi (http://legislacja.rcl.gov.pl/docs//527/12299455/12439859/12439860/dokument293922.pdf), że:

§ 4. Deklaracje i podania mogą być opatrywane:

1) kwalifikowanym podpisem elektronicznym albo

2) podpisem elektronicznym użytkownika na portalu podatkowym zapewniającym

autentyczność deklaracji i podań, jeżeli są przesyłane przez portal podatkowy, albo

3) podpisem elektronicznym weryfikowanym przy pomocy certyfikatu celnego, albo

4) podpisem potwierdzonym profilem zaufanym ePUAP, jeżeli są przesyłane przez portal

podatkowy, albo

5) innym podpisem elektronicznym zapewniającym autentyczność deklaracji i podań.

Wciąż zatem mamy na szczycie hierarchii kwalifikowany podpis elektroniczny weryfikowany… itp. itd. Co więcej, zasadą ogólną jest, że wszystkie deklaracje i podania mogą być opatrywane tym rodzajem podpisu (par. 5 pkt 1). Jednak, w kolejnych paragrafach wprowadza się szereg wyjątków od tej zasady, pozwalających wysyłać poszczególne typy deklaracji także za pomocą pozostałych narzędzi / technologii zapewniających podstawowe parametry autentyczności.

I tak, za pomocą e-podpisu na portalu podatkowym można wysłać szereg deklaracji PIT i PCC. Jest to uzasadnione charakterem akurat tutaj wskazanych deklaracji oraz samego portalu (jego przeznaczenia). Co więcej, ten e-podpis oparty jest na szeregu unikalnych danych podatnika, który to mechanizm identyfikacji istotowo podobny do tego zastosowano w deklaracjach rocznych PIT wysyłanych bez użycia kwalifikowanego e-podpisu.

Idąc dalej, certyfikat celny “przyda się”, siłą rzeczy, do deklaracji akcyzowych oraz w zakresie podatku od gier. W zakresie konstrukcji mechanizmu identyfikacji, pewnym novum w stosunku do poprzednich mechanizmów jest użycie 17-znakowego numeru identyfikacyjnego nadawanego w Systemie Informacyjnym Skarbowo-Celnym (par. 9 pkt 4 projektu rozporządzenia).

Znalazło się także miejsce dla sławnego już systemu ePUAP, który umożliwia obsłużenie (wysłanie) kilku rodzajów deklaracji PIT.

Na koniec listy z par. 4 mamy chyba najważniejszy element całego projektu. To jest, wskazanie tzw. innego e-podpisu, któremu postawiono „jedynie” celowościowy warunek zapewnienia autentyczności (konstrukcja ustawodawcza analogiczna i poniekąd znana z przepisów o fakturach elektronicznych). W odniesieniu do tego rodzaju innego e-podpisu, projekt rozporządzenia wprowadza listę deklaracji, które takim podpisem można opatrzyć. Co bardzo ważne, formułą takiego (uwolnionego technologicznie) e-podpisu mogą być opatrywane deklaracje składane przez podatnika będącego osobą fizyczną, płatnika będącego osobą fizyczną oraz osobę fizyczną (par. 11). Następująca dalej lista deklaracji jest bardzo długa i obejmuje różnego rodzaju deklaracje VAT, PIT, PCC, SD, AKC, KOP i IGH, których wspólnym mianownikiem jest właśnie “fizyczność” składających je podmiotów.

Oczywiście w kolejnych paragrafach projekt rozporządzenia definiuje co jest minimalnym zestawem danych pozwalającym spełnić kryterium autentyczności w poszczególnych grupach deklaracji (par. 12).

Przechodząc do wniosków z tej krótkiej analizy można powiedzieć, że projekt rozporządzenia, z racji materii, jest dość hermetyczny. Nie jest to na pewno to lektura porywająca np. dla fanów „Sagi pieśni i lodu” czy „Trzech muszkieterów” (myślę, że jakąś przyjemność w czytaniu tych przepisów znajdą za to fani „Ulissesa” Joyce’a i „Lodu” Dukaja). Mimo wszystko, wynikają z niego pewne interesujące, dwie kwestie.

Przede wszystkim, widać więc wyraźnie, że osoby prawne, w kontekście całego rozporządzenia są wciąż zobowiązane korzystać dla swoich deklaracji z klasycznego e-podpisu kwalifikowanego. Tego z bezpiecznym urządzeniem i koniecznością udania do instytucji (firmy) wydającej kwalifikowane podpisy. Ma to pewien sens, ponieważ mówimy tutaj o osobach prawnych, które, w polskim systemie prawnym (przynajmniej jeszcze teraz) nie mogą dysponować własnym kwalifikowanym e-podpisem. W efekcie, wszystkie oświadczenia woli i wiedzy składane przez osoby prawne za pomocą kwalifikowanego e-podpisu są składane przez upoważnione wewnętrznie osoby fizyczne, które taki e-podpis mogą posiadać. Stąd, w jakiś sposób uzasadnione jest stawianie bardziej rozbudowanych wymogów w zakresie bezpieczeństwa i pewności obrotu.

Wreszcie, w przypadku osób fizycznych mających potrzebę (lub raczej konieczność) złożenia e-deklaracji otwiera się swego rodzaju supermarket możliwości związanych z e-deklaracjami i e-podpisami. W zależności co dla zainteresowanej osoby jest najłatwiejsze (np. w zależności jaką technologią dysponuje), może ona na różne sposoby opatrywać swoją deklarację podpisami elektronicznymi. Dla kogoś kto ma tradycyjny podpis kwalifikowany, najłatwiej będzie skorzystać z tej właśnie opcji. Ktoś inny ma profil na ePUAP. Innej osobie zdarzało się korzystać z systemu celnego. Też będzie jak znalazł. Wreszcie, kolejna osoba może dysponować tzw. innym e-podpisem, spełniającym pewne minimalne wymagania omawianych przepisów, z którego teraz będzie mogła skorzystać także w sferze podatkowej. Niektóre deklaracje można więc w efekcie złożyć (opatrzyć e-podpisem) na kilka, alternatywnych sposobów.

Bardzo słusznie. W końcu obywatel i/lub podatnik powinien mieć jak największe możliwości wyboru. Także w zakresie stosowanych technologii.

Read More

When we hear about pioneers, the vision that springs to mind (at least for those of us who used to read K. May, J. F. Cooper, J. London or A. Szklarski as a child) is the vision of North America. We can’t help but go back to Westerns and novels of those authors.

And quite possibly, the myth of Wild West, with its explorers and conquerors, would never have been able to settle in public consciousness if it wasn’t for the Homestead Act of 1862. The law that triggered a massive wave of American expansion, which moved steadily westward and actually paved a way for the growth of the United States.

And clearly, this is only one of countless examples of legislation being a spark for cutting-edge changes. Nowadays, progress no longer means the use of stagecoaches and the journey to Promised Land happens in cyberspace (with the obvious exception of unsettled places such as recent Syria). Yet, more and more developed and developing countries are still taking advantage of the potential that lays in new technologies and their actions inspire others to do likewise.

The document which set in motion the work of contemporary pioneers, in this instance from the tax industry, was the ‘Guidance for the SAF-T’ – the set of guidelines developed in 2005 by the OECD – the godfather of the modern approach to tax supervision. It was then that the tax authorities were handed an up-to-date weapon worthy of fighting dishonest taxpayers which in its efficiency may be compared to revolution brought to the Wild West by the Colt revolver or the book-famous Henry rifle.

The solution is genius in its simplicity – all information relevant to tax supervision have to be contained in one file. Starting with VAT invoices, through accounting books, ending with sales and purchase registers. Suddenly companies realized, they would have to reveal a considerable quantity of tax information to tax authorities. Moreover, reporting form imposed by SAF-T is vastly different from the one to which entrepreneurs were used to. Generating account records in Excel or PDF would no longer be sufficient. Tax authorities in countries which implemented SAF-T require reports in the XML format which quite often are is impossible to generate the file without dedicated software. Additionally, a strict, pre-set data format often proves to be quite a challenge to both the accounting and IT departments.

But let’s start from the very beginning. Where did journey of digital tax supervision pioneers, which by now has spread all across Europe, begin?

Once upon a time in Portugal

Contrary to American pioneers’ movement, SAF-T’s travel originated in the West from where it headed towards the East. Portugal was the first country to notice the opportunities arising from the solution proposed by the OECD. Since 2008 all taxpayers of corporate income tax are obliged to submit the SAF‑T file. This means that, as an example, all big chain stores are obliged to provide, with no need for a special request, the tax authorities with monthly reports in XML format containing information about clients, payments or suppliers.

Austria implemented SAF-T a year after Portugal. However, that was enough for this country to opt for a different model from the Portuguese one. The main difference being that the files are sent by entrepreneurs only on tax authorities’ explicit demand. On the one hand, this means that companies are not burdened with generating files required by tax administration regularly. On the other hand, they never know when the request for those files may come. Tax authorities are the ones to determine which data should be presented in each specific case.

Portugal decided to concentrate on close to real-time data control. It makes SAF-T similar to a new type of tax return which may be used to identify audit targets. On the contrary, Austria chose a model in which SAF-T is just a new format of data submission during tax audit. It doesn’t influence initial assessment of compliance but can make data analysis easier. In a short period of time Europe saw the emergence of two different approaches to SAF-T. Which of them would be more popular? Which countries would model (consciously or not) Portugal and which Austria? Turns out, we had to wait a little to hear the answer.

The new adventures of SAF-T

SAF-T’s conquest of Europe stopped for a few years just to re-emerge in France (a hub of revolutions since XVIII century) under the name FEC, implemented in 2014. FEC shows that Portugal’s SAF-T model was perceived superior by France. Under this model taxpayers are obliged to generate required files without explicit request. In contrast to residents of Magellan’s homeland, companies registered in France or having branches there are obliged to submit data required by FEC to tax administration only once a year. We can only suspect how big the file send to tax departments by biggest French hypermarkets may be given just one unit can handle anywhere between 5 to 30 thousand of clients daily.

From France SAF-T moved over to neighbouring Luxemburg. And once again countries which implemented the system within one year from one another settled for different solutions. Luxemburg, which is traditionally being chosen by companies as a place to register headquarters because of its favourable tax policy chose in favour of the Austrian model – sending files on demand. Taxpayers there have 15 days to generate file. Small businesses, taxpayers benefiting from a simplified VAT regime and taxpayers who are exempt from Standard Chart of Accounts obligation are excluded from this obligation. However, Luxemburg plans to extend SAF-T to all entities subject to VAT taxation.

The magnificent two (five may join in)

In 2016 SAF-T reached first Central-Eastern European countries – Poland and Lithuania (and by doing so, it has breached the historic economic frontier on the Łaba River). In those countries SAF-T finally received local modifications, diverging from standards proposed by the OECD, for instance with regards to the scope of required information.

Polish equivalent of SAF-T consists of 7 files (sic!). However, entrepreneurs are only obliged to regular submissions of the JPK_VAT structure. The remaining six structures are prepared on demand of tax authorities. During the audit Polish tax authorities may demand particular files such as bank account statements or warehouse movements in the XML format. The range of required data is therefore quite untypical, especially considering that SAF-T was implemented to make tax audit more efficient.

Lithuanian i.MAS, similar to Polish SAF-T, consists of seven subsystems (coincidence? Or perhaps a consequence of Polish-Lithuanian Commonwealth). One of them – i.SAF-T is based directly on the OECD standard. In addition, Lithuanian tax authorities created an i.SAF subsystem, through which invoice data will be submitted and i.APS – an accounting system for small companies.  Obligation to share data by SAF-T structure depends on reaching a certain threshold of net sales. Its precise amount however, is shrinking each year. From 7mln Euro in 2016 (report duty actualizes on 1 January 2018) to 45 000 Euro in 2017 (report duty actualizes in 2020). This in turn means a growing number of entities obliged to use i.MAS from year to year.

In case of retail companies, the most significant i.MAS subsystem may be the i.EKA module which requires regular submissions of cash registers data. The more complex the entity, the more data it has to generate. This means that big store chains are or may soon be obliged to supply information detailing operations from each of their cash registers.

Dance with invoices

In 2016 an alternative for SAF-T emerged in a form of detailed VAT reporting. Czech Republic was the first country to show interest in it (“Czech New Wave”) by implementing the VAT Control Statement. This system aims to emphasize VAT invoice tracking. VAT taxpayers with turnover below 10 000 CZK are allowed to submit to tax authorities only the following data: VAT numbers of buyer and seller, base amount and VAT amount. Companies with higher turnover however, may be asked for more detailed information. Data are sent to tax authorities in electronic format monthly or quarterly with no need of an explicit request.

The Czech SAF-T alternative focused mainly on detailed VAT reporting became a trend in 2017. Hungary in turn, implemented a system which electronically shares data from invoices in real-time. All invoices exceeding 100 000 HUF (320 EUR) have to be registered in this manner. What’s particularly important, is that the obligation also applies to companies which are only registered in Hungary as VAT taxpayers.

Going back to Southern Europe, we shouldn’t forget Italy (after all – all roads lead to Rome) which in 2017 introduced electronic VAT reports in which all kinds of information have to be submitted. Those quarterly report comprise of the following data: client’s data, date and number of invoice, tax base, tax rate, total tax value and the transaction type. Italy and Hungary have one more thing in common, namely in both of these countries failing to fulfil the obligation may result in fine.

In 2017 Spain also decided to adopt SAF-T and connect its capabilities with solutions typical for detailed VAT reporting. First of all, Spanish tax authorities put more emphasis on the real-time control. It manifested mainly through the way invoices are submitted. All invoices have to be reported within 8 days from the issue date and Spain aims to ultimately reduce this time to 4 days.

This kind of real-time invoice registration will require good organization. Moreover, in some cases implementation of dedicated software will be needed. Otherwise identification of the appropriate data on invoices and reporting it to tax authorities may be impossible.

3:10 for SAF-T

More and more countries are walking the path marked out by pioneers of digital tax audit with the ultimate goal of boosting the financial transparency of companies. Norway should be the next in line – implementing the SAF-T in 2018 for companies with turnover above 5mln NOK.

SAF-T is the harbinger of change in the approach to audit and tax as a whole. Entrepreneurs just as first American settlers have to face new challenges. Even though they may not be in danger of grizzly bear’s fangs any more the consequences of not adapting to the new circumstances may be dire. Not delivering required files on time may result in tax audit, sanctions, reputation damage and in extreme cases – falling out of market. It is therefore, another tax topic to take into consideration and eventually implement into a daily routine.

Read More