Blockchain kan btw-fraude helpen voorkomen? – Deel 2

In het vorige deel heb ik een voorbeeld gegeven van btw-fraude. Dat deel eindigde met de introductie van blockchain als middel om die fraude te bestrijden. Nu gaan we dat eens in de praktijk bekijken.

Blockchain

De laatste afbeelding in het vorige deel was een ‘snapshot’ van een btw-blockchain. Dat heb ik nog iets aangepast. In de volgende afbeelding zijn de blocks ondertekend:

 

Elk block toont een verkoop- of inkoopfactuur. De verkoopfactuur van de één is de inkoopfactuur van de ander. Ze zijn beide onderdeel van dezelfde transactie. Oftewel: controleschakel = verkoop/inkoop transactie. En dus is elke transactie twee blocks. Dit is anders dan bij Bitcoin waar elke transactie in maximaal één block is gevat. Zo’n transactie ‘uit: 0.5 bitcoin/in 0.5 bitcoin’ moet tegelijkertijd plaatsvinden omdat er anders bitcoins blijven zweven. Bitcoin is iets complexer dan dat overigens. In ons geval met facturen kan je niet de transactie in één block stoppen want op het moment dat ik een verkoopfactuur maak is dat nog niet een inkoopfactuur van de ander. Stel dat hij de inkoopfactuur niet accepteert? Of nooit inboekt? Er zit in ieder geval tijd tussen de verkoop- en inkoopfactuur. Dus er zijn twee blocks nodig om een verkoop- en inkoopactie weer te geven.

RSIN is een nummer waarmee de Belastingdienst fiscale entiteiten registreert. Het gebruik is niet helemaal correct in dit geval. Er had beter btw-nummer kunnen staan maar voor het principe maakt het niet uit.

Ik ga u niet lastig vallen met het hele verhaal rondom hashes. In dit geval worden ze gebruikt om te voorkomen dat er blocks toegevoegd kunnen worden in de blockchain zonder dat alle daaropvolgende blocks opnieuw uitgerekend én ondertekend moeten worden door elke RSIN.

Actoren

  • Verkopers, zij reiken verkoopfacturen uit. De in de factuur berekende btw moeten ze afdragen aan de Belastingdienst.
  • Inkopers, zij ontvangen facturen van verkopers en boeken die als inkoopfacturen in. De in de factuur berekende btw kunnen ze terugvragen van de Belastingdienst.
  • Belastingdienst, belanghebbende die uiteindelijk btw van de consument wil ontvangen.

Regels

Zo’n bovenstaande blockchain is maar een statisch ding. Het is een domme database. We moeten wat regels afspreken die met software worden gehandhaafd. In de wereld van de softwareontwikkeling noemen we dit business logic of business rules. Het beschrijft onder welke voorwaarden er iets/niets gebeurt. Sommige regels zijn er ook om het wat behapbaar te houden voor dit onderzoekje. Uitgangspunt is dat de Belastingdienst de blockchain gaat zien als de bron van waarheid voor de btw-huishouding.

  1. Alles wat af te leiden is uit data wordt niet opgeslagen als data.
  2. Tegenover elk block met type ‘Verkoop’ (verkoopblock (vb)) kan maar één block met type ‘Inkoop’ (inkoopblock (ib)) staan.
  3. Elk block moet gesigned (getekend) worden door de RSIN ‘eigen’ zodat niet iemand blocks kan toevoegen onder andermans RSIN.
  4. Een inkoopblock kan pas toegevoegd worden als een bijbehorend verkoopblock reeds aanwezig is in de chain.
  5. Een inkoopblock hoort bij een verkoopblock als de RSIN’s kruislings overeenkomen en de factuurnummers hetzelfde zijn. Dit is dan een controleschakel.
  6. De controleschakel kan goed- of afgekeurd zijn. Dit ligt niet vast als gegeven in een block maar is af te leiden uit de blocks.
  7. Een controleschakel is goedgekeurd wanneer ib.kostprijs + vb.omzet == 0, ib.btw + vb.btw == 0, ib.tarief == vb.tarief en ib.datum.maand == vb.datum.maand.
  8. Een controleschakel is afgekeurd als niet aan de voorwaarden van regel 7 is voldaan.
  9. Uiteindelijk blijft er een verkoopblock over zonder bijbehorend inkoopblock. Dat betekent dat er verkocht is aan een klant die geen btw kan terugvragen zoals de consument.

Er is nog veel meer logica op te stellen maar voor nu houden we het hier bij.

In de praktijk

We kijken hoe het in de praktijk eraan toegaat. Het voert iets te ver om nu een complete blockchain op te gaan zetten zodat we alle regels kunnen verifiëren. Regel 7 is de regel waar in mijn optiek fraude met te vroeg terugvragen of het te laat betalen mee tegengegaan wordt.

Legale gang van zaken

Verkoper stuurt een factuur van 100 euro + 21 euro btw met factuurdatum 3 april naar de klant. De klant, nu inkoper dus, boekt diezelfde factuur in op 3 april met dezelfde bedragen. Dit vertegenwoordigt een controleschakel. Dat ziet er dan zo uit:

 

Is deze controleschakel nu akkoord? Daarvoor moeten we eerst kijken naar regel 7:

  • Is de kostprijs in het inkoopblock gelijk aan de omzet in het verkoopblock? Dat is het geval: -200 tegenover 200 ofwel -200 + 200 == 0.
  • Is de btw in het inkoopblock gelijk aan de btw in het verkoopblock? Dat is het geval: -42 tegenover 42 ofewel -42 + 42 == 0.
  • Is het btw-tarief in het inkoopblock gelijk aan het btw-tarief in het verkoopblock? Dat is het geval: 21 == 21
  • Is de periode (maand in de datum) in het inkoopblock gelijk aan de periode in het verkoopblock? Dat is het geval: 4 == 4

De controleschakel is akkoord en kan worden toegevoegd aan de blockchain. De Belastingdienst kan nu afleiden dat ze van RSIN 55.263.22.14 een bedrag van € 42 btw gaan ontvangen in periode 4 van 2018. In diezelfde periode moeten ze een bedrag van € 42 overmaken aan RSIN 69.215.68.98.

Is aan de andere regels ook voldaan? Dat kun je op basis van deze informatie niet zeggen. Je zult de hele blockchain moeten controleren of er al niet een verkoop- of inkoopblock bestaat dat exact hetzelfde is. De legaliteit zit hem voornamelijk in regel 7 dus we houden de focus dan ook daarop.

Minder legale gang van zaken

Verkoper stuurt een factuur van 100 euro + 21 euro btw met factuurdatum 3 april naar de klant. De klant, nu inkoper dus, boekt diezelfde factuur in op 20 maart met dezelfde bedragen. Dit vertegenwoordigt ook een controleschakel:

Deze controleschakel zou nog weleens niet akkoord kunnen zijn. We kijken weer naar regel 7:

  • Is de kostprijs in het inkoopblock gelijk aan de omzet in het verkoopblock? Dat is het geval: -200 tegenover 200 ofwel -200 + 200 == 0.
  • Is de btw in het inkoopblock gelijk aan de btw in het verkoopblock? Dat is het geval: -42 tegenover 42 ofewel -42 + 42 == 0.
  • Is het btw-tarief in het inkoopblock gelijk aan het btw-tarief in het verkoopblock? Dat is het geval: 21 == 21
  • Is de periode (maand in de datum) in het inkoopblock gelijk aan de periode in het verkoopblock? Dat is niet het geval: 3 == 4

De inkoper vraagt de btw te vroeg terug. De controleschakel is niet akkoord en het inkoopblock zou nu niet toegevoegd kunnen worden. De inkoper zal nu zijn btw in het geheel niet terugkrijgen totdat hij een inkoopblock toevoegt met de juiste  periode erin.

En nu?

Volgens mij voorkom je met bovenstaande blockchain dus dat je btw te vroeg kunt terugvragen. Maar of dit in de praktijk zo werkt? Met zoveel belastingplichtigen? Daarbij heeft de Belastingdienst op het gebied van IT al zat uitdagingen. Als daar ook nog een blockchain bijgesleept wordt dan vraag ik me sterk af of de belastinginning niet in gevaar komt…

Dit heeft geen énkele zin

Nou, ik ga eerlijk zijn: deze hele exercitie met een blockchain aan de btw proberen te hangen, is uitputtend geweest, demotiverend en ik ga dit nooit weer doen want hier heb ik me schuldig moeten maken aan iets wat ik bestrijd: met een oplossing in de hand op zoek gaan naar een probleem.

Waarom zou je hier nu toch een blockchain voor gaan gebruiken? De Belastingdienst is de controlerende instantie die het grootste belang heeft uit naam van de overheid. Waarom niet automatisch alle inkoop- en verkoopfacturen doorsturen naar de Belastingdienst. Zij kunnen dat in een gewone, ordinaire relationele database stoppen om er vervolgens software omheen te bouwen die alle checks doet. Ik zie geen enkele meerwaarde van de blockchain hier. Waar veel blockchain-fanaten mee dwepen is de decentralisatie en de transparantie. Waarom zou je dat willen? Dit ga je toch nooit openbaar maken? Het is bijna lachwekkend: dit is concurrentiegevoelige informatie van de allergrootste orde en er is geen bedrijf dat in Nederland nog zaken gaat doen als dit een publieke blockchain gaat worden. Maar, zeggen voorstanders, dan moet je die blockchain niet openbaar maken. Wat? Het hele idee is toch dat het te controleren moet zijn?

Er zullen genoeg mensen zijn die het oneens zijn met mij maar alleen roepen is makkelijk: toon dan maar aan dat je btw wel in de blockchain zou moeten stoppen. Welke unieke eigenschappen heeft de blockchain die btw-fraude kunnen tegenaan die huidige software-oplossingen niet bieden? Ik ben benieuwd!

Ik zeg: kijk mooi naar andere oplossingen voor het oplossen van btw-fraude. Blockchain hoort daar zeker niet bij.

Gelooft u nog niet de blockchain een hype is? Ik wel en ik raad u dit artikel aan om daar ook van overtuigd te raken: https://decorrespondent.nl/8628/de-blockchain-een-oplossing-voor-bijna-niets/519071687772-2a5ee060