Standaard analyses op auditfiles

1. De uitdaging van standaard analyses op auditfiles

De uitdaging in het standaardiseren van analyses, is het aansluiten van nieuwe databronnen op de gemaakte oplossingen. Om een dashboard te kunnen hergebruiken dient de onderliggende dataset in het exact hetzelfde formaat aangeleverd te worden. Maar hoe standaard zijn de auditfiles?

De auditfile is rond de millenniumwisseling geïntroduceerd door de belastingdienst. Het doel van de auditfile was om een standaard te maken voor het uitwisselen van diverse soorten data; financieel, kassasystemen, salarissen en zelfs rittenregistraties. De data is opgeslagen in XML-formaat en je herkent een financiële auditfile aan de .xaf extensie. In deze blog focussen we op de financiële auditfile.

Hoewel het idee van de auditfile goed is, blijkt de praktijk weerbarstiger. De auditfiles zijn namelijk niet zo standaard als we denken. Tussen de diverse versies van auditfiles zijn veel verschillen waar te nemen. In de loop van de jaren zijn er meerdere versies van de auditfile uitgebracht, waarbij de nieuwere versies meer data bevatten dan oudere versies. Omdat je niet van tevoren weet welke versie de klant kan exporteren, ben je verplicht om rekening te houden met meerdere versies. Hier vind je een overzicht van de verschillen per auditfile.

Je kan dit probleem vergelijken met de volgende situatie. Stel je voor dat je een wereldreiziger bent die verschillende landen bezoekt, elk met zijn eigen valuta. Bij elke grensovergang moet je je geld omwisselen naar de lokale valuta. Dit is tijdrovend, verwarrend, en je bent voortdurend bezig met het berekenen van wisselkoersen. Wat als er 1 valuta zou zijn, die in elk land gebruikt wordt? Reizen zou direct een stuk makkelijker worden. Je hoeft niet te stoppen bij elke grens om je geld om te wisselen of te worstelen met de verschillende wisselkoersen.

Dit is vergelijkbaar met het standaardiseren van data uit verschillende formaten tot een uniform datamodel. Zonder standaardisatie, is het alsof je steeds weer je data moet omwisselen om te passen bij de eisen van elk nieuw “land” (oftewel een nieuw softwareprogramma of auditfile).

2. De oplossing?

Om deze uitdaging te tackelen is het noodzakelijk om een ETL-proces te ontwikkelen die verschillende versies van auditfiles op dezelfde manier kan inlezen. Een ETL-proces bestaat uit het importeren en transformeren van (ruwe) gegevens, om deze vervolgens op te slaan in opgeschoonde datasets. Het doel van de scripts is om data uit de auditfiles te transformeren tot een uniform datamodel. Dit datamodel dient als basis voor de standaard analyses en dashboards. Het ontwerp van dit financiële datamodel is leidend voor het opzetten van het ETL-proces. Het doel is om de verschillende auditfile versies aan te laten sluiten op dit datamodel.

Een bijkomend voordeel is dat je dit ETL-proces kan automatiseren. Je zou bijvoorbeeld de inleesroutine kunnen verbinden aan een SharePoint omgeving, zodat nieuwe geüploade auditfiles automatisch worden verwerkt. Hierdoor zijn je analyses en dashboards altijd up-to-date.

3. Bouwen van een universeel financieel datamodel

Het datamodel bestaat uit tabellen en kolomnamen en de relaties hiertussen. Het voordeel van het datamodel ten opzichte van de ruwe data is dat dit datamodel altijd hetzelfde is vormgegeven. De volgende afbeelding laat een voorbeeld zien van een standaard financieel datamodel.

Dit is vergelijkbaar met het converteren van vreemde valuta naar onze eigen valuta’s, zoals beschreven in de inleiding. We zorgen ervoor dat data altijd op dezelfde manier wordt opgeslagen, zodat de eindgebruiker niet bezig is met wat voor type auditfile gebruikt is.

4. De voordelen: efficiënt, herbruikbaar en herkenbaar.

Door dit proces te standaardiseren, bespaar je niet alleen tijd op je lopende project. Je bouwt een framework op dat gebruikt kan worden voor meerdere klanten. De meeste tijd die een data-analist heeft, wordt besteed aan data preparatie. Daardoor blijft een kleiner deel van de tijd over voor het maken van analyses, dashboards en automatisering. Door een ETL-script te ontwikkelen die meerdere auditfiles kan importeren, wordt bij iedere opdracht tijd bespaard. Deze tijd kan vervolgens besteed worden aan het opzetten van dashboards en analyses, wat de kwaliteit van de controle verhoogd.

Een ander voordeel is dat de (eind)gebruiker altijd werkt met een herkenbare dataset. De definities en kolomnamen liggen vast, waardoor het makkelijker is om de data te interpreteren. Het maakt dus niet meer uit of data uit ExactOnline, Twinfield, Unit4 of Snelstart komt, sterker nog, je zou deze bronnen kunnen combineren tot één geconsolideerd overzicht. Je kan hierover lezen in een eerdere blog: Financiële consolidatie met Python.

5. Analyses en dashboards.

Om een beeld te krijgen wat voor standaard analyses je zou kunnen uitvoeren op een auditfile:

• afloopcontrole debiteuren
• Volledigheids- en juistheidscontroles op omzet en kosten verkoop.
• Dubbele betalingen analyse
• Werkkapitaal analyse
• Omzet-, kosten- en marge analyses.

We hebben bij Zypp een aantal standaard dashboards ontwikkelt. Onze dashboards maken het mogelijk om op geconsolideerd niveau te rapporteren, of juist op specifieke entiteiten.

De rapportages kunnen door meerdere stakeholders gebruikt worden. Zo zien we vaak de behoefte om 1 geconsolideerde rapportage te hebben voor de CEO, maar ook gelijktijdig de behoefte voor enkelvoudige rapportages voor managers van een Business Line. Om beide behoefte te vervullen zetten we Row Level Security in om te kunnen beveiligen wie toegang heeft tot welke onderliggende data in de rapporten.

6. Conclusie

Wanneer je dit leest en je herkent in de uitdagingen, dan kan je hier iets aan veranderen. Dat kan op 3 manieren:

1. Door zelf een standaard datamodel en ETL-scripts te ontwikkelen.
2. Zypp biedt dienstverlening aan op dit gebied, om je op weg te helpen dit zelf te kunnen doen.
3. Zypp kan ook per opdracht auditfiles op ons standaard datamodel aansluiten. Daarbij zou het mogelijk zijn om direct gebruik te maken van de dashboards die hierboven te zien zijn.