In de afgelopen weken zijn er slechts twee jaarrekeningen via XBRL gedeponeerd bij de Kamer van Koophandel. Van de beloofde lastenverlichting door XBRL is nog weinig te merken.
"Het zijn nog geen grote aantallen," geeft persvoorlichter Diana Vergeer van de Kamer van Koophandel toe. "We hebben wel bewezen dat het werkt en bedrijven kunnen nu via XBRL gaan aanleveren. Zelf verwachten we dat intermediars pas volgend jaar mee gaan doen. Op dit moment hebben ze het nog te druk met de jaarrekeningen zelf." De jaarrekeningen konden overigens afgelopen jaar al via PDF worden aangeleverd. "Daar zagen we ook nog geen grote aantallen. Ze wisten dat XBRL er aan kwam. Dan investeer je niet in een tussenvorm."
Tegengas
Daar ligt volgens Gerard Bottemanne van onderzoeksbureau GBNED nu juist het probleem. "Eerst is het PDF, de Belastingdienst doet het nog met BAPI dus van echte standaardisering is nog geen sprake. Ik geloof best dat XBRL – of een andere universele standaard – op den duur het beloofde gemak geeft, maar voorlopig zie ik daar nog niets van terug. Er wordt met mooie beloftes zand in de ogen van ondernemers gestrooid. Ik begrijp ook niet dat MKB Nederland of het VNO niet meer tegengas geven. Alleen het College van Belastingadviseurs durft een kritisch geluid te laten horen. Verder blijkt uit onderzoek dat veel softwareleveranciers nog niet klaar zijn."
Lastenverlichting
Mohamed Amri, productmanager accountancy van AFAS legt uit dat men blij is met elke vorm van ketenintegratie. "Waar ik wel mijn vraagtekens bij zet, is het gekozen tijdspad. Op dit moment zet de Belastingdienst het XBRL-document om in XML. Converteert het naar EDIFACT en zet deze op het eigen systeem. Dan mag de overheid zeggen dat dit hún probleem is, maar als er een fout zit in de aangifte, worden de softwareleveranciers er op aangesproken. Bij de accountantskantoren die er echt mee moeten werken, leeft XBRL nog niet echt. De vraag is terecht of het wel echt een administratieve lastenverlichting oplevert. De meeste zaken gaan nu ook al digitaal weg."
Iedereen lijkt het er over eens dat de invoering tijd zal vragen. Rien Stor, hoofd architectuur van GBO Overheid: "De infrastructuur is er klaar voor maar zowel aan de vraag- als aan de aanbodzijde moet nog veel gebeuren. Dit soort zaken kosten tijd. Normaal wordt er altijd gezeurd dat de overheid achter de feiten aanloopt. Nu lopen we voor en is het wéér niet goed!"
Het inrichten van een informatieketen op basis van een nieuwe standaard zoals XBRL vergt tijd, geduld en doorzettingsvermogen. De relatieve onbekendheid met de standaard speelt een rol, maar zeker ook het feit dat gangbare financie pakketten nog niet XBRL-enabled zijn maakt het lastig om rapportages te maken. Het inbouwen van XBRL functies in een pakket is niet zo eenvoudig en het vraagt veel kennis van de technische en functionele aspecten van taxonomie en de XBRL specificaties. De kunst is natuurlijk om deze complexiteit voor de gebruikers verborgen te houden. We zitten nog niet in een pull-market, dus een leverancier kijkt liever nog even de kat uit de boom.
Als we kijken naar de mogelijkheden die deze elektronische rapportage standaard biedt, dan kan men concluderen dat er geen alternatief voorhanden is. Er zijn diverse XBRL rapportage projecten in productie. Kenmerkend hierbij is dat de software voor het produceren van de XBRL rapportages vaak onderdeel vormde van het project. De gehanteerde taxonomie bestrijken meestal ook een kleiner rapportage domein, dit in tegenstelling tot de Nederlandse Taxonomie.
De Nederlandse overheid is op dit gebied toonaangevend en heeft haar nek uitgestoken door in te zetten op deze innovatie. De heer Stor heeft volkomen gelijk. De invoering van XBRL ’takes more than two to tango’. Het lijkt een beetje op het fax probleem. Het wordt echt nuttig als vele een fax hebben en deze ook gaan gebruiken. Gewoon doorzetten, geduld hebben en stap-voor-stap naar het einddoel werken. Tevens proberen te zorgen dat de software industrie van financie pakketten daadwerkelijk XBRL gaat implementeren.
De mogelijkheden van XBRL gaan verder dan pure financie rapportages en zal nieuwe toepassingen gaan opleveren en zo bijdragen aan een algehele kostenverlaging (of tenminste een minder snelle stijging van kosten veroorzaken doordat veel ‘handwerk’ in de nieuwe toepassingen gaat vervallen).
De inzender van de vorige reactie, Peter Stamps, werkt ongetwijfeld bij een van de weinige IT bedrijven die verdient aan XBRL of daar een verdienmodel in ziet. Stamps meldt zelf een belangrijk deel van de reden van het mislukken van XBRL, namelijk ” Het inbouwen van XBRL functies in een pakket is niet zo eenvoudig en het vraagt veel kennis van de technische en functionele aspecten van taxonomie en de XBRL specificaties”. Als je als overheid een standaard neerzet die opgepakt moet worden door honderden softwareleveranciers moet je een standaard neerzetten die juist EENVOUDIG is in te bouwen, anders schiet je je doel volledig voorbij en kost het alleen maar geld. XBRL is niet zo succesvol als sommigen doen geloven. In Ierland zijn ze er maar mee gestopt en in Nederland komen we niet verder dan het noemen van een project binnen de Waterschappen en Gemeenten van enkele jaren geleden. In de praktijk wordt voor dit laatste liever gebruik gemaakt van Excel. En dan hebben we nog de infrastructuur om gegevens uit te wisselen met de overheid. De overheidstransactiepoort is bijzonder onduidelijk. Ooit begonnen via het ICTAL project binnen EZ en nu via Financien. Van een geaccepteerde standaard door ALLE partijen is zeker geen sprake. Tja de overheid heeft een leuk speelte voor dure (veelal extern ingehuurde) IT specialisten. Wij als ondernemers moeten voor de rekening opdraaien. Ben benieuwd welk deel van de rekening opgemaakt wordt door Atos Origin waar de heer Stamps werkt.
De heer Bottemanne spreekt over het mislukken van XBRL en probeert dit aan de hand van wat voorbeelden te illustreren. Dit is een conclusie die wel erg kort door de bocht is. We staan wereldwijd nog maar aan het begin. Er zijn wel degelijk voorbeelden bekend waar al bewezen is dat de XBRL standaard geschikt is en voordelen biedt. De toezichthouder van de Spaanse beurzen is ruim een jaar in produktie. Ruim 3000 bedrijven rapporteren in XBRL. In Amerika heeft de toezichthouder van de banken een uitgebreide rapportage gegeven van haar bevindingen nadat ze in productie is gegaan. Deze resultaten zijn voor iedereen via het internet toegankelijk. De SEC (Securities and Exchange Commission) is ervan overtuigd dat deze standaard er zal komen en stelt ruim $54 miljoen dollar beschikbaar. In vele landen in de wereld start men met XBRL. De eerste XBRL open source componenten zijn beschikbaar, dus ook voor de pakketleveranciers. Natuurlijk moet men eerst investeren (eerst zaaien en dan oogsten). XBRL biedt een grote flexibiliteit en moet een complex domein, namelijk dat van (financiele) business rapportages, afdekken. Dit is niet met een simpele standaard op te lossen; dat is een utopie. Je hoeft als gebruiker ook niet te weten hoe XBRL in elkaar steekt. Als vergelijking je hoeft niets van de MP3 muziekstandaard te weten om toch te kunnen genieten van de muziek. De industrie moet natuurlijk wel MP3 spelers en software ontwikkelen. Zo geldt dat ook voor XBRL. Er zijn al diverse productleveranciers die tijdens de internationale XBRL congressen aantonen dat XBRL onder de motorkap aanwezig is terwijl de gebruiker profiteert van krachtige functionaliteit dankzij deze standaard.
Er zijn talloze rapportage trajecten die vandaag de dag absoluut niet efficient verlopen. Veel informatie reeds ingebracht in computer systemen wordt geprint, gefaxed of gemailed en weer overgetypt omdat de formaten en definities niet op elkaar aansluiten. Het laat zich raden dat hier een efficiency slag mogelijk is, zeker als je de kracht van XBRL kent.
Er zijn in de gehele keten kosten te besparen. Zowel de zender als de ontvanger van informatie moet investeren anders zal een besparing niet echt lukken. Het op gang brengen van het ‘XBRL vliegwiel’ kost energie.
Het alternatief om door te gaan op de huidige manier biedt eenvoudigweg geen perspectief en een eenvoudige standaard ontwikkelen zal ook tot niets leiden, omdat deze ontwikkelaars hetzelfde traject zullen moeten doorlopen als de vele acoountants, IT-specialisten en anderen gedaan hebben die zich wereldwijd vrijwillig inzetten om XBRL tot een succes te maken.