SBR RGS kent standaard het principe van omslagcodes. Volgens ons afkomstig van rapportagesoftware. De huidige werkwijze met omslagcode binnen SBR RGS leidt volgens RGS MKB tot wat dubbele rekeningen en verwarring op welk moment deze omslagcodes toe te passen. 

Waar het om gaat is dat bepaalde rekeningen soms debet op de balans komen en soms credit. Het bekendste is de rekening "Bank". Bij een positief saldo is sprake van "Liquide middelen" die debet op de balans staan. Bij een negatief saldo is sprake van "Schulden op korte termijn" die credit op de balans staan. Andere voorbeelden zijn:

• Rekening-courant (RC) verhouding; denk aan een RC met een bestuuder, aandeelhouder of binnen een groepsmaatschappij. Ook leden van een coöperatie worden genoemd. Een betaalrekening bij een bank waarbij het saldo negatief kan zijn is ook een vorm van een RC-rekening. Zie rekeningen met omslagcodes RC.
  
  
• Te betalen en terug te vorderen; diverse belastingen (zoals loonheffing, VpB, dividendbelasting en omzetbelasting).
    
• Tussenrekeningen; zie de tussenrekeningen binnen RGS. 

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. Naast eerder genoemde rekeningen gaat het dan met name om:

• Onderhanden projecten; het gaat hier om 8 rekeningen in de groep "Onderhanden projecten" (niet te verwarren met onderhanden werk) die een omslagcode hebben naar niveau 5 (mutaties) binnen standaard RGS. 
  
  Vanuit RGS MKB adviseren we tot heden geen gebruik te maken van deze omslagcodes omdat niveau 5 niet actief is bij RGS MKB. 
  
  
• Transitoria; zie Overlopende activa en passiva boeken, oftewel transitorische posten.
  Vanuit standaard RGS is er bijvoorbeeld de rekening "Nog te ontvangen / vooruitbetaalde provisies" een omslagcode naar de rekening "Nog te betalen / vooruitontvangen provisies" (en vice versa). 
  
  Vanuit RGS MKB hebben we voorgesteld met aparte rekeningen te werken, zoals "Nog te ontvangen provisie" en "Vooruitontvangen provisie" voor een ontvanger van provisie. 
  En ten tweede vragen we ons het nut af van een omslagcode tussen betreffende rekeningen.
  Hoewel dit laatste verder geen obstakel vormt.
  
  
• Rente baten en -lasten; binnen de winst- en verliesrekening kennen we tot slot in 14 siuaties een omslagcode voor bepaalde rentelasten rekeningen versus rentebaten rekeningen. We noemen als voorbeeld "Rentebaten bank" versus "Rentelasten en kosten bank". .

Dubbele rekeningen in RGS schema

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.  

De 6 opgenomen "Rekening courant bank A t/m F onder "Vorderingen" kennen als tegenhanger de 6 opgenomen rekeningen "Rekening-courant bij kredietinstellingen A t/m F". Ook dat lijkt dubbelop, bezien vanuit een of meer rekeningen "bank" in het grootboek. Hoewel dit laatste verder geen obstakel vormt.

Van grootboek naar rapportage

Een standaard decimaal rekeningschema (van rubriek 0 tot 9) kent weliswaar groepen van rekeningen (zoals Liquide middelen), maar werkt bij de presentatie zelf niet met een omslagcode. Denk aan een (proef- en) saldibalans of een kolommenbalans per rekening. Een omslagcode is volgens ons louter bedoeld voor de jaarrekening en bijvoorbeeld de winstaangiftte IB en VpB. En wellicht ook voor kredietrapportages. De omslagcode kan dan toegepast worden tijdens het proces "aanmaken kolommenbalans" om deze verder uit te werken. Niet te verwarren met een standaard kolommenbalans in een boekhoudpakket.

Zoals eerder aangegeven, bij het voorbeeld van de bank, gaat het erom dat een rekening, afhankelijk van het saldo (plus of min) onder de juiste balansrubriek wordt weergegeven. Een systematiek die volgens ons al meer dan 50 jaar wordt toegepast en waar ook niets mis mee is.

Waar het dan op neer komt is dat bij betreffende rekeningen het saldo terecht komt onder de juiste balansrubriek. We nemen weer even de rekening "Bank" als voorbeeld, waarbij een positief saldo wordt geschaard onder "liquide middelen" en een negatief saldo onder "Schulden op korte termijn". En dat apart voor de begin- en eindbalans per grootboekrekening.  

Dit wordt als zodanig aangegeven bij de koppeling tussen grootboek en betreffende rapportage. Rapportagesoftware kent veelal mechanismen om deze rubricering op orde te brengen, al dan niet op basis van RGS codes. 

Omslagcodes RGS

Voor het rangschikken van rekeningen onder activa of passiva (of in sommige gevallen kosten / opbrengsten), afhankelijk van een debet of credit saldo, is er binnen standaard SBR RGS gekozen voor omslagcodes. Een systematiek die volgens ons afkomstig is van rapportagesoftware. Binnen RGS doorgevoerd op een wijze die 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.
   
   Vanuit de "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. Dit moet dan wel binnen de koppelvlakken verder ingericht worden en uitgevoerd worden vanuit de software die betreffende koppelvlakken gebruikt voor rapportages.
   Inrichten binnen RGS MKB zal plaatsvinden afhankelijk van de uiteindelijk gekozen werkwijze.

Omslagcodes RGS handhaven of juist niet

Een belangrijke vraag is nu of de huidige RGS omslagcodes gehandhaafd blijven. Daarom zetten we de 2 uiterste opties, 1) handhaven omslagcodes in de huidige vorm en 2) laten vervallen omslagcodes in de basis van RGS, op een rij. 

A) Handhaven omslagcodes;

1. Accepteren dat RGS dubbele rekeningen bevat. Het gaat om zo'n 20 rekeningen.
2. Omslagcodes herstellen of weghalen bij "Onderhanden projecten".
3. Omslagcodes niet op niveau 4 en 5 naar elkaar laten verwijzen. 
   Voor RGS MKB worden dan betreffende omslagcodes als niet aaanwezig beschouwd.
     
4. Nalopen of alle bestaande omslagcodes logisch zijn in de praktijk, voorzien van voorbeelden.
5. Nalopen bij welke rekeningen eventueel omslagcodes ontbreken, voorzien van voorbeelden.
6. Afspreken hoe omslagcodes te gebruiken, met name op welk moment. Hierbij ook de XAF en RGS brugstaat betrekken.
   Dit goed documenteren en zo nodig meenemen bij een update van RGS ready.
    
7. Omslagcodes implementeren binnen de RGS taxonomie in XBRL. Of in elk geval duidelijk maken dat de RGS taxonomie ook altijd de implementatie van SBR RGS vereist via de Excel-sheets.
   Dit punt speelt niet voor RGS MKB. 

B) Laten vervallen omslagcodes in de basis van RGS;

1. Omslag verder implementeren bij de eerder genoemde "rapportage koppelvlakken RGS MKB".
2. Softwareleveranciers van rapportage- en fiscale aangiftesoftware (winstaangifte IB en VpB) duidelijk maken dat zij zelf de omslagen implementeren waar nodig.
3. Omslagcodes implementeren binnen de RGS taxonomie in XBRL. Dit punt speelt niet voor RGS MKB.
4. Omslagcodes, en eventueel overbodige rekeningen, uitfaseren c.q. hergroeperen (denk aan de tussenrekeningen). In elk geval (nog) niet fysiek verwijderen. 

Uitvraag huidig gebruik omslagcodes

Aan leveranciers van boekhoud-, rapportage- en fiscale aangiftesoftware wordt gevraagd op welke wijze zij omgaan met de huidige omslagcodes in RGS. Wat verwachten zij mede in relatie tot de XAF, RGS brugstaat en de RGS taxonomie. 

Deze uitvraag wordt komende periode uitgevoerd en ook kenbaar gemaakt via LinkedIn.
Als de resultaten beschikbaar zijn worden die hier gemeld.
Hierna vindt besluitvorming plaats vanuit in elk geval RGS MKB of en hoe verder te gaan met de RGS omslagcodes in de toekomst.

24-5-2026
Gezien de tot heden binnengekomen reacties lijkt de voorkeur uit te gaan naar scenario A.
Dat vereist met name een goede documentatie rondom het gebruik van de omslagcodes.