De laatste tijd zijn wij bezig geweest met het ontwikkelen van data-analyse rapportages voor de NOW regeling. Wij schreven er al eerder over in onze nieuwsbrief. De grootste uitdaging was om een uniform data-model te ontwikkelen en zoveel mogelijk gebruik te maken van de data die kantoren al bezitten. Zo maken we gebruik van auditfiles en de mappingschema’s uit verschillende jaarrekeningsoftware zoals CaseWare, Unit 4 Audition, Infine of MakeLifeEasier (MLE). In deze software moet je het grootboekrekeningschema van de klant koppelen of toewijzen aan de jaarrekeningposten, zodat de jaarrekening en de publicatiestukken gemaakt kunnen worden. Deze mappingschema’s uit de jaarrekeningsoftware zijn verschillend van elkaar doordat ze andere codes en omschrijvingen gebruiken. Dit vormt een uitdaging voor data-analyse.
In onze data-analyses hebben wij dat probleem opgelost door te kiezen voor ReferentieGrootboekSchema (hierna: RGS). RGS is door softwareleveranciers, koepelorganisaties en de overheid ontwikkeld. Je kunt RGS gebruiken als schakelschema tussen het grootboekschema van de klant en jaarrekeningposten. Wij vertalen het mappingschema van de verschillende jaarrekeningpakketten naar RGS codes. Hiermee voorkomen wij dat we voor de verschillende jaarrekeningpakketten een specifieke versie van onze data-analyse moeten maken.
Voordelen RGS
Het grootste voordeel van RGS is dat je efficiënter gegevens kunt uitwisselen tussen verschillende programma’s en partijen. Je hoeft niet opnieuw de vertaalslag te maken tussen het klantspecifieke grootboekschema en de jaarrekeningposten. De RGS codes kun je vaak direct al in de bron (het administratiepakket) instellen, maar we zien helaas dat daar nog weinig gebruik van wordt gemaakt. Met RGS kun je het verschil tussen de rapportage uit de financiële administratie en de jaarrekening verkleinen. Met een RGS rekeningschema kun je efficiënter ondernemingen vergelijken en ben je klaar om in de toekomst slimme analyses over alle data te kunnen doen.
Zijn er dan ook nadelen aan RGS?
Er zijn al zes verschillende versies van RGS verschenen. De zevende versie (RGS 3.3) is op dit moment als conceptversie uitgebracht. Vorige week liepen wij tegen versieproblemen aan. Enkele grootboekrekeningen die in RGS 3.0 gemapt waren, konden niet in de RGS 3.2 structuur vertaald worden. In RGS 3.0 is bijvoorbeeld de koppelcode voor Elektra in de huisvestingskosten WBedHuiElk, terwijl dit in RGS 3.2 WBedHuiGweElk is geworden. De code WBedHuiElk is daarmee komen te vervallen. Gelukkig heeft RGS hier wel vertaaltabellen voor, al blijft het toch onhandig. Een ander nadeel is dat RGS niet verplicht is en die vrijblijvendheid zorgt ervoor dat het nog maar weinig wordt toegepast.
Mocht je meer informatie willen over RGS of data-analyse neem dan contact met mij op.
Thijs de Nijs