Handleiding Referentie GrootboekSchema

Referentie Grootboekschema

“Een ieder die een bedrijf of zelfstandig een beroep uitoefent, is verplicht van zijn vermogenstoestand en van alles betreffende zijn bedrijf of beroep, naar de eisen van dat bedrijf of beroep, op zodanige wijze een administratie te voeren en de daartoe behorende boeken, bescheiden en andere gegevensdragers op zodanige wijze te bewaren, dat te allen tijde zijn rechten en verplichtingen kunnen worden gekend. (BW3:art.15i lid 1).”

Het unieke van boekhouden is dat voor iedereen (bijna) dezelfde regels gelden, maar dat ieder hier op zijn eigen manier invulling aan geeft. Logisch, want geen twee bedrijven zijn hetzelfde. Dit staat haaks op de steeds meer gestandaardiseerde informatie-uitvraag van Kamer van Koophandel, Belastingdienst, CBS en banken, die met het Standaard Business Reporting (SBR) programma juist hierin veel effort hebben gestoken. Om hieraan tegemoet te komen is er steeds meer noodzaak tot  het standaardiseren van financiële administraties.  Dit is in Nederland in drie stappen gerealiseerd:

  • Harmonisatie van de gegevens, zoals die door de verschillende partijen worden uitgevraagd: SBR
  • Export van alle financiële gegevens in een standaard bestandsformaten: XBRL en de auditfiles
  • Eenduidige codering  van deze financiële gegevens: het referentie grootboekschema (RGS).

In deze notitie zal nader op de inhoud en de betekenis van het Referentie Grootboekschema worden ingegaan.

Een klein stukje geschiedenis

Ik ga niet helemaal terug naar de eerste beschrijving van het dubbel boekhouden, zoals dit is gepubliceerd in 1494 in het boek Summa de Arithmetica Geometria Proportione et Proportionalita door de Italiaanse franciscaner monnik Luca Pacioli. Maar wel naar mijn oude boekhoud leerboeken waarin het rekeningstelsel van P. Bakker en M.J. van der Ploeg met het decimale rekeningstelsel voor de fabricageboekhouding  werd gehanteerd.

Rubriek Omschrijving
Rubriek 0 Vaste activa, Eigen vermogen, Schulden lang
Rubriek 1 Financiële rekeningen
Rubriek 2 Neutrale rekeningen
Rubriek 3 Voorraadrekeningen
Rubriek 4 Rekeningen van kostensoorten
Rubriek 5 Rekeningen van kostenplaatsen
Rubriek 6 Fabricagerekeningen
Rubriek 7 Kostprijsrekeningen
Rubriek 8 Verkooprekeningen
Rubriek 9 Resultatenrekeningen

De meeste bedrijven – voor zover die geen Angelsaksische moeder hebben – zullen hun grootboekschema’s hierin wel herkennen. Op basis van het principe “hoog aan laag” konden transacties als een soort keten worden gevolgd om zo het uiteindelijke resultaat vast te stellen.

Financieel rapporteren

Mijn loopbaan stamt nog uit de tijd dat accountants een jaarrekeningrapport concipieerden en dit vervolgens door de typekamer werd uitgewerkt. Een boekhoudkundige correctie had toen dramatische gevolgen en zo is het correctielint, de ‘typex’ etc. uitgevonden. Gelukkig is dat niet meer van deze tijd, waarin accountantskantoren bijna met een druk op de knop een jaarrekeningrapport automatisch kunnen genereren.  Hoe werkt zo’n rapportgenerator? De saldibalans van een klant op basis van zijn unieke grootboekschema wordt ingelezen en ‘gemapt’ met een rapportageschema, waarin de verschillende rapportage-elementen zijn gedefinieerd. Soms is er een één op één koppeling tussen het eindsaldo van een grootboekrekening en zo’n rapportage-element, soms kunnen op die manier meerdere grootboekrekeningen worden samengevoegd, maar soms zal een grootboekrekening voor bepaalde rapportage-elementen moeten worden gesplitst in beginsaldo, betalingen en ontvangsten wat uiteindelijk resulteert in het ingelezen eindsaldo. Nadat de financiële gegevens op de hiervoor beschreven manier zijn ingelezen en gekoppeld aan de verschillende rapportage-elementen kunnen deze verder worden geanalyseerd, gecontroleerd en waar nodig gecorrigeerd en uiteindelijk in de verschillende standaardvormen worden gerapporteerd. Dit zijn enkele stappen uit de financieel administratieve rapportageketen waarin een aantal verrijkingen van de informatie plaatsvinden(rubriceren, uitsplitsen, toelichten en presenteren van de gegevens).

Hoewel de inhoud van dit proces wordt opgeslagen in zogenaamde mappingschema’s kan het wellicht toch wat efficiënter. Wat als de boekhouding al zodanig was ingericht op basis van de noodzakelijke rapportage-elementen, zodat er achteraf niet meer hoeft te worden uitgesplitst of posten moeten worden overgeboekt? Wat als de boekhouding in staat zou zijn om die standaard-rapportage dan in een keer te vervaardigen? Eigenlijk was dat de feitelijke doelstelling van het SBR programma. Niet om daarmee de accountant overbodig te maken, want hierdoor kan die zich veel meer op zijn feitelijke taak richten: de betrouwbaarheid van die rapportage en de adviezen die daaruit gegeven kunnen worden. En ook niet om de ‘lyfecycle’ van de rapportagesoftware vroegtijdig te beëindigen, want die is heel belangrijk voor het vervaardigen van de financiële rapportages in leesbare en uitwisselbare formaten, zodat die gegevens rechtstreeks door de uitvragende partijen kunnen worden ingelezen en toch ook op een nette leesbare manier kunnen worden gepresenteerd.

Het gaat om de vraag hoe kan de financieel administratieve rapportageketen zodanig kan worden vereenvoudigd, dat de verschillende rapportages efficiënter tot stand kunnen komen.

Initiatief Referentie Grootboekschema

Verschillende partijen vanuit de overheid en marktpartijen hebben het initiatief opgezet om te zien hoe de financiële informatieoverdracht door een verdergaande integratie op gegevensniveau kan worden vereenvoudigd. De oplossing ligt voor een belangrijk deel in het definiëren van een referentieschema op grootboekniveau  waarmee een brug wordt geslagen tussen de gegevens binnen de administratie en de uiteindelijke rapportages. Dit fenomeen is niet nieuw want sinds er vanuit de administratie wordt gerapporteerd wordt er gewerkt met brugstaten waaruit de aansluiting tussen de financiële administratie en het uiteindelijke rapport is weergegeven. 

We draaien het nu alleen om: door de verschillende financiële rapportages te projecteren op de inrichting van de administratie, kan daarmee samenhang worden gebracht tussen de financiële administratie en de begrippen zoals die in die financiële rapportages worden gehanteerd.

Om tot een goed hanteerbaar referentie grootboekschema te komen zijn een aantal eisen geformuleerd:

  • Verlies niet uit het oog dat er al enkele (minstens vijf) standaard rekeningschema’s in gebruik zijn in Nederland. Ontwikkel de inhoud van het RGS niet vanaf scratch, maar borduur voort op deze schema’s.
  • Zorg voor een goede aansluiting met de Nederlandse Taxonomie: zowel qua elementdefinitie als qua omschrijving;
  • Beperk het RGS tot de kern, in ieder geval in eerste instantie. Probeer niet meteen alle specifieke en/of uitzonderingssituaties af te dekken (en vermijd dus in dit stadium discussies over branchespecifieke zaken); leg jezelf daarbij geen onnodige beperkingen op;
  • Zorg voor voldoende stabiliteit rond het RGS, zodat eventuele wijzigingen in de taxonomie, als het ook maar even kan, zonder complicaties worden vertaald in RGS en dat bedrijven niet hoeven te gaan aanpassen in hun basisadministraties;
  • Zorg omgekeerd ook voor voldoende awareness bij de uitvragende partijen, zodat zij hun uitvraag zoveel mogelijk baseren op de bestaande RGS;
  • Zorg ervoor dat het schema ook kan worden ingezet bij andere rapportages (banken, fiscaal etc.)
  • Bouw ruimte in voor flexibiliteit en uitbouw (extensibility) voor branches etc.
  • Zorg voor voldoende aandacht voor implementation guidelines, in combinatie met voorlichting en opleiding over het juiste inhoudelijke gebruik van de standaard (zodat geen inhoudelijk verschillende implementaties ontstaan); dit kan onder meer worden bereikt door:
    • Aansluiting bij de opzet van bestaande grootboek rekeningschema’s (decimale stelsel)
    • Goed (in de context en zoveel mogelijk zelfstandig) leesbare grootboekomschrijvingen
    • Goed bruikbare referentiecodes, waarmee op eenvoudige wijze aansluitingen en controles kunnen worden gedefinieerd

Werkgroep ineenschuiven mappingschema’s

Op basis van de eerste eis zijn in een werkgroep van softwareleveranciers en eindgebruikers een drietal standaard rekening- en mappinschema’s in een basisschema samengevoegd (Caseware, PM Report en Deloitte). Hoewel de uitgangspunten hetzelfde zijn (Besluit Modellen Jaarrekening, de Richtlijnen voor de Jaarverslaggeving en later ook de Nederlandse Taxonomie) bleken de rapportage-elementen van de verschillende rapportagesoftwareleveranciers niet helemaal op elkaar aan te sluiten. Verschillende codestructuren, omschrijvingen en soms ook verschillende uitwerkingen op basis van klantbehoeften  gaven uiteindelijk een mooi overzicht van waaruit de generieke grootboekdefinities konden worden samengesteld. Daarbij bleek dat er niet alleen behoefte was aan een financieel rekeningschema, maar ook aan een eenduidige manier van omschrijven en een goede referentie op basis van semantische codes, waarmee standaard aansluitingen en controles kunnen worden gedefinieerd.

Referentie Grootboekschema

RGS bestaat uit vijf hiërarchische niveaus: verantwoording, hoofdrubriek, rubriek, rekening en mutatie. Het is mogelijk om het rekeningschema minder of meer gedetailleerd weer te geven. Voor kleine ondernemingen is level 1 (bestaande uit de eerste 4 niveaus) voldoende en bestaat RGS uit 800 regels. Grootboekrekeningen op niveau 4 eindigen altijd op 00. Op level 2 worden ook de mutatierekeningen geopend, eindigend op 0.

Per standaard- grootboekrekening zijn de volgende attributen gedefinieerd: rekeningnummer, omschrijving en referentiecode. De referentiecode is samengesteld uit vier referentietabellen, waarin een drie-letterige code en een omschrijving zijn opgenomen.  Door een combinatie te maken van een uniek element uit de hoofdrubriek-referentie tabel, een uniek element uit de rubriek-referentietabel, een uniek element uit de rekening-referentietabel en een uniek element uit de mutatie-referentie-tabel ontstaat een grootboekrekening. De omschrijving van de grootboekrekeningen is zodanig samengesteld uit de omschrijvingen van de referentietabellen, dat de context van de grootboek-rekening uit de omschrijving kan worden afgeleid. Hierdoor zijn de rekeningen op die manier strak omschreven.

Aansluiting met de Nederlandse Taxonomie

Nadat op basis van bestaande schema’s de grootboek elementen (op basis van samengestelde referentiecodes en hun omschrijvingen op hoofdrubriek, rubriek en toelichting niveau) zijn gedefinieerd is vervolgens aansluiting gezocht bij de Nederlandse Taxonomie. Hiervoor zijn de volgende twee taxonomieën gebruikt:

  • NT7.0_20130527 (Kamer van Koophandel, Belastingdienst en Centraal Bureau voor de Statistiek)
  • BT2013 (de bankentaxonomie van de Rabobank, ABNAMRO, ING)

Deze taxonomieën bestaan uit 44 verschillende entrypoints, oftewel 44 verschillende rapportages, variërend van de taxonomie voor de inrichting en publicatie van de jaarrekening voor grote ondernemingen tot de taxonomie voor de aangifte omzet belasting. Per rapportage is niet alleen gekeken naar de elementen maar ook naar de omschrijvingen (die zoveel mogelijk zijn overgenomen in de referentietabellen). Vervolgens is per entrypoint de cross reference gelegd met de referentie code volgens RGS. Hieruit blijkt in ongeveer 85% een één op één relatie te bestaan met de RGS tabel, in een aantal gevallen moeten elementen worden samengeteld, maar in een aantal gevallen zal nog een uitsplitsing moeten worden gemaakt. Dit geldt met name voor de kasstroomoverzichten, waarbij ik de relatie nog niet heb gelegd. De vraag is of dit nodig is, want feitelijk is een kasstroomoverzicht een andere presentatie van de elementen uit de balans en winst- en verliesrekening met een nadere detaillering weliswaar, maar er zijn geen nieuwe grootboekrekeningen voor nodig en er valt er ook geen af. Bij het leggen van die cross references vielen wel één belangrijk aspect op:

De term “Overige …” in de sheets kunnen op twee manieren worden geïnterpreteerd (getagt):

  •    Direct door het hanteren van de letterlijke omschrijving dus bijv. overige personeelskosten
  •    Indirect dus alle andere personeelskosten die in de elementen daarboven zijn uitgesloten

     

Hierna zal op de verschillende aspecten van het mappen van de rekeningen met de taxonomie entrypoints worden ingegaan, waarbij ook op het fenomeen direct of indirect mappen zal worden ingegaan.

 

Een aanzet voor modellering- en mappingprincipes

We zijn nu een flink eind met een eerste versie van het RGS, maar we onderkennen dat het nodig is om een aantal  principes te formuleren over de modellering en vooral de manier waarop de mapping moet worden uitgevoerd. We geven daarvoor hier een eerste aanzet. Nota bene: nog niet voor alle principes is duidelijk welke keuze moet worden gemaakt, hierover is gedachtevorming en vooral ook nader onderzoek noodzakelijk, bijvoorbeeld op een aantal voorbeeldadministraties- en rapportages.

Hiërarchie impliceert optelling

We constateren dat de hiërarchie die in de structuur van het RGS zit niet alleen optellingen impliceert, maar dat die ook expliciet gemaakt moeten worden. De manier waarop dat geformaliseerd moet worden (dus begrijpelijk voor software) staat nog open voor discussie. Een manier kan zijn een pragmatische toepassing van de calculation linkbase uit de XBRL specificaties. Dit kan, als we de eigenschappen van debit en credit, min- en plus attributen achterwege laten en we niet over contexten met verschillende periode-eigenschappen heen gaan rekenen. [MROS]: mogelijk kunnen we een nieuwe arcrole maken voor de calculation linkbase, die die specifieke eigenschappen negeert.  Een alternatief is het werken met de formula linkbase, hoewel die wat complexer is om te implementeren.

Labeling van rubrieken bevat hiërarchie-informatie

In het RGS zien we dat de labeling van de rubrieken (de kinderen in de hiërarchie, ofwel de bladeren in de boom) een label krijgen waarin voor een deel verwezen wordt naar de ouders. Dat kan in sommige gevallen ook niet anders, afschrijvingen in zichzelf is nietszeggend, afschrijvingen gebouwen al meer zeggend. (XBRL) data-modellering puristen zullen hier wat bezwaar tegen hebben, in hun ogen mag een nam geen ‘presentatie’ (lees: hiërarchie) eigenschappen hebben. Wij denken dat het voor dit doel (een eenduidig stabiel koppelschema, waarin elementen niet van plaats zullen veranderen) geen probleem is. Hiervoor is bewust gekozen om het RGS zo eenvoudig mogelijk leesbaar en dus toepasbaar te maken.

‘Mappen’ naar overige

We geven in dit  stuk de interpretatie van de post ‘overige …’ zoals die in de entrypoints voorkomt. We onderscheiden een directe en een indirecte mapping van grootboekrekeningen.

Bij een directe mapping wordt de post ‘overige kosten’ in een boekhouding direct gemapt op ‘overige kosten’ in RGS.

Van een indirecte mapping is sprake als er bepaalde posten binnen een hiërarchie niveau  wel (direct) worden gemapt, maar niet allemaal. De overige posten, die wel benoemd zijn in het RGS als onderdeel van een hiërarchie niveau, worden in de rapportage als ‘overige’ aangeduid en worden bepaald door het totaal van het hiërarchie niveau verminderd met de posten binnen dit hiërarchie niveau die wel direct zijn gemapt. Deze ‘overige’ posten worden dan indirect gemapt op ‘overige kosten’. Letterlijk zou het betekenen: alle posten die een bedrijf wel bijhoudt voor een bepaald niveau, maar niet in het RGS genoemd zijn.

We vinden het een belangrijk onderscheid, omdat het tot een andere interpretatie kan leiden van een bepaald begrip, met name als de mappings naar de rapportages verschillen.

Een goed voorbeeld is het begrip ‘Personeelskosten’.  De personeelskosten kunnen voor een bepaalde rapportage uitgesplitst worden naar:

  • Lonen
  • Salarissen
  • Overige personeelskosten

Voor een andere rapportage kunnen ze uitgesplitst worden naar:

  • Lonen
  • Salarissen
  • Sociale lasten
  • Opleidingskosten
  • Overige kosten

In het RGS wordt dan opgenomen:

  • Lonen
  • Salarissen
  • Sociale lasten
  • Opleidingskosten
  • Overige kosten

De mapping is dan niet triviaal:

Voor de eerste rapportage ziet de mapping er als volgt uit (inclusief fictieve waardes):

  • Lonen: Lonen 100
  • Salarissen: Salarissen 150
  • Overige kosten: sociale lasten + opleidingskosten + overige kosten: 300

Voor de tweede rapportage als volgt:

  • Lonen: Lonen: 100
  • Salarissen: Salarissen: 150
  • Sociale lasten: Sociale lasten: 100
  • Opleidingskosten: opleidingskosten: 100
  • Overige kosten: overige kosten: 100

Best spannend, want wat gebeurt er nu als een bedrijf bijvoorbeeld de opleidingskosten als onderdeel van de verkoopkosten boekt? We kunnen dit ondervangen door eerst alle personeelskosten onder deze rubriek te boeken en daarna een deel door te berekenen naar de verkoopkosten. Maar dan moeten we wel een extra element definiëren voor dit soort doorberekende kosten om de aansluiting met de winst- en verliesrekening te kunnen behouden.

We zouden met betrekking tot dit probleem de volgende principes kunnen formuleren:

  • De informatie moet gekoppeld kunnen worden aan verschillende hiërarchische niveaus: als een bedrijf alleen personeelskosten bijhoudt zonder verdere uitsplitsing, dan moet hij op dat niveau kunnen koppelen.
  • Als een bedrijf een deel van een uitsplitsing wel bijhoudt, maar een deel niet, dan moet dat overige deel naar een ‘overige’ post kunnen worden geboekt. Ieder hiërarchisch niveau in het RGS heeft daarom een aparte, unieke ‘overige’ post nodig.

Stroomoverzichten: selecties uit een deel van de boekingen, of apart definiëren?

We hebben het over rapportages waarin het belangrijk is de aard van de mutaties van balansposten te kennen, in plaats van alleen de saldering van die mutaties in een balanspost (of Verlies en winstrekeningpost?). Vaak genoemd worden kasstroomoverzichten, maar ook voorraadmutaties komen langs. We zien daarin twee mogelijkheden om deze uit de boekhouding te halen:

  • Mutaties in zichzelf vormen een deel van de boekhouding en worden daarmee vastgelegd. Als op een bepaald kenmerk van de mutaties geselecteerd kan worden uit die vastleggingen, dan kan al een stroomoverzicht gemaakt worden. Een voorbeeld zijn de voorraadmutaties: alle aangekochte voorraden samen onderscheiden van alle gebruikte voorraden, onderscheiden van correcties daarop, geven een goed beeld van hoeveel verbruikt is de productie. Bij het samenvoegen van de mutaties in de proef- en saldibalans worden deze afzonderlijke mutaties gesaldeerd en verdwijnt dat inzicht. Mappen vanuit de proef- en saldi- balans maakt inzicht daarin dus lastig, mappen op een selectie van de mutaties weer wel.

    We hebben het dan wel nodig dat we de software kunnen vertellen welke selectie we willen. Het mechanisme daarvoor is nog onduidelijk.
  • Mutaties kunnen ook als afzonderlijk element (een niveau onder de rubrieken) worden opgenomen in het RGS. Dat wil zeggen dat we boeken op mutaties in plaats van op een rubriek. Een voordeel hierbij is dat de mutaties op meer kenmerken dan alleen ‘afboeken’ of ‘bijboeken’ mogelijk is (een voorbeeld?). Dat is in principe eenvoudiger dan het selectiemechanisme zoals dat in het eerste punt beschreven werd, maar vraagt meer ‘boekingsinspanning’ en sluit daarom wellicht minder aan op de gangbare praktijk. Naar ons idee zullen mutaties met name bij de grotere bedrijven worden gebruikt. In de verschillende taxonomie entrypoints  zie je dat ook zo terug komen. Hoe om te gaan met mutaties? De bovenliggende rekening bevat alleen het beginsaldo en het eindsaldo wordt bepaald door dit beginsaldo +/- de onderliggende mutaties, wat weer de uitgangspositie voor het beginsaldo voor het komend jaar wordt. Dit lees ik ook zo in de taxonomie, waarbij dit eindsaldo als berekend veld op het einde van zo’n reeks opnieuw wordt genoemd. Die heb ik niet meer opgenomen, omdat dit dus feitelijk, zoals hierboven is weergegeven wordt berekend en daar mag niet op geboekt worden.

Gebruik van correctieposten

Met betrekking tot salderingen: als een bedrijf bepaalde opbrengsten of kosten saldeert op een grootboekrekening, dan gaat informatie verloren die voor sommige rapportages wellicht van belang is. Een mogelijkheid is om ook correcties op vrijwel alle posten  te kunnen mappen. Iedere hiërarchisch niveau heeft dan een correctiepost nodig.

 

Het volgende voorbeeld verduidelijkt:

Een rapportage bevat de volgende elementen

  • Overige opbrengsten
    • …
    • Loonsubsidies
  • …
  • Personeelskosten
    • Lonen
    • Salarissen
    • …
    • Overige personeelskosten

Een andere rapportage is dan weer als volgt opgebouwd:

  • Overige opbrengsten
    • Geen uitsplitsing (ongedefinieerd)
  • Personeelskosten
    • Geen uitsplitsing (ongedefinieerd)

Stel dat een bedrijf zijn loonsubsidies voor die laatste rapportage gewoon saldeert in zijn personeelskosten. Hoe zou dan het RGS er uit moeten zien om dat sluitend te krijgen? We gaan er even van uit dat de loonsubsidies direct gesaldeerd worden door het bedrijf in de loonkosten.

  • Overige opbrengsten
    • …
    • Loonsubsidies
  • Personeelskosten
    • Lonen
    • Salarissen
    • …
    • Overige personeelskosten
    • Correctiepost personeelskosten

Dat die laatste post nodig is blijkt, uit de mapping:

Rapportage 1:

  • Overige opbrengsten 110
    • …: … 100
    • Loonsubsidies: loonsubsidies 10
  • Personeelskosten: 300
    • Lonen: lonen 100
    • Salarissen: salarissen 100
    • …: … 100
    • Overige personeelskosten: overige personeelskosten 100
    • Correctiepost personeelskosten:  Loonsubsidies 10

In rapportage 2:

  • Overige opbrengsten: 100
    • …: …: 100
    • Loonsubsidies: leeg (geen mapping)
  • Personeelskosten: 290
    • Lonen: lonen 90 (inclusief gesaldeerde loonsubsidies)
    • Salarissen: salarissen 100
    • Overige personeelskosten: overige personeelskosten 100
    • Correctiepost: leeg

De correctiepost kan dienen om extracomptabele correcties uit te voeren voor bepaalde rapportages, met name als bedrijven zaken niet bijhouden op een bepaald detailniveau.

Een alternatieve benadering (en ook een belangrijk discussiepunt) is dat het RGS als definitie leidend is: dat wil zeggen dat als in het RGS staat dat loonsubsidies onder overige opbrengsten horen, de boeking van de loonsubisidies ook daadwerkelijk gebeurt onder ‘overige opbrengsten’. 

Conclusie

Hoe goed RGS ook is gedefinieerd; het mappen met alle entrypoints was niet eenvoudig omdat je zaken soms op meerdere manieren kunt interpreteren in de taxonomie. Dit vereist nog wel het nodige reviewwerk door de uitvragende partijen. Maar daarmee bewijst het RGS nu al zijn nut omdat ik toch wel de nodige problemen voorzie als gebruikers zelf hun rekeningschema zouden moeten mappen. RGS stimuleert absoluut een betrouwbare rapportage aan de uitvragende partijen.

Categorie

Handleiding