Magazine 01 september 2009

XBRL: Samenwerking accountants met softwareleveranciers essentieel

XBRL is voor accountants meer dan een technische ontwikkeling die alleen de softwareleverancier aangaat. Dat steeds vaker wordt gesproken over Standard Business Reporting (SBR) geeft al aan dat XBRL een bredere betekenis heeft. Als de eigen leverancier niet 'bij' is, kijk dan eens verder wat dat betekent.

Dit artikel is verschenen in de Accountant nr. 9, 2009

Bekijk alle artikelen uit dit nummer

» Download dit artikel in pdf

Mark Bisschop en Paul Snijders

De realisatie van Standard Business Reporting, en daarmee de implementatie van XBRL binnen het accountantskantoor, gaat behalve over techniek ook over optimalisatie van werkprocessen en standaardiseren van rapportages. Door de steeds bredere acceptatie binnen de rapportageketens in Nederland, moet nu worden nagedacht hoe deze standaardisatie moet worden vormgegeven. Het meeste werk kan inmiddels worden gedaan door de softwareleveranciers.

Standaard business reporting zal de rol van de intermediair (accountant) gaan veranderen. Door standaardisering hoeft de accountant zelf steeds minder handelingen uit te voeren, want dat wordt al gedaan door de met XBRL ingerichte systemen. Hierdoor ontstaat meer ruimte voor advisering en kan de cliënt breder worden bediend.

Steeds meer ontwikkelingen vergroten de behoefte aan een standaard waarmee in de behoefte van alle gebruikers kan voorzien.

Juist nu

Aan de overheid ligt het deze keer in ieder geval niet. Zij heeft alle randvoorwaarden geschapen om standaardisatie met XBRL op gang te laten komen. Efficiency is daarbij het hoofddoel. Voor accountants zijn er echter meer redenen om XBRL te gaan implementeren. Denk aan onderwerpen als de samenval, verkorte winst- aangifte en horizontaal toezicht.

Zeker als banken in staat zijn een XBRL-jaarrekening te ontvangen en verwerken, mag worden verwacht dat een verdere versnelling kan worden gerealiseerd. Processen en infrastructuur zijn inmiddels zo ingericht dat XBRL de ‘taal’ is waarin gesproken zal gaan worden.

Wat nu als systemen deze ‘taal’ niet kunnen spreken? Communiceren is dan niet mogelijk of moet worden uitbesteed - terwijl de meesten van ons liever alles in eigen hand houden. Juist nu er al veel mogelijk is met XBRL, is dit een uitgelezen moment om het softwareapparaat eens goed onder de loep te nemen. Achteroverleunen en wachten totdat de softwareleverancier XBRL gaat aanbieden leidt mogelijk tot ongewenste achterstand.

Trendsetters

Dat XBRL de standaard zal worden binnen de rapportageketen is logisch en zeker. De overheid heeft miljoenen geïnvesteerd in SBR, met als gevolg dat instanties als het CBS, Kamer van Koophandel en Belastingdienst zo langzamerhand zitten te wachten op een stroom aan XBRL-berichten. Tot dusver komt die stroom langzaam op gang. Maar we zouden hier weleens te maken kunnen hebben met de bekende stilte voor de storm.

Elke nieuwe ontwikkeling heeft zijn trendsetters. XBRL geniet bijvoorbeeld ruimschoots de aandacht van accountantsorganisaties als BDO en Gibo Groep. Deze twee organisaties hebben begrepen wat de mogelijkheden zijn van standaardisatie en stralen dit ook uit. Liepen trendsetters tot voor kort nog aan tegen het probleem van de remmende voorsprong, inmiddels plukken zij als eerste de vruchten van XBRL.

Ook enkele leidende softwareleveranciers zoals Unit4Agresso, Coda, Pro-Management en Accountview bieden keurige XBRL-faciliteiten.

Dat deze partijen publiekelijk aangeven XBRL te ondersteunen, betekent niet dat zij de enige zijn. Achter de schermen hebben meer partijen de XBRL-implementatie met hoofdletters ingevuld in hun agenda.

Scenario's

Bij het gereed maken van interne systemen voor XBRL is er een aantal mogelijkheden. Hieronder een korte beschrijving met de voor- en nadelen:

1. XBRL op rapportniveau

Neem hierbij het finale rapport opgemaakt en wel. Deze legt veldje voor veldje een koppeling aan met de definities van XBRL-taxonomieën. Dit werkt, er zijn zelfs tools die dit concept als basis hebben.

Voordeel: Het rapport ziet er hetzelfde uit. Nadeel: Zeer arbeidsintensief omdat elk celletje moet worden behandeld, en dat binnen alle rapportage-templates. Ook audit en control zijn lastig of zelfs onmogelijk. Verder moet, als het rapport of de taxonomie verandert, veel onderhoud worden verricht.

2. XBRL op dataniveau

Hierbij worden de rapportagegegevens uit de database rechtstreeks gekoppeld met XBRL. Een codeschema voor bijvoorbeeld het grootboek wordt gekoppeld met de XBRL-definities. Bijvoorbeeld: 110.001 Kas --> IFRS_Cash (XBRL-definitie).

Voordeel: Er vindt eenmalig koppeling op gegevensniveau plaats en de koppeling is volledig herbruikbaar. Betere audit en control en minimale inspanning bij wijzigingen.

Nadeel: Het moet ook eenmalig worden opgezet en onderhouden. Dit vergt marginale inspanning maar is wel het meest efficiënt en effectief.

3. XBRL uit basissystemen

Een aantrekkelijke oplossing is wanneer alle leveranciers van software waarmee gewerkt wordt, een save as-optie bieden.

Voordeel: Er hoeft niets te worden gedaan, de softwareleverancier zorgt voor de realisatie.

Nadeel: Niet alle softwareleveranciers zijn zover, sommige hebben nog geen enkele stap gezet in deze richting. Tweede punt is dat zelfs áls de leveranciers XBRL-opties bieden, er met elke leverancier waarmee nu wordt gewerkt, moet worden onderhandeld; met alle verschillende applicaties moet XBRL worden aangemaakt, waarna dit moet worden beoordeeld en gecontroleerd.

Steeds meer accountantskantoren kiezen voor een soort tussenoplossing zoals beschreven onder 1. Het rapport wordt presenteerbaar gemaakt in de rapportgenerator, waarna het vervolgens kan worden ‘geconverteerd’ naar XBRL en verstuurd naar elke gewenste partij.

Het is echter niet mogelijk om de rapportgenerator als aangiftesoftware te gebruiken. Dit betekent dat geen verkorte winstaangifte kan worden verstuurd in XBRL-formaat. Accountants doen er verstandig aan om vooral ook de samenval en de ontwikkeling rond de verkorte winstaangifte met XBRL in de gaten te houden.

Communicatie met cliënt en overheid

Naast de implementatie van XBRL binnen de rapportageketens speelt bovendien communicatie met overheid en cliënt een voorname rol. Ook deze aspecten verdienen nu de aandacht. XBRL-documenten kunnen uitsluitend via de zogenaamde Overheidstransactiepoort (OTP) naar de Kamer van Koophandel, Belastingdienst of het CBS worden verstuurd. Dit betekent dat er één communicatiekanaal zal zijn voor verzending. Voor de Overheidstransactiepoort zijn ook onderwerpen als authenticatie en het autorisatieregister aangepakt.

Overweeg verder ook de implementatie van een ‘cliëntenportaal’ voor communicatie met cliënten en kijk of het inpassen van XBRL-rapportages een centrale functie binnen de organisatie zou moeten zijn. Ook het onderhouden van het cliëntendossier kan met XBRL-opslag worden uitgevoerd.

Leveranciersonafhankelijk

De genoemde onderwerpen als invoering van de samenval, verkorte winstaangifte, standaardisering, centrale communicatie, het cliëntendossier en niet afhankelijk zijn van de verschillende leveranciers, zijn nu actueel. Ze kunnen de aanleiding zijn om nu te overwegen om meer fundamenteel de XBRL-processing te onderzoeken. Zo'n fundamentele benadering pakt zowel de optimalisering van interne processen als de communicatie met cliënt en uitvragers breed aan en levert uiteindelijk wellicht het beste resultaat.

Nadeel: Het vergt wat meer inspanning.

Voordeel: Completere benadering en legt de basis voor het cliëntenportaal en Overheidstransactiepoort. Het geeft ook onafhankelijkheid van leveranciers.

Mond vol tanden

De overheid ziet graag dat de vraag naar XBRL vanuit de markt zal gaan toenemen, waardoor verplichtstelling niet noodzakelijk zou zijn. Als banken straks aangeven dat zij XBRL-jaarrekeningen willen gaan ontvangen, dan kan de rapportageketen hier niet meer omheen.

Wie wil straks met de mond vol tanden staan als de cliënt voor een lening afhankelijk is van snelle, correcte aanlevering aan de bank? Of als die cliënt direct belang heeft bij een snelle afhandeling bij de fiscus op basis van horizontaal toezicht?

Noot
Mark Bisschop is werkzaam bij Van der Veen & Kromhout registeraccountants en student NIVRA-Nyenrode. Paul Snijders is directeur bij Semansys Technologies, vice chair XBRL Nederland en gastdocent NIVRA-Vera. Het artikel is geschreven op persoonlijke titel.