Softwarepakketten.nl

Onderzoek

Waarom is het ReferentieGrootboekschema (RGS) na 6 jaar nog niet van de grond gekomen: wij zochten het voor u uit

Plaatsingsdatum 31-08-2018
Berichtdatum 30 juni 2018

"Wat gaat er mis met de introductie van RGS?"

Door Gerard Bottemanne, Onderzoeksbureau GBNED.
Het initiatief voor het Referentie grootboekschema (RGS) is eind 2011 ontstaan. Het eerste werkdocument Referentie Grootboekschema dateert van 18 mei 2012. Inmiddels (zomer 2018) is RGS versie 3.0 alweer een tijdje een feit. Het gebruik van RGS in de praktijk lijkt na 6 jaar echter nauwelijks van de grond gekomen. De hamvraag is "wat gaat er mis met de introductie van RGS?".

De afgelopen 2 zomermaanden is door Onderzoeksbureau GBNED een tweetal enquêtes uitgezet om antwoord te krijgen op de vraag "wat gaat er mis met de introductie van RGS?". Het betreft een uitvraag aan enerzijds gebruikers (accountants-, administratiekantoren en ondernemers) en anderzijds leveranciers van boekhoudsoftware, jaarrekeningsoftware en fiscale aangiftesoftware.

Enquête aan softwareleveranciers

Zo’n 15 softwareleveranciers hebben antwoord gegeven op door ons gestelde vragen.
(Een vijftal leveranciers heeft de enquête voor de gebruikers ingevuld. Die antwoorden hebben wij niet verwerkt, omdat dan de kans op een vertekend beeld kan ontstaan).
Hieronder vindt u zowel de vragen als de antwoorden. 

  1. Vindt u dat in de keten “boekhoudsoftware – rapportagesoftware” RGS van toegevoegde waarde is?
    95% vindt RGS van toegevoegde waarde in deze keten.
     
  2. Vindt u dat in de keten “boekhoudsoftware – fiscale aangiftesoftware” RGS van toegevoegde waarde is?
    95% vindt RGS van toegevoegde waarde in deze keten.

  3. Vindt u dat in een andere keten RGS van toegevoegde waarde is? 
    70% vindt RGS van toegevoegde waarde in een andere keten.
      
  4. Vindt u het huidige RGS 3.0 met meer dan 3.000 RGS-codes goed werkbaar om te koppelen (door uw klanten) aan (andere) grootboekschema’s?
    Slechts 5-10% vindt RGS met meer dan 3.000 RGS-codes goed werkbaar.
      
  5. Vindt u het huidige RGS 3.0 goed werkbaar om te gebruiken als rekeningschema voor nieuwe administraties?
    Slechts 5-10% vindt RGS met meer dan 3.000 RGS-codes goed werkbaar voor nieuwe administraties.
      
  6. Maakt u in uw software actief gebruik van filtermechanismen in RGS 3.0 (Excel) en vindt u dat goed werkbaar?
    Slechts 15-20% gebruikt actief de filtermechanismen en vindt dat goed werkbaar.
       
  7. Vindt u (mutatie) niveau 5 thuishoren in RGS? Dus op het niveau van grootboekschema en zo ja kent u grootboekrekeningen om te koppelen aan niveau 5?
    Slechts 25-30% vindt niveau 5 thuishoren in RGS in relatie tot het grootboek.
       
  8. Vindt u de herhaald voorkomende rekeningen (zoals voor vennoten 1-5 en opbrengsten 1-5 met daarbinnen productgroep A-E) goed bruikbaar?
    Slechts 15-20% vindt herhaald voorkomende rekeningen goed bruikbaar in de huidige vorm in RGS.
      
  9. Een andere oplossing voor punt 8 is een analytische boekhouding (zoals ook onze zuiderburen al decennia toepassen). Wat vindt u daarvan?
    Hierover lopen de meningen nogal uiteen. Zo’n 40-50% vindt een analytische boekhouding een mogelijke oplossing voor herhaald voorkomende rekeningen. 30% vindt het geen goed idee en de rest twijfelt. Duidelijk een punt voor nadere analyse.
       
  10. Heeft u behoefte aan volledige XML-schema’s van RGS met o.a. filters en andere kenmerken? Nu zijn filters alleen beschikbaar in Excel.
    65% vindt dit een goed idee.
      
  11. Doet u iets met de huidige RGS-XBRL schema’s voor de vele entrypoints (ruim 30 volgens mij) van SBR?
    Slechts 15% maakt gebruik van de entrypoints.
       
  12. Wat vindt u van het beheer rondom RGS?
    Hier is sprake van een open vraag, waardoor we geen antwoord hebben in de vorm van een percentage. Het beeld dat naar voren komt over het huidige beheer van RGS is zeker niet altijd positief te noemen, gegeven de individuele reacties. De eerste vijf reacties zijn als volgt:

    Er lijkt weinig daadkracht uit voort te komen, maar dat is niet enkel van de beheergroep afhankelijk. Marktadoptie blijft ook sterk achter en dit heeft serieuze impact op de implementatie.

    Veel te laat op gang gekomen. Het lijkt nu de goede kant op te gaan.

    Wij vinden dat het geherstructureerd worden. Er moet een RGS ‘structuur’ zijn wat enkele keren samen komt en vooral bezig is met het schema op zich. Ten tweede moet er een RGS ‘marketing’ groep zijn wat zicht richt op aantonen, promoten en stimuleren van RGS. Taskforce implementatie is in principe afgerond want er zijn inmiddels bewezen voorbeelden genoeg. De verantwoordelijkheid tot implementatie wordt langzamerhand een gedwongen aspect.

    Ik vind dat er omslachtige keuzes worden gemaakt, voorbeeld is niveau 4 coderingen slechts van 3 posities voorzien “omdat het dan makkelijker is naar de nieuwe versie over te stappen”.

    Dit kan beter; sommige zaken zijn niet altijd op voorhand volledig geïmplementeerd.

    De verschillen tussen elke versie zijn telkens te ingrijpend geweest. Er is te weinig aansluiting met de praktijk.


    Voor meer reacties wordt verwezen naar de uitgebreide resultaten van het onderzoek, dat verderop aan de orde komt.

  13. Wanneer denkt u volledig RGS-Ready te zijn?
    Ook hier is sprake van een open vraag met sterk wisselende antwoorden, zoals:

    Als mijn klanten het meer gaan gebruiken / vragen als de keten dit nodig heeft, gaan wij de RGS ondersteuning uitbreiden.

    Wanneer de marktadoptie en bewezen meerwaarde zijn intrede doen.

    Er zijn nog geen concrete plannen voor.

    Staat niet hoog op de agenda.

Verder hebben we vanuit softwareleveranciers onder meer de volgende toelichtingen ontvangen:

  • Wij zijn een kleine softwareontwikkelaar die erg klant- en branchegericht is. D.w.z. dat wij inspelen op de wensen van de klant. We hebben geen met redenen omklede verzoeken gehad om RGS te gaan ondersteunen. Zolang dat het geval is, gaan we hier geen kostbare tijd aan besteden”.
        
  • De belangrijkste reden dat de adoptie van RGS (nog) niet op gang is gekomen is dat vrijwel alle rekeningschema’s standaard al aan rapportagesoftware zijn gekoppeld en dus een tussenstap met RGS niks toevoegt als je het alleen daarvoor gebruikt. Als het binnen API’s van boekhoud-, rapportage-, fiscale- en dashboard beschikbaar en de adoptie is hoog dan kan het veel gemak opleveren voor de gebruiker bij het koppelen van verschillende systemen”.
       
  • De toegevoegde waarde van het (lastig te implementeren) RGS is absoluut nog niet duidelijk en zeker nog geen praktijk, de belangrijkste factor voor het niet van de grond komen van dit project”.

Voor meer reacties wordt verwezen naar de uitgebreide resutalten van het onderzoek, dat verderop aan de orde komt.

Enquête aan gebruikers

Ruim 35 gebruikers hebben antwoord gegeven op door ons gestelde vragen. 
Hieronder vindt u zowel de vragen als de antwoorden. 

  1. Bent u bekend met RGS?
    98%
    is bekend met RGS.
      
  2. Bent u operationeel in de praktijk met RGS en zo ja, waarvoor?
    20% geeft aan RGS in gebruik te hebben.
      
  3. Bent u van plan RGS binnen een jaar in gebruik te nemen en zo ja, waarvoor?
    20% geeft aan RGS binnen een jaar in gebruik te willen nemen.
      
  4. Kent u echte praktijkvoorbeelden van RGS?
    20% zegt praktijkvoorbeelden van RGS te kennen.
     
  5. Bent u in voldoende mate geïnformeerd door uw branche organisatie(s) over de exacte mogelijkheden van RGS?
    15% zegt in voldoende mate geïnformeerd te zijn. Zowel NBA als NOAB worden genoemd als branche organisaties.
      
  6. Vindt u dat RGS overbodig is nu er SBR is dat al gekoppeld is aan rapportagesoftware? 
    25% vindt RGS overbodig nu SBR er al is.
      
  7. Is volgens u uw softwareleverancier(s) de vertragende factor wat betreft het gebruik van RGS?
    20% vindt softwareleveranciers de vertragende factor.
      
  8. Vindt u het huidige RGS met momenteel ruim 3.000 RGS-codes een werkbaar geheel?
    25% vindt het huidige RGS een werkbaar geheel.  

Verder hebben we vanuit gebruikerszijde onder meer de volgende toelichtingen ontvangen:

  • “Zolang opname in softwarepakketten van leveranciers geen verplichting is zal gebruik niet toenemen. Naast SBR m.i. overbodig”.
      
  • “Door eenmalig koppelen zijn de meeste problemen prima te tackelen. Dat gebeurd nu al jaren van boekhoudprogrammatuur naar rapportagesoftware en daarna nogmaals naar fiscale software en omzetting naar SBR”.
      
  • “Ik ben er in het verleden mee bezig geweest maar ik ben ermee gestopt. Veel werk om bestaande administraties om te zetten naar RGS”.
      
  • “Op zich vind ik RGS met ruim 3.000 codes wel een werkbaar geheel in relatie met het grootboek. Maar er is op diverse plaatsen geen eenduidigheid en dat maakt het 'labellen' er in sommige gevallen niet makkelijker op. Ook ondersteunende tools bieden dan geen uitkomst”.
      
  • “Ruim 3.000 RGS-codes is een gigantisch aantal nummers. Ik denk dat kantoren die voor ZZP-ers werken een dergelijk groot aantal codes niet zal gebruiken. In ons buurland wordt een standaard grootboekschema gebruikt. Heb er mee gewerkt. Geen enkel probleem met de codes. Wel anders ingedeeld maar voldeed uitstekend”.
      
  • “Laat de huidige versie 3.0 een keer langer in stand en zorg voor een handleiding hoe je e.e.a. aanpakt en op wat voor niveau je iets moet gaan koppelen”.

Voor meer reacties wordt verwezen naar de uitgebreide resultaten van het onderzoek, dat verderop aan de orde komt.

NOAB
We hebben aan NOAB gevraagd waarom zij die ruim 3.000 RGS-codes tot heden ondersteunen. Zij zitten namelijk erg dicht op het (RGS) vuur en hebben juist een achterban die zzp, micro en klein bedient. Dat leverde het volgende antwoord op door NOAB:

Zolang verwezen wordt naar RGS als standaard is het niet toegestaan referentiecodes te wijzigen of uit te breiden (bron: website RGS). Reden dat NOAB een uitgebreid aanbod ondersteunt. Omdat er zowel extern als intern gerapporteerd wordt, is het noodzakelijk dat er een omvangrijk aanbod aan RGS-codes moet zijn.

Daarnaast maakt het niet hoeveel codes je hebt in je ‘template’ of standaard. Je kiest de gewenste codes per ondernemingsvorm of per branche, en je hebt een beknopt rekeningschema voor de ZZP. Om die keuzes te kunnen maken heb je dus een ‘allesomvattend’ RGS nodig.

Overigens snappen we je verbazing over die 3.000 codes wel: je wilt een standaard ook niet té uitgebreid maken. Anders lijkt het weer op wildgroei en kan er ruis ontstaan in de eenduidigheid van verslaglegging. Maar je hebt voldoende ruimte in het schema nodig om alle ondernemingsvormen en branches onder te kunnen brengen”.

Onze conclusie
Als antwoord op de vraag "wat gaat er mis met de introductie van RGS?" zijn wij van mening dat met name de huidige RGS organisatie te wensen overlaat.

Met name op basis van de ontvangen reacties constateren wij onder meer de volgende tekortkomingen:

  • Er zijn nauwelijks praktijkvoorbeelden over het gebruik van RGS. De NBA levert zowel de Voorzitter van de Expertgroep RGS, alsmede de voorzitter van de beheergroep RGS en de NOAB levert de voorzitter Taskforce Implementatie RGS. Maar volgens ons hebben beide organisaties RGS zelf ook niet in gebruik. Dat laatste is opmerkelijk te noemen omdat juist deze organisaties een voorbeeldfunctie hebben in het gebruik van RGS volgens ons. NOAB laat ons desgevraagd weten wel zelf met de voorbereidingen bezig te zijn om RGS op het secretariaat in te voeren. Op de officiële website van RGS staan weliswaar enkele interviews, sommigen ons inziens wat commercieel van aard, maar zonder het tonen van concrete praktijkvoorbeelden of instructies die potentiële gebruikers bij de hand nemen om RGS stap voor stap in te voeren. Beschikbaar stellen van praktijkvoorbeelden op basis waarvan de werking van RGS concreet aangetoond wordt op alle mogelijke fronten is volgens ons een must.

  • 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. Ons advies is het aantal RGS-codes op een dermate niveau stellen dat dit voor de markt goed werkbaar is in de praktijk. Let daarbij op rekeningcodes voor de eenmanszaak, vennootschap onder firma (VOF), BV, stichting en vereniging. 

  • 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. 
      
  • 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. XML is de moedertaal van SBR maar, ondanks het feit dat RGS al sinds 2015 onderdeel is geworden van SBR, heeft RGS als basis nog steeds een Excel sheet die ons inziens niet meer van deze tijd is. Ons advies is ook om vanuit de RGS-beheerorganisatie RGS-schema’s per soort organisatie en/of branche beschikbaar te stellen via een of meerdere api's.

Onze belangrijkste aanbeveling is op korte termijn een uitgebreide onafhankelijke herijking van de oorspronkelijke doelstelling van RGS en van de staande (beheer)organisatie rondom RGS uit te voeren. Onafhankelijk van de direct betrokkenen bij de huidige SBR- en RGS organisatie. Dit laatste om zo objectief mogelijk een beeld te kunnen vormen zonder het risico van belangenverstrengeling. En een tweede aanbeveling is om theorie en praktijk dichter bij elkaar te brengen. Dit laatste onder meer door RGS ontwikkelingen eerst te toetsen met echte praktijkvoorbeelden door zowel softwareleveranciers als gebruikers en pas definitief te maken als de uitkomst van de toets positief is.

We willen wel benadrukken dat bovenstaande onze conclusie en aanbeveling is. U kunt er natuurlijk heel anders over denken.

Complete RGS onderzoek en resultaten
Het complete RGS onderzoek en de resultaten daarvan (inclusief de nodige toelichtingen door softwareleveranciers en gebruikers) is opgenomen in het rapport "RGS: Uniform rekeningschema voor alle bedrijven". In de hoofdstukken 6.1 "De impact op softwaresystemen > Visie" en 7 "RGS in de praktijk".
Het rapport is gratis beschikbaar.
Meer informatie en opvragen rapport...  


Woensdag 19 september 2018
Praktijkdag scan, herken, efactureren en robotic 2018  
Hier komt RGS als volgt aan de orde:
Wat is de stand van zaken van RGS zelf? En kan RGS toegevoegde waarde hebben voor UBL?
Na een korte introductie door Gerard Bottemanne over RGS en de relatie tussen UBL en RGS wordt u uitgenodigd uw visie over de relatie tussen UBL en RGS met aanwezige leveranciers en deelnemers te delen.
Meer over deze praktijkdag en aanmelden...
 

Categorie(n) RGS (ReferentieGrootboekSchema), Branche > Financials, SBR / XBRL, Branche > Accountantskantoren, Standaardisatie, (open)standaarden
Bronvermelding Onderzoeksbureau GBNED
Internet URL http://www.gbned.nl

Automatisch op de hoogte blijven?
Schrijf u in voor onze gratis periodieke nieuwsbrief.

Terug

Gerelateerde berichten

Presentaties beschikbaar van praktijkdag: scan, herken, elektronische factuurverwerking en robotic accounting 2018 [20-09-2018]

Scannen en herkennen van boekingsdocumenten en elektronische factuurverwerking op basis van robotic accounting [18-09-2018]

Robotic accounting: welke boekhoudpakketten ondersteunen dat echt? [17-07-2018]

Presentaties kennisevent administratieve software: Privacy, Instant payments, UBL EN16931, PEPPOL, Blockchain, RGS en PSD2 [30-06-2018]

Gids boekhoudsoftware 2018: met nulmeting blockchain en boekhoudsoftware [27-06-2018]


Woensdag 31 oktober 2018
ICT Accountancy jaarcongres

Met als centraal thema "Real-time accountancy" en op het programma onder meer: Instant Payments, beoordelen veiligheid (web)applicaties, Data driven mindset, 3.0 Boekhouding, API-ontwikkeling en administratieve software, de ICT Accountancy softwaregids 2019 en de ICT Accountancy award in het teken van robotic accounting binnen boekhoudsoftware.
Meer informatie en aanmelden...


CreAim

Informer software


KING


Timewriter


Onerzoeksbureau GBNED