2023 het jaar van RGS als…..

1. RGS meer prioriteit krijgt
2. We het een stuk simpeler gaan maken
3. Fouten oplossen en zorgen voor een goede basis
4. De XML Auditfile op orde brengen
5. Leveranciers in staat zijn aanpassingen snel en gemakkelijk door te voeren
   
   In deze blog ga ik in op de status van RGS op dit moment. In de afgelopen periode ben ik samen met Gerard Bottemanne vanuit ons STIPAC initiatief aan de slag gegaan met RGS. Destijds ben ik betrokken geweest bij de start van RGS. Nu ik me er verder in heb verdiept ben ik op de hoogte van de ins en outs. Zoals eerder gemeld door STIPAC is de status op dit moment uiterst teleurstellend.

Ik heb een aantal instanties gesproken die betrokken zijn bij het beleid rondom RGS en een grote rol spelen, ook op bestuurlijk vlak bij SBR. Onze zorgen hebben we meerdere keren gedeeld. Ik kan een klaagzang gaan houden over wat er allemaal wel niet mankeert aan RGS. En dat het op deze manier nooit een succes gaat worden, maar ik heb gekozen voor een positieve insteek. Een nadrukkelijk voorstel met 5 randvoorwaarden waaraan moet worden voldaan willen we RGS succesvol kunnen gaan gebruiken. Ik zal ze punt voor punt toelichten:

Toelichting

1. Als we RGS een goed idee vinden dan moeten we dit ook serieus nemen. Qua governance valt RGS onder SBR. Dit lijkt op het eerste gezicht logisch, maar zoals het nu gaat doet geen recht aan RGS. Het is geen terugkerend agendapunt op de SBR Beraad meetings. Er is een RGS beheer- en expertgroep met een beperkt groepje deelnemers waarin niet alle implementatie- en kennisonderdelen zijn geborgd. Er is onlangs een kwartiermaker aangesteld die al jaren bij RGS betrokken is, maar niet de onafhankelijke persoon die RGS uit het slop gaat trekken. Een duidelijke governance en plan van aanpak zou ons meer helpen.

Gericht op het MKB is er inmiddels het initiatief RGS MKB dat zich zoals de naam al zegt op de oorspronkelijke doelgroep van RGS, het MKB segment. Waarover later nog meer.

• RGS is ruim 10 jaar geleden gestart (in 2012) als een referentieschema voor het grootboek, opgesteld in Excel. Dit werkt prima. Indertijd is ook een koppelschema opgesteld voor de relatie tussen RGS en (externe) rapportages. Dit laatste is echter niet verder uitgewerkt in Excel, maar onder druk van het SBR programma en de RGS beheergroep in XBRL. Er wordt gesproken over de RGS Taxonomie. Heel complex en ingewikkeld. Juist de leveranciers die RGS willen implementeren (boekhoudpakketten) beschikken niet over de kennis om dit te kunnen (en te willen). Zij zijn 15 jaar geleden al afgehaakt bij SBR omdat ze niet in staat waren de Nederlandse Taxonomie (NT) te implementeren voor SBR Jaarrekeningen. Dat laatste was mede de aanleiding om RGS te ontwikkelen als laagdrempelig alternatief. De NT is nu overigens vele malen complexer dan indertijd, maar dat terzijde.
  
  Mij is volkomen onduidelijk wat de business case en reden is voor een complexe RGS taxonomie in XBRL. Geen eindgebruiker en leverancier van boekhoudsoftware heeft daar om gevraagd. Daar komt nog bij dat er op geen enkele wijze een formele beoordeling is van de RGS taxonomie. Geen gebruiker c.q. accountant kan deze lezen en dus beoordelen of er fouten in zitten. En hoewel de NBA nadrukkelijk betrokken is bij zowel het SBR- als het RGS programma willen zij ook geen beoordeling geven over de betrouwbaarheid van de RGS taxonomie.RGS kent nu een koppeling naar SBR rapportages, met name de SBR jaarrekening (in meerdere varianten) en de winstaangifte voor de IB en VPB.

  RGS kent ook een koppeling naar de Productie jaarstatistiek van het CBS die niet (meer) in SBR is opgenomen. En de Belastingdienst kent haar programma Automatische Winstaangifte (AWA) voor zelfstandigen met weer een eigen koppeling naar RGS die ook niet in SBR is opgenomen. Mijn verzoek is te komen tot een uniform koppelvlak voor RGS en uitvragende rapportages. Daarbij terug te gaan naar Excel of een gelijkwaardig niveau, zoals bijvoorbeeld JSON. Simpel en duidelijk in elk geval.Vanuit het eerdergenoemde initiatief RGS MKB en STIPAC is medio 2022 voorgesteld te komen tot een uniforme koppelvlakspecificatie (er is zelfs al een opzet aanwezig) om RGS eenduidig te koppelen aan:
  SBR rapportages,
  de productie jaarstatistiek,
  de AWA en
  straks wellicht de kredietrapportages voor banken.

“Als antwoord op je vraag of iemand vanuit de RGS overlegorganen misschien wil aanhaken moeten we afwijzend reageren”, aldus de projectleider RGS die vanuit het CBS is toegewezen. Ik stel voor op het niveau van het SBR beraad deze negatieve houding om te buigen is een positieve houding en het voorstel vanuit RGS MKB en STIPAC breed te ondersteunen.  

2. RGS bevat nog een behoorlijk aantal fouten. Zaken die ontbreken of verkeerd zijn opgenomen. Hier hebben we al meerdere keren melding van gemaakt maar zonder succes. Er wordt gewerkt met een aantal filters, maar hierin zitten ook fouten. De gedachte achter RGS is juist om het aantal velden beperkt te houden en ervoor te zorgen dat iedereen dezelfde posten gebruikt voor hetzelfde. Er is nu niemand die inhoudelijke kennis heeft om ALLE issues te beoordelen. Hier komt bij dat niet één RGS code standaard is voorzien van documentatie met onder andere boekingsvoorbeelden. Dit moet gebeuren door boekhouders in plaats van techneuten. De gebruikers moeten zich immers herkennen in hetgeen aanwezig is in RGS.

Vanuit RGS MKB is uitgebreide documentatie opgezet rondom RGS codes en boekingsvoorbeelden. Met medewerking van NOAB is gewerkt aan een inventarisatie van ontbrekende codes c.q. rekeningen om RGS op niveau 4 volwaardig te kunnen gebruiken. Op dit moment is de inventarisatie gereed en voor iedereen beschikbaar om te beoordelen. Ook de projectleider RGS vanuit het CBS is geïnformeerd. Dat betekent dat we voor in elk geval het MKB met 2.500 RGS codes (niveau 5) minder te maken hebben. Ik stel voor dat de beleidmakers deze aanpak gaan ondersteunen.

Zo kunnen we deze maand (januari 2023) komen met een volgende versie van RGS (3.5) die volledig afgestemd is op het MKB en niveau 5 van RGS overbodig maakt. Voor RGS MKB gaan we dan terug van 4.638 RGS codes naar nog geen 1.000 RGS codes. Zo’n 20% van het huidige RGS. Hoe gaaf is dat.

3. Alweer wat jaren terug is de laatste XML Auditfile gepubliceerd vanuit de Belastingdienst. Een initiatief welke bijna aanwezig is in elk boekhoudpakket. Superhandig ook om imports en exports te kunnen doen. RGS is geïntegreerd in de Auditfile, maar van deze laatste blijken vanuit de Belastingdienst een 2-tal versies in omloop (beide onder de noemer XAF 3.2). Al meerdere jaren heeft de Belasting beloofd dit recht te trekken en gelijk de XAF naar een hoger niveau te tillen.

Ik stel voor dat de Belastingdienst de daad bij het woord voegt. Vanuit STIPAC zijn we graag bereid mee te denken.

4. Leveranciers doen echt hun best om RGS te implementeren in hun software. De belangrijkste leveranciers ondersteunen RGS, maar niet op een manier zoals je zou willen. Veel leveranciers ondersteunen alleen een oude RGS versie, zoals RGS 3.2 uit 2019 en zonder filter op de 800 specifieke RGS codes voor Woningcorporaties. Naast de complexiteit zit er ook een issue in versiebeheer. Bij een nieuwe RGS versie moeten sommige leveranciers opnieuw beginnen. Doordat RGS als gratis feature wordt beschouwd is hiervoor geen business case voor de leveranciers. SBR is verplicht gesteld waardoor leveranciers geen andere keus hadden. Bij RGS gaat dit niet gebeuren. Voor leveranciers is ‘eenvoud’ het middel. Als leveranciers in staat zijn aanpassingen snel en gemakkelijk door te voeren zullen ze daar eerder gehoor aan geven en kan de markt dat ook beter afdwingen.

RGS MKB

Vanuit RGS MKB is inmiddels een subset samengesteld om RGS weer toegankelijk te maken op MKB niveau. Dat doen we door:
A. Een selectie te maken uit de RGS codes, afgestemd op de beoogde doelgroep.
B. Het RGS-schema ondersteunen t/m niveau 4 (grootboekrekeningen) en niveau 5
(mutaties) achterwege laten.
C. Het opnemen van documentatie bij ALLE gebruikte RGS-codes binnen RGS MKB.
D. Het RGS-schema onderverdelen in een decimaal rekeningschema van 5 cijfers.
E. Waar nodig ontbrekende RGS-codes opnemen in het schema.
F. De relatie tussen RGS en (externe) rapportages leesbaar maken voor gebruikers en
softwareleveranciers.

De stappen A t/m D zijn nagenoeg gereed. Stap E is onderhanden en stap F stap op de planning. De actieve houding vanuit NOAB aangaande RGS MKB zie ik ook graag vanuit andere accountantskoepels.

Beleidsmakers zijn aan zet

Ik ben groot voorstander van SBR en de Nederlandse Taxonomie. Een taxonomie zoals nu is echter ‘to much’ voor RGS. ‘Keep it simple’ is het toverwoord. Als we met bovenstaande punten aan de slag gaan en hier prioriteit aangeven dan heb ik nog vertrouwen in de toekomst van RGS. We trekken nu aan een dood paard. Ik hoop dat de beleidmakers hun ogen eens openen en niet blindstaren op hetgeen nu wordt verteld door intern betrokkenen.

Ik nodig de beleidmakers dan ook uit om contact met mij op te nemen.