Bijgewerkt 22 juni 2025: met name op basis van reacties softwareleveranciers. 

Binnen standaard SBR RGS zijn zo'n 180 rekeningen (op niveau 4) met een omslagcode opgenomen. Omdat verreweg de meeste rekeningen 1 op 1 naar elkaar verwijzen mag uitgegaan worden van zo'n 90 situaties.

Omwille van de gehanteerde methodiek van omslagcodes kent het standaard RGS schema ook een aantal dubbel opgenomen grootboekrekeningen. We noemen met name tussenrekeningen, zoals voor betalingen, salarissen en inkopen.
11 rekeningen zijn aanwezig onder "Vorderingen" en exact dezelfde rekeningen zijn aanwezig onder "Schulden". 

Vanuit RGS MKB zouden we graag betreffende rekeningen éénmalig opgenomen zien.  

Consequenties omslagcodes RGS

De binnen RGS doorgevoerde omslagcodes leidt tot:

1. Dubbel opgenomen rekeningen in het standaard RGS schema en daarmee ook in RGS MKB om niet uit de pas te lopen bij de standaard. Een en ander zoals hiervoor uitgelegd.
   
   
2. Geen eenduidigheid over het moment waarop de omslagcodes toegepast worden in de praktijk. 
   Stel je werkt met de XML Auditfile (XAF) of RGS brugstaat voor het exporteren van grootboeksaldi, dan is de vraag of de omslagcode (en dan apart voor begin- en eindbalans) al wordt toegepast bij het aanmaken van de XAF of de RGS brugstaat.
   
   Interessant is dat bekende leveranciers van jaarrekening software zelf veelal werken met mechanismen voor de omslag, al dan niet op basis van de omslagcodes in RGS. Terwijl leveranciers van fiscale aangiftesoftware bij de tot stand koming van de RGS brugstaat veelal aangeven dat leveranciers van boekhoudsoftware al rekening moeten houden met de omslagcodes bij het aanmaken van de RGS brugstaat. 
   
   Leveranciers van jaarrekening software zijn gewend te werken met de XAF. Binnen de XAF wordt de RGS code aangegeven waar betreffende rekeningen betrekking op hebben. Met de RGS omslagcode wordt bij het aanmaken van de XAF volgens ons niets gedaan. De RGS omslagcode wordt dan gebruikt bij het proces 'uitwerken kolommenbalans'.
   
   Vanuit SBR RGS wordt gewerkt met een XBRL Taxonomie voor de relatie tussen RGS en betreffende rapportages (zoals jaarrekening en aangifte IB/VpB). Volgens ons is binnen de RGS Taxonomie geen omslagcode geïmplementeerd. We hebben geen documentatie gevonden over de preciese implementatie van omslagcodes in combinatie met de RGS Taxonomie. En kennen zelf ook geen boekhoudsoftware die de RGS Taxonomie gebruikt als koppelvlak voor rapportages jaarrekening en (winst)aangifte IB/VpB. Input is altijd welkom, ook documentatie over het gebruik van de RGS Taxonomie in het algemeen.

Uitvraag huidig gebruik omslagcodes

Aan leveranciers van boekhoud-, rapportage- en fiscale aangiftesoftware is gevraagd (mei 2025) op welke wijze zij omgaan met de huidige omslagcodes in RGS. Antwoorden op deze uitvraag heeft geleid tot de volgende bevindingen:

• Allereerst hebben we de nodige positieve reacties ontvangen op de uitvraag. Duidelijkheid hoe precies om te gaan met de RGS omslagcodes lijkt gewenst. 
   
• Binnen boekhoudsoftware zelf wordt nauwelijks iets gedaan met omslagcodes. We kunnen stellen dat de omslagcodes voor het gebruik van RGS binnen boekhoudsoftware zelf geen functie heeft. Behoudens als sprake is van een jaarrekeningfunctie.
    
• Bij het aanmaken van de XML Auditfile Financieel (XAF) binnen boekhoudsoftware wordt niets gedaan met de omslagcodes. 
  Soms wordt een omslagcode bij een rekening meegegeven in een extra veld binnen de XAF versie 3.2. 
  
  
• Leveranciers van jaarrekening software hebben de RGS omslagcodes, of een eigen afgeleide daarvan, zelf al geïmplementeerd in hun rapportagesoftware. Dat kan zelfs erg uitgebreid zijn, getuige de volgende input:
  
  "De gebruiker kan zelf kiezen of deze de presentatie op één plek (met negatieve vergelijkende cijfers) of op twee plekken in de balans wil presenteren huidige jaar debet (met vergelijking leeg) en vergelijkend jaar credit (met huidig jaar leeg)".
  
  En.
  
  "Bij de jaarrekening is er een optie in de vragendialoog waar men kan aangeven hoe de omslagcode wordt bepaald.*)
   RGS omslagcode bepalen op basis van 1) RGS-totaal en 2) Grootboektotaal". Met dit laatste wordt dan bedoeld 1) RGS code en 2) Onderliggende grootboekrekeningen. 
    
• Bij het aanmaken van de RGS brugstaat houden nog niet alle leveranciers van boekhoudsoftware zich aan de afspraak om rekening te houden met de omslagcodes. Aanmaken RGS brugstaat (2.0) attentiepunt 6 luidt "Als sprake is van een omslagcode moet hier rekening mee gehouden worden, zodat de fiscale aangifte de cijfers binnen krijgt op de juiste rekening."
  
  Met name leveranciers van fiscale aangiftesoftware IB/VPB hebben daar hinder van. We hebben begrepen dat 3 leveranciers de omslagcodes (of een eigen afgeleide daarvan) nu zelf implementeren in hun aangiftesoftware. Analoog aan leveranciers van rapportagesoftware. 

Aanbevelingen

Op basis van bovenstaande komen we tot de volgende aanbevelingen:

1. De werking van RGS omslagcodes goed en uitgebreid documenteren. Tevens voorzien van de nodige (boekings)voorbeelden en nagaan of alle bestaande omslagcodes logisch zijn in de praktijk en ook gebruikt worden.
       
2. Het aantal dubbele rekeningen (denk aan tussenrekeningen) in RGS tot een minimum proberen te beperken.
   Het gaat nu om zo'n 20 rekeningen.
     
3. Omslagcodes herstellen of weghalen bij "Onderhanden projecten".
   Dit punt staat al langer open binnen SBR RGS. Ook hier speelt duidelijkheid een belangrijk aspect.
   
   
4. Omslagcodes sowieso niet op niveau 4 en 5 naar elkaar laten verwijzen. 
       
5. Afspreken hoe omslagcodes te gebruiken, met name op welk moment. Hierbij ook de XAF en RGS brugstaat betrekken.
   Dit goed documenteren (zie eerder punt 1) en zo nodig meenemen bij een update van RGS ready.
   
   Bij het aanmaken van de XAF wordt volgens ons geen rekening gehouden met de RGS omslagcode en wordt dit overgelaten aan de ontvanger van de XAF. Denk aan rapportagesoftware. Volgens ons is er ook geen behoefte om dit aan te passen.
   
   Bij het aanmaken van de RGS brugstaat is afgesproken om al direct rekening te houden met de omslagcode. Dus door leveranciers van boekhoudsoftware. Zie wel punt hierna.
   
   Bij API-koppelingen m.b.t. RGS is het aan softwareleveranciers zelf om onderling te overleggen waar en hoe eventueel rekening gehouden wordt met RGS omslagcodes.  
     
6. Softwareleveranciers van rapportage- en fiscale aangiftesoftware (winstaangifte IB en VpB) duidelijk maken dat zij zelf de omslagcodes, of een eigen afgeleide daarvan, implementeren waar nodig. Als men wil vertrouwen op de omslag binnen de RGS brugstaat, dan vooraf controleren of dit goed is gevuld. 
   
   De praktijk leert dat softwareleveranciers van rapportagesoftware goed uit de voeten kunnen met de omslagcodes of een eigen afgeleide daarvan. En enkele leveranciers van Fiscale aangiftesoftware (winstaangifte IB/VPB) dit ook zelf opgepakt hebben. 
   
   Bij "rapportage koppelvlakken RGS MKB" is de mogelijkheid open gelaten om te werken met de systematiek om rekeningen te koppelen aan rapportagerubrieken op basis van een debet of credit saldo. Deze manier van implementeren maakt het gebruik van de huidige omslagcodes zelfs overbodig voor betreffende rapportages. Dit wordt vanuit RGS MKB ingericht als daar behoefte aan is. Nu is alleen de mogelijkheid geschapen.  

Zie uitgebreidere toelichting Omslagcode bij RGS rekeningen.