default logo

Data-analyse voor Auditors – Deel 3

Deze blogpost vormt het derde deel van de 5-delige serie: ‘Data-analyse voor Auditors’. Wij hebben deze serie ontwikkeld omdat wij vaak de vraag krijgen hoe auditors data-analyse in de praktijk kunnen inzetten.

In dit derde deel bespreek ik wat wij als auditors graag willen weten: Hoe waakt het controleraamwerk ervoor dat de data betrouwbaar tot stand komt?

De toegang tot serveromgevingen en applicaties is hierin een belangrijke bouwsteen. Nog belangrijker is de vraag of de geautomatiseerde ‘controls’ die in bedrijfskritieke applicaties zijn ingebouwd wel of niet werken. Met andere woorden: welke ‘gesloten deuren’ staan open?

In de vorige aflevering van deze serie besprak ik de eerste twee toepassingen van data-analyse in de planingfase van het data-driven controleproces (grasduinen en risico-inschattende werkzaamheden). Dit deel gaat over de derde en laatste toepassing van data-analyse in de planningfase: Onderzoeken ITGC en Application Controls.

ITGC

In onze mindset vormen de IT General Controls (ITGC) een duidelijke randvoorwaarde voor het zinvol toepassen van data-analyse, maar zeker geen vereiste voorwaarde. Wij weten als geen ander dat in 90% van de MKB ondernemingen tussen ‘middelgroot’ en ‘groot’ geen sprake is van een geformaliseerde, intern getoetste en geëvalueerde ITGC setting.

In onze beleving kunnen (bewuste) fouten in de verwerking van transacties door de juiste mix van analyses worden vastgesteld. Immers, hoeveel relevante ITGC leiden uiteindelijk tot materiële fouten in de jaarrekening?

Door transactiestromen te rubriceren en te koppelen aan de ‘niet werkende ITGCs’ kunnen we inzoomen op de vraag: wat is de de mogelijke, materiële impact op de posten van de jaarrekening indien ITGC 1, 2, of 3 niet werken (individueel of in samenhang)?

Door transactiestromen te rubriceren en te koppelen aan de ‘niet werkende ITGCs’ kunnen we inzoomen op de vraag: wat is de de mogelijke, materiële impact op de posten van de jaarrekening indien ITGC 1, 2, of 3 niet werken?

Afhankelijk van de casus bestaat deze mix uit:

  • Het toetsen van feiten (data) aan interne en externe normen;
  • Het inzetten van verbandscontroles;
  • Het uitvoeren van detailcontroles.
Voorbeeld 1

Binnen een MKB+ bedrijf is Kees de persoon die verkooporders goedkeurt, waarbij kortingen buiten de vastgestelde range in het verkoopordersysteem alleen goedgekeurd mogen worden door Wim.

Wij hebben gemerkt dat het in de praktijk vaak voorkomt dat een verkoopkorting buiten de range niet altijd wordt goedgekeurd door Wim. Bijvoorbeeld omdat Wim op vakantie was of omdat Kees, om welke reden dan ook, geen goedkeuring gevraagd heeft aan Wim.

Aan de hand van een analyse kunnen wij zien dat zowel Kees als Wim hebben ingelogd in de verkoopapplicatie, echter weten wij dat de kans aanwezig is dat Kees heeft ingelogd op het account van Wim om de korting goed te keuren (de post-it met het password van Wim hangt op zijn beeldscherm).

De eerste vraag die hierbij komt kijken is: Is er een aanvullende interne controle waarbij Wim elke dag een overzicht krijgt met alle verkooporders met verkoopkortingen buiten de range? Vaak is dit niet het geval. Wat nu?

Wat is nu precies ons ‘detectierisico’? En wat is de kans op een materiële fout in de jaarrekening nu duidelijk is geworden dat Wim niet alle kortingen buiten de range hoeft te hebben goedgekeurd? De hogere kortingen en de lagere omzet zijn correct verantwoord; niets fout dus in de jaarrekening, maar wel omzet misgelopen, tenzij…

Tenzij achteraf kan worden aangetoond dat de kortingen onrechtmatig zijn toegekend en je je cliënt mogelijk een aanvullende rekening kunt sturen. Deze tenzij wil je in kaart kunnen brengen, toch?

Ten eerste is het belangrijk om na te gaan hoe vaak Kees de interne goedkeuring bewust heeft omzeild. Om deze omvang te kwantificeren kan er een selectie gemaakt worden van alle verkoopfacturen en bijbehorende kortingen die zijn goedgekeurd door Wim. Deze verkoopfacturen kunnen we bijvoorbeeld per afnemer of per product visualiseren.

Vervolgens kunnen we analyseren wie wel hogere kortingen krijgt voor dezelfde producten en wie niet. Is er al een trend zichtbaar? Krijgen bepaalde afnemers altijd die hogere korting? Deze handige overzichten bespreken we uiteraard met Wim en zijn sales manager om erachter te komen wat de oorzaak is. De interne follow up en de mogelijke impact op de omzet en debiteuren is dan onderdeel van het werkprogramma.

Voorbeeld 2

Een andere toepassing van ITGC en data-analyse is een zogenaamd Windows Active Directory script. Met behulp van twee datafiles met de logs van alle computers en gebruikers zijn handige views te maken over bijvoorbeeld:

  • Welke Windows versies zijn (nog) actief?
  • Wie logt in op welke omgeving?
  • Hoe ziet het password beleid eruit?
  • Hoevaak wordt er door welke gebruiker ingelogd?

Uit het combineren van bovenstaande voorbeelden zou kunnen blijken dat Wim twee keer zo vaak heeft ingelogd als Kees, wat zou kunnen bevestigen dat Kees inderdaad ingelogd heeft op het account van Wim om korting goed te keuren. Verder kunnen we door dit script te koppelen aan de salarisadministratie ook eenvoudig nagaan of medewerkers die uit dienst treden wel tijdig worden afgemeld uit de Active Directory omgeving.

Het geheel van deze snelle doorkijkjes in de Active Directory omgeving geeft geen keiharde assurance, maar geeft ons wel een duidelijk beeld over hoe serieus het management omgaat met het beheren van de (ICT-)processen. De onderstaande afbeelding geeft een illustratie van een analyse zoals hierboven beschreven.

Application Controls

In een toenemend aantal systemen zitten slimme application controls die de Do’s en Don’ts regelen. We vergelijken deze controls altijd met trafficmanagers; wat gaat door en wat gaat niet door? Ook het vraagstuk van toegang tot applicaties valt hieronder.

Belangrijke uitgangspunten bij het testen van application controls zijn de onderliggende business rules. Op basis van SOLL (normen) en IST vergelijkingen kunnen we transacties ‘reperformen’.

Een data-driven manier om de werking van application controls te testen is de business rule die ten grondslag ligt aan de application control te reperformen door de opdracht te geven: ‘Laat mij alle transacties zien die NIET aan deze business rule voldoen’. Als hier transacties uit naar voren komen betekent dit in potentie dat de betreffende application control zijn werk niet heeft gedaan.

Voorbeeld 1:

Consistentie in boekingen, voorraad en kostprijs wordt afgedwongen door een application control, maar werkt dit ook?

Dit kunnen we onderzoeken door bijvoorbeeld de uitgaande goederen te waarderen tegen de gecontroleerde VVP (SOLL) en deze te vergelijken met de verantwoorde kostprijs omzet (IST). De afwijking tussen de SOLL en IST dient vervolgens verder onderzocht te worden.

Voorbeeld 2:

Creditnota’s worden alleen toegekend als de retouren in het magazijn zijn geaccepteerd en de magazijnmanager de retouren heeft goedgekeurd in het systeem. Deze ‘relatie’ wordt bewaakt door een application control.

Met behulp van data-analyse kunnen we snel onderzoeken voor welke creditnota’s geen bijbehorende retour is geboekt. Uiteraard kunnen we ook zien door wie en wanneer alle taken uitgevoerd zijn.

Met behulp van data-analyse kunnen we snel onderzoeken voor welke creditnota’s geen bijbehorende retour is geboekt

Overigens komen wij ook situaties tegen waarin 9 van de 10 application controls naar behoren werkt. Het bijhorende ‘hoog’ interne controlerisico wordt dan door een maximale invulling van ons ‘detectierisico’ naar ‘laag’ teruggebracht.

Volgende week

In de volgende aflevering bespreek ik de toepassing van data-analyse in de controlefase, waarbij ik in het bijzonder stil zal staan bij het ‘gegevensgericht’ controleren van de werking van interne beheersingsmaatregelen.

WELLICHT OOK INTERESSANT VOOR U:

Laat een reactie achter

*

Send this to a friend