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

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. 

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

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.
   
   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.

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)".   
  
  
• 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.   .