Softwarepakketten.nl

Onderzoek

RGS Niet Ready: openstaande punten

Plaatsingsdatum 22-11-2019
Berichtdatum 22 november 2019

Bijgewerkt 4 april 2020

RGS Ready geeft aan in hoeverre softwarepakketten (met boekhoudpakketten als uitgangspunt) voldoen aan RGS op basis van een aantal normen. "RGS Niet Ready: openstaande punten" geeft inzicht in de openstaande punten rondom de implementatie van het Referentie grootboekschema die voor een belangrijk deel van belang zijn voor de gebruikers van RGS.

Zie ook de blog "ReferentieGrootboekSchema (RGS): voorstel om problemen op te lossen en RGS weer beheersbaar te maken en te houden" (29-2-2020).

De ons bekende openstaande punten (die we door eigen analyse en mede uit de markt vernomen hebben) zijn de volgende:

Gebruik omslagcode

(Oktober 2019)
Afstemmen hoe de omslagcode is bedoeld t.o.v. niveau 4 (rekening) c.q. 5 (mutatie) in RGS.

De RGS-code BLimBanRba “Rekening-courant bank” (op niveau 4 – grootboekrekening) kent GEEN omslagcode.
Wel de onderliggende RGS-codes BLimBanRbaBg1 t/m BLimBanRbaBg5 “Tegoeden op Bankgirorekeningen Rekening-courant bank groep 1 t/m groep 5” (op niveau 5 – mutatieniveau).
De omslagcodes verwijzen in dit geval naar BSchSakRbaBg1 t/m BSchSakRbaBg5 “Schulden aan banken Rekening-courant bank groep 1 t/m groep 5” (op niveau 5 – mutatieniveau).

Dit zou betekenen dat je altijd verplicht bent niveau 5 te gebruiken, ook al werk je maar met één bankrekening. Want op niveau 4 is geen omslagcode aanwezig in de huidige situatie van RGS.

Is bovenstaande werkbaar of is het logischer om de code BLimBanRba “Rekening-courant bank” (op niveau 4 – grootboekrekening) onder te verdelen naar bijvoorbeeld 5 mogelijke bankrekeningen? De huidige code BLimBanRba kan dan blijven (waardoor huidig RGS op niveau 4 volledig intact blijft) en bijvoorbeeld onderverdeeld worden naar BLimBanRb2 t/m BLimBanRb5. Met idem de omslagcodes op het zelfde niveau 4. Niveau 5 is dan niet nodig voor de bank.

Antwoord op deze vraag is mede afhankelijk van wat nu precies het doel en logisch gebruik is van niveau 5 van RGS.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Om juist opgebouwde cijfers aan andere applicaties of rapportages aan te bieden zullen bepaalde posten beoordeeld moeten worden op “omslag”. Dit houdt in dat als de telling van een RGS code positief is, code “x” gebruikt dient te worden, indien de telling negatief is code “y”. Een voorbeeld is “Liquide middelen – Bank”
In RGS3.0 hebben we dit vakinhoudelijk standpunt verder doorgevoerd.
Hierdoor is het ook mogelijk om het saldo van verschillende banken, welke niet gesaldeerd mogen worden (ING – ABN – Rabo etc.), juist te laten bepalen. Dit geldt o.a. ook voor vorderingen - schulden (groeps)maatschappijen, belastingvorderingen – schulden per aard (BTW – LH – VpB). De omslagcodes zijn in zaken deze onderdelen gecomplementeerd.

Theoretisch zou het mogelijk zijn om de omslag met meerdere codes dus te regelen op niveau 4, met dien verstande dat er dan geen totaal rekeningen-courant zichtbaar zal zijn. De keuze hierover ligt bij de gebruiker.
BLimBanRba – Rekening-courant bank 1 is dan b.v. ABN AMRO
BLimBanRbb – Rekening-courant bank 2 is dan b.v. ING
BLimBanRbc – Rekening-courant bank 3 is dan b.v. Rabobank
BLimBanRbd – Rekening-courant bank 4 is dan b.v. XX
BLimBanRbe – Rekening-courant bank 5 is dan b.v. YY.
   

Branche- of sectorspecifieke RGS uitbreidingen

(Juni 2019)
RGS is een enorm uitgebreid schema waarvan de omvang sinds 2017 erg hard is gegroeid:
- Versie 1.1 met > 2.300 RGS-codes; begin 2015.
- Versie 2.0 met > 2.500 RGS-codes; voorjaar 2016.
- Versie 3.0 met > 3.000 RGS-codes; eind 2017.
- Versie 3.1 met > 3.700 RGS-codes; eind 2018.
- Versie 3.2 met > 3.800 RGS-codes; eind 2019.

In de praktijk blijkt er soms behoefte aan branche- of sectorspecifieke uitbreidingen. Een voorbeeld hiervan is de Woningcorporatiesector waarvoor RGS is uitgebreid met een aantal mutaties, rekeningen en zelfs rekeninggroepen. Bij elkaar meer dan 500 RGS-codes (bij alleen al de overgang van RGS 3.0 naar 3.1). Het is natuurlijk de vraag of dit het RGS wel ten goede komt. De vraag is dan ook welke richtlijnen er zijn als behoefte is aan uitbreiding van RGS met branche- of sectorspecifieke rekeningen? Zijn hier normen voor of kunnen RGS extensies hier van betekenis zijn? Vindt er een bewaking plaats op de uitbreiding van standaard RGS en hoe wordt er voor gezorgd dat er geen ondoorzichtige brei aan rekeningen gaat ontstaan waar niemand meer wijs uit kan? Is de huidige gekozen filtermethode afdoende voor de toekomst als er zich meer branche- of sectorspecifieke uitbreidingen aandienen? Kortom: welke afspraken gelden hiervoor en wie bewaakt dit. Stel je hierbij de vraag of het uberhaupt wel verstandig is branche- of sectorspecifieke uitbreidingen op te nemen in RGS. Ligt een oplossing buiten RGS dan niet meer voor de hand?

Verondersteld wordt dat een standaard rekeningschema voor productie-, handels-, dienstverlenende- en projectmatig werkende bedrijven standaard in RGS aanwezig is. Evenals de mogelijkheid tot het voeren van een administratie volgens het factuur- of kasstelsel.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep

  1. De vraag is dan ook welke richtlijnen er zijn als behoefte is aan uitbreiding van RGS met branche- of sectorspecifieke rekeningen?Omdat RGS in eerste instantie bedoeld is als generiek schema zal het daarom te kort schieten voor gebruikers die afwijkende wensen hebben. Daarvoor zijn extensies in het leven geroepen. In sommige gevallen is het toch wenselijk specifieke uitbreidingen toe te voegen, om zo aan de wensen van een branche te kunnen voldoen en zo de implementatie van RGS te stimuleren. Om een wildgroei aan RGS codes te voorkomen wordt dit wel met beleid gedaan.

    Als een branche aangeeft dat zij behoefte hebben aan een uitbreiding op RGS doet de Beheergroep eerst een intake. Daarbij wordt gekeken naar het belang van een succesvolle implementatie en het draagvlak binnen de branche voor een branche-specifieke RGS.

    Voor wat de branche coderingen (nu alleen nog de WoCo’s) betreft, laten wij de betreffende branche in ‘the lead’. Er worden wel afspraken gemaakt over de planning en dat alleen branche specifieke coderingen mogen worden opgesteld. Daarnaast verwachten wij dat de branche zelf een mechanisme bedenkt voor de toetsing van de coderingen. Bij de WoCo’s is dit ook het geval. Onder toezicht van Aedes hebben de WoCo’s een eigen beheergroep en stuurgroep voor RGS opgericht. Eén lid van de stuurgroep is bij de bijeenkomsten van de Beheergroep RGS aanwezig. Hiermee is de verbinding tussen beide gremia gerealiseerd.

    Overigens wordt deze werkwijze toegepast sinds 2018. In eerdere versies van RGS zijn uitbreidingen toegevoegd voor bijvoorbeeld de agro- en bouwsectoren. Voor deze uitbreidingen zijn minder ‘strenge’ eisen gesteld dan de huidige werkwijze.
     
  2. Zijn hier normen voor of kunnen RGS extensies hier van betekenis zijn?
    Een branche zou ook gebruik kunnen maken van extensies (na de punt), hoewel dit niet altijd mogelijk is (zie ook hieronder).
      
  3. Vindt er een bewaking plaats op de uitbreiding van standaard RGS en hoe wordt er voor gezorgd dat er geen ondoorzichtige brei aan rekeningen gaat ontstaan waar niemand meer wijs uit kan?
    Zie antwoord op de eerste vraag. Er is een intake, afspraken worden gemaakt tussen de brancheorganisatie en de RGS Beheergroep.
      
  4. Is de huidige gekozen filtermethode afdoende voor de toekomst als er zich meer branche- of sectorspecifieke uitbreidingen aandienen?
    In principe wel, als de filter goed wordt toegepast. Er is incidenteel afgeweken van de filtermethode op verzoek van de markt (zie verder). Door sommige gebruikers wordt dit als negatief ervaren.
      
  5. Stel je hierbij de vraag of het überhaupt wel verstandig is branche- of sectorspecifieke uitbreidingen op te nemen in RGS. Ligt een oplossing buiten RGS dan niet meer voor de hand?
    Belangrijke criteria zijn dat de branche uitbreiding de implementatie van RGS moet bevorderen en dat het gebruik van eigen extensies niet mogelijk is. Als veel branches de Beheergroep gaan benaderen met wensen voor uitbreiding dan moet wel gekeken worden hoe dit beheersbaar te houden. Tot nu toe zijn alleen de woningcorporaties toegevoegd en er lopen geen gesprekken met andere branches. Mocht dat veranderen is het wel aannemelijk om te onderzoeken hoe hiermee om te gaan.

Woningcorporaties (Woco) in standaard RGS-schema

(januari 2020)
Voor Woningcorporaties, verder te noemen Woco, zijn honderden RGS-codes toegevoegd sinds RGS versie 3.1 Hierbij is geen gebruik gemaakt van een extensie, zodat de RGS-codes voor Woco deel uitmaken van het standaard RGS-schema. In de Excel versie van het RGS-schema is een filter voor Woco opgenomen, maar die filter laat alle RGS-codes zien die voor de Woco sector gelden, inclusief de standaard RGS-codes die daar gebruikt worden. Zo komen we voor Woco rekeningen tegen als:
- Kostprijs Niet-Daeb- vastgoed in exploitatie;
- Cumulatieve afschrijvingen en waardeverminderingen Niet-Daeb-vastgoed in exploitatie;
- Schuld aan DAEB. 
Maar ook standaard RGS-codes niet specifiek voor Woco, zoals:
- Voorraad grond- en hulpstoffen, bruto;
- Handelsdebiteuren nominaal;
- Terug te vorderen Loonheffing.

Voor de RGS-codes die specifiek branchegericht zijn voor Woco is op dit moment geen filter aanwezig. In de RGS-taxonomie is uberhaupt geen filtermogelijkheid opgenomen voor dit soort situaties. Het is volgens ons dus niet mogelijk een standaard RGS-schema op te vragen zonder de branchespecifieke RGS-codes voor Woco. 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
De werkwijze van de filter is voor de WoCo’s anders dan bij de overige filters. Dit is op verzoek van de markt op deze wijze geïmplementeerd. In de voorbereidingen voor de volgende versie van RGS (RGS 3.3) zullen we de markt hierover consulteren, met de vraag of dit een storende factor is, en of het nodig/wenselijk is om de filter anders in te richten (of een andere oplossing om de WoCo-specifieke codes te identificeren). 
  

Bouwsector in standaard RGS-schema

(januari 2020)
Het RGS-schema bevat specifiek voor de bouwsector 39 RGS-codes op niveau 5 (mutaties). Dit zijn RGS-codes als:
- Grond- en hulpstoffen geactiveerde kosten onderhanden projecten onderhanden projecten in opdracht van derden;
- Arbeidskosten geactiveerde kosten onderhanden projecten onderhanden projecten in opdracht van derden;
- Afschrijving installaties en uitrusting geactiveerde kosten onderhanden projecten onderhanden projecten in opdracht van derden.
De bovenliggende RGS-codes op niveau 4 (rekeningen) zijn echter NIET specifiek toegewezen aan de bouwsector. Dit betreft bijvoorbeeld de RGS-code "Onderhanden projecten in opdracht van derden, geactiveerde kosten voor nog niet geleverde diensten".

De vraag is nu of er een toelichting kan komen waarom de rekeningen op niveau 4 niet bouwspecifiek zijn en op niveau 5 wel? Zo mogelijk met voorbeelden. 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Niveau 5 is een nadere uitsplitsing (detaillering) van niveau 4. Voor wat betreft Onderhanden projecten zijn op niveau 4 algemene in gebruik zijnde beschrijvingen opgenomen, zoals deze ook in de taxonomie (labels) aanwezig zijn. Onderhanden projecten geldt overigens niet alleen voor Bouwondernemingen. 

Vraagposten

(juni 2019)
Accountants- en administratiekantoren werken met de rekening "vraagposten" als klanten zelf boeken en ze kunnen een bepaalde boeking zelf niet kwijt. De grootboekrekening vraagposten biedt dan uitkomst. Nu kent RGS vele tussenrekeningen. De vraag is echter welke (tussen)rekening bestemd is voor vraagposten. De afspraak over dit rekeningnummer is ook van belang voor het op 'nul' lopen van deze rekening als bijvoorbeeld cijfers aan een rapportage worden aangeboden in RGS. 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Nul lopen van posten in vraagposten (BVorTusTovTvp) is altijd van belang. Als men onder deze posten een saldo laat bestaan zullen deze altijd in het rapport onder de “Overlopende activa – passiva” worden opgenomen. Waarom dan wel de reden van bestaan van een saldo is niet aan ons ter beoordeling. De verantwoordelijkheid hierover ligt bij de gebruiker en in basis al in het bronsysteem. De tussenrekeningen – vraagposten zijn al gecategoriseerd (11 groepen) op verzoek van de markt.

RGS in de Auditfile FInancieel (XAF)

(juli 2019)
De RGS code kan meegegeven worden in de XML Auditfle Financieel op het niveau van grootboekrekeningen. In de praktijk wordt dit door softwareleveranciers op 2 verschillende manieren geïmplementeerd. Er moet duidelijkheid komen over de bedoelde implementatiewijze inclusief daarbij behorende documentatie (met een voorbeeld). Aandachtspunten zijn:
- Duidelijkheid over de RGS versie in betreffende auditfile;
- Hoe om te gaan met RGS code op niveau 5 (mutatieniveau); bij betreffende mutaties?
- Hoe om te gaan met eventuele extensies? 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Dit punt is onder behandeling bij het Auditfile platform.

Het doel en gebruik van RGS niveau 5

(2018)
RGS niveau 4 staat voor "rekeningen" en RGS niveau 5 staat voor "mutaties". 
Het gebruik van niveau 5 is echter niet eenduidig toegepast. Zo wordt niveau 5 gebruikt bij verbijzonderling van de volgende rekeningen op niveau 4:

  1. De rekening "Cumulatieve afschrijvingen machines en installaties", verbijzonderd naar niveau 5 :
    - Beginbalans (overname eindsaldo vorig jaar)
    - Afschrijvingen
    - Afschrijving op desinvesteringen
    - Bijzondere waardeverminderingen
    - Terugneming van bijzondere waardeverminderingen.
      
  2. De rekening "Vorderingen uit hoofde van leningen en voorschotten houders van aandelen op naam (langlopend)", verbijzonderd naar niveau 5:
    - Vorderingen op aandeelhouder 1
    - Vorderingen op aandeelhouder 2
    - Vorderingen op aandeelhouder 3
    - Vorderingen op aandeelhouder 4
    - Vorderingen op aandeelhouder 5
       
  3. De rekening "Overige financiële vaste activa(langlopend)", verbijzonderd naar niveau 5:
    - Overige vordering 1 (langlopend)
    - Overige vordering 2 (langlopend)
    - Overige vordering 3 (langlopend)
       
  4. In tegenstelling tot 2 en 3 is de "Vorderingen op groepsmaatschappijen (kortlopend)" op niveau 3, verbijzonderd naar niveau 4:
    - Rekening-courant groepsmaatschappij 1
    - Rekening-courant groepsmaatschappij 2
    - Rekening-courant groepsmaatschappij 3
    - Rekening-courant groepsmaatschappij 4
    - Rekening-courant groepsmaatschappij 5
    En op niveau 5 is elk van deze rekeningen dan weer verbijzonderd naar:
    - Rekening courant
    - Cumulatieve waardeverminderingen
    - Doorbelastingen
    - Te vorderen dividend
    - Waardeveranderingen
    - Overige mutaties
       
  5. De groep "Onderhanden werk" op niveau 3 is onderverdeeld naar de rekeningen "Onderhanden werk, bruto", "Gefactureerde termijnen onderhanden werk" en "Voorziening verliezen onderhanden werk" op niveau 4.
    Maar....
    De groep "Onderhanden projecten in opdracht van derden" op niveau 3 kent ook de rekening "Gefactureerde termijnen" op niveau 4 (tot zover conform hiervoor). Maar deze laatste rekening "Gefactureerde termijnen" op niveau 4 is (in tgenstelling tot de rekening onderhanden werk) dan weer verbijzonderd (op niveau 5) naar:
    - Beginbalans gefactureerde termijnen onderhanden projecten
    - Belast met algemeen tarief gefactureerde termijnen onderhanden projecten
    - Belast met verlaagd tarief gefactureerde termijnen onderhanden projecten
    - Belast met overige tarieven gefactureerde termijnen onderhanden projecten
    - Belast met nultarief of niet belast gefactureerde termijnen onderhanden projecten
    - Niet belast wegens heffing verlegd gefactureerde termijnen onderhanden projecten
    - Installatie in landen binnen EU gefactureerde termijnen onderhanden projecten
    - Installatie in landen buiten EU gefactureerde termijnen onderhanden projecten
    - Interne doorbelastingen binnen fiscale eenheid gefactureerde termijnen onderhanden projecten
    - Opgeleverde werken gefactureerde termijnen onderhanden projecten
    - Overige mutaties gefactureerde termijnen onderhanden projecten.
       
  6. "Provisies" op niveau 4 is verbijzonderd op niveau 5 naar:
    - Provisies op verkopen handel
    - Provisies op verkopen productie
    - Provisies op verkopen dienstverlening
    - Overige provisies.

En zo zijn er zeker tientallen voorbeelden van het gebruik van niveau 5. Het is niet zonder meer duidelijk wat de reden is om te kiezen voor een rekening op niveau 4 of een rekening en verbijzondering daarvan op niveau 5.

Een toelichting of voorbeelden (zo mogelijk in de vorm van journaalposten) van het gebruik ontbreekt.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Niveau 5 is in overeenstemming met de beschrijving om mutaties aan te geven. Dit is met name van toepassing bij de verloopoverzichten – Mutaties in het boekjaar. Hiermee wordt dekking gegeven/verzorgd naar de opgenomen verloopoverzichten in de SBR rapportages van de uitvragende partijen, zijnde:
- Immateriële vaste activa, - materiële vaste activa, - vastgoedbeleggingen,
- Financiële vaste activa, - eigen vermogen, - voorzieningen, - langlopende schulden
Dit is dan al een totaal van 1.502 RGS codes

Bij een aantal onderdelen is dit ook opgenomen, zonder dat momenteel SBR dat uitvraagt, maar vaak in rapportagetools wel aanwezig is.
- Vorderingen/Schulden rekeningen-courant groepsmij / ov deeln / etc (162 RGS codes)
- Kortlopende effecten (53 RGS codes)

Ook wordt niveau 5 gebruikt om een omslagcode op het diepste niveau weer te geven. Dit is vaak een uitbreiding na RGS 2.0 op de dan al bestaande structuur om dit ook te realiseren. (Betreft ongeveer 144 RGS codes).

Daarnaast wordt niveau 5 gebruikt voor verdere uitgebreidere verbijzonderingen/detaillering
welke men optioneel kan gebruiken. Hierbij valt te denken aan;
- Onderhanden projecten 39 RGS codes
- Werkkostenregeling 119 RGS codes
- Tussenrekening/vraagposten 82 RGS codes
- Belastingen (Balans) 35 RGS codes
- Uitbreiding op verzoek als detaillering op niveau 4 61 RGS codes
- Uitbreiding t.b.v. Woningcorporaties 202 RGS codes

Opbouw van niveau 5 RGS codes:
- Dekking verloopoverzichten SBR rapportages: 1.502.
- Dekking verloopoverzichten externe rapportages: 215.
- Dekking voor omslag: 144.
- Dekking voor verbijzondering/detaillering: 240.
- Uitbreiding t.b.v. woningcorporaties: 202.
- Uitbreiding nadere detaillering niveau 4 op  verzoek: 29.
Totaal: 2.332.

Keuze voor alleen RGS niveau 4

(november 2019)
Meerdere leveranciers van boekhoudsoftware hebben bewust gekozen om alleen niveau 4 (rekeningniveau) van RGS, zijnde "rekeningen", te gebruiken. In de praktijk blijkt dit prima te werken. Er moet alleen duidelijkheid komen welke rekeningen eventueel ontbreken en bijvoorbeeld op dit moment alleen aanwezig zijn als "mutatie" (niveau 5) en dus niet als "rekening" (niveau 4). Een expliciet voorbeeld van dit laatste komt hierna bij "De BTW boeken op RGS niveau 4" aan de orde. Ook is de vraag of in de koppeling tussen RGS en SBR niveau 5 van RGS vereist of gewenst is en zo ja, waarvoor precies. 

Het alleen kunnen werken met niveau 4 kan wellicht helpen bij de verdere adotie van RGS. Inclusies niveau 5 (mutaties) is sprake van een schema van inmiddels ruim 3.800 codes. Dat laatste is niet echt een makkelijke basis voor zowel leveranciers van boekhoudsoftware als gebruikers. Zonder niveau 5 is sprake van een schema van zo'n 1.200 codes. Nog steeds erg omvangrijk, maar met enkele filters alweer beter toepasbaar. 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
De softwareleverancier is, afhankelijk van de behoefte, vrij om te kiezen hoe niveau 4 en niveau 5 worden toegepast. In de praktijk is het inderdaad zo dat meerdere leveranciers gekozen hebben om alleen niveau 4 te gebruiken. Waar RGS wordt toegepast voor de SBR-KvK rapportages voor Micro en Klein (die nagenoeg geen diepgang hebben d.m.v. verloopoverzichten) is dat ook te begrijpen. Dit zal overigens anders zijn voor de andere rapportages zoals middelgroot. De wens en noodzaak voor andere applicaties (zoals dashboard en analyse tooling) is afhankelijk van de diepgang gewenst door de gebruiker. 
  

De BTW boeken op RGS niveau 4

(juni 2019)
Het is nu niet mogelijk de af te dragen, te verrekenen en afgedragen BTW te boeken op niveau 4. De rekening "afgedragen BTW" ontbreekt op niveau 4. 

Opvallende zaken m.b.t. BTW en RGS zijn ook:

  • De omzet is verregaand verbijzonderd naar soort en hoogte omzetbelasting op niveau 4 en BTW rekeningen zelf niet. Deze laatste zijn verbijzonderd op niveau 5. Waarom wordt niveau 4 en 5 in deze verschillend toegepast.

  • Waarom kent "af te dragen BTW" in RGS een beginbalans op niveau 5 en kent "te vorderen BTW" in RGS geen beginbalans op niveau 5?

  • "Te betalen Omzetbelasting" (BSchBepBtw) kent als Referentie omslagcode "Terug te vorderen Omzetbelasting" (BVorVbkTvo). Beide rekeningen kennen echter een volledig andere onderverdeling op niveau 5, waardoor de omslagcode niet logisch meer is als met niveau 5 gewerkt wordt.  

  • Het voorgestelde ZZP-schema door de Belastingdienst (ZekerOnline team) kent de volgende extra RGS-code: BSchBepBtwOlt - Omzetbelasting leveringen/diensten verlaagd tarief 9%.

    Het kan toch niet waar zijn dat bij elke wijziging van een BTW percentage er RGS-codes bij moeten komen? Het percentage is niet af te leiden uit RGS! Ook niet voor standaard percentage, dus waarom wel voor 9%.
      
  • BTW aangifte vindt plaats op basis van de sub administratie BTW en staat daarmee feitelijk los van RGS. Net zoals de ICP opgave los staat van RGS. Niveau 5 voor de BTW aangifte opnemen lijkt alleen logisch als dit voor de ICP opgave ook zou plaatsvinden. Daarnaast is er SBR voor de BTW aangifte en ICP opgave.  

Voorbeeld (grootboek)rekeninngen koppelen aan RGS-codes
Een RGS voorbeeld paper is aanwezig om concreet weer te geven op welke wijze het grootboek aan RGS-codes gekoppeld kunnen worden wat betreft BTW-rekeningen. 
Naar "RGS: voorbeeld paper BTW".

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
In RGS3.2 is voldoende duidelijkheid en dekking gegeven om met RGS een BTW aangifte kunnen laten vullen. Codes (tekstueel) zijn afgestemd met rubrieken in de BTW aangifte.

De logica van niveau 4 en 5 heeft te maken met de rubricering in de desbetreffende onderdelen.
Dat dit in Balans en W&V verschillend is zou niet tot problemen of verwarring moeten leiden bij de gebruiker.

De Beheergroep zal nader beoordelen en bekijken in hoeverre vorderingen en schulden qua methode en codestructuur gelijk getrokken kunnen worden.

Tarief 9%. Is in het verleden opgenomen in RGS (in dat boekjaar was er sprake van zowel 6% als 9%). Dit was een eenmalige situatie. Echter, deze wordt niet verwijderd omdat anders historische gegevens niet ontsloten kunnen worden.

Een ICP aangifte is een per regel (mutatie) opgebouwde aangifte dat geïmporteerd wordt.
Deze heeft geen logische relatie met RGS en is daarom niet opgenomen.
    

ZZP'ers en RGS

(voorjaar 2019)
Hiervoor is al even het voorgestelde ZZP-schema van de Belastingdienst aan de orde geweest in relatie tot de BTW. RGS kent een "ZZP-filter" en een "ZZP Belastingdienstfilter". Allereerst is de vraag wat de status is van beide filters en of deze noodzakelijk zijn. In de praktijk zorgen leveranciers van boekhoudsoftware en administratiekantoren al voor een subset van rekeningen die gebruikt worden door de diverse doelgroepen. Denk aan ZZP, VOF, Stichting, etc. Als er al met een ZZP-filter gewerkt moet worden is de vraag waarom er 2 filters zijn? De Belastingdienst heeft tot heden geen duidelijkheid verschaft over haar "ZZP Belastingdienstfilter" en de status daarvan.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
De ZZP filter van de Belastingdienst betreft de selectie van RGS codes die ondersteund worden c.q. opgenomen zijn in het door de Belastingdienst uitgebrachte ZZP schema en zijn dus bedoeld voor het rapporteren aan de Belastingdienst.

De 2e filter ZZP elimineert RGS codes welke niet gelden voor een ZZP. Dit op basis van een keuze door RGS gremia. Deze is dus uitgebreider van opzet dan de filter van de Belastingdienst en is op verzoek van de markt ontstaan.

Het is te begrijpen dat twee filters gericht op ZZP’ers (maar met verschillende doelstellingen) verwarrend kan zijn. Wij zullen deze toelichting in ieder geval op de RGS website publiceren. Als dit nog steeds verwarrend blijft kan in overleg met de markt hier een andere oplossing voor worden bedacht.
  

25 overbodige omzetrekeningen

(2018)
RGS kent keurig omzetrekeningen verbijzonderd naar
1.   Netto-omzet uit leveringen geproduceerde goederen opbrengsten uit de verkoop van goederen;
2.   Netto-omzet uit verkoop van handelsgoedere.n opbrengsten uit de verkoop van goederen;
3.   Opbrengsten uit het verlenen van diensten;
4.   Toegerekende opbrengsten;
5.   Agrarische bedrijfsopbrengsten veeteelt; (een voorbeeld van branchegerichte rekeningen in het standaard RGS schema).
6.   Overige netto-omzet;
7.   Netto-omzet intercompany transacties;
8.   Kortingen en bonussen en provisies;
9.   Netto resultaat exploitatie van vastgoedportefeuille; (een voorbeeld van branchegerichte rekeningen).
10. Netto resultaat verkocht vastgoed in ontwikkeling; (een voorbeeld van branchegerichte rekeningen).
11. Netto gerealiseerd resultaat verkoop vastgoedportefeuille; (een voorbeeld van branchegerichte rekeningen).
12. Waardeveranderingen vastgoedportefeuille; (een voorbeeld van branchegerichte rekeningen).

En daarbinnen waar van toepassing verbijzonderd naar soort van BTW of anderzijds.

Daarnaast kent RGS, volledig los van genoemde omzetrekeningen ook nog de volgende omzetrekeningen op niveau 4:
- Netto omzet groep 1
- Netto omzet groep 2
- Netto omzet groep 3
- Netto omzet groep 4
- Netto omzet groep 5
En elk van deze omzetrekeningen zijn op niveau 5 ook nog eens uitgesplist naar:
- Netto-omzet groep X product A
- Netto-omzet groep X product B
- Netto-omzet groep X product C
- Netto-omzet groep X product D
- Netto-omzet groep X product E

Dit levert in totaal 25 overbodige RGS-codes op volgens ons.
Het zelf kunnen uitbreiden van omzetrekeningen of uitsplitsen van bestaande omzetrekeningen is op zich een prima utgangspunt, maar dan niet via losse omzetrekeningen die geen andere relatie hebben.

Naast omzetrekeningen zijn er volgens ons analoog hieraan 25 overbodige RGS-codes voor de kostprijs inkoopwaarde groep 1 t/m 5 (op RGS niveau 4), gesplitst naar product A t/m E op RGS niveau 5.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Deze specifieke groepen zijn ontstaan in RGS 3.0. RGS is niet alleen t.b.v. de SBR rapportages, maar ook voor uitwisseling in de keten. Vanuit diverse marktpartijen is het verzoek gekomen om de omzet en inkoopwaarde zo in te kunnen delen dat men de mogelijkheid heeft, b.v. via een Dashboard, om brutomarges per omzetgroep te kunnen presenteren.

Men kan overigens "twee" heren dienen middels boekingen via tussenrekeningen. Dit vraagt wel extra aandacht van de gebruiker. 
 

Het Referentie grootboeknummer

(2018)
Het Referentie grootboeknummer wordt gebruik naast de RGS-code. Over de toegevoegde waarde van het referentienummer in RGS lopen de meningen uiteen. Zie ook de blog "Rekeningnummer Lonen en salarissen 4100 of RGS-code WPerLesLon". Zolang het Referentie grootboeknummer onderdeel is van RGS moet het goed ondersteund worden, hetgeen nu niet het geval blijkt. 

Advies:

  1. Het referentienummer laten bestaan, uniek houden en niet wijzigen in de toekomst;
  2. Onderbouwen waarom het referentienummer niet als sortering gebruikt kan worden (volgens de RGS beheergroep) en aangeven wat er nodig is dat wel te kunnen;
  3. Zorgen voor blijvende logica in het referentienummer en eventueel de logica herstellen waar dat is misgegaan in het verleden.

Of (in plaats van 1,2 en 3), na uitgebreide marktconsultatie, het referentienummer verwijderen uit RGS als de markt dat wil.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Het referentienummer is in RGS opgenomen als voorbeeld en moet niet als een grootboekrekening beschouwd worden.

Het referentienummer is het in het verleden mede opgenomen om voor een sortering zorg te dragen. Dit functioneerde niet of niet voldoende en daarom is de sortering geïntroduceerd. Omdat het referentienummer door sommige softwareleveranciers werd gebruikt hebben wij deze laten bestaan in RGS. Nieuwe RGS codes kregen dus ook nog een referentienummer maar hierbij ontbrak dan zeker de logica.

De beheergroep zal het verwijderen van het referentienummer bespreken omdat (ondanks dat is aangegeven dat het slechts een voorbeeld is) er verwarring is over het gebruik ervan. Dit rekening houdend met het feit dat het door sommige partijen gebruikt wordt.
   

Referentie grootboeknummer positie 7

(november 2019)
Binnen het referentie grootboeknummer is positie 7 bedoeld voor extensies. In andere gevallen behoort deze positie dus niet in gebruik te zijn en derhalve gelijk aan "0".

Er blijken meerdere referentie grootboeknummers, waarbij positie 7 ongelijk is aan 0, terwijl er geen gebruik is van een extensie.
Bijvoorbeeld:
- 8405005 Waardeveranderingen groepsmaatschappijen 
- 8410015.01 Resultaat deelneming groepsmaatschappij 1.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Zie hierhoor en hierna de discussie over referentienummers en extensies.
   

Mutaties niveau 5 en het Referentie grootboeknummer

(2018)
Binnen het Referentie grootboeknummer worden mutaties (dus niveau 5 van de RGS code) genummerd van 01 – 99, achter de "." (punt). Voor het overgrote deel klopt dit ook. Maar niet bij de volgende mutaties:

RGS-Code Ref. Grootboeknr Naam
BSchBepOvbBib
BSchBepOvbBut
BSchBepOvbPrb
BSchBepOvbGbe
BSchBepOvbBgd
BSchBepOvbTdb
BSchBepOvbOvb

WOvbOrsOreOsa
WOvbOrsOreOar
WOvbOrsOreEeo
1208010
1208020
1208030
1208040
1208050
1208070
1208060

8207020
8207030
8207040

Binnenlandse belastingen
Buitenlandse belastingen
Provinciale belastingen
Gemeentelijke belastingen
Belastingen op verkochte goederen en diensten uitgezonderd BTW
Te betalen Dividendbelasting
Te betalen overige belastingen

Ontvangen loonsubsidies
Ontvangen afdrachtrestituties
Export- en overige restituties en subsidies ingevolge EU-regelingen

En op de nodige andere plaatsen in de kostensfeer. Op dez wijze lijken mutaties niet consequent weergegeven in het referentie grootboeknummer.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Zoals eerder gemeld is referentienummer slechts een voorbeeld. Het voorbestaan van het referentienummer zal besproken worden in de RGS Beheergroep (in maart 2020).

Het gebruik van extensies

(2017)
Extensies zijn bedoeld om naar eigen inzicht uitbreidingen toe te voegen aan RGS, zonder de basis aan te tasten c.q te hoeven uitbreiden. Als bepaalde rekeningen meerdere keren voor komen kan worden gewerkt met extensies. De referentiecode wordt dan voorzien van een “.” (punt) met daarachter de extensie. Bijvoorbeeld voorraadcodes of opbrengstcodes. 
Binnen het referentie grootboeknummer is positie 7 bedoeld voor extensies (eventueel uit te breiden). Al meerdere jaren is er geen volstrekte duidelijkheid over het exacte gebruik van extensies. Het is zelfs de vraag of dit wel is geïmplementeerd binnen (administratieve) software. Vanuit de RGS beheergroep is indertijd de volgende info verschaft aangaande de status van extensies:

"De extensies zijn wel een onderwerp van discussie.

Vooralsnog is het probleem van de "banken/liquide middelen" getackeld door een aantal groepen met codes. Dit mede om het omslagprobleem nu te regelen.

Daarnaast is er het probleem dat indien men min of meer aanvullende codes (uitbreiding op bestaande code) zou hanteren het niet duidelijk is hoe dit in de RGS taxonomie te ondervangen.

Blijft overigens wel het besef aanwezig dat extensies nodig zullen zijn om binnen een basis RGS ook uitbreidingen t.b.v. bepaalde doelgroepen te realiseren (Horeca, Bouw, Transport, WoCo etc.)".

Opvallend hierbij is dat Bouw en Woco worden genoemd en dat in beide gevallen daarvoor het standaard RGS schema is uitgebreid. 
Zie hiervoor ook het eerder genoemd punt "Branche- of sectorspecifieke RGS uitbreidingen". Duidelijkheid, inclusief een goede handreiking, over het gebruik van extensies is dan ook nodig. Een andere optie is het gebruik van extensies in RGS niet meer toepassen. Dit laatste mede in verband met de beheersbaarheid van RGS.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep

Om de discussie over dit onderwerp te vereenvoudigen kunnen we onderscheid te maken tussen twee soorten extensies:

  1. Horizontale extensies’ (een uitbreiding van na de punt). Deze geeft ruimte aan gebruikers om RGS uit te breiden naar eigen wensen. Daarbij is uiteraard de kanttekening dat de gebruiker en/of de software er zelf voor moet zorgen dat dat deze codes meegenomen worden in optellingen voor dashboards en rapportages. Eveneens is het voor de gebruiker belangrijk te realiseren dat de toegevoegde/gewijzigde RGS-codes buiten de organisatie mogelijk niet bruikbaar zijn.

    De toepassing van horizontale extensies (na de punt) vraagt om aanpassing in de programmatuur van het koppelen (altijd bovenliggend vastgesteld niveau en code). Wanneer dit niet wordt toegepast en de gebruiker heeft vrijheid na de punt zal er nooit een volledige dekking plaatsvinden in de RGS taxonomie, waardoor gegevens niet sluiten zullen zijn.

    In RGS zijn op diverse plekken uitbreidingen van het Referentienummer toegevoegd. Dit zijn volgnummers (dus na gebruik van een punt (.)) die in principe alleen plaatsvinden op niveau 5. Deze volgnummers zijn gegeven om mutaties of aantal keer eenzelfde post (op basis van naam of aantal) te onderscheiden. Dit heeft nooit zijn weerslag gekend in de Referentiecode omdat deze op basis van de voor gedefinieerde (SXxxXxxXxxXxx) is bepaald. "Extensies" zijn aldus hier (nog) niet toegepast. Dit ook omdat extensies volgens de beschrijving buiten het beheer van de beheerorganisatie valt.

    Er zijn 112 RGS codes op niveau 5 die niet met een (referentie)volgnummer zijn gedefinieerd, hetgeen wel logisch zou zijn geweest. Dit betreft o.a. 82 referentienummers in het onderdeel "Tussenrekeningen". Dit onderwerp (uitbreidingen van het referentienummer met een punt) zal worden meegenomen in de discussie rondom de wens en noodzaak van de referentienummers.

  2. Verticale extensies’ zijn branche-specifieke RGS codes. Deze worden toegevoegd als het gebruik van een horizontale extensie (uitbreiding na de punt) niet logisch of mogelijk is binnen de opbouw van het RGS schema.

    De intentie van de Beheergroep is altijd geweest dat verticale extensies door de gebruiker weg gefilterd kunnen worden door het gebruik van de filter voor de betreffende branche. Alleen is hier op verzoek van de markt afgeweken (in het geval van de Woningcorporaties). Er zal in overleg met de markt onderzocht worden of in de volgende RGS versie dit anders ingericht moet worden. De vraag is in hoeverre de markt ‘last’ heeft van het feit dat horizontale extensies niet eenvoudig weg gefilterd kunnen worden. Veel softwarepartijen (vooral die RGS ready zijn) hanteren algoritmes voor het koppelen van bestaande grootboekrekeningen aan RGS waardoor het waarschijnlijk niet uitmaakt dat er branche specifieke RGS codes in het schema zitten. Dit wordt bij de markt getoetst. 

    Zie ook deze informatie op de RGS site: https://www.referentiegrootboekschema.nl/het-werken-met-extensies.

RGS versus SBR op basis van XBRL

(juni 2019)
Rond 2004 is het allemaal begonnen met XBRL (tegenwoordig SBR - Standard Business Reporting). In eerste instantie was de opzet te komen tot één uitgebreid NTP-schema (Nederlands Taxonomie Project) op basis waarvan informatie aangeleverd kan worden vanuit de boekhouding (grootboekadministratie). Uitvragende partijen zouden dan hun deel daaruit kunnen afleiden. Uiteindelijk is de koppeling tussen de boekhouding en XBRL nooit echt van de grond gekomen en is SBR gekoppeld aan rapportagesoftware. Vanuit boekhoudsoftware zijn daarmee de koppelingen met rapportagesoftware (denk aan jaarrekening en winstaangifte IB en VPB) in stand gebleven. 

RGS is (in ek geval wat betreft niveau 4) diect gekoppeld aan het grootboek. Vanuit het RGS project (onderdeel van het SBR project) is een relatie gelegd tussen het RGS-schema en meerdere rapportages op basis van SBR. De uitwerking mist echter een simpele brugstaat tussen RGS en de diverse SBR-rapportages, waarbij eenvoudig inzicht is in bepaalde SBR-rapportages (zoals de jaarrekening volgens de diverse modellen en de winstaangifte IB en VPB) en de onderliggende RGS-codes. Dan kan bijvoorbeeld vanuit boekhoudsoftware een rapportage samengesteld worden op volgorde van de jaarrekening of de winstaangifte. Mede als controle op juistheid en volledigheid van betreffende rapportages.

Het is zelfs maar de vraag of RGS opnemen in een XBRL Taxonomie (RGS Taxonomie) wel zo'n verstandige en werkbare keuze is geweest. Slechts een handjevol personen in Nederland kan overweg met XBRL en het nut is niet aangetoond voor RGS. Nagenoeg alle leveranciers van boekhoudsoftware maken gebruik van de RGS-Excel sheet en geven aan daar prima mee uit de voeten te kunnen. En anders kan altijd nog gedacht worden aan een eenvoudige XML- of Json-variant.

Om uiteindelijk inzicht te krijgen tussen RGS en de winstaangifte IB en VPB (op basis van SBR-codes voor de winstaangifte) is ook een (voorlopige) excel-sheet opgeleverd door de RGS beheergroep. Deze excel-sheet mist een formele goedkeuring door de Belastingdienst en de RGS-beheergroep.

Een niet onbelangrijk punt is dat naast de XBRL Taxonomie voor leveranciers van boekhoudsoftware ook de RGS Excel-sheet benodigd is om RGS te koppelen aan het grootboek. Dit laatste heeft te maken met filters die NIET opgenomen zijn in de XBRL Taxonomie. Zo kun je niet eenvoudig de RGS codes voor woningcorporaties weglaten als die niet nodig zijn. En ook het filteren op bijvoorbeeld een ZZP-schema is niet mogelijk zonder gebruik te maken van de RGS Excel-sheet. De XBRL Taxonomie is op dit moment dus incompleet. 

Wij willen dringend adviseren te onderzoeken of de koppeling tussen RGS en de nodige SBR-rapportages niet standaard in Excel (of desnoods XML) opgenomen kan, waarbij de RGS Taxonomie o.b.v. XBRL volledig kan vervallen. Ook het parallel lopen van een jaarlijkse RGS taxonomie met de SBR-taxonomie kan dan wellicht vervallen. XBRL is geen doel op zich en daar lijkt het nu wel op bij het opzetten van de RGS-Taxonomie in XBRL. 

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
De reden dat er geen sprake kan zijn van een simpele brugstaat ligt in het dimensionale karakter van de Nederlandse Taxonomie en de Financieren Taxonomie, een mismatch in de granulariteit tussen de RGS-codes en de XBRL-elementen en het feit dat gelijke XBRL elementen in meerdere rapportages of meermaals in één rapportage kunnen voorkomen. Door deze redenen was het onmogelijk om de koppeling tussen RGS en XBRL op een eenduidige manier in het RGS-schema (Excel) op te nemen. In diverse bijeenkomsten van de Beheergroep is dit besproken, waarna het voorstel is gekomen om de koppeling op basis van de Nederlandse Taxonomie Architectuur op te stellen. Dit besluit is met consensus door de Beheergroep, met daarbij aanwezig softwareleveranciers, genomen.

Dat slechts een handjevol personen in Nederland met XBRL overweg kunnen spreken wij ten stelligste tegen. De RGS Taxonomie is overigens de simpelste taxonomie die door het SBR Programma wordt uitgeleverd. Bij elke release wordt een handleiding verstrekt die uitlegt hoe softwareleveranciers de RGS Taxonomie kunnen gebruiken. Daarbij volstaat alleen XML kennis. Dat de RGS Beheergroep in staat was om een Excel sheet op te leveren voor de koppeling tussen RGS en de fiscale XBRL-elementen, komt doordat hier geen sprake was van dimensionale aspecten en meermaals voorkomen van identieke XBRL-elementen in één rapportage. Bij de uitlevering van deze Excel sheet is dit ook expliciet benoemd.

Het RGS schema en de RGS Taxonomie zijn twee verschillende producten met beide hun eigen doelstelling. Het RGS schema kent filters voor gebruik (WoCo, ZZP, BV etc.), terwijl de RGS Taxonomie filters kent voor de verantwoordingsrapportage en indien nodig de onderliggende delen.

Evenmin kan ontkomen worden aan het parallel lopen van de RGS Taxonomie met uitgaven van de Nederlandse Taxonomie en de Financieren Taxonomie. Immers deze taxonomieën worden jaarlijks geüpdatet en krijgen als gevolg van wijzigingen in wet- en regelgeving nieuwe XBRL elementen. Dit moet natuurlijk ook worden verwerkt in het RGS schema en de taxonomie.

RGS Brugstaat (IB en VPB) versus RGS Taxonomie

(september 2019)
In het najaar van 2019 is de RGS Brugstaat opgeleverd voor een koppeling tussen boekhoudsoftware en fiscale aangiftesoftware voor de winstaangifte IB en VPB. RGS codes worden daartoe (direct of indirect) gekoppeld aan de SBR-codes (in XBRL). Vanuit de RGS-beheergroep is al eerder een RGS-taxonomie opgeleverd (zie ook het punt hiervoor) met een koppeling tussen RGS-codes en SBR-codes (in XBRL). Deze koppeling blijkt niet juist in de praktijk. De RGS-beheergroep heeft samen met de Belastingdienst een actie onderhanden om e.e.a. te controleren, te corrigeren en op te leveren aan de markt.

(20 maart 2020)
Conceptreactie van de RGS Beheergroep
Er zijn gesprekken gaande tussen de Beheergroep en de Belastingdienst over de organisatie en procesgang rondom de inhoud van de RGS taxonomie voor de IB en VPB. Alle opmerkingen worden verwerkt in de definitieve versie van de RGS Taxonomie 3.2. 

Inzicht SBR rapportages per RGS code

(4 april 2020)
Geef per RGS code inzicht in de corresponderende SBR rapportagecode(s) met de bijbehorende rapportages (in XBRL termen: entrypoints) waar deze gebruikt worden. Dan kun je als gebruiker zien voor welke rapportages een RGS-codes wordt gebruiikt en waarvoor.

Filtermechanisme niet compleet

(5 mei 2020)
De filterfunctionaliteit is niet beschikbaar in de RGS Taxonomie. Softwareleveranciers en gebruikers zijn aangewezen op Excel.
Filters voor stichtingen en verenigingen ontbreken.
De filters zijn niet constant gebleven vanaf RGS versie 3.0.
Een duidelijk uitleg en voorbeelden van de filters ontbreekt op dit moment.

Tot slot
Mocht u zelf een openstaand punt hebben dan kunt u dat mailen aan rgsready@gbned.nl
Mocht u de oplossing voor een openstaand punt hebben of een fout constateren dan horen we dat natuurlijk ook graag.

Wij hopen tot slot dat de organisatie achter RGS bovenstaande punten kan oppakken en oplossen, zodat "RGS Niet Ready" zo snel mogelijk tot het verleden behoort en alleen RGS Ready overblijft met tevreden softwareleveranciers en gebruikers.

Zie ook de blog "ReferentieGrootboekSchema (RGS): voorstel om problemen op te lossen en RGS weer beheersbaar te maken en te houden" (29-2-2020).

Reageren kan ook via LinkedIN.
 

Categorie(n) RGS (ReferentieGrootboekSchema), Branche > Accountantskantoren, Soort > Boekhoudsoftware, Standaardisatie, (open)standaarden
Bronvermelding Onderzoeksbureau GBNED / RGS Ready
Internet URL http://www.rgsready.nl

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

Terug

Seminar RPA en robotic accounting

Najaar 2020
Seminar RPA en robotic accounting
Met ook gerelateerde ontwikkelingen, zoals: Artificial intelligence (AI), Elektronisch factureren, Purchase-2-Pay, PSD2, Blockchain en Chatbots.
Meer informatie en deelname...


Kleisteen

Informer Software

MUIS Software


Timewriter


Onerzoeksbureau GBNED