Lancering en implementatie RGS; een terug- en vooruitblik

Reactie van RGS organisatie op resultaat GBNED-onderzoek

Bij publieke en private partijen heerst al jaren de behoefte aan het transparanter en eenvoudiger inrichten van de rapportageketen. In 2014, twee jaar nadat de eerste gesprekken tussen initiatiefnemers en geïnteresseerden hadden plaatsgevonden, werd RGS 1.0 met enthousiasme gelanceerd. Maar niet zonder verschillende uitdagingen en knelpunten. Onlangs heeft onderzoeksbureau GBNED de resultaten van een onderzoek naar de adoptie van RGS onder softwareleveranciers en intermediairs gepubliceerd, met als hamvraag "wat gaat er mis met de introductie van RGS?". Een belangrijk signaal vanuit de markt waar de voorzitters van de drie RGS gremia* de markt en de gebruikers graag toelichting op bieden.

Aan de slag met feedback uit de markt

De aanleiding voor deze toelichting is niet alleen een reactie op de resultaten uit het GBNED-onderzoek. Sinds augustus 2018 loopt er tevens vanuit de RGS organisatie een onderzoek onder gebruikers en niet-gebruikers. Dit is verspreid onder de leden van de diverse koepelorganisaties, sociale media platformen en de RGS website. De resultaten van beide onderzoeken, vormen de basis voor een analyse op de huidige situatie, het inventariseren van behoeften onder (niet-)gebruikers, in gang zetten van toekomstige ontwikkelingen en het vormgeven van een Roadmap.

Terugkoppeling op het implementatieproces

De standaardisatie geboden door RGS betekende een stap richting het transparanter en eenvoudiger inrichten van de rapportageketen. Vier jaar na lancering zijn een aantal slagen gemaakt:

• Een groot aantal softwareleveranciers van financiële boekhoudpakketten heeft RGS, met wisselende diepgang, ingebouwd;
• Met het vrijgeven van RGS 3.0 in 2017 ligt er een stabiele en kwalitatief verbeterde RGS versie;
• Het aantal toepassingen op basis van RGS groeit, bijvoorbeeld voor data-analyse en benchmarken, en binnen fiscale- en dashboardsoftware;
• Verschillende early adopters in de markt zijn aan de slag gegaan met RGS. Dit biedt de mogelijkheid om gebruikerservaringen te toetsen en te kijken naar verbeteringen en knelpunten.

Een goede implementatie betekent tevens dat er nog verschillende stappen te maken zijn:

• Softwareleveranciers zijn in toenemende mate bereid om te investeren in RGS. De SBR verplichtstellingen van de afgelopen jaren hebben echter voorrang gekregen bij het keuzeproces dat softwareleveranciers doorlopen over het inzetten van middelen;
• Als RGS alleen gebruikt wordt voor externe rapportages blijft de toegevoegde waarde gering. Dit omdat rekeningschema’s in de meeste gevallen al gekoppeld zijn aan rapportagesoftware;
• Bij de gebruikers zijn de voordelen van overgaan op RGS nog onvoldoende bekend. De adoptie van RGS gaat namelijk niet alleen over techniek. Voor eindgebruikers betekent het tevens een andere werkwijze en inrichting van organisatieprocessen. Hierdoor ontbreekt bij een grote groep de ‘sense of urgency’ om met RGS aan de slag te gaan.

Hoe spelen we hierop in?

In gesprek blijven met de markt, regelmatig behoefte-inventarisatie laten plaatsvinden en hierop inspelen zijn cruciaal voor een goed verloop van implementatie van RGS. De organisatie van RGS neemt daarom stappen om hierin verbeterslagen te maken.

Toelichting conclusies GBNED-onderzoek

Het onderzoek van GBNED sluit af met een aantal conclusies. Hieronder per conclusies een reactie en toelichting vanuit de voorzitters van de drie RGS gremia.

Beschikbaar stellen van praktijkvoorbeelden op basis waarvan de werking van RGS concreet aangetoond wordt op alle mogelijke fronten is volgens ons een must.

Op de RGS website zijn praktijkvoorbeelden gedocumenteerd. In juni is bijvoorbeeld een filmpje gelanceerd met drie gebruikers aan het woord. Deze gebruikers vertellen waarom zij RGS geïmplementeerd hebben en welke voordelen dat heeft opgeleverd (de 'waarom' vraag). Mede getriggerd door de bevindingen van GBNED en ons eigen onderzoek gaan wij het accent leggen op de 'hoe' vraag (hoe heb je RGS geïmplementeerd, waar ben je tegenaan gelopen, welke lessen zou je willen delen met anderen). Omdat de implementatie van RGS voor een intermediair tot een zekere zin software-afhankelijk is gaan wij hierin een balans zoeken tussen generieke aspecten van de implementatie en de software-specifieke aspecten.

Het aantal RGS-codes is inmiddels de 3.000 gepasseerd en op basis van het aangekondigde RGS 3.1 blijken het aantal RGS-codes nog verder toe te nemen. Er lijkt sprake van wildgroei.

Los van het leidende karakter van de vraagstelling in het onderzoek herkennen wij ons niet in deze conclusie. Wij hebben voorheen geen klachten of opmerkingen ontvangen over het aantal RGS codes. In het zelfde rapport van GBNED wordt NOAB gevraagd op dit punt te reageren. NOAB heeft aangegeven dat het niet uitmaakt hoeveel codes er zijn: “Je kiest de gewenste codes per ondernemingsvorm of per branche, en je hebt een beknopt rekeningschema voor de ZZP’er. Om die keuzes te kunnen maken heb je dus een ‘allesomvattend’ RGS nodig.” aldus NOAB.

Hoewel de stabiliteit van RGS een punt van aandacht is geweest, is er geen sprake van ‘wildgroei’. Wij hebben de geluiden van onze stakeholders binnen en buiten de RGS gremia gehoord en wat betreft de stabiliteit is de afgelopen periode veel werk verricht op dit gebied. In de transitie van RGS 2.0 naar 3.0 zijn de nodige wijzigingen doorgevoerd omdat anders dan eerdere versies van RGS, de SBR rapportages als leidraad zijn genomen. Nu hebben wij een stabiele RGS 3.0 versie met een meer volwassen beheerorganisatie. Wijzigingen blijven nodig om in lijn te blijven met wet- en regelgeving en gebruikerswensen. Nu het beheer beter is ingericht, is ook de planning van updates voorspelbaarder geworden. Met het uitbrengen van RGS 3.1 zitten wij op schema om de taxonomie eind dit jaar definitief te maken.

Besluitvorming laat te wensen over. Zo is het nog steeds niet goed duidelijk hoe om te gaan met extensies binnen RGS. Dat laatste leidt mede tot wildgroei van RGS-codes.

Wij vinden deze conclusie lastig te plaatsen want wij lezen weinig concreets op dit gebied in de onderzoeksresultaten. Duidelijk is dat vooral de implementatie te wensen overlaat maar dit heeft wat ons betreft minder te maken met de besluitvorming van de RGS organisatie en meer met de adoptie van RGS door de markt.

Wat betreft de extensies: er zijn op dit moment nog geen extensies toegevoegd aan RGS. Er lopen wel gesprekken met een aantal branches voor branche-specifieke uitbreiding om rapporteren en benchmarken binnen deze sectoren te ondersteunen met RGS. Meest concrete hiervan is de sector Woningcorporaties die voortvarend bezig is met een uitbreiding van RGS. De verwachting is dat deze eind dit jaar toegevoegd zal worden aan RGS.

De RGS-taxonomie is niet compleet, waardoor softwareleveranciers afhankelijk zijn van het Excel-tijdperk om bijvoorbeeld gebruik van filters aan te bieden aan cliënten.

Het RGS-schema (Excel) en de RGS Taxonomie (XBRL/XML) hebben allebei een eigen specifieke functie. Het RGS-schema wordt bijvoorbeeld gebruikt om de koppeling tussen grootboekrekeningschema en de referentiecodes te bepalen. De reden dat het RGS-schema in Excel wordt gepubliceerd is dat deze dan door een gebruiker gemakkelijk hanteerbaar is. Hoewel softwareleveranciers gebruik maken van het RGS-schema zijn het voornamelijk eindgebruikers zoals intermediairs en ondernemers die het RGS-schema hanteren. Doorgaans hebben zij geen verstand van XML. Het filter dat in het RGS-schema zit, is puur om de eindgebruiker te faciliteren, om een deelselectie van de referentiecodes te krijgen.

De RGS Taxonomie definieert per entrypoint de koppeling tussen één of meerdere referentiecodes en een SBR-concept. Aangezien alleen softwareleveranciers XBRL-rapportage software vervaardigen is het evident dat deze wel in het XBRL/XML-formaat wordt opgeleverd. Een filter opnemen, zoals gedefinieerd in het RGS-schema, heeft in de RGS Taxonomie geen toegevoegde waarde. Immers het uitgangspunt is het samenstellen van een entrypoint (rapportage) en hiervoor is wel een filter aanwezig in de RGS Taxonomie.

Tot slot, softwareoplossingen, zoals API’s, mogen niet binnen de SBR Governance worden vervaardigd. De overheid zou hiermee een oneerlijke concurrentiepositie innemen.

* Namens de RGS organisatie

Dirk-Jan van Blijderveen: voorzitter van de Taskforce Implementatie RGS

Robert Mul: voorzitter van de Expertgroep RGS

Jacques Urlus: voorzitter van de Beheergroep RGS