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.