Als het met SBR niet lukt om tot één datadefinitie te komen, waarom zou dat met RGS wel lukken? Zo nu en dan verschijnt er een artikel over het Referentie Grootboekschema, oftewel RGS. Boekhoudsoftwaremakers adopteren steeds vaker het RGS en dat zou SBR-implementatie een stuk simpeler maken. Op de website staat het RGS omschreven als ‘de brug tussen de financiële administratie en in- en externe rapportages van een onderneming’. Eindelijk dus die SBR-belofte! Maar waarom moet die belofte bereikt worden met het RGS?
Historie
Het idee van het RGS was dat er een standaard grootboekschema zou ontstaan die door alle ondernemingen gebruikt kan worden, om de uitwisseling van gegevens tussen ondernemingen en overheid gebruik te maken. Naar aanleiding van dit idee zijn werkgroepen gevormd bestaande uit marktpartijen (onder andere softwareleveranciers van rapportgeneratoren) en overheidsorganisaties. De softwareleveranciers maakten allen gebruik van mappingschema’s. De elementen hieruit zijn samengevoegd en vervolgens is een codestructuur daarvoor opgesteld. Hetgeen heeft geresulteerd in een eerste versie van het RGS eind 2013. Inmiddels is versie 2 ter consultatie beschikbaar gesteld.
De inhoud
In het RGS is een alfanumeriek grootboek (referentiecode) opgenomen en een numeriek (referentienummer). Het referentienummer bestaat uit 7 posities. Mutaties worden ook genummerd. In dat geval wordt een “.” achter het referentienummer opgenomen, gevolgd door 2 cijfers. Volgens de handleiding sluit dit aan bij de systematiek van verschillende rapportgeneratoren die splitscodes aanbieden. Dit lijkt mij een vreemde uitleg, het gaat toch om een grootboekrekeningschema in de financiële administratie? Toch niet om de rapportgenerator? Ik hoop dat die laatste SBR als standaard hanteert i.p.v. het RGS. De administratie is immers primair bedoeld voor transactieverwerking en dat is een andere invalshoek dan het (complexere) rapportageproces.
Verder staat in de handleiding dat het een voorbeeldnummering is, er mag vanaf geweken worden. Ik begrijp dat we in Nederland graag polderen, maar dit doet bij mij toch de vraag oproepen wat het doel van het RGS nu eigenlijk is….
Verderop lees ik dat het RGS met name gericht is op het werken met de referentiecodes. Als je je een beetje inleest in de opbouw van de referentiecodes, zou dat misschien best handig kunnen zijn. Ik kan me voorstellen dat met een zoekopdracht vrij snel een rekening gevonden kan worden. Maar dan is wel de vraag: is onze wereld klaar voor een alfanumeriek grootboekrekeningschema?
De efficiency verloren
Even snel bekeken telt het RGS zo’n 11.102 grootboekrekeningen. Dat klinkt in ieder geval alsof niets vergeten is. Ik licht er zo eens wat uit:
Het RGS kent t.a.v. de immateriële vaste activa meer rubrieken dan wet- en regelgeving heeft opgenomen. Zo is de categorie ‘Concessies, vergunningen en intellectueel eigendom’ uitgesplitst. Software is apart benoemd maar valt onder intellectueel eigendom. Daarnaast worden “Bouwclaims” apart benoemd. Dit laatste sluit aan bij de rapportages die woningbouwcorporaties moeten indienen. Bij goodwill is een uitsplitsing gemaakt waarbij goodwill uit eerdere overnames apart is opgenomen. En dan is er nog “Overige immateriële vaste activa” opgenomen. Dit bestaat echter niet als aparte rubriek maar wordt in rapportages gebruikt als samenvoeging van rubrieken immateriële vaste activa. In het RGS zou dit m.i. derhalve niet als zodanig voor moeten komen.
Het RGS heeft bij de materiële vaste activa rekening gehouden met de uitsplitsing die in de bankentaxonomie wordt gehanteerd, onder meer door Vliegtuigen, Schepen, Meerjarenplantopstand en Gebruiksvee op te nemen. Het RGS voorziet echter niet in de uitsplitsing naar ‘Vaste bedrijfsmiddelen in uitvoering’ en ‘Vooruitbetalingen op materiële vaste activa’ die in de toelichting van de bankentaxonomie staat.
Per materieel vast actief worden, ten behoeve van het mutatieoverzicht, de investeringen als aparte grootboekrekening opgenomen. Er zijn maar liefst 3 (!) verschillende investeringsrekeningen: investeringen nieuw aangeschaft, investeringen tweedehands aangeschaft en investeringen in eigen beheer. De activamodules in de boekhoudsoftware kan de deur uit, het grootboekschema neemt die taak over.
Dat geldt misschien ook wel voor een groot deel van de module projectadministratie voor de onderhanden projecten. De wet- en regelgeving vraagt een specificatie waaruit onder meer de geactiveerde kosten blijken. Dit is dus ook in het RGS opgenomen. Maar het RGS gaat verder en een nadere uitsplitsing van geactiveerde kosten, zie onderstaand:
De Werkkostenregeling (WKR) vereist dat in de administratie de vergoedingen e.d. worden bijgehouden. Het RGS heeft hierbij ‘administratie’ vertaalt naar ‘financiële administratie en heeft bij de personeelskosten zo te zien de WKR verwerkt in haar rubrieken:
- Werkkosten vrije ruimte (42 rekeningen)
- Werkkosten met nihil waardering (16 rekeningen)
- Werkkosten gericht vrijgesteld (24 rekeningen)
- Werkkosten noodzakelijkheidscriterium (6 rekeningen)
- Werkkosten intermediair (4 rekeningen)
- Werkkosten belast loon (8 rekeningen)
- Werkkosten geen of vrijgesteld loon (9 rekeningen)
- Werkkosten overig (4 rekeningen)
U leest waarschijnlijk ook in de media dat de administratie steeds meer wordt geautomatiseerd. De ontwikkelingen op het gebied van UBL zou dit nog verder aanwakkeren. Hoeveel technische intelligentie is straks vereist om geautomatiseerd facturen te boeken met dergelijk uitgesplitste grootboekrekeningschema’s? Ik denk dat de accountancy robots waar Fou-Khan Tsang over schreef maar beter snel kunnen komen want als een mens hierover moet nadenken bij het boeken, is die efficiency die RGS en SBR bieden nog ver te zoeken. Bovendien is het maar de vraag of de robot(computer) van een bloemetje op een factuur kan afleiden voor wie dat bloemetje is geweest.
Het RGS is de pleister om eerdere fouten te herstellen
Een aantal softwareleveranciers van boekhoudsoftware bieden het RGS als een mappingstructuur aan. De ondernemer kan zijn huidige rekeningschema in stand houden. Vervolgens koppelt hij de grootboekrekeningen aan de referentiecodes van het RGS. Het boekhoudpakket kan vervolgens aan de hand van deze koppeling de vertaalslag maken van het grootboekrekeningschema naar de SBR-rapportage. Is dat niet wat rapportagesoftware al jaren doet? Wat maakt dit dan efficiënter behalve dat het in één pakket gebeurt?
Als de softwareleveranciers er op deze manier mee omgaan, waarin verschilt het RGS dan nog met SBR? “Doordat het RGS aan alle SBR-taxonomieën is gekoppeld en je daardoor met één druk op de knop diverse rapportages kunt opstellen” zullen de softwareleveranciers zeggen. Tja, is dat nou net niet hetgeen waar het in het SBR-programma mis is gegaan? Als het SBR niet is gelukt om tot één data definitie te komen, waarom zou het dan het RGS wel lukken? En als het RGS erin slaagt, schaffen we dan al die SBR-taxonomieën af?
Vera van Dijk RA is projectmanager bij BDO. Deze blog is geschreven op persoonlijke titel.
Dat bloemetje kan van mij naar Vera. Niks WKR dus.
Maar jahh… waar dan wel?
Als een van de grondleggers van het RGS wil ik toch even kort reageren op de blog van Vera van Dijk. Persoonlijk vind ik het jammer dat RGS in die bijdrage nogal eenzijdig en negatief is belicht. Het begint al door na een foute snelle blik te snel te concluderen dat de efficiency is verloren.
1. De consultatieversie van RGS 2.0 bevat geen “11.102 grootboekrekeningen”, maar 2.528 records, waarvan 1.023 grootboekrekeningen, 1.288 mutatieregels en 217 (hoofd)rubrieken. Dat is minder dan een kwart Vera!
2. RGS is ontstaan door enerzijds te kijken naar de NT en BT taxonomieën waarbij we elementen van 350 verschillende entrypoints bij elkaar hebben gevoegd op een zodanige wijze dat alle overzichten vanuit RGS kunnen worden vervaardigd. Daarbij is ook goed gekeken naar de verschillende dimensions (het CBS wil bijvoorbeeld inzicht in nieuwe en tweedehands investeringen, omdat alleen de eerste categorie bijdraagt tot het BNP), waardoor we alles tot zo’n 2.000 records konden terugbrengen.
3. Daarnaast is ook goed gekeken naar de praktijk van de boekhouding en rapportering. Zo is het door jou aangehaalde voorbeeld m.b.t. onderhanden projecten ontstaan uit een discussie met een leverancier van administratieve software en gebruikers uit de bouwbranche.
4. Hetzelfde geldt voor de WKR; hoewel dit niet vanuit de NT of BT is voorgeschreven biedt RGS een schema om deze kosten goed te kunnen verantwoorden: at your service, m.a.w. maak er gebruik van zo je dit wenst.
4. Met sommige punten ben ik het (deels) eens: Overige immateriële vaste activa bestaan niet (tenzij men alleen aan de bank hoeft te rapporteren) en Vaste bedrijfsmiddelen in uitvoering’ en ‘Vooruitbetalingen op materiële vaste activa’ zullen moeten worden gesplitst om aansluiting met de BT.
Ik had gehoopt dat je in dit artikel ook terug zou komen op de SBR problemen die je in eerdere bijdragen hebt gesignaleerd. Volgens mij biedt RGS daar namelijk goede mogelijkheden, waardoor de brugfunctie van RGS tussen de administratie en SBR kan worden bevestigd.
Tenslotte: RGS is een stap in de standaardisatie van de administratieve functie en laat zien dat zowel administreren en rapporteren niet zomaar door robots kan worden overgenomen. Professionals hebben gevoel voor het karakter van de rekening (dat was mijn eerste les boekhouden) en de informatiebehoefte van de klant en zijn stakeholders. Met automatisering kan het efficiënter, maar accountancy is nog steeds een vak om trots op te zijn.
Een voordeel van RGS is dat de lastige “mapping” tussen het eigen rekeningschema en de verschillende SBR- taxonomieën niet gemaakt hoeft te worden. De mapping van RGS naar de SBR-Taxonomieën zijn immers voor iedereen gelijk en kunnen door de softwareleverancier, of liever nog door de bouwer van de betreffende SBR-Taxonomie, worden geleverd. Er kan dus aan de zijde van de ondernemer worden volstaan met het eenmalig toevoegen van RGS-referentiecodes aan de bestaande grootboekrekeningen.
Je kan je inderdaad afvragen waarom we dan nog SBR-Taxonomieën nodig hebben. Eén van de redenen daarvoor is dat een ondernemer terecht niet meer gegevens wil afstaan dan strikt nodig of wettelijk verplicht. Voor de KvK is dat een andere subset uit de saldibalans als voor de fiscus, de bank of het CBS. Stel je voor dat concurrentiegevoelige omzetcijfers in het openbare handelsregister zouden komen.
Dat neemt niet weg dat er te veel SBR-Taxonomieën zijn, en dat deze soms bijzonder complex zijn. Je hebt daar zelf terecht al een paar keer op gewezen.
Het allemaal vast beter en eenvoudiger gekund. We hebben echter nu de huidige SBR-Taxonomieën. Het gebruik daarvan wordt in toenemende mate afgedwongen. RGS is nu zeer welkom om toch de oorspronkelijk belofte van SBR een stuk dichterbij te brengen.