Onderzoek naar het geautomatiseerd gegevensgericht testen ...€¦ · 1.4 Onderzoeksaanpak 9 1.5 Leeswijzer 9 2 Theoretische studie: inkoopproces, functiescheiding en vastlegging

1

Onderzoek naar het geautomatiseerd gegevensgericht

testen van functiescheidingen in het inkoopproces

Student

Ruud Schellekens M. Sc. (1172816)

Deloitte Accountants B.V.

E-mail [email protected]

Telefoon +31 (0)6 2078 9945

Begeleider Deloitte

Mr. Wouter-Bas van der Vegt RE



Telefoon +31 (0)6 5111 0742

Student

Drs. Suzanne de Vries (1005294)



Telefoon06 1258 0225

Begeleider VU

Dr. Bob van Kuijck RA RC


Telefoon +31 (0)6 5136 6752

2

Inhoudsopgave

Voorwoord 4

1 Inleiding 5

1.1 Aanleiding voor het onderzoek 5

1.2 Probleemstelling 8

1.3 Onderzoeksvragen 8

1.4 Onderzoeksaanpak 9

1.5 Leeswijzer 9

2 Theoretische studie: inkoopproces, functiescheiding en vastlegging 11

2.1 Inleiding 11

2.2 Inkoopproces 11

2.3 Functiescheiding 14

2.4 Minimaal benodigde informatie 16

2.4.1 Vastlegging van data in ERP-applicaties 16

2.4.2 Rijkdom van de informatie 17

2.4.3 Benodigde informatie voor testen functiescheiding in het inkoopproces 18

2.5 Conclusie 20

3 Theoretische studie: randvoorwaarden voor geautomatiseerde

gegevensgerichte analyse 21

3.1 Inleiding 21

3.2 Primaire vastleggingen in de ERP-applicatie 21

3.3 Organisatorische inrichting 22

3.3.1 Implementatie van functiescheidingen in logische toegangsbeveiliging 23

3.3.2 Logische beveiliging van de audit trail 24

3.4 Conclusie 24

4 Theoretische studie: analysetechnieken 26

4.1 Inleiding 26

4.2 Criteria ter beoordeling van automatische analysetechnieken 26

4.2.1 Integriteit van de data tijdens de analyse 27

4.2.2 Data Volumes en Formaten 27

4.2.3 Data Verwerking en Analyse 28

4.2.4 Analysesnelheid 29

4.2.5 Conclusie 29

4.3 Mogelijke analysetechnieken 30

4.4 Beoordeling Process Mining (ProM) en Linear Temporal Logic (LTL) 30

4.5 Beoordeling Audit Command Language (ACL) 32

4.6 Beoordeling SAS 33

3

4.7 Beoordeling Structured Query Language (SQL) 34

4.8 Analyse 35

4.9 Conclusie 38

5 Casusbedrijf 1: Het productiebedrijf 39

5.1 Inleiding 39

5.2 Beschrijving organisatie 39

5.3 Het inkoopproces bij het productiebedrijf 40

5.4 Aanwezige randvoorwaarden 40

5.5 Dataset definitie 42

5.6 Te testen functiescheidingen 43

5.7 Keuze analysetechniek 44

5.8 Resultaten 45

5.9 Analyse 51

5.10 Conclusie 52

6 Casusbedrijf 2: Het detailhandelsbedrijf 54

6.1 Inleiding 54

6.2 Beschrijving organisatie 54

6.3 Het inkoopproces bij het detailhandelsbedrijf 55

6.4 Aanwezige randvoorwaarden 55

6.5 Dataset definitie 56

6.6 Te testen functiescheidingen 57

6.7 Keuze analysetechniek 59

6.8 Resultaten 60

6.9 Analyse 62

6.10 Conclusie 63

7 Algemene analyse en conclusie 65

7.1 Inleiding 65

7.2 Discussie terugkoppeling van de resultaten naar het theoretische model 65

7.3 Randvoorwaarden 66

7.4 De gevolgde analyse aanpak 67

7.5 Resultaten 70

7.6 Gevolgen voor de jaarrekeningcontrole 71

7.7 Conclusie 73

Literatuur 75

4

Voorwoord

Deze scriptie is voor beide auteurs de afsluiting van de EDP-auditopleiding aan de Vrije

Universiteit van Amsterdam. De afgelopen jaren hebben wij zowel in de praktijk als aan de

opleiding ervaring opgedaan op het gebied van IT-auditing. Binnen dit vakgebied hebben wij

beide een focus op datagerichte controles. Een interessant werkgebied om diverse redenen.

In het algemeen, maar ook specifiek binnen de accountantscontrole moet steeds meer

rekening gehouden worden met kritische gegevens die in toenemende mate alleen in

digitale vorm beschikbaar zijn. Daarnaast kan de jaarrekeningcontrole ook efficiënter en

effectiever worden uitgevoerd door meer gebruik te maken van informatie die in applicaties

binnen een organisatie wordt vastgelegd. Grote hoeveelheden data zijn beschikbaar door

alle vastleggingen in applicaties. Door middel van (geautomatiseerde) analyse van deze data

is het mogelijk antwoord te geven op diverse vragen van de accountant in het kader van de

jaarrekeningcontrole.

Eén van de vragen die een accountant heeft ten aanzien van de jaarrekening, is hoe te

bepalen wat de impact is van geconstateerde functievermenging in de autorisatiematrix.

Deze scriptie geeft een handvat om antwoord te geven op deze vraag. Wij hopen hiermee

een bijdrage te hebben geleverd aan een meer efficiënte en effectieve uitvoering van de

jaarrekeningcontrole. Daarnaast hopen wij hiermee een voorbeeld te geven voor overige

data analyses die kunnen bijdragen aan het oplossen van vraagstukken voor de accountant.

Wij hebben met plezier gewerkt aan deze scriptie. Bij deze willen wij onze begeleiders, Bob

van Kuijck en Wouter-Bas van der Vegt, hartelijk bedanken voor hun kritische en

constructieve bijdrage in het proces om te komen tot dit eindresultaat.

5

1 Inleiding

Zoals in bijna ieder vakgebied inmiddels wel het geval is, is ook in het audit domein de

impact van automatisering merkbaar. Deze heeft niet alleen de functie als ondersteunende

software (bijvoorbeeld een tekstverwerker of een presentatieprogramma), maar ook steeds

vaker in de actieve rol als audit tool. Hierdoor ontstaat er een nieuwe manier om een audit

uit te voeren naast de traditionele werkwijze, evenals nieuwe mogelijkheden qua

auditmethodiek en -technieken. Voor onze scriptie zullen we een van die mogelijkheden

onderzoeken op haalbaarheid in de praktijk evenals het theoretische kader scheppen

waarbinnen deze nieuwe aanpak gegrond kan worden.

Dit hoofdstuk start met een paragraaf over de aanleiding voor ons onderzoek. Dit begint

met het in hoofdlijnen beschrijven van de huidige dominante audit aanpak in de

jaarrekeningcontrole en de beperkingen hiervan. Vervolgens zullen wij ingaan op de nieuwe

ontwikkelingen die spelen in het audit domein. Op basis van de nieuwe ontwikkelingen

formuleren we de onderzoeksvraag. De onderzoeksvraag wordt ingeperkt door een aantal

keuzes op het gebied van de scope. Tot slot van het hoofdstuk wordt de onderzoeksvraag

uitgesplitst naar de verschillende subvragen en wordt de structuur van de scriptie gegeven.

1.1 Aanleiding voor het onderzoek

Huidige dominante audit aanpak

Traditioneel gaat de accountant uit van de systeemgerichte controleaanpak. De accountant

bekijkt de organisatie en de risico’s daarin en maakt dan een controle aanpak die vaak

gericht is op het controleren van processen. Indien er in het proces gebruik gemaakt wordt

van IT-systemen en deze dominant genoeg aanwezig zijn, zal er een IT-auditor betrokken

worden in het controle proces. De IT-auditor test dan voor de betrokken IT-systemen of de

beheersingsmaatregelen in opzet, bestaan en werking effectief zijn geweest in de

controleperiode. Hiermee verkrijgt de accountant zekerheid over het bedrijfsproces en de

vastleggingen hierin waardoor deze minder gegevensgericht hoeft te controleren tijdens de

jaarrekeningcontrole (Kemp, 2006) en (NIVRA, 2009).

Deze strategie wordt als efficiënt beschouwd omdat hiermee gegevensgerichte controles

beperkt kunnen worden door de zekerheid verkregen uit de systeemgerichte controle op de

processen. Gegevensgerichte controles namelijk zijn vaak duur om uit te voeren vanwege de

grote hoeveelheid handmatig werk die hiermee gepaard gaat om elke casus te beoordelen.

De beperkingen van de huidige aanpak

Een beperking aan een systeemgerichte aanpak is dat deze geen kwantificering van het

risico geeft indien een beheersingsmaatregel niet effectief is geweest. Een voorbeeld

hiervan is het testen van de inrichting van functiescheidingen in een geautomatiseerde

omgeving.

6

Indien de geïmplementeerde functiescheidingsmaatregel niet effectief is geweest

gedurende de te controleren periode geeft dit nog geen uitspraak over:

1. hoe vaak zich een transactie heeft voorgedaan waarbij daadwerkelijk sprake was van

functievermenging in het proces (onrechtmatigheid in de procedure);

2. of er in geval van functievermenging ook daadwerkelijk sprake is van een niet

getrouw beeld van de informatie (was de transactie naast onrechtmatig ook

ongeoorloofd);

3. hoe groot de monetaire de impact is van de transacties.

Hierdoor is het risico voor het getrouwe beeld van de jaarrekening dus lastig te bepalen op

basis van alleen de systeemgerichte aanpak. Of de functievermenging zich daadwerkelijk

heeft voorgedaan en wat voor bedrag hier mee gemoeid ging, blijkt niet uit het ineffectief

zijn van een maatregel. Het schatten van het risico, de kans van optreden keer de verwachte

impact, is in dit geval moeilijk.

Om alsnog het risico te kwantificeren moet de accountant additioneel werk verrichten op de

gegevens en de diepgang van het onderzoek dus vergroten. Echter, uit zijn systeemgerichte

aanpak komen verder geen aanwijzingen over welke transacties mogelijk afwijkend zijn van

het standaardproces en dus extra aandacht verdienen. Hij moet eerst zoeken naar

transacties waarbij functievermenging is opgetreden alvorens hij kan nagaan of deze

transacties inderdaad ongeoorloofd waren. Om toch zekerheid te verkrijgen zou de

accountant een steekproef op de applicatie kunnen doen, waarbij de brondocumentatie

moet worden opgezocht en gecontroleerd. In de traditionele situatie betekent dit dat

handmatig facturen, bestellingen etc. gecontroleerd moeten worden. In een (hoog)

geautomatiseerde omgeving moet additioneel werk gedaan worden in de vorm van de

analyse van logbestanden en transactiebestanden om zo te achterhalen welke handeling

met betrekking tot een bepaalde transactie door welke medewerker is uitgevoerd.

De accountant kan op deze wijze de functievermenging constateren en, als de verbinding te

leggen is naar het transactiebedrag, ook de maximale fout berekenen voor de controle. In

beide omgevingen, traditioneel en geautomatiseerd, is dit traject van beschreven

werkzaamheden echter voor accountant en klant een erg arbeidsintensieve manier van

controleren.

Nieuwe ontwikkelingen met impact op het audit domein

Momenteel zijn een aantal ontwikkelingen waarneembaar in de techniek die hun impact

hebben op de jaarrekeningcontroles. Hieronder lichten we er drie uit die relevant zijn voor

de hierboven beschreven problematiek. De eerste ontwikkeling is de verschuiving van

vastleggingen in het proces van fysieke vastlegging naar digitale vastlegging. De tweede

ontwikkeling is het soms geheel ontbreken van fysieke vastleggingen bij internetgebaseerde

bedrijven. De derde is de toename in reken- en opslagcapaciteit.

7

Verschuiven van fysieke naar digitale vastlegging

Vaak vanuit efficiency oogpunt, is er bij veel bedrijven momenteel een digitaliseringslag

gaande. Trend is dat steeds vaker van fysieke documentatie wordt afgestapt. Een voorbeeld

hiervan is dat papieren facturen worden vervangen door digitale facturen (ANP, 2009). De

fysieke vastlegging op papier is aan het verdwijnen of wordt in ieder geval in de procesgang

slechts in digitale vorm, na inscannen, gebruikt.

Opkomst van volledig digitale bedrijven

Sommige bedrijven, internet gebaseerde bedrijven, hebben hun hele bedrijfsproces

gedigitaliseerd (Bolluijt, 2001). Het verkopen van digitale muziek via internet bijvoorbeeld of

het verkopen van online advertenties. Alle vastleggingen in het proces zijn digitaal. Er is

geen product meer dat opgeslagen hoeft te worden, geen pakbonnen en afgifte bewijzen of

facturen. Dit impliceert dat voor sommige bedrijven geen primaire fysieke vastlegging meer

te achterhalen is buiten de ICT-systemen om. In de controle aanpak van de accountant is het

in dit geval niet mogelijk om het systeem heen te controleren. De accountant zal hier

rekening mee moeten houden in zijn aanpak.

Uitbreiding van de reken- en opslagcapaciteit

Een derde ontwikkeling is dat de verwerkingscapaciteit en de opslagcapaciteit nog steeds

elke anderhalf jaar tot twee jaar ongeveer verdubbelen (Moore, 1965; Walter, 2005).

Hierdoor is het inmiddels mogelijk om grote volumes data te verwerken en op te slaan op

relatief goedkope en toegankelijke IT-middelen. Daarnaast zijn betere softwareprogramma’s

beschikbaar om deze datavolumes snel en effectief mee te doorgronden. Wellicht is het nu

mogelijk om geautomatiseerd gegevensgericht beheersingsmaatregelen te testen in

gevallen waar dit eerst niet efficiënt was of in gevallen waar de beheersingsmaatregel

gefaald heeft.

Evaluatie

De systeemgerichte controle aanpak heeft dus beperkingen indien de controle als conclusie

heeft dat niet alle beheersingsmaatregelen effectief waren. Het is dan lastig om het risico te

kwantificeren. In dit geval is additioneel handmatig audit werk nodig om het risico helder te

krijgen. Dit vergt veel extra tijd aan zowel de zijde van de accountants als aan de zijde van

de klant.

Echter, door nieuwe technieken in te zetten en gegevensgerichte testwerkzaamheden te

automatiseren is het wellicht mogelijk om de diepgang van de accountantscontrole en de

impact op de jaarrekening integraal vast te stellen. Dit vergt wel dat de te controleren

omgeving een digitaliseringgraad heeft dit hoog genoeg is. Omdat veel bedrijven

momenteel al aan het digitaliseren zijn, wordt deze aanpak in de toekomst alleen maar

relevanter. Voor sommige (vaak internetgebaseerde) bedrijven vindt al geen fysieke

vastlegging meer plaats. Dit vraagt om een onderzoek naar de haalbaarheid van het

geautomatiseerd gegevensgericht controleren.

8

1.2 Probleemstelling

Zoals in de inleiding aangegeven is het voor een accountant moeilijk om in de huidige

controle aanpak het risico voor de jaarrekening te bepalen indien de systeemgerichte

controleaanpak op sommige punten niet effectief blijkt te zijn. Daarom willen we het

volgende in deze scriptie onderzoeken:

Gegeven een bedrijf waarbij is vastgesteld dat functievermenging in het inkoopproces

mogelijk is opgetreden gedurende de audit periode, is de probleemstelling:

“Kun je uit de logbestanden en transactie data in de financiële administratie bepalen

of in de praktijk daadwerkelijk functievermenging heeft plaatsgevonden en wat zijn

de gevolgen hiervan voor de jaarrekeningcontrole?”

Deze probleemstelling zal beantwoord worden aan de hand van praktijksituaties. Hiervoor

nemen we praktijkcasussen van bedrijven die een ERP-applicaties in gebruik hebben.

Omdat dit onderzoek slechts een beperkte tijd kent, hebben we de volgende keuzes

gemaakt met betrekking tot de scope van het onderzoek:

1. In dit onderzoek beperken we ons tot het inkoopproces.

2. We beperken ons tot het testen van de beheersingsmaatregelen voor

functiescheiding en zullen dus geen andere maatregelen beoordelen.

3. In onze analyse beperken we ons tot twee datasets van verschillende bedrijven.

Gegeven de scope en onderzoeksvraag kunnen we een aantal onderzoeksvragen en

subvragen definiëren. Zie hieronder de structuur voor alle onderzoeksvragen en

bijbehorende hoofdstukken.

1.3 Onderzoeksvragen

In de nu volgende paragrafen zullen we de structuur van dit onderzoek en de diverse

onderzoeksvragen uiteen zetten. Het doel van deze scriptie is het onderzoeken of het

automatisch testen van functiescheidingen mogelijk is. De probleemstelling valt uiteen in de

volgende onderzoeksvragen tevens de volgende hoofdstukken:

• Wat is het theoretische referentiekader van het inkoopproces van waaruit we de

casussen zullen beoordelen? (Hoofdstuk 2)

• Welke randvoorwaarden moeten vervuld zijn in de organisatie en in de applicaties

om op opgetreden functievermenging te testen? (Hoofdstuk 3)

• Welke analyse technieken zijn er om geautomatiseerde gegevensgerichte analyses

uit te voeren voor functiescheidingen? (Hoofdstuk 4)

9

• Wat is het resultaat van toepassing van het theoretisch kader in de praktijk?

(Hoofdstuk 5 & 6)

In het laatste hoofdstuk, hoofdstuk 7, bekijken we of we de onderzoeksvraag kunnen

bevestigen dan wel weerleggen op basis van de resultaten van het onderzoek.

1.4 Onderzoeksaanpak

Omdat het uitvoeren van een gegevensgerichte functiescheidingscontrole, voor zover bij de

auteurs bekend, nog niet eerder is uitgevoerd is het pad daar naartoe per definitie een

onderzoekspad. Er is in de literatuur dus geen “best practice” te vinden om dit op te

baseren.

We hebben onze onderzoeksaanpak gebaseerd op de standaard aanpak voor data analyse

zoals gebruikelijk is binnen de data-analyse praktijk van Deloitte. Hierin hebben we de

volgende stappen onderkend:

1) Onderzoeken van de software pakketten die betrokken zijn bij het inkoopproces

2) Verkrijgen van het schema dat aangeeft waar in de applicatie de benodigde informatie

zit met betrekking tot de door ons gekozen functiescheidingen (zie hoofdstuk 2)

3) Extraheren/transporteren van de data uit de ERP-applicatie

4) Plotten van de ontvangen data naar de mogelijk te testen functiescheidingen in het

standaard inkoopproces (in het geval van incomplete of niet eerder geanalyseerde data)

5) Geautomatiseerd gegevensgericht testen van de functiescheidingen met behulp van

analyse software

6) Validatie van de resultaten met de gecontroleerde partij

Deze stappen zullen we aanhouden bij het uit te voeren onderzoek bij de twee

casusbedrijven in hoofdstuk 5 & 6.

1.5 Leeswijzer

We zullen beginnen met het scheppen van het theoretisch raamwerk in hoofdstuk 2. Dit

raamwerk dient als norm om de uiteindelijke analyseresultaten te kunnen plaatsen in een

context. In hoofdstuk 3 geven we de belangrijke randvoorwaarden die nodig zijn

geautomatiseerd gegevensgericht te controleren. Vervolgens geven we in hoofdstuk 4 een

theoretische vergelijking van de verschillende analysetechnieken die mogelijk zijn voor de

werkzaamheden. Op basis hiervan kan later een keuze gemaakt worden per casusbedrijf

voor de meest geschikte analysetechniek.

Nu het theoretische raamwerk in de eerste vier hoofdstukken is neergezet, kunnen we in

hoofdstuk 5 en 6 een beschrijving geven van de twee casusbedrijven. In deze hoofdstukken

zetten we per casusbedrijf uiteen wat de resultaten zijn van de toepassing van het

theoretisch kader in de praktijk. In beide hoofdstukken worden ook de gevolgen van deze

resultaten voor de jaarrekeningcontrole behandeld.

10

Tot slot zullen we de resultaten uit de casussen terugkoppelen naar de onderzoeksvraag in

hoofdstuk 7. Ook bediscussiëren we hier of de onderzoeksvraag beantwoordt kan worden

op basis van het onderzoek.

11

2 Theoretische studie: inkoopproces, functiescheiding en vastlegging

2.1 Inleiding

In dit hoofdstuk zullen we de basis leggen van de theoretisch achtergronden. Doel van het

theoretisch kader is om de onderzoeksresultaten die later uit de casussen met bedrijfdata

komen te kunnen plaatsen en te kunnen vergelijken in een vooraf gedefinieerde context.

De onderzoeksvraag voor dit hoofdstuk is dus gericht op het literatuur onderzoek en luidt:

Wat is het theoretische referentiekader van het inkoopproces van waaruit we de

casussen zullen beoordelen?

Het is belangrijk vooraf goed uit te denken welke informatie cruciaal is in het

geautomatiseerd gegevensgericht testen van de functiescheidingen. Hiervoor is het

allereerst nodig de stappen in het inkoopproces goed te kennen, maar ook om te weten wat

functiescheiding zelf inhoudt en waar dit belangrijk is in het inkoop proces.

De onderzoeksvraag voor dit hoofdstuk valt dus uiteen in de volgende subvragen:

• Hoe ziet het standaard inkoopproces eruit?

• Wat is functiescheiding?

• Welke functiescheidingen onderkennen we in het standaard inkoopproces?

• Wat zijn de benodigde informatie behoeften om de functiescheidingen in het

inkoopproces te kunnen testen?

De structuur van dit hoofdstuk is als volgt. In paragraaf 2.2 wordt het inkoopproces uiteen

gezet, gevolgd in paragraaf 2.3 door een uitleg over functiescheiding in het algemeen en

functiescheiding in het inkoopproces. Als dan duidelijk is op welke punten geautomatiseerd

gegevensgericht testen wenselijk is, wordt in de paragraaf 2.4 beschreven welke informatie

hiervoor benodigd is in de applicatie. Dit hoofdstuk wordt afgesloten met een conclusie.

2.2 Inkoopproces

Dit onderzoek richt zich specifiek op functiescheiding in het inkoopproces. (Weele, 2008)

definieert inkoop als volgt:

“Inkoop omvat de analyse, planning, implementatie en beheersing van activiteiten die

gericht zijn op het ontwikkelen, uitbouwen en onderhouden van de relaties met de

leveranciersmarkt ter bevrediging van de korte- en lange termijn inkoopbehoeften van een

onderneming, teneinde een optimale bijdrage aan de ondernemingsdoelstellingen te

bewerkstelligen.”

12

In deze definitie is inkoop een marktgerichte ondernemingsactiviteit die verder strekt dan

een zuiver uitvoerende en administratieve activiteit. Grofweg kan het operationele

inkoopproces in de volgende stappen onderverdeeld worden:

1. Impuls tot inkopen

2. Aanvragen van offerten

3. Bestellen

4. Goederenontvangst

5. Factuurcontrole

6. Factuurregistratie

7. Factuurbetaling

In deze stappen is te zien dat een initiatief tot aankoop wordt omgezet in een bestelling,

wat leidt tot een goederenontvangst en een factuur die betaald moet worden. Voor dit

onderzoek naar functiescheidingen laten wij het eerste deel van het proces buiten

beschouwing. In dit eerste stadium van het proces wordt de inkoopbehoefte gespecificeerd,

de leverancier(s) geselecteerd en wordt bepaald bij welke leverancier de bestelling

daadwerkelijk geplaatst zal worden. Vanaf het punt dat de bestelling wordt opgemaakt,

start het proces dat in dit onderzoek bekeken zal worden. Door naar dit tweede deel van het

inkoopproces te kijken, van bestelling tot en met factuurbetaling, onderzoeken we de

volgende onderdelen van het inkoopproces:

1. Aanmaken en verwerken van bestellingen

Nadat een keuze is gemaakt voor een bepaald product wordt de daadwerkelijke

bestelling aangemaakt na afgifte van goedkeuring door de geautoriseerde personen.

De bestelling wordt in de administratie verwerkt.

2. Registreren van de verplichting behorend bij de bestelling

De in de administratie verwerkte bestelling levert (geautomatiseerd) een

bijbehorende verplichting op aan de crediteur in kwestie.

3. Ontvangen van goederen of diensten

De bestelde goederen of diensten worden na controle op basis van de gegevens van

de bestelling in ontvangst genomen.

4. Verwerken en registreren van financiële transacties

De factuur wordt voldaan nadat door de geautoriseerde personen goedkeuring is

verleend om de betaling uit te voeren. Hierbij worden de factuurgegevens

vergeleken met de ontvangstgegevens en de gegevens van de bestelling.

Deze functies van het inkoopproces zijn tegelijkertijd de processtappen waarin

functiescheidingen essentieel zijn. Indien deze functies in handen zijn van slechts één enkele

persoon, is het voor die persoon gemakkelijk om te frauderen. Hier zullen we in meer detail

op in gaan in paragraaf 2.3.

13

In de volgende figuur is het procesdeel voor inkoop meer uitgewerkt. Dit is een bewerkte

versie van het model dat Jans (Jans, 1989) hanteert. In dit model worden verticaal de

verschillende functies in een organisatie onderkend. Het stroomschema laat zien hoe de

verschillende documenten door de organisaties stromen en welke activiteiten worden

uitgevoerd (Starreveld, van Leeuwen, & van Nimwegen, 2002).

Inkoopproces

GrootboekCrediteurenadm.Inkoop Magazijn Voorraadadm. FactuurcontroleLeverancier

BestelsignaallijstBestelsignaallijst

Controle bestelling

BestellingBestelling Bestelling

Magazijn ontvangstbon


Goederen Goederen

Controle met

bestelling

Factuur Factuur

Controle factuur

Factuur

Boeken op grbkrekg

crediteuren


Bestelling Boeken op rekening te

ontv fact

Bestelling

Voorraadboeking


Voorraadboeking

Boeking crediteur

Betalen factuur

Invoer stamgegevens

crediteuren

Figuur 1 - Schematische weergave van het inkoopproces (Bron Jans, 1989)

Voor het geautomatiseerd gegevensgericht testen van functiescheiding in het inkoopproces

gaan we er vanuit dat de handelingen met betrekking tot het inkoopproces zich binnen een

ERP-applicatie afspelen. Een bestelling ontstaat als een de behoefte gespecificeerd is en de

bestelling door de afdeling inkoop geplaatst wordt bij een leverancier. Dit is doorgaans de

eerste vastlegging van de kwalitatieve en kwantitatieve gegevens in de financiële

administratie. Deze bestelling wordt uiteraard aan de leverancier doorgegeven, daarnaast

wordt de bestelling geboekt in het grootboek als aangegane verplichting. Ook is de

bestelling vanaf nu benaderbaar voor het magazijn. Op het moment dat de bestelde

goederen binnenkomen in het magazijn, wordt door de magazijnmedewerker de bestelling

gecontroleerd en wordt een magazijnontvangstbon (digitaal) opgesteld. Op basis van de

magazijnontvangstbon vindt een voorraadboeking plaats. De leverancier zal een factuur

opsturen voor de geleverde goederen. De factuur komt binnen op de administratie, hier

wordt de factuur gecontroleerd en vervolgens geboekt en betaald door de

crediteurenadministratie.

Om de risico’s in het inkoopproces te beheersen zijn er onder andere twee belangrijke

(geprogrammeerde) beheersingsmaatregelen te definiëren, te weten de three-way-match

14

en functiescheiding. Als eerste de three-way-match; dit houdt in dat voorafgaand aan de

uitvoering van de betaling een controle wordt uitgevoerd waarbij drie documenten uit het

eerder genoemde inkoopproces worden vergeleken. Hierbij worden de kwantitatieve en

kwalitatieve kenmerken van de bestelling, de magazijnontvangstbon en de factuur tegen

elkaar afgezet. Kenmerken waar het om gaat zijn onder andere de hoeveelheid, de kwaliteit,

de prijs van de goederen en de leverancier. Op het moment dat er afwijkingen zijn op een

bepaald kenmerk, is dit een reden voor verder onderzoek. Als geen afwijkingen

geconstateerd zijn, kan de factuur betaalbaar worden gesteld.

Functiescheiding vormt de tweede belangrijke maatregel in het beheerst laten verlopen van

het inkoopproces. Deze maatregel vormt is een voorwaarde voor een goed functionerende

three-way-match. Bij functiescheiding kan men denken aan scheiding van de registratie- en

de beschikkingsfuncties, maar ook aan de autorisatielagen bij de uitvoering van een

betaling. Dit onderzoek richt zich specifiek op functiescheiding als beheersingsmaatregel, de

three-way-match is niet in scope. In de volgende paragraaf weiden wij verder uit over

functiescheiding in het algemeen en over functiescheiding in het inkoopproces.

2.3 Functiescheiding

Functiescheiding is één van de kernbegrippen in interne controle en geldt als een

organisatorische beheersingsmaatregel. Volgens ISACA wordt functiescheiding als volgt

omschreven:

“A basic internal control that prevents or detects errors and irregularities by assigning to

separate individuals responsibility for initiating and recording transactions and custody of

assets to separate individuals.”

De kern van functiescheiding is dat de (combinatie van) functies waarmee ongezien waarde

aan de organisatie onttrokken kan worden, niet worden gecombineerd in de taken en

verantwoordelijkheden van één functionaris. Hiermee wordt hiermee wordt het risico

bestreden dat één enkele persoon in staat is om ongezien waarde aan de organisatie te

ontrekken. Er blijft altijd een restrisico van samenspanning tussen meerdere personen

bestaan, waartegen ook functiescheiding geen oplossing biedt.

Starreveld (Starreveld, van Leeuwen, & van Nimwegen, 2002) geeft de volgende richtlijnen

met betrekking tot de doorvoering van functiescheidingen in de organisatie:

• Functionarissen mogen slechts een beperkt aantal schakels van het totale

omloopproces beïnvloeden;

• Beslissingen over het beschikken over zaken mogen alleen worden genomen

door personen die niet zelf met de bewaring van die zaken belast zijn;

• Personen die als uitvoerders verantwoordelijk zijn voor het rendement van

bepaalde technische of commerciële omzettingsprocessen, mogen niet tevens

belast zijn met een relatief langdurige bewaring van de aan te wensen

respectievelijk verkregen goederen c.q. gelden;

15

• Er moeten mogelijkheden worden geschapen tot het verkrijgen van elkaar

wederzijds controlerende verantwoordingsverslagen van personen met niet-

identieke en waar mogelijk tegengestelde belangen;

• Geen der bij beschikken, uitvoeren of bewaren betrokken functionarissen mogen

deelnemen aan enig deel van de registratie van dat kritisch is ten aanzien van de

op hun activiteit uit te oefenen controle;

• Ten aanzien van die onderdelen van de administratieve organisatie die praktisch

mede een bewaringskarakter hebben, moet de controle in handen worden

gelegd van een ander dan degene door wie dat onderdeel van de administratie

wordt bijgehouden.

Deze globale eisen met betrekking tot functiescheiding zijn voor dit onderzoek naar

functiescheiding in het inkoopproces nader te concretiseren. Hier zijn voor de

jaarrekeningcontrole specifiek de onderstaande (chronologische) functiescheidingen van

belang. In figuur 2 ziet u nogmaals het inkoopproces in een schema. Hierin zijn de gewenste

functiescheidingen te herkennen aan de vakken die overeenkomen in kleur. Deze kleur

wordt in de onderstaande lijst ook vermeld bij de omschrijving van de te scheiden functies.

• Een medewerker die mutaties in stamgegevens van crediteuren doorvoert,

verricht geen transacties in het inkoopproces en omgekeerd (zwart);

• Een medewerker die een bestelling plaatst, is niet de medewerker die

goedkeuring verleent op die bestelling en omgekeerd (geel);

• Een medewerker die een bestelling plaatst, is niet de medewerker die de

goederen in ontvangst neemt en andersom (oranje);

• Een medewerker die een factuur ontvangt en registreert, is niet de medewerker

die de controle op de factuur uitvoert en andersom (rood);

• Een medewerker die een factuur registreert/controleert, is niet de medewerker

die de factuur betaalbaar stelt en andersom (paars).

Functiescheiding heeft een minimale omvang van de organisatie nodig om effectief te

kunnen zijn. Een eenmanszaak zal geen functiescheiding kennen omdat het simpelweg niet

mogelijk is om een functie bij een tweede persoon te beleggen. Bij een organisatie van meer

dan twee personen kan het evengoed zo zijn dat meerdere functies bij een persoon belegd

zijn. Zolang er in het hele proces in ieder geval minimaal één kritieke stap is die door een

andere functionaris wordt uitgevoerd, is dit voldoende om (beperkte) functiescheiding te

waarborgen. In dit geval is het niet mogelijk dat één medewerker het volledige proces

afhandelt.

Het kan voorkomen dat er geen tweede functionaris beschikbaar is om een kritieke stap in

het inkoopproces uit te voeren. In dat geval kan er nog steeds sprake zijn van een adequate

interne controle als er compenserende maatregelen zijn genomen om de functionaris met

te veel vrijheden alsnog achteraf te controleren. Dit kan bijvoorbeeld door een aantal

transacties te controleren per periode die door de functionaris alleen zijn uitgevoerd.

16

Inkoopproces



Controle bestelling




Goederen Goederen

Controle met

bestelling

Factuur Factuur

Controle factuur

Factuur

Boeken op grbkrekg

crediteuren


BestellingBoeken op rekening te

ontv fact

Bestelling

Voorraadboeking


Voorraadboeking

Boeking crediteur

Betalen factuur

Invoer stamgegevens

crediteuren

Figuur 2 - Inkoopproces inclusief functiescheiding en three-way-match

Tijdens dit onderzoek zullen wij voor zover mogelijk met de beschikbare data alle

functiescheidingen betrekken. Dit is afhankelijk van de informatie die beschikbaar is in de

applicatie. In de volgende paragraaf zullen wij aangeven welke informatie uit de financiële

administratie benodigd is om de functiescheidingen te kunnen testen.

2.4 Minimaal benodigde informatie

In de vorige paragraaf hebben we de relevante functiescheidingen gedefinieerd. Nu is het

noodzakelijk om de informatiebehoefte te definiëren die het mogelijk maakt om de

functievermenging ook geautomatiseerd gegevensgericht te kunnen testen. Hieronder

beschrijven we eerst op welke wijze vastlegging van informatie met betrekking tot

functiescheiding in ERP-systemen plaatsvindt. Nu duidelijk is waar de informatie gevonden

kan worden, is het zaak te bepalen welke informatie hier precies wordt vastgelegd. Dit

wordt behandeld in de paragraaf 2.4.2. Hier is in generieke termen te vinden welke

informatie benodigd is. Vervolgens wordt dit specifiek gemaakt voor het testen op

functiescheiding in het inkoopproces.

2.4.1 Vastlegging van data in ERP-applicaties

Informatie in ERP-applicaties ligt typisch vast in twee verschillende vormen. De eerste vorm

is in de daadwerkelijke transactiedata. Dit ligt meestal vast in de database van de ERP-

applicatie. Deze informatie heeft direct met de verrichte transactie te maken. Bijvoorbeeld,

bij het aanmaken van een bestelling wordt de leverancier, het bedrag, de hoeveelheid

17

bestelde goederen, een omschrijving van de goederen, etc. vastgelegd in de tabel met

bestellingen.

Dan is er een tweede vastlegging mogelijk en dat is de vastlegging van gebeurtenissen in de

vorm van een log. Dit log kan in de database van de applicatie vastgelegd worden maar kan

ook naar een bestand, bijvoorbeeld een tekstbestand, zijn weggeschreven. Logbestanden

bevatten meta informatie over de transactiedata die in de ERP-applicatie zit. Soms wordt

bijvoorbeeld de gebruiker die de transactie uitvoert niet bij de bestelling vastgelegd. Dit

wordt dan wel gelogd naar een logbestand of logtabel. Mogelijkheden tot vastlegging in

logbestanden in een applicatie kunnen typisch aan of uitgezet worden in verband met

performance overwegingen van de applicatie.

Beide bronnen kunnen aangesproken worden in het geautomatiseerde gegevensgerichte

testen door middel van data analyse. De combinatie van transactiedata en logbestanden

heet de audit trail. Voor dit onderzoek dient het audit trail genoeg informatie te bevatten

om te geautomatiseerd gegevensgericht te kunnen testen op functievermenging.

2.4.2 Rijkdom van de informatie

Ook de rijkdom van de informatie, de hoeveelheid beschikbare informatie elementen bij

een gebeurtenis en de relevantie daarvan, is van belang voor dit onderzoek. Indien bepaalde

informatie van of over een transactie gewoonweg niet wordt vastgelegd op het moment van

de gebeurtenis, zal deze dus later ook niet beschikbaar zijn in de audit trail voor een

analyse. Onderzoek naar de minimaal benodigde informatie in de audit trail is gedaan door

van Dongen en van der Aalst (van der Aalst, de Beer, & van Dongen, 2005) als onderdeel van

de databehoeften voor proces mining1. Zij definieerden de volgende informatiebehoeften

om een analyse te kunnen doen:

• Tijdstip en/of datum van een gebeurtenis

Elke gebeurtenis in een proces moet vastgelegd worden in een chronologische

volgorde. Een periode is geen geldige indicatie voor een gebeurtenis. Voor een

periode geldt dat deze geïdentificeerd kan worden door zowel het beginpunt als het

eindpunt van de periode. Dit zijn twee aparte gebeurtenissen die apart vastgelegd

kunnen worden.

• Elke vastlegging dient over een unieke activiteit te gaan

Voor elke vastlegging moet gelden dat deze over slechts een enkele activiteit gaat.

De activiteit in kwestie moet daarnaast ook uniek identificeerbaar zijn.

1 Proces mining is een techniek waarbij uit logging data het gevolgde proces en alle stappen daarin zichtbaar

worden gemaakt dan wel worden getest of conformiteit met een standaard model.

18

• Elke vastlegging dient te beschrijven wat er plaats vond ten aanzien van de

bijbehorende activiteit

Bijvoorbeeld, de activiteit begon of was juist afgerond.

• Elke vastlegging in de audit trail dient te refereren naar een unieke instantie van het

proces: een casus.

Bijvoorbeeld de casus van precies één hele aankoop.

• Elke procesinstantie behoort toe tot precies een specifiek proces.

Een casus mag dus niet zowel een inkoop- als een verkoopproces zijn.

In de volgende subparagraaf worden deze behoeften vertaald naar concrete niveaus en

velden van de benodigde data.

2.4.3 Benodigde informatie voor testen functiescheiding in het inkoopproces

Om de functiescheiding geautomatiseerd gegevensgericht te kunnen testen is vastlegging

van de procesinformatie in de ERP-applicatie nodig. Hierbij gaat enerzijds om vastlegging

van de kwantitatieve en kwalitatieve kenmerken van de basisdocumenten in het proces, de

bestelling, de magazijnontvangstbon en de factuur. Anderzijds gaat het om de vastlegging

van de gebruikers die inhoudelijke wijzigingen hebben doorgevoerd,

controlewerkzaamheden hebben uitgevoerd of goedkeuring hebben gegeven. Dit is nodig

om vast te stellen of de gebruikers die gemoeid zijn bij deze activiteiten verschillend zijn.

Om de functiescheiding in het inkoopproces geautomatiseerd gegevensgericht te kunnen

testen hebben we om te beginnen gegevens nodig van de basisdocumenten/objecten die

betrokken zijn in het inkoopproces. Deze documenten betreffen de bestelling, de

magazijnontvangstbon en de factuur, zoals ook terug te vinden in de weergave van het

inkoopproces in figuur 1. Per document zijn op het niveau van de bestelling/magazijn-

ontvangstbon/factuur de volgende basisgegevens nodig om de gegevensgerichte controle

volledig te kunnen uitvoeren:

• Bestelling

o Ordernummer (unieke identificatie)

o Besteldatum

o Bestelbedrag

o Bestelregels (inhoud van de bestelling)

o Leveranciersnummer

• Magazijnontvangstbon

o Ordernummer (unieke identificatie)

o Ontvangstdatum

o Bedrag waarvoor goederen of diensten zijn ontvangen

o Goederenregels (kenmerken van de ontvangen goederen)

19

o Leveranciersnummer

• Factuur

o Factuurnummer/Ordernummer (unieke identificatie)

o Factuurbedrag

o Factuurregels (omschrijving van hetgeen wordt gefactureerd)

o Crediteurnummer

Met betrekking tot deze basisdocumenten is het vervolgens noodzakelijk een aantal

handelingen te registreren. Essentieel hierbij is dat wordt geregistreerd wat de handeling in

heeft gehouden, wie de handeling heeft verricht en op welke datum en tijd de handeling is

verricht.

• Bestelling

o Medewerker (incl. datum en tijd waarop) die de bestelling heeft geplaatst

o Medewerker (incl. datum en tijd waarop) die de bestelling heeft

gecontroleerd

• Magazijnontvangstbon

o Medewerker (incl. datum en tijd waarop) die de goederen in ontvangst heeft

genomen

• Factuur

o Medewerker (incl. datum en tijd waarop) die de factuur heeft geregistreerd

o Medewerker (incl. datum en tijd waarop) die de factuur heeft gecontroleerd

o Medewerker (incl. datum en tijd waarop) die de crediteurboeking heeft

uitgevoerd

o Medewerker (incl. datum en tijd waarop) die de factuur heeft geboekt

Naast deze transacties die verricht worden in het inkoopproces, is er nog de informatie die

nodig is om functiescheiding tussen mutaties in crediteurenstamgegevens en transacties in

het inkoopproces te kunnen vaststellen. Hiervoor is aanvullende de volgende informatie

nodig:

o Medewerker (incl. datum en tijd waarop) die crediteurenstamgegevens heeft

gewijzigd

o Waarde voorafgaand aan de wijziging

o Waarde na de wijziging

Mutaties in stamgegevens worden typisch vastgelegd in de logbestanden in de audit trail.

De handelingen op bestelling, magazijnontvangstbon en factuur worden in de meeste

gevallen vastgelegd in transactie tabellen en daarnaast mogelijk nog in logbestanden.

20

2.5 Conclusie

In dit hoofdstuk hebben we een model neer gezet van een standaard inkoopproces (zie

paragraaf 2.2) dat we verder zullen aanhouden in de rest van deze scriptie. Het model van

het inkoopproces met de te onderscheiden stappen zal dienen als basis voor de analyse van

functiescheiding bij de praktijkcasussen.

Daarnaast is het begrip functiescheiding geïntroduceerd. We hebben functiescheiding

beschreven als:

Functiescheiding is een middel om het risico dat waarde uit de organisatie wordt

onttrokken door een enkele functionaris wordt voorkomen door de verschillende

taken die dit mogelijk maken te spreiden over meerdere personen.

Het restrisico dat overblijft, is dat er samenspanning optreedt tussen functionarissen in de

organisatie. Dit risico is niet te voorkomen door middel van functiescheidingen en zal verder

niet in deze scriptie worden onderzocht. Vervolgens hebben we de volgende algemene

functiescheidingen onderkend in het standaard inkoopproces:

• Mutaties op stamgegevens crediteuren scheiden van transacties in het inkoopproces

• Goederen bestellen scheiden van de goedkeuring op die bestelling

• Goederen bestellen scheiden van de goederenontvangst

• De factuurregistratie scheiden van de controle op de factuur

• De factuurregistratie en controle op de factuur scheiden van de betaling van de

factuur

Op basis van deze vijf functiescheidingen hebben we onderzocht welke informatie benodigd

is om geautomatiseerd gegevensgericht functiescheiding te testen in de audit trail en hoe

informatie wordt opgeslagen in ERP-applicaties. De minimale vastleggingen, in het

algemeen, moeten zijn:

• Tijdstip en/of datum van een gebeurtenis

• Elke vastlegging dient over een unieke activiteit te gaan

• Elke vastlegging dient te beschrijven wat er plaats vond ten aanzien van de

bijbehorende activiteit

• Elke vastlegging in de audit trail dient te refereren naar een unieke instantie van het

proces: een casus.

• Elke procesinstantie behoort toe tot precies een specifiek proces.

De rijkdom van de beschikbare informatie zal bepalen of alle of slechts een deel van de

functiescheidingen geautomatiseerd getest kunnen worden. Alle benodigde elementen voor

de vijf standaard functiescheidingen zijn opgesomd in paragraaf 2.4.3. Op basis van deze lijst

kan later bepaald worden welke functiescheidingen getest kunnen worden gegeven de data

aanwezig in de ERP-applicatie.

21

3 Theoretische studie: randvoorwaarden voor geautomatiseerde

gegevensgerichte analyse

3.1 Inleiding

Voor elke audit zijn randvoorwaarden nodig zonder welke een audit niet uitgevoerd kan

worden. Centraal in dit hoofdstuk staat dan ook de vraag:

Welke randvoorwaarden moeten vervuld zijn in de organisatie en in de applicaties

om op opgetreden functievermenging te testen?

In paragraaf 2.4.3 hebben we gezien welke informatie elementen nodig zijn voor de analyse

van functiescheidingen. Een belangrijke vraag is of de ERP-applicatie de bron was van deze

informatie of slechts een registratie middel. Daarnaast moet de integriteit van de

geregistreerde data gewaarborgd zijn. Dit zijn onderwerpen die in dit hoofdstuk aan het bod

komen in de volgende onderzoeksvragen:

• Wat is primaire vastlegging en waar is dit belangrijk in het analyse proces?

• Welke organisatorische maatregelen zijn er noodzakelijk om de integriteit van de

analyse data te waarborgen en hoe worden deze nu geïmplementeerd?

In paragraaf 3.2 bespreken we het onderwerk van primaire vastleggingen en secundaire

vastleggingen. In paragraaf 3.3 gaan we in op de organisatorische maatregelen aan welke

voldaan moeten worden om een geautomatiseerde gegevensgerichte analyse met volledige

betrouwbaarheid te kunnen uitvoeren. Ook komen hier de logische toegangsbeveiliging

maatregelen die geautomatiseerde gegevensgerichte analyse ondersteunen aan bod. Tot

slot, in paragraaf 3.4, eindigen we dit hoofdstuk met een conclusie over de

onderzoeksvragen.

3.2 Primaire vastleggingen in de ERP-applicatie

Zoals aangegeven in hoofdstuk 2.4.3 zal bepaalde informatie digitaal aanwezig moeten zijn

om geautomatiseerd gegevensgericht functiescheiding te kunnen testen. Deze informatie

zal vastgelegd moeten zijn in de audit trail van de te controleren ERP-applicatie.

We maken onderscheid tussen de primaire en de secundaire vastlegging van data. Bij de

primaire vastlegging hebben we het over de vastlegging die als eerste bekend is bij het

bedrijf. Bij een secundaire vastlegging gaat het om een vastlegging die is afgeleid van de

primaire vastlegging of van een vastlegging die pas veel later plaats vind. Dit illustreren we

hieronder met een voorbeeld.

Transactie data, zoals ordernummers en prijzen en bestelde hoeveelheden, zijn vaak wel

aanwezig in de ERP-applicatie van een bedrijf. Het gaat hier echter vaak om de secundaire

vastlegging van data. Als voorbeeld kunnen we de factuur nemen. Het komt nog vaak voor

22

dat een factuur op papier wordt ontvangen en vervolgens de relevante informatie hiervan

wordt overgenomen in de ERP-applicatie. In dit geval is de primaire vastlegging de factuur

(hier staat de daadwerkelijke informatie op die als eerst het bedrijf binnenkomt) en is het

invoeren in de ERP-applicatie de secundaire vastlegging (er is namelijk nog een primaire

bron beschikbaar waar deze informatie van afgeleid is).

De trend in de markt is dat de primaire vastlegging steeds vaker digitaal wordt gedaan en

dat het verschil tussen de primaire en secundaire vastlegging verdwijnt. Denk hierbij aan

elektronische facturen (ANP, 2009) die gelijk digitaal worden opgeslagen in de ERP-

applicatie en waarvan de informatie gelijk geautomatiseerd wordt opgeslagen. Daarnaast

kunnen veel magazijnen goederen ontvangen en de vastlegging doen door middel van een

barcode scan bij ontvangst van de goederen.

Het kan zijn dat delen van het proces in andere applicaties worden vastgelegd of zelfs buiten

de digitale omgeving om. Een veelvoorkomend voorbeeld hiervan is de goedkeuring van

orders. Regelmatig wordt hiervoor een aparte work flow ingeregeld in een externe

applicatie of buiten de applicatie om op papier. In dit geval is het niet voldoende om alleen

de data uit de ERP-applicatie te gebruiken. Er zal dan additionele data uit, in dit voorbeeld

het work flow systeem, aan de data van de ERP-applicatie toegevoegd moeten worden.

Alleen op die manier kan de databehoefte zoals beschreven in 2.4.3 volledig worden

vervuld.

In de volgende paragraaf zullen we aandacht besteden aan de organisatorische

randvoorwaarden die vervuld dienen te zijn voor het geautomatiseerd gegevensgericht

controleren van functiescheidingen.

3.3 Organisatorische inrichting

Bij het inrichten van een organisatie dient, in het geval van geautomatiseerd

gegevensgericht testen, naast de gebruikelijke inrichting zoals beschreven in (Starreveld,

van Leeuwen, & van Nimwegen, 2002) en (Arens & Loebbecke, 1980), rekening te worden

gehouden met het bewaren en beschikken over de informatie in de audit trail van de ERP-

applicatie. Dit is een verbijzondering van het standaardgeval waarbij de audit trail niet altijd

in scope is.

Omdat de audit trail het uitgangspunt is bij het geautomatiseerd gegevensgericht testen van

functiescheidingen moet deze niet manipuleerbaar zijn voor de te controleren gebruikers.

Daarom dienen de volgende zaken organisatorisch gewaarborgd te zijn:

1. Het bewaren van de audit trail gegevens mag niet in handen zijn van een functionaris

wiens acties geregistreerd zijn in het audit trail.

2. Het configureren van de audit trail instellingen die bepalen wat in het audit trail wordt

vastgelegd, mag niet toegankelijk zijn voor functionarissen wiens acties in de audit trail

worden opgeslagen.

23

3. De geautomatiseerde gegevensgerichte testwerkzaamheden en de configuratie daarvan

mogen niet worden uitgevoerd door een functionaris wiens acties geregistreerd zijn in

het audit trail.

In een kleinere organisatie zal het typisch voorkomen dat meerdere functies in de handen

liggen van één persoon. Dit geeft geen probleem qua functiescheiding zolang de

bovenstaande scheidingen maar gewaarborgd blijven.

Er zijn verschillende soorten (IT-)beheersingsmaatregelen die invloed hebben op het

afdwingen van de bovenstaande functiescheidingen. Tevens zijn er maatregelen die de

kwaliteit en de betrouwbaarheid van de geautomatiseerde gegevensgerichte analyse

kunnen waarborgen. Beide categorieën van maatregelen komen hieronder aan de orde.

3.3.1 Implementatie van functiescheidingen in logische toegangsbeveiliging

Naast de organisatorische opzet van functiescheidingen is ook de implementatie hiervan in

informatiesystemen van belang. We zullen ons nu eerst richten op de maatregelen op het

gebied van logische toegangsbeveiliging die de implementatie van de organisatiestructuur

met functiescheidingen mogelijk maakt. Typisch zullen bedrijven de toegang tot

informatiesystemen beperken om op deze manier functiescheiding en digitale autorisaties

te realiseren. Logische toegangsbeveiligingstechnieken en tools worden ingezet om deze

beperkingen te definiëren. Er zijn een aantal factoren belangrijk bij de implementatie van

logische toegangsbeveiliging. Deze zetten we hieronder uiteen.

Accountability

Het meest belangrijke aspect voor geautomatiseerd gegevensgericht testen is

accountability. Accountability (ISACA, 2005) betekent dat voor elk gebruikersaccount op een

applicatie geldt dat er te allen tijde bekend is wie er gebruikt maakt van het account. Op

deze manier kan deze persoon verantwoordelijk worden gesteld voor de activiteiten die zijn

verricht met gebruikmaking van het account. Deze voorwaarde is nodig omdat het

geautomatiseerd gegevensgericht testen van functiescheidingen alleen mogelijk is als men

op basis van de gebruikersaccount kan zien welke persoon welke actie gedaan heeft. Het

gebruikersaccount geeft de sleutel naar de identiteit van de uitvoerende functionaris maar

alleen als het account niet gedeeld wordt door meerdere mensen.

Gebruikersidentificatie op basis van gebruikersaccount

Het is noodzakelijk om alle accounts van gebruikers in kaart te brengen en te koppelen aan

de personen die er gebruik van maken. Het kan namelijk zo zijn dat een gebruiker meerdere

accounts heeft op een ERP-applicatie. Je zou dan twee accounts ten onrechte als twee

aparte personen in het proces kunnen aanmerken en daardoor een functiescheidingsconflict

missen.

Het kan ook voorkomen dat gebruikers meerdere accounts hebben die ook verdeeld zijn

over meerdere systemen die gebruikt worden voor delen van het proces. Ook hierdoor kan

een functievermenging wellicht onopgemerkt blijven. Voor elke applicatie in scope van de

24

geautomatiseerde gegevensgerichte analyse geldt dus dat deze koppeling bekend moet zijn

om de resultaten te kunnen interpreteren. De kennis van deze koppeling moet dus ook in de

organisatie beschikbaar zijn.

Nu we weten wat er qua organisatie ingericht moet zijn, kunnen we kijken hoe de logische

toegangsbeveiliging op de audit trail te realiseren is.

3.3.2 Logische beveiliging van de audit trail

In deze paragraaf zullen we verder ingaan op welke gegevens beschermd dienen te worden

met logische toegangsbeveiliging om geautomatiseerde gegevensgerichte analyse hiervan

mogelijk te maken. Zoals in hoofdstuk 2.4.1 beschreven is, bestaat een audit trail uit 2

soorten data: transactiedata en logbestanden. Voor beide soorten gegevens geldt dat deze

adequaat beschermd dienen te worden met behulp van logische toegangsbeveiliging.

Ten eerste dient de audit trail beschermd te worden tegen aanpassingen en verwijderingen

door onbevoegden personen en door te controleren personen (zie 3.3.1). Hiervoor kunnen

technieken als access control lists, database management systemen en applicatiebeveiliging

gebruikt worden. Hierbij geldt dat het beheer niet mag worden uitgevoerd door een

persoon die zelf in de logging gecontroleerd wordt.

Ten tweede is het belangrijk om te kijken naar de beschikbaarheid van de registratiemedia

voor het audit trail. Indien een kwaadwillend persoon er in slaagt om de opslag van de

gegevens te verhinderen, bereikt deze in feite hetzelfde als wanneer de data verwijderd zou

worden.

Tot slot nog een kanttekening bij de beveiliging van de gegevens in de audit trail. Omdat de

audit trail grote hoeveelheden data kan bevatten, wordt deze soms niet (lang) op het

bronsysteem bewaard vanwege opslaggebrek en/of prestatievermindering van de

systemen. Vaak worden er aparte catalogi opgezet met een kopie van de data. Indien er

sprake is van transport van de data, hetzij via een netwerk of via een vast medium, dienen

er controles te zijn over de juistheid, de volledigheid en de tijdigheid van de overdracht (zie

(Senft & Gallegos, 2008)).

3.4 Conclusie

De onderzoeksvraag voor dit hoofdstuk was welke randvoorwaarden belangrijk zijn voor

een geautomatiseerde gegevensgerichte functiescheidingsanalyse. We onderkennen de

volgende randvoorwaarden:

• Primaire vastleggingen

Het is belangrijk dat alle vastleggingen in de ERP-applicatie gebeuren. Ofwel primair,

de ERP-applicatie is de bron van de vastlegging, ofwel secundair wanneer de ERP-

applicatie slechts dient ter registratie van een primaire vastlegging.

25

• Accountability

Het meest belangrijke is de accountability van acties. Dat wil zeggen dat voor elke

actie in de applicatie bekend is welk gebruikersaccount deze actie heeft uitgevoerd.

Daarnaast is het noodzakelijk om vanuit elk gebruikersaccount de mapping naar

gebruikers juist, tijdig en volledig is. Zonder deze mapping kan er geen uitspraak

worden gedaan omver functiescheiding omdat er niet helder is welke functionaris

welke acties heeft (kunnen) uitvoeren.

• Scheiding tussen beheerderstaken en gebruikerstaken

Het belangrijkste aspect van de organisatorische inrichting is dat er goede

functiescheiding bestaat tussen beheerders van applicaties en audit trails versus de

eindegebruikers. Hiermee waarborg je dat gebruikers niet in staat zijn om de

vastleggingen omtrent hun acties te wijzigen. Ze zouden dus wel onrechtmatige

zaken kunnen uitvoeren maar er is dan altijd te achterhalen welke acties dit ware.

Zowel de functiescheiding tussen beheerstaken en gebruikstaken als de accountability kan

ondersteund worden door goede inrichting van de logische toegangsbeveiliging.

Nu we het theoretisch kader qua randvoorwaarden voor geautomatiseerde

gegevensgerichte analyse van functiescheidingen hebben omschreven, kunnen we een

analyse maken van de technieken die toepasbaar zijn binnen dit kader. Deze technieken

zullen we onderzoeken in hoofdstuk 4.

26

4 Theoretische studie: analysetechnieken

4.1 Inleiding

Miljoenen regels data in een audit trail zijn geen uitzondering tijdens de

jaarrekeningcontrole van een multinational. Dit zijn hoeveelheden waarbij het voor mensen

niet meer rendabel is om dit handmatig te controleren. Dit moet dus geautomatiseerd

gebeuren. Gegeven een theoretische achtergrond kunnen we een selectie maken van

mogelijke analysetechnieken om deze geautomatiseerde analyse uit te voeren. De

onderzoeksvraag voor dit hoofdstuk is dus:

Welke analyse technieken zijn er om geautomatiseerde gegevensgerichte analyses

uit te voeren voor functiescheidingen?

Doel van dit hoofdstuk is om de beschikbare analysetechnieken ter ondersteuning van de

gegevensgerichte analyse uiteen te zetten. Deze analysetechnieken worden beoordeeld op

basis van een aantal criteria om zo een overzicht te creëren van welke technieken te

gebruiken in welke situatie.

Wat zijn de vereisten aan en de gewenste eigenschappen voor analyse technieken?

Wat zijn mogelijke automatische analysetechnieken voor het testen van

functiescheiding op basis van logbestanden en transactie data en wat zijn hun voor

en nadelen?

We starten dit hoofdstuk met de bespreking van de criteria op basis waarvan de

analysetechnieken beoordeeld worden in paragraaf 4.2. Vervolgens behandelen we de

belangrijkste technieken in paragraaf 4.3 en analyseren we deze tegen het de criteria van

paragraaf 4.2 in paragraaf 4.4, 4.5, 4.6 en 4.7. We ronden af met een conclusie in paragraaf

4.8.

4.2 Criteria ter beoordeling van automatische analysetechnieken

In deze paragraaf geven we de criteria die belangrijk zijn voor analysetechnieken die ingezet

kunnen worden voor geautomatiseerd gegevensgericht testen van functiescheidingen. We

kijken naar de volgende aspecten:

1. integriteit van de data tijdens de analyse

2. de volumes en data formaten die verwerkt kunnen worden

3. de analyse mogelijkheden tijdens de verwerking van de data

4. de analyse snelheid

27

Elk van deze aspecten komt aan bod in de volgende paragrafen. In totaal leidt dit tot acht

criteria op basis waarvan de analysetechnieken behandeld zullen worden. We eindigen deze

paragraaf met een korte conclusie over de criteria.

4.2.1 Integriteit van de data tijdens de analyse

Integriteit van de data tijdens de analyse is van groot belang. Tijdens is het niet wenselijk

dat de te analyseren data muteert tijdens de analyse zodat een tweede zelfde analyse een

ander resultaat zou geven. De analyse moet altijd herhaalbaar zijn en dan hetzelfde

resultaat geven. Hiervoor zijn de volgende zaken belangrijk:

1. Onveranderlijkheid van de data

Tijdens de analyse vinden er geen toevoegingen, veranderingen of verwijderingen

plaats in de brondata door de analyse tool (OrangeBook, 1985).

2. Herhaalbaarheid van de testresultaten

Indien een test gedaan is met een techniek en deze test voor een tweede maal

uitgevoerd wordt, dienen de resultaten gelijk te zijn aan de voorgaande test gegeven

dat de andere randvoorwaarden gelijk zijn gebleven (Apgar & Lynch, 2004).

3. Audit trail van de handelingen

Alle acties die worden uitgevoerd tijdens de analyse worden vastgelegd zodat deze

later herhaald kunnen worden (OrangeBook, 1985).

De eerste van deze drie is een eis waaraan altijd voldaan dient te worden vanuit een audit

perspectief. De tweede en derde hoeven niet noodzakelijk aanwezig te zijn in de tool zelf

omdat dit ook zou kunnen met behulp van externe documentatie.

4.2.2 Data Volumes en Formaten

De analysetechnieken moeten in staat zijn om de volumes en de verschillende formaten

waarin data wordt aangeboden te kunnen verwerken. Hieronder beschrijven we wat we

hieronder verstaan en wat belangrijke aspecten zijn op dit gebied.

4. Maximale verwerkingscapaciteit

Voor het datavolume geldt dat de verwerkingslimiet van de tool, oftewel: hoeveel

data kan er maximaal tegelijkertijd geanalyseerd worden, toereikend moet zijn voor

grote tot zeer grote datasets. Hiermee wordt bedoeld datasets van honderden

miljoenen regels en van tientallen gigabytes.

28

5. Opslag data tijdens verwerking

De tweede volumefactor is de opslagcapaciteit benodigd voor analyse. Bij de analyse

van grote bestanden gaat het om vele gigabytes aan data. Hierbij is het belangrijk

om te weten of de tool diverse kopieën maakt tijdens de uitvoering van de data

analyse. Naarmate het aantal kopieën groeit, kan dit leiden tot

capaciteitsproblemen.

6. Data formaten - Ontsluiting van de data voor analyse

Er zijn verschillende formaten waarin de data voor analyse aangeboden kan worden.

Hierbij valt te denken aan databases zoals Oracle DBMS, MS SQL server en MySQL.

Ander formaten zijn tekstbestanden in diverse formaten zoals Comma Separated

Values (CSV), SAP report files, fixed width columns bestanden en gestructureerde

bestanden zoals HTML, MS Excel, XBRL, etc.

Des te meer van deze formaten een tool aan kan, des te gemakkelijker is het om een

analyse uit te voeren op data over verschillende bronnen heen. Voor onze analyse zullen we

ons beperking tot de drie meest gangbare standaard formaten in de bovengenoemde

categorieën;

• Database via Open DataBase Connectivity (Idehen, 1993)

• CSV files (Shafranovich, 2005)

• XML-based files (Bray, Paoli, Sperberg-McQueen, Maler, & Yergeau, 2008)

We kiezen voor deze drie formaten omdat deze regelmatig voorkomen bij bedrijven.

Daarnaast gaat het hier om standaard gedefinieerde formaten en dus is voor alle

toolontwikkelaars de mogelijkheid aanwezig om aan deze standaard te voldoen (geen

gepatenteerd format).

4.2.3 Data Verwerking en Analyse

Naast de volumes en de formaten die een techniek kan verwerken, is het ook de

bruikbaarheid van een techniek van belang. Wat bijvoorbeeld belangrijk is, tijdens de

analyse, is dat de techniek inzicht geeft in de data die verwerkt wordt.

7. Inzicht in de data

Met inzicht in de data wordt bedoeld dat het op elk moment mogelijk is om met de

analysetechniek te valideren dat de analyse op de juiste manier verloopt. Dit kan

doordat er snapshots van de data beschikbaar zijn in de techniek zelf of dat er

achteraf terug kan worden gekeken naar elke tussenstap van het analyseproces.

29

Dit inzicht versnelt het ontwikkelen van tests omdat gemakkelijk kan worden gegaan of en

wanneer wellicht een fout zit in het proces. Daarnaast kan een tussenresultaat ook inzicht

geven in de oorzaak van bevindingen tijdens een audit.

4.2.4 Analysesnelheid

Het laatste criterium dat hier behandeld wordt, is de snelheid waarmee de analyse

uitgevoerd kan worden door de analysetechniek.

8. Analysesnelheid

De factorsnelheid is nog een criterium op basis waarvan de analysetechniek

beoordeeld kan worden. Indien een analyse voor een jaarrekening lang duurt, is

deze niet relevant meer en dus ook niet meer bruikbaar. Hoe eerder het resultaat,

hoe beter.

De snelheid laat zich slecht voorafgaand aan de analyse voorspellen. Hier zijn wel metrieken

voor zoals de “Big O” notatie (Paul E. Black, 2008). Echter, deze geven allemaal een

vergelijking op het gebruikte algoritme. Het gaat hier dus altijd om een theoretische

verwerkingsduur. De meeste analysetechnieken bevatten meerdere algoritmen waaruit de

gebruiker kan kiezen en ook de specifieke implementatie hiervan kan verschillen. Voor elke

combinatie van algoritmen geldt een ander effect op de doorlooptijd van de test. Dit is dus

moeilijk vooraf te voorspellen en zal achteraf bepaald moeten worden.

Een andere complicerende factor is de hardware. Deze is vaak bepalend voor de

performance van de verschillende technieken. De ene techniek heeft veel fysiek geheugen

nodig en de ander heeft een snelle schijftoegang nodig. Afhankelijk van de computer

configuratie kan dit erg voordelig of juist negatief uitpakken voor een bepaalde techniek.

De snelheid van de analyse is dus van veel factoren afhankelijk zijn en kan het beste

gemeten worden door een test daadwerkelijk uit te voeren. Dit betekent dus wel dat we er

hier nu op voorhand geen theoretische beoordeling over kunnen geven.

4.2.5 Conclusie

Op basis van bovenstaande onderscheiden we de volgende criteria om de

analysetechnieken te beoordelen qua bruikbaarheid voor geautomatiseerd gegevensgericht

testen van functiescheidingen:







a. Database via Open DataBase Connectivity

b. CSV files

30

c. XML-based files


8. Analyse snelheid

Hierbij zijn nummer 1 en 2 absolute harde voorwaarden in een audit context, nummers 3 tot

en met 7 zijn gewenste eigenschappen en nummer 8 is slechts achteraf te bepalen.

4.3 Mogelijke analysetechnieken

In deze paragraaf zullen we de door ons geselecteerde technieken om de geautomatiseerde

gegevensgerichte analyse op functiescheidingen uit te voeren, beschrijven. We hebben

gekozen voor de volgende software pakketten omdat deze tezamen een goede doorsnede

geven van de verschillende beschikbare tools.

• ProM met Linear Temporal Logic (LTL)

Dit is een nieuw opkomende techniek en methode voor het analyseren van data

vanuit de proces optimalisatie hoek. Vanuit dit domein wordt het nu ook steeds

vaker toegepast in een audit context.

• Audit Command Language (ACL)

In Nederland de “de facto” standaard voor data analyse bij accountants en interne

audit diensten (IAD). Dit pakket is een standaard audit tool maar begint ook enigszins

verouderd te raken.

• SAS

Bedoelt als statistiek analyse techniek maar ook bruikbaar in andere contexten.

Prettig is dat dit pakket gericht is op hele grote datasets en daar efficiënt mee om

kan gaan.

• Standard Query Language (Sequel or SQL)

In tegenstelling tot de andere tools werkt deze techniek direct op de data in de

database. Daarnaast wordt deze vrij regelmatig bij klanten aangetroffen als tool voor

interne rapportages etc.

Hieronder zullen we de verschillende technieken introduceren en beschrijven op basis van

de in paragraaf 4.2 gedefinieerde criteria.

4.4 Beoordeling Process Mining (ProM) en Linear Temporal Logic (LTL)

ProM is een in Java (Sun Microsystems, 2009) geprogrammeerde PROces Mining (ProM)

omgeving waarin vrijelijk nieuwe componenten zijn te programmeren (ProcessMiningGroup,

2008). ProM maakt gebruik van eXtended Markup Language (XML) als input formaat om een

audit trail in te lezen en op te slaan. ProM verwerkt deze audit trails (proces logs in ProM

termen) tot resultaatsets zoals sociale netwerken, procesdiagrammen en transactie

overzichten die aan bepaalde voorwaarden voldoen. Die voorwaarden kunnen op diverse

manieren gedefinieerd worden. Een van die manieren is Linear Temporal Logic.

31

Linear Temporal Logic (Pnueli, 1997) is een logica die ook tijdsbegrip mee kan nemen in de

logische premissen. LTL is als een module toegevoegd aan het ProM proces mining

framework (van der Aalst, de Beer, & van Dongen, 2005) en werkt op dezelfde proces logs

als proces mining.

Dan zullen we ProM met LTL nu beschrijven in termen van de gekozen criteria.


Omdat ProM altijd data in het MXML format nodig heeft, is het per definitie een

kopie van de data en blijft de originele set dus altijd intact. Daarnaast maakt het

ProM framework ook geen wijzigingen aan de data van de MXML tijdens de analyse.


ProM kan een veelvoud aan algoritmen gebruiken. Sommige zijn niet deterministisch

en geven dus verschillende resultaten tussen twee verschillende runs met alle

randvoorwaarden gelijk. Voor het gebruik met LTL geldt dit echter niet en zijn de

resultaten wel deterministisch en dus herhaalbaar.


In LTL worden eerst de tests beschreven voordat deze worden toegepast op de

dataset. Het is dus mogelijk, indien de set van testen niet wijzigt in de tussentijd, om

een test te herhalen op basis van deze beschrijving. Echter, wijzigingen of

aanpassingen aan de beschrijving worden niet vastgelegd en hiervan is dus geen

audit trail.


De maximale verwerkingscapaciteit van ProM is niet gelimiteerd door de software.

Er is dus geen harde limiet vanuit de tool. Echter, het format waarin de tool zijn input

accepteert is XML. Dit heeft als eigenschap dat het de dataset gemiddeld met een

factor tien groter maakt dan, bijvoorbeeld, de CSV versie van deze set. Dit betekent

dat hoge eisen worden gesteld aan de opslagmedia van de computer waarop de

analyse wordt uitgevoerd.


Tijdens de verwerking heeft LTL geen extra datasets nodig en werkt het volledig op

het XML log dat als invoer dient. Wel moet er voldoende capaciteit zijn in het

werkgeheugen van de computer zodat in ieder geval de langste, meest uitgebreide

casus in de invoerset in het geheugen geladen kan worden. Alle andere gevallen

zullen dan uiteraard ook passen.


ProM kan importeren uit een ODBC (JDBC in Java terminologie) bron en uit XML

bronnen. Echter, importeren uit CSV is niet standaard mogelijk en moet via een

omweg. Daarnaast is het zo dat ProM eist dat er in de data een unieke identifier

aanwezig is op basis waarvan elke casus apart geïdentificeerd kan worden. Dat

32

betekent dat elke inkooporder en alle bijbehorende acties zoals goederenontvangst

en goedkeuring allen eenzelfde unieke identifier moeten hebben die ze groepeert.


Bij ProM is er constant inzicht in de invoerdata mogelijk. Echter de tussenstappen die

de tool maakt zijn niet zichtbaar.

Subjectieve argumenten

Voordeel van LTL is dat het gemakkelijk mogelijk is te modelleren welke gebeurtenissen in

welke volgorde plaats zouden moeten vinden in het proces en welke functionaris betrokken

zou moeten zijn. Daarmee is het mogelijk te modelleren welke stappen in het proces niet

door dezelfde functionaris mogen worden uitgevoerd, hiermee is de tool bruikbaar voor het

testen van functiescheidingen.

Nadeel is dat het opzetten van een proces log een arbeidsintensief proces is omdat de

dataset eerst handmatig omgezet dient te worden naar het Mining XML format.

4.5 Beoordeling Audit Command Language (ACL)

Audit Command Language (ACL) is een audit software pakket waarmee gegevensgerichte

analyses kunnen worden uitgevoerd (ACL_Services_Ltd, 2009). ACL is zo ingericht dat het

kan omgaan met grote databestanden. Daarnaast is ACL specifiek gericht op gebruik in de

audit sfeer.


ACL heeft altijd “alleen lezen” toegang tot de brondata waardoor de integriteit

gewaarborgd is. Dit zit in de programmatuur opgenomen en wordt dus altijd

afgedwongen.


In ACL is een audit trail in de tool ingebouwd zodat altijd controleerbaar is welke

stappen er zijn uitgevoerd op de brondata om tot een bepaald resultaat te komen.

Alle tussenstappen worden naar aparte databestanden weggeschreven en zijn dus

ook inzichtelijk. Deze stappen kunnen opgenomen worden in een script waarmee de

analyses herhaalbaar zijn.


Zoals genoemd in het voorgaande punt is een audit trail beschikbaar in ACL.


ACL heeft geen limiet op de maximale verwerkingscapaciteit. Een limiet is de

maximale bestandsgrootte op het Microsoft Windows operating system (WikiMedia,

2009).

33


ACL maakt voor elke tussenstap waarin een bewerking op de data plaatsvindt een

nieuw bestand aan. Dan betekent dat er voor elke stap voldoende schijfruimte moet

zijn om dit op te slaan. Dit kan bij hele grote sets een nadeel zijn. Mogelijke oplossing

is om de totale analyse stap voor stap uit te voren. Tussenbestanden kunnen tijdens

de analyse worden verwijderd om capaciteit te besparen.


ACL heeft een uitgebreide set aan import filters en kan ODBC, CSV en XML formaten

aan.


Zoals eerder gezegd, bij ACL wordt voor elke tussenstap een tussenbestand gemaakt,

dit bestand geeft inzicht in het verloop van de analyse.


Omdat ACL veel gebruikt wordt in het audit vakgebied geniet het veel vertrouwen. Het is

een tool waar veel accountants vertrouwd mee zijn. Nadeel van ACL is dat het een oud

programma is en het ontwerp begint in de huidige wereld met de huidige volumes

achterhaald te raken in dat het de extreem grote sets niet aan kan.

4.6 Beoordeling SAS

SAS (SAS_Institute_Inc, 2009) is een tool waarmee op snelle en efficiënte wijze data

ingelezen kan worden om vervolgens selecties, classificaties en analyses uit te voeren. Op

deze manier kunnen onder andere patronen in de data, anomalieën en verbanden in de

data worden achterhaald, om te komen tot nieuwe inzichten. SAS heeft veel dezelfde

mogelijkheden als ACL, alleen heeft SAS minder accountantspecifieke commando’s tot de

beschikking. De audit trail en read-only functionaliteit zijn hier niet standaard gegarandeerd

aanwezig. SAS werkt sneller dan ACL maar heeft een minder gebruiksvriendelijke interface

omdat het voornamelijk met een opdrachtregel werkt in plaats van met een grafische

interface.


SAS voert geen mutaties uit op brondata en laat deze dus gegarandeerd in tact.


SAS verandert de data niet en maakt gebruik van deterministische algoritmen zodat

bij herhalen van de test het resultaat gelijk zal zijn.


SAS heeft een logging functie die alle uitgevoerde commando’s laat zien indien deze

functie is ingeschakeld. Dit kan dus dienen om een test te herhalen en om deze te

documenteren voor een audit.

34


SAS heeft geen limiet op de maximale verwerkingscapaciteit en is vanuit haar

historie altijd ontworpen voor zeer grote datasets waarop statistische functies

uitgevoerd kunnen worden.


SAS maakt geen gebruik van tussenbestanden, tenzij hier expliciet om wordt

gevraagd. De opslagcapaciteit benodigd voor analyse is gelijk aan de grootte van de

invoerdata.


SAS heeft een uitgebreide set aan import filters en kan ODBC, CSV en XML formaten

aan.


Bij SAS bestaat de mogelijkheid om de tussenresultaten in bestanden weer te geven

zodat deze inzichtelijk zijn ter analyse.


Het voordeel van SAS is dat het gebouwd is voor snelle resultaten en om kan gaan met

enorme datasets.

Het nadeel is dat SAS van oorsprong een statistisch pakket is en zich daarom minder leent

voor audits. Hiervoor moet een vertaalslag plaatsvinden in de programmeertaal van SAS.

4.7 Beoordeling Structured Query Language (SQL)

Structured Query Language, Sequel of SQL is niet zozeer een tool als wel een

programmeertaal (ISO/IEC, 2009) waarmee direct op een SQL database query’s of analyses

kunnen worden uitgevoerd. SQL heeft als duidelijke voordeel dat in het geval van een SQL

server database query’s direct op de database gedraaid kunnen worden. Hierbij is geen

export vanuit de database en import in een nieuwe tool benodigd. Nadeel is dat SQL minder

geschikt is om snel inzicht te krijgen in grote bestanden. Bij miljoenen regels is gedegen

kennis van de inrichting van de database noodzakelijk om inzicht te krijgen in de data.


SQL kan mutaties uitvoeren op de brondata. Dit kan voorkomen worden door een

kopie van de originele database te gebruiken. Echter, SQL zal zelf geen data

aanpassen in het analyse proces tenzij dit expliciet geprogrammeerd is.


SQL verandert de data niet (zie voorwaarde bij 1) en maakt gebruik van

deterministische algoritmen zodat bij herhalen van de test het resultaat gelijk zal

zijn.

35


SQL heeft meestal een logging functie in de implementatie die alle uitgevoerde

commando’s laat zien. Dit kan dienen om een test te herhalen en om deze te

documenteren voor een audit. Echter, dit is een aparte module in de database vanuit

een beveiligingsoogpunt. Het is niet als zodanig beschikbaar voor de gemiddelde

gebruiker. Daarnaast is het gebruikelijk om een lange, complexe reeks van

commando’s op te slaan in een brondocument, dit kan ook als documentatie kan

dienen.


SQL heeft geen limiet op de verwerkingscapaciteit. Dit zal afhangen van het bron

database systeem waarop gewerkt wordt.


Tijdens het verwerken van query’s slaat SQL vaak data op in het geheugen van de

computer. Dat kan dus een beperkende factor zijn tijdens het verwerken maar hangt

sterk af van het gebruikte databasesysteem.


SQL is vrij bijzonder aangezien het al direct op de database werkt. Het is ook niet los

van een database implementatie te gebruiken. In een database kun je vaak data

importeren die in CSV of XML format is. SQL op zich heeft geen functionaliteit voor

het inlezen van XML. CSV kan wel worden ingelezen met SQL zelf. Via externe tools

zijn zowel XML als CSV vrijwel altijd in de database in te lezen.


Tijdens de analyse is het mogelijk om tussentabellen aan te maken die inzicht geven

in de verwerking van de data. Echter, dit vergt extra programmeerwerk en moet dus

handmatig opgegeven worden.


Voordelen van SQL zijn dat gelijk op de brondata en het bronsysteem kan worden gewerkt

zonder externe tools of datatransport.

Nadeel van SQL is dat het vaak redelijk technische programmeerkennis vereist om een

analyse te kunnen maken of reviewen.

4.8 Analyse

We hebben een viertal analyse technieken behandeld omdat elke techniek voor- en nadelen

heeft. In onze analyse in hoofdstuk 5 en 6 willen we de keuze voor de techniek baseren op

de situatie bij het bedrijf dat voor de casus is geselecteerd. Echter, om zo een keuze te

kunnen maken is het goed om de verschillende analyse technieken te vergelijken.

36

In het audit domein komt het vaak voor dat de accountant zijn analysetechniek moet

aanpassen aan de middelen en eisen van de klant. Indien de klant geen data uit het systeem

kan halen, moet er op het systeem van de klant gewerkt worden bijvoorbeeld. Vandaar dat

we in dit hoofdstuk de verschillende technieken vergelijken om zo tot een juiste keuze te

kunnen komen in verschillende situaties.

In Tabel 1 staan alle vier de technieken en hun score op de diverse criteria uiteengezet. We

hebben hierbij de analysesnelheid tijdens runtime (het uitvoeren van de tests) niet

meegenomen omdat deze op voorhand niet bekend is. Het is namelijk zo dat alle technieken

generiek genoeg zijn om verschillende analyse algoritmen te ondersteunen. Hierdoor is er

ook geen “big O” analyse (Ellard, 1997) te maken op basis van het toegepaste analyse

algoritme omdat dit algoritme kan verschillen binnen een analyse techniek. Het hangt dus

van het gebruik af wat de precieze runtime impact gaat zijn van een techniek op de data.

Daarnaast is vanwege het generieke karakter van de technieken de gebruiker/programmeur

een belangrijke factor. Een gebruiker die inefficiënte code schrijft zal een slecht resultaat

kunnen bereiken qua snelheid met een zeer snelle analysetechniek. Een betere

programmeur zal zeer snel resultaat kunnen krijgen. We blijven voor dit aspect dus weg van

een beoordeling op voorhand alsmede achteraf wegens de grote variatie in

uitkomstmogelijkheden.

Uit de tabel wordt zichtbaar dat ACL in principe de meest geschikte keuze is omdat het in

het algemeen het beste scoort in onze vergelijking. Een goede tweede is SAS. Dit beeld

wordt ook bevestigd door de praktijk. ACL is de “de facto” standaard applicatie voor

accountants in Nederland en SAS wordt ook wel gebruikt. Pas als er specifieke noodzak is

voor SQL wordt deze tool ingezet. SQL is minder populair omdat het vaal als zeer technisch

gezien wordt. ProM en LTL zijn tools die pas net op het toneel verschijnen en het gebruik is

nog voornamelijk in het onderzoeksgebied aan de universiteit en niet in een productie

omgeving bij de accountant.

37

Legenda

Groen = Tool voldoet standaard aan dit criterium

Geel = Tool voldoet wel indien de gebruiker handmatig maatregelen treft

Oranje = Tool voldoet wel maar tijdens de analyse kan er een probleem optreden

Rood = De tool voldoet niet voor dit criterium

2 Niet alle algoritmen in ProM zijn deterministisch. LTL is dit wel.

3 Dit programma kan direct werken op de brondata en maakt daar niet noodzakelijk een kopie van voor een

volgende analyse. De aanname is dus dat de brondata ongewijzigd is. 4 Dit programma kan direct werken op de brondata en maakt daar niet noodzakelijk een kopie van voor een

volgende analyse. De aanname is dus dat de brondata ongewijzigd is. 5 ProM heeft geen ingebouwd audit trail. Dit zal de gebruiker dus in externe documentatie moeten vastleggen.

6 Een ingebouwd audit trail is aanwezig indien dit door de gebruiker wordt aangezet.

7 SQL heeft geen ingebouwde audit functionaliteit. Deze is soms beschikbaar in een specifieke implementatie

van SQL maar niet noodzakelijk aanwezig. 8 Vanwege het XML formaat waarin ProM de input data opslaat wordt de grootte van de data gemiddeld met

een factor tien vergroot. 9 ACL maakt bij elke tabelbewerking een nieuwe werktabel aan waar de data heen gekopieerd wordt.

10 Alleen indien de gebruiker hier handmatig rekening mee houdt. Dit is niet afgedwongen aanwezig.

11 Alleen indien de gebruiker hier handmatig rekening mee houdt. Dit is niet afgedwongen aanwezig.

ProM + LTL ACL SAS SQL

1 Onveranderlijkheid van

de data

Ja, brondata wordt

gekopieerd voor

analyse

Ja, brondata wordt

gekopieerd voor

analyse

Ja, indien door

gebruiker expliciet

aangezet

Ja, indien de

gebruiker dit zelf

waarborgt in de code

2 Herhaalbaarheid van de

testresultaten

Ja, voor LTL2 Ja Ja

3 Ja

4

3 Audit trail van de

handelingen

Nee5 Ja Ja

6 Nee

7

4 Maximale

verwerkingscapaciteit

Geen vastgestelde

beperkingen

Geen vastgestelde

beperkingen

Geen vastgestelde

beperkingen

Geen vastgestelde

beperkingen

5 Opslag data tijdens

verwerking

± tien keer de

brondata-set8

Voor elke

tussenstap extra

bestand nodig9

Een maal de

dataset grootte

Een maal de dataset

grootte

6 Data formaten

Database via Open

DataBase Connectivity

Ja Ja Ja Nvt

CSV files Nee Ja Ja Ja

XML-based files Ja Ja Ja Nee

7 Inzicht in de data Nee Ja Alleen handmatig

10 Alleen handmatig

11

Tabel 1 - Vergelijking van de analysetechnieken

38

4.9 Conclusie

De onderzoeksvraag voor dit hoofdstuk was om te onderzoeken welke analyse technieken

geschikt zijn voor het automatisch testen van functiescheidingen.

In dit hoofdstuk hebben we vier analysetechnieken afzonderlijk beschreven, namelijk:

• ProM met Linear Temporal Logic (LTL)

• Audit Command Language (ACL)

• SAS

• Standard Query Language (Sequel or SQL)

Verder hebben we beschreven wat de gewenste eigenschappen zijn van analyse technieken

en hieruit hebben we keuze criteria opgesteld (zie paragraaf 4.2.5):







a. Database via Open DataBase Connectivity (Idehen, 1993)

b. CSV files (Shafranovich, 2005)

c. XML-based files (Bray, Paoli, Sperberg-McQueen, Maler, & Yergeau,

2008)


8. Analyse snelheid

Op basis van deze criteria hebben we de verschillende technieken geanalyseerd op

bruikbaarheid voor een geautomatiseerde gegevensgerichte functiescheidingsanalyse.

Zoals blijkt uit Tabel 1 zijn ProM met LTL en SQL de minst geschikte technieken voor een

audit. Beide missen standaard de optie om een van de dataformaten in te lezen en hebben

daarnaast geen ingebouwde mogelijkheid tot het bijhouden van de audit trail. Tussen SAS

en ACL zijn slechts kleine verschillen. SAS vereist een paar handmatige veranderingen om als

audit tool te kunnen werken op het gebied van inzicht in data en om het audit trail te

activeren terwijl ACL deze functionaliteit standaard al heeft en afdwingt. ACL lijkt dus op

basis van de theorie de meeste geschikte keuze.

39

5 Casusbedrijf 1: Het productiebedrijf

5.1 Inleiding

In dit hoofdstuk komen het analyseproces en de analyseresultaten van de eerste

praktijkcasus, het productiebedrijf, aan de orde. We zullen kort de door ons gevolgde

aanpak behandelen en u inzicht geven in het gevolgde proces en haar resultaten. De

onderzoeksvraag voor dit hoofdstuk is:

Wat is het resultaat van toepassing van het theoretisch kader in de praktijk?

We beginnen dit hoofdstuk met een algemene introductie van het bedrijf. Vervolgens

behandelen we kort de door ons gebruikte onderzoeksaanpak zoals beschreven in

hoofdstuk 1, paragraaf 1.4). Verder bespreken wij de inrichting van het inkoopproces voor

dit specifieke bedrijf en zetten dit af tegen de theorie zoals geschetst in hoofdstuk 2. Hierna

wordt beschreven hoe het productiebedrijf zich verhoudt ten aanzien van de

randvoorwaarden zoals beschreven in hoofdstuk 3. Op basis van de karakteristieken van de

ontvangen data en de uiteenzetting over analysetechnieken in hoofdstuk 4 zal vervolgens de

analysetechniek voor deze casus worden bepaald.

Na afronding van dit theoretische deel van de casus worden de resultaten van de casus

beschreven. Hierbij komen de te testen functiescheidingen en de resultaten van mogelijke

doorkruising hiervan aan de orde. Het geheel van dit hoofdstuk wordt afgesloten door een

analyse van de resultaten en een conclusie. In deze laatste paragraaf bespreken we ook de

impact die deze bevindingen zouden hebben op de jaarrekening controle van het productie

bedrijf.

5.2 Beschrijving organisatie

In dit hoofdstuk introduceren we het eerste casusbedrijf. Het bedrijf heeft haar

medewerking verleend met als voorwaarde dat haar anonimiteit gewaarborgd blijft en dat

de resultaten van het onderzoek niet zullen worden gebruikt in de jaarrekeningcontrole of

elders openbaar worden gepubliceerd. Vandaar dat de beschrijving van het bedrijf en haar

diensten slechts op hoofdlijnen is en dat waar de details de identiteit van het bedrijf zullen

onthullen hier slechts in algemeenheden gesproken zal worden.

Het productiebedrijf dat in deze casus wordt beschreven is een bedrijf dat in 1991 is

opgericht en werkzaam is in de Technologie, Media en Telecommunicatie industrie. Het

bedrijf heeft ruim 3.000 medewerkers over de hele wereld en produceert elektronische

artikelen voor consumenten. De jaaromzet bedraagt ongeveer € 2 miljard per jaar in 2008.

De diverse artikelen zijn voorzien van software waarmee het bedrijf zich onderscheidt van

concurrenten. Het productiebedrijf heeft voor softwareontwikkeling een uitgebreide

onderzoeksafdeling om de producteigenschappen van de software continu te optimaliseren

en vernieuwende functionaliteiten toe te voegen.

40

5.3 Het inkoopproces bij het productiebedrijf

Dit productiebedrijf maakt sinds 2008 gebruik van SAP als ERP-applicatie voor het

ondersteunen van alle bedrijfsprocessen. Het volledige inkoopproces wordt dus ook

ondersteund in de applicatie met uitzondering van de daadwerkelijke betalingen. Voor deze

betalingen wordt het softwarepakket van de bank gebruikt.

In het SAP pakket worden voor het inkoopproces alle administratieve handelingen

vastgelegd. Zowel de transactiedata van een order wordt opgeslagen in de tabellen van de

ERP-applicatie als wel de goedkeuringen op de inkooporders. Het bedrijf maakt voor de

goedkeuringen van inkoop orders gebruik van een work flow management module in SAP

om het inkoopproces digitaal te ondersteunen.

Er zijn meerdere soorten inkoopstromen gedefinieerd bij het productiebedrijf. Er wordt

onderscheid gemaakt tussen eigen verbruiksartikelen en artikelen bestemd voor de

productie. Het verschil qua proces is dat voor de productie de bestelling automatisch wordt

voorbereidt door het SAP systeem en de bestelling na goedkeuring van de planner/inkoop

manager effectief wordt gemaakt. Vanaf het moment dat de bestelling geplaatst is, loopt

het proces voor beide stromen weer gelijk. Voor onze analyse betekent dit dat we ze als

gelijk kunnen beschouwen. Slechts het initiatief tot bestelling is anders en voor de analyse

van functiescheidingen is kennis hierover niet noodzakelijk, zoals gedefinieerd in onze

scope.

Bij een bedrijf van deze omvang is het mogelijk om functiescheiding in te richten. De

omvang van het productiebedrijf laat het namelijk toe om de verschillende functies over de

functionarissen te verdelen. Er zijn minimaal vijf inkoopmanagers die voor hun personeel

diverse bestellingen goed kunnen keuren en die voor elkaar de bestellingen kunnen

goedkeuren. Op de diverse afdelingen werken voldoende (tien of meer) medewerkers om

de dagelijkse functies die gescheiden dienen te worden niet bij eenzelfde persoon onder te

hoeven brengen. Samenspanning tussen de medewerkers op de afdeling om de

noodzakelijke functiescheiding te doorbreken is echter altijd mogelijk.

Het is dus theoretisch mogelijk om een degelijke organisatie in te richten waarbij

functiescheidingen gewaarborgd zijn, samenspanning buiten beschouwing gelaten. Laten

we nu dan kijken naar de voorwaarden voor het uit kunnen voeren van de analyse.

5.4 Aanwezige randvoorwaarden

In hoofdstuk 3 zijn de randvoorwaarden uiteengezet waaraan een organisatie moet voldoen

om betrouwbaar de functiescheiding geautomatiseerd te kunnen analyseren. Het betreft de

primaire vastlegging van de informatie, de organisatorische inrichting en de logische

toegangsbeveiliging. We zullen nu beschrijven hoe de situatie bij het productiebedrijf is

ingericht ten aanzien van deze punten.

41

Primaire vastlegging in de ERP-applicatie

Qua vastlegging in het inkoopproces bij het productiebedrijf is dit momenteel als volgt

ingericht. De primaire vastlegging van de bestellingen vindt plaats in de ERP-applicatie. De

magazijnontvangstbonnen en facturen komen fysiek binnen bij de organisatie en worden

secundair in de applicatie vastgelegd. De controleslagen in het proces, goedkeuring van de

bestelling en goedkeuring van de factuur, worden primair in de applicatie vastgelegd. Er is

bijvoorbeeld geen sprake meer van papieren facturen die fysiek door de organisatie worden

gestuurd om te worden voorzien van de benodigde parafen ter goedkeuring. Dit proces is

gedigitaliseerde en goedkeuringen worden direct in de applicatie ingegeven. In essentie

geldt dat de benodigde informatie primair dan wel secundair wordt vastgelegd in de

applicatie, zoals reeds geconstateerd in paragraaf 5.6.

Organisatorische inrichting

Met betrekking tot de organisatorische inrichting zouden de volgende randvoorwaarden

moeten gelden:

1. Het bewaren van de audit trail gegevens is niet in handen van iemand van wie de

acties geregistreerd zijn in de audit trail.

2. Het configureren van de audit opties is niet toegankelijk voor personen waarvoor

acties geregistreerd moeten worden.

3. De geautomatiseerde analyse op functiescheiding wordt niet uitgevoerd door een

persoon die zelf in de audit trail voor kan komen.

Voor het productiebedrijf geldt dat de bovenstaande zaken geen problemen opleveren. De

activiteiten die worden vastgelegd in de applicatie zijn niet te muteren door gebruikers. Er

wordt gebruik gemaakt van transactietabellen waarbij altijd vermeld wordt welke gebruiker

een activiteit heeft uitgevoerd. Dit is niet te verwijderen waardoor de bewaring van de

gegevens en de configuratie van de audit opties geen aandachtspunt is. Ten aanzien van het

derde punt geldt dat de geautomatiseerde analyse in dit geval door ons wordt uitgevoerd

als externe partij. De analyse wordt dus uitgevoerd door een persoon die zelf niet in audit

trail voor kan komen, aan deze randvoorwaarde is voldaan. Op het moment dat deze

geautomatiseerde gegevensgerichte analyse opgenomen wordt als onderdeel van de

jaarrekeningcontrole, en uitgevoerd wordt door de externe accountant, is dus ook meteen

voldaan aan deze voorwaarde.

Omdat de audit trail het uitgangspunt is bij de geautomatiseerde gegevensgerichte analyse

moet deze niet manipuleerbaar zijn voor de gebruikers van de ERP-applicatie van het

productiebedrijf. In de praktijk is het zo dat de applicatiebeheerders de personen zijn die de

audit trail kunnen beïnvloeden. Deze medewerkers hebben zelf geen rol in het

inkoopproces. Het productiebedrijf maakt gebruik van gebruikersaccounts voor gebruikers,

uitgangspunt is dat elke gebruiker gebruik maakt van zijn eigen unieke account. Dit zorgt

ervoor dat activiteiten herleidbaar zijn naar één specifiek persoon.

Nu we hebben vastgesteld dat aan alle randvoorwaarden is voldaan, kunnen we verder gaan

met de uitvraag van de data bij het productiebedrijf

42

5.5 Dataset definitie

In deze paragraaf zullen wij definiëren welke data wij hebben opgevraagd bij het

productiebedrijf. SAP is een erg uitgebreide en gecompliceerde ERP-applicatie en het vereist

specialistische kennis om te bepalen welke tabellen benodigd zijn om de in hoofdstuk 2.3

gedefinieerde functiescheidingen te kunnen testen. Daarom hebben wij informatie

opgevraagd bij SAP-experts vanuit onze werkgever Deloitte en vanuit de Technische

Universiteit Eindhoven (TUe) over:

- welke tabellen uit SAP benodigd zijn om functiescheidingen in het inkoopproces te

testen;

- op welke wijze deze tabellen gecombineerd moeten worden om de

functiescheidingen te kunnen testen.

Deze experts hebben ons voorzien van een lijst tabellen en een schema hoe de tabellen

gecombineerd moeten worden om te komen tot de gewenste informatie. Deze tabellen

hebben wij opgevraagd bij het productiebedrijf. Niet alle tabellen zijn opgeleverd door het

productiebedrijf. Dit zal in meer detail besproken worden in paragraaf 5.8, waar wij de

punten bespreken die wij zijn tegengekomen in het proces van data uitvraag en analyse.

De periode waarvoor wij data hebben opgevraagd is de volledige periode dat het

productiebedrijf gebruik maakt van SAP, vanaf 1 januari 2008 tot en met het tijdstip van

extractie begin 2009. De benodigde tabellen zijn niet allemaal op dezelfde dag uit de ERP-

applicatie gehaald, de redenen hiervoor komen aan de orde in paragraaf 5.8. De tabellen

zijn in een periode van een paar weken, in de periode tussen half februari 2009 en half

maart 2009, uit de applicatie ontvangen. Voor de verschillende tabellen is daarom in het

ene geval over een wat langere periode data beschikbaar dan in het andere geval, omdat de

tabel later uit de applicatie is aangeleverd.

De geleverde data met betrekking tot het inkoopproces van het productiebedrijf hebben wij

ontvangen in CSV-formaat. Zie het voorbeeld hieronder van een deel van de data.

Figuur 3- Voorbeeld data productiebedrijf

Nu de data tot onze beschikking is, gaan we in de volgende paragraaf bekijken welke

functiescheidingen bij het productiebedrijf geautomatiseerde gegevensgericht getest

kunnen worden.

43

5.6 Te testen functiescheidingen

Voordat we resultaten kunnen leveren moeten we eerst onderzoeken of de data die we tot

onze beschikking hebben bruikbaar is in de context. Het blijkt namelijk uit ervaring met data

analyses dat het verschil tussen de opgeleverde data en de aangevraagde data erg groot kan

zijn. Hieronder zullen we dit voor het productiebedrijf valideren en gelijk de slag maken naar

het theoretische raamwerk uit paragraaf 2.2.

Hieronder is een overzicht weergegeven van de benodigde informatie om de gewenste

functiescheidingen te testen, zoals gedefinieerd in paragraaf 2.3. Per item is vervolgens

aangegeven of de informatie wordt vastgelegd in de applicatie van het productiebedrijf en

of wij deze beschikbaar hebben kunnen maken voor de analyse.

Informatie Aanwezig Beschikbaar

Plaatsing bestelling Ja Ja

Controle bestelling Ja Ja

Goederenontvangst Ja Ja

Registratie factuur Ja Ja

Controle factuur Ja Nee

Betaling factuur Ja Nee

Mutatie stamgegevens crediteur Ja Ja

Tabel 2 - Beschikbare informatie productiebedrijf

Vanwege onder meer technische storingen tijdens het downloaden van de benodigde data

is het niet gelukt om de informatie met van de betaling van de factuur en de controle

hiervan beschikbaar te maken. Dit zal in meer detail besproken worden in paragraaf 5.8.

Op basis van de informatie die wel beschikbaar is vanuit de SAP-applicatie van het

productiebedrijf is het mogelijk om de volgende functiescheidingen te testen:

- Een medewerker die een bestelling plaatst, is niet de medewerker die goedkeuring

verleent op die bestelling (geel);

- Een medewerker die een bestelling plaatst, is niet de medewerker die de goederen

in ontvangst neemt (oranje);

- Een medewerker die mutaties in stamgegevens van crediteuren doorvoert, verricht

geen transacties in het inkoopproces (rood).

Zie ook de grafische weergave van de functiescheiding die in het bedrijf getest kunnen

worden in relatie tot het inkoopproces zoals dat is gedefinieerd in paragraaf 2.2 in de

onderstaande figuur.

44

Inkoopproces



Controle

bestelling


Magazijn

ontvangstbon

Magazijn

ontvangstbon

Goederen Goederen

Controle

met

bestelling

Factuur Factuur

Controle

factuur

Factuur

Boeken op

grbkrekg

crediteuren

Magazijn

ontvangstbon

BestellingBoeken op

rekening te

ontv fact

Bestelling

Voorraad

boeking

Magazijn

ontvangstbon

Voorraad

boeking

Betalen

factuur

Invoer stam

gegevens

crediteuren

Figuur 4 - Te testen functiescheidingen productiebedrijf

Deze drie functiescheidingen zullen dus bekeken worden, op grond van de ontvangen data.

In paragraaf 2.3 zijn vijf functiescheidingen genoemd die voor de jaarrekeningcontrole

relevant zijn. De resterende twee functiescheidingen kunnen op grond van de beschikbare

data niet getest worden bij het productiebedrijf. Het betreft de volgende functiescheidingen

die niet getest kunnen worden:


die de controle op de factuur uitvoert;

• Een medewerker die een factuur registreert/controleert, is niet de medewerker

die de factuur betaalbaar stelt.

In de volgende paragraaf zullen we bekijken welke analysetechniek het meest geschikt is om

de ontvangen data snel en effectief te doorgronden.

5.7 Keuze analysetechniek

In deze paragraaf zullen we kort onderzoeken welke analysetechniek de beste keuze is in de

situatie van het productiebedrijf, op basis van de data zoals beschreven in de vorige

paragraaf.

45

In hoofdstuk 4 zijn de criteria opgesomd op basis waarvan een bepaalde analysetechniek

gekozen kan worden om de gegevensgerichte analyse uit te voeren. Zoals blijkt uit de

uiteenzetting over mogelijke analysetechnieken in hoofdstuk 4 is ACL in het algemeen de

meest geschikte tool om de in dit onderzoek aan de orde zijnde geautomatiseerde

gegevensgerichte analyse uit te voeren. Dit is ook in dit geval zo. We zullen de verschillende

analysetechnieken en de voor- en nadelen ten aanzien van deze specifieke dataset

doornemen om dit te toe te lichten.

ProM/LTL

Voor ProM + LTL geldt dat de data eerst geconverteerd zal moeten worden naar een XML

format waarin er slechts een enkele identifier is op basis waarvan men een inkooporder kan

definiëren. Aangezien er binnen SAP niet een globaal kenmerk is per inkooporder, zal dit

handmatig moeten worden toegevoegd. Dit is een bewerkelijke en tijdrovende klus.

SAS

Bij gebruik van SAS zullen handmatig de audit opties aangezet moeten worden om de

herhaalbaarheid van de resultaten te waarborgen. Groter nadeel is dat er niet direct inzicht

is in de data. Aangezien we een nieuwe onderzoeksmethode gaan ontwikkelen is het wel

belangrijk om zeker te weten dat alle ondernomen stappen te traceren zijn. Daarnaast is het

in een onderzoeksituatie vaak noodzakelijk om de data goed inzichtelijk te hebben zodat je

de volgende stap in het onderzoek sneller kunt vinden.

SQL

De dataset is niet aangeleverd in de vorm van een SQL database en dus zal de data eerst

handmatig moeten worden omgezet naar een database voordat SQL als techniek toegepast

kan worden. Dit zal veel tijd kosten gezien er geen standaard filter beschikbaar is voor CSV

data.

ACL

Een belangrijk voordeel is dat met behulp van ACL snel bestandsonderzoek uitgevoerd kan

worden. Door de relatieve onbekendheid met de informatie uit de SAP-applicatie is het met

behulp van ACL mogelijk geweest om snel inzicht te krijgen in de databestanden. ACL lijkt

hier dus de meest geschikte keuze. Nadeel van ACL is de hoeveelheid data die opgeslagen

moet worden gedurende de analyse. De bestanden zoals wij die hebben ontvangen voor

deze analyse zijn echter niet groter dan 2 gigabyte en hiervoor is voldoende opslagcapaciteit

beschikbaar voor de analyse zodat dit geen probleem vormt.

Op grond van deze overwegingen hebben wij ervoor gekozen om in deze casus ACL als

analysetechniek in te zetten. De drie te testen functiescheidingen zijn dus geautomatiseerd

geanalyseerd in het softwarepakket ACL.

5.8 Resultaten

In deze paragraaf zullen we de resultaten van de analyse bespreken. We zullen eerst een

doorlopen proces bespreken zodat de resultaten in de juiste context geplaatst kunnen

46

worden. Hierna bespreken we de analyseresultaten en validatie. De stappen in het

analyseproces hieronder corresponderen met die van de beschrijving van de

onderzoeksaanpak in hoofdstuk 1. In de volgende paragraaf zullen we de impact van de

resultaten op de jaarrekening bespreken.

Het analyseproces

1) Onderzoeken van de softwarepakketten die betrokken zijn bij het inkoopproces

We hebben van de interne audit afdeling van het bedrijf begrepen dat bij het inkoopproces

alleen maar gebruik wordt gemaakt van SAP en de bankapplicatie van ABN AMRO. De

documentatie verkregen van de accountants van Deloitte, die bij dit bedrijf de

jaarrekeningcontrole doen, bevestigt dit beeld.


zit met betrekking tot de door ons gekozen functiescheidingen.

De kennis om processtappen van een applicatie te kunnen vertalen naar de data zoals

opgeslagen in de ERP-applicatie is een stap die veel specifieke kennis vereist. Het vereist

namelijk zowel kennis van het inkoopproces, van de functionele werking van de ERP-

applicatie als van de manier waarop de ERP-applicatie de data intern vastlegt. We hebben

hiervoor diverse experts om advies gevraagd zowel vanuit Deloitte, vanuit het

productiebedrijf als vanuit de TUe. Met behulp van hun kennis en kunde hebben we een

deel van de stappen kunnen achterhalen in de ERP-data. Op basis van deze informatie is ook

de dataset definitie (zie paragraaf 5.5) opgesteld.

3) Extraheren van de data uit de ERP-applicatie.

Nadat we hebben achterhaald welke data we nodig zouden hebben uit de ERP-applicatie,

hebben we geprobeerd deze data ook uit de applicatie te halen. Dit hebben we eerst

gedaan door het aan de experts bij het productiebedrijf te vragen. Deze hadden moeite om

de data op te leveren omdat het een groot volume betrof. Voor enkele benodigde tabellen

slaagde dit maar niet, helaas waren dit interessante tabellen voor de analyse: de

transactiedata.

Vervolgens hebben we gebruik gemaakt van speciale extractie tooling om de data toch te

kunnen extraheren. Dit is gedeeltelijk gelukt. Voor enkele tabellen was een download nog

steeds niet mogelijk. Het betrof hier voornamelijk de goedkeuring van orders en de data

met betrekking tot wijzigingen op de orders nadat deze in eerste instantie aangemaakt zijn.

Ook na herhaalde pogingen (die elk ruim 3 dagen van pure download tijd in beslag namen)

en enkele aanpassingen aan de extractie software bleek dit niet mogelijk vanuit de SAP-

applicatie van het productiebedrijf. Omdat zowel de tijd als de middelen beperkt

toegankelijk waren voor ons hebben we besloten om de extractie pogingen verder te

staken.

47


standaard inkoop proces.

Het resultaat van deze exercitie is al besproken in de voorgaande paragraaf, 5.4. Het gebruik

van SAP vormt een praktische drempel in de analyse van de audit trail. De uitgebreidheid

van het pakket en de vereiste specialistische kennis om de juiste informatie uit het pakket te

halen en op juiste wijze te combineren maakt een geautomatiseerde analyse complex.

Kennis op dit niveau van de applicatie is zeer spaarzaam. Van de weinige mensen die hier

precies weten hoe het werkt, zijn er vrijwel geen beschikbaar geweest om mee te werken

aan dit onderzoek.

5) Geautomatiseerd gegevensgericht testen van de functiescheidingen

Met de data die voor handen was, hebben we de testen gedefinieerd in ACL. Op basis van

de door onze SAP experts verschafte kennis is deze data zodanig gecombineerd dat er

herkenbare processtappen ontstonden in de context van functiescheidingstesten. De data

bevatte de volgende informatie die bruikbaar was voor onze analyse:

Informatie Aantal rijen Bedrag

Geplaatste bestellingen 11.391 Niet bekend

Goedgekeurde bestellingen 1.201 Niet bekend

Bestellingen gekoppeld aan

goedkeuring

931 Niet bekend

Goederenontvangsten in periode 329.415 € 213,6 miljoen

Goederenontvangsten gekoppeld

aan een bestelling

363 € 3,3 miljoen

Geregistreerde facturen 10.621 € 680,5 miljoen

Mutatie stamgegevens crediteuren 21.463 N.v.t.

Waarvan bankrekening nummers 6.795 N.v.t.

Waarvan naam-/adresgegevens 14.668 N.v.t.

Tabel 3 - Karakteristieken van beschikbare data

De data beslaat de periode van januari 2008 tot en met februari/maart 2009. Op basis van

de beschikbare informatie konden we drie functiescheidingen gegevensgericht testen.

Hieronder zullen per geteste functiescheiding de resultaten beschrijven:

Bestelling plaatsen vs. goedkeuren bestelling

In de te analyseren periode, januari 2008 tot en met februari/maart 2009, zijn 11.391

bestellingen geplaatst. Volgens de methodiek van goedkeuring zijn slechts 1.201

goedkeuringen verleend. In totaal zijn er 931 bestellingen waaraan een goedkeuring

48

gekoppeld kon worden teruggevonden in de data. Ten aanzien van deze 931 bestellingen is

op basis van de data te constateren dat er geen functievermenging heeft plaatsgevonden

tussen de medewerker die de bestelling heeft geplaatst en de medewerker die de bestelling

heeft gecontroleerd.

Het feit dat er maar 1.201 goedkeuringen op 11.391 bestellingen terug te vinden zijn is

opmerkelijk. Op basis van de data hebben we hiervoor geen verklaring kunnen vinden.

Aansluiten van de verschillende sleutelvelden leverde geen betere resultaten op. Door het

verschil in de tijd van downloaden van de verschillende tabellen kan een deel van het

verschil verklaard worden door verschuivingen. Echter, dit is typisch nooit meer dan 10%

van de totale dataset. Zelfs met de volle 10% er van af blijft de discrepantie nog steeds

groot.

Wij hebben deze constatering teruggekoppeld aan het productiebedrijf en hen de vraag

gesteld of zij wellicht een verklaring hadden. Steekproefsgewijze oproep van de

detailgegevens in SAP toont aan dat er wel degelijk een goedkeuring op een bestelling heeft

plaatsgevonden waar wij deze niet vinden. Ook het opzoeken van de waarden van de

sleutelvelden uit het SAP systeem in onze data levert geen resultaat op. We hebben dit

onderzocht op basis van de werkwijze die wij vanuit SAP-experts hebben meegekregen, hoe

een goedkeuring op een bestelling te herkennen.

Wij hebben verder nog eens bij onze interne SAP-experts aangegeven dat de door hen aan

gegeven werkwijze deze beperkte koppeling als gevolg heeft. Zij hadden hiervoor geen

verdere verklaring en konden geen verdere uitspraken doen zonder dat zij direct in het

systeem van het productiebedrijf zouden kunnen kijken. Dit was echter niet mogelijk vanuit

het productiebedrijf. Een mogelijke verklaring zou volgens ons kunnen zijn dat bij het

productiebedrijf een (groot) deel van de goedkeuringen op bestellingen anders dan op de

standaard SAP wijze wordt opgeslagen in de database. Hierdoor zouden wij deze

goedkeuringen niet terugvinden in de data in de standaard tabellen.

Bestelling plaatsen vs. de goederenontvangst

De 11.391 bestellingen in de periode januari 2008 tot en met februari/maart 2009 hebben

ongeveer 329.415 goederenontvangsten als gevolg gehad. Van deze goederenontvangsten

en bestellingen is het op basis van de ontvangen informatie mogelijk om er 363 met elkaar

in verbinding te brengen. Voor deze gevallen is op basis van de data te constateren dat in 31

gevallen functievermenging is opgetreden. Voor deze 31 gevallen is de persoon die de

bestelling heeft geplaatst dezelfde als de persoon die de goederenontvangst heeft geboekt.

Deze bestellingen hebben een totale waarde van ongeveer € 3,2 miljoen over de periode

van ruim 2 jaar waar deze analyse betrekking op heeft.

Hierbij moet wel aangetekend worden dat dit bedrag niet juist is. Het is berekend door het

aantal bestelde stuks te vermenigvuldigen met de productprijs. Echter, die prijs is gebaseerd

op een standaardhoeveelheid, bv 100 stuks kosten €50. Wij hebben nu gerekend met de

€50 als de stuksprijs in plaats van deze eerst te delen door de standaardhoeveelheid. Het

49

veld voor de standaardhoeveelheid zat namelijk niet in onze data extractie en hebben we

dus niet kunnen gebruiken. In de tweede stap van het analyseproces (verkrijgen van het

schema dat aangeeft waar in de applicatie de benodigde informatie zit met betrekking tot

de door ons gekozen functiescheidingen) bleek een fout te zitten in de datadefinitie,

hierdoor ontbrak het veld voor de standaardhoeveelheid in de opgevraagde en ontvangen

dataset. Doordat we nu de prijs van een standaardhoeveelheid gebruiken als stuksprijs

weten we dus zeker dat de € 3,2 miljoen een overschatting is. Een nieuwe data extractie

waarin het veld voor de standaardhoeveelheid wel is opgenomen zou dit kunnen oplossen

met een precies bestelbedrag. Echter, wegens herhaalde problemen met het downloaden

van deze tabel en de additionele werkdruk die dit bij het productie bedrijf zou neerleggen

hebben we hiervan afgezien. Het betreft hier een bekende en constante afwijking dus het

doet verder niet af aan de resultaten op zich.

Een tweede opmerking die we bij het resultaat moeten plaatsen is dat uit bijna 329.415

goederen ontvangsten en 11.391 bestellingen, slechts 363 bestellingen gekoppeld konden

worden met de goederenontvangst. Ook in dit geval hebben wij het productiebedrijf

steekproefsgewijs laten uitzoeken of zij een koppeling konden maken tussen diverse

bestellingen en goederenontvangsten.

Dit was het geval, waar dit in onze dataset op basis van het verkregen schema van de SAP-

experts niet mogelijk is. Het lijkt er dus op dat het productiebedrijf een andere manier

gebruikt dan de standaard SAP manier om de goederen aan een order te koppelen. Dit kan

momenteel niet uitgezocht worden omdat er geen bronnen beschikbaar zijn bij het

productiebedrijf om dit uit te zoeken.

Mutaties stamgegevens crediteuren vs. transacties in het inkoopproces

Ten aanzien van de mutaties in stamgegevens is gekeken naar zowel mutaties in

bankgegevens als mutaties in NAW-gegevens van crediteuren. In beide gevallen is te

constateren dat gebruikers zowel mutaties in de stamgegevens als betrokkenheid in het

inkoopproces hebben. Onderstaand de bevindingen:

Stap in het

inkoopproces

# gebruikers die

de actie

uitvoerden

# gebruikers die ook

NAW wijzigden

# gebruikers die ook

bankgegevens

wijzigden

Totaal #

gebruikers

functievermenging

Plaatsing bestelling 26 10 9 10

Goedkeuring bestelling 10 2 1 2

Goederenontvangst 30 4 3 4

Factuurregistratie 23 2 2 2

50

Tabel 4 - Functievermenging stamgegevens crediteuren vs. transacties in het inkoopproces

Op basis van de bovenstaande tabel kunnen wij onder meer de volgende zaken constateren

over de geanalyseerde periode januari 2008 tot en met februari/maart 2009:

- Tien gebruikers hebben bestellingen geplaatst en daarnaast mutaties in

stamgegevens crediteuren, zowel NAW-gegevens als bankgegevens, doorgevoerd.

- Twee gebruikers hebben zowel een bestelling vrijgegeven als de NAW-gegevens van

een crediteur gewijzigd.

- Drie gebruikers hebben zowel goederenontvangsten geboekt als mutaties in NAW-

gegevens en bankgegevens van crediteuren geboekt.

- Twee gebruikers hebben zowel facturen geboekt als mutaties doorgevoerd in de

bankgegevens van crediteuren.

Daarnaast is te constateren dat in 26 gevallen geen gebruiker is vermeld bij de wijziging in

de stamgegevens van de crediteuren. De oorzaak hiervan is dat de gegevens van welke

gebruiker een wijziging gemaakt heeft in een andere tabel staan als de gegevens over wat er

gewijzigd is. Deze tabellen worden gekoppeld op basis van de change nummers die in beide

tabellen staan. In een aantal gevallen kon deze data niet gekoppeld worden omdat de data

in de downloads niet dezelfde change nummers bevat.

Dit probleem is niet gegarandeerd op te lossen. Er zijn namelijk twee factoren die dit

verhinderen. Het is ten eerste niet mogelijk in de gebruikte download techniek om data uit

een tabel te koppelen aan een andere tabel tijdens de download. Dit zou in ons probleem

oplossen van de missende gebruikers, maar dat kan dus niet wegens een technische

beperking. Een tweede optie is om de periode grenzen nauwkeurig af te stemmen tussen

beide tabellen. Helaas is ook dat niet mogelijk omdat de tijdsaanduiding in de ene tabel (de

tabel met de inhoudelijke wijzigingen) wel aanwezig is en in de andere tabel (de tabel met

wie de wijziging heeft uitgevoerd) niet. Het blijft dus altijd onbekend welke periode er moet

worden gedownload. Dit verklaart de aangetroffen 26 gevallen zonder gebruiker. Een

mogelijke oplossing zou zijn om de data te downloaden op een selectie van changenummers

waarvan bekend is dat die in de te controleren periode vallen.


De bovenstaande constateringen hebben wij, zoals eerder al besproken, teruggelegd bij het

productiebedrijf. In het geval van de eerste bevinding, geen functievermenging tussen

plaatsing en goedkeuring bestelling, kan het productiebedrijf zich hierin herkennen. Het

eerder genoemde punt, slechts 1.201 goedkeuringen behorende bij 11.391 bestellingen, is

momenteel nog niet opgelost. Voor het productiebedrijf is dit nu geen prioriteit omdat de

gegevens in het eigen SAP systeem wel een consistent beeld geven.

De tweede bevinding, functievermenging in een aantal gevallen bij plaatsing bestelling en

goederenontvangst is ook herkenbaar voor het productiebedrijf. Het productiebedrijf zal de

specifieke bestellingen nader gaan bekijken.

51

De functievermenging bij medewerkers die stamgegevens mogen muteren en daarnaast

betrokken zijn in het inkoopproces was bekend bij het productiebedrijf. De organisatie

onderkent hier ook superuser-accounts bij te gebruiken. Dit punt wordt momenteel

gecorrigeerd.

5.9 Analyse

In het casusbedrijf is op twee punten doorkruising van de functiescheiding te constateren.

Het gaat hierbij specifiek om de functiescheiding tussen het boeken van de bestelling en de

goederenontvangst alsmede om de mutatie van stamgegevens crediteuren en

betrokkenheid in het inkoopproces. Voor de drie bevindingen zullen we hieronder de

implicaties bespreken, te starten met de eerste functiescheiding tussen het plaatsen en

goedkeuren van een bestelling.

Bevinding 1: Bestelling plaatsen vs. goedkeuring bestelling

Geautomatiseerde gegevensgerichte analyse heeft voor deze functies geen vermenging

aangetoond. Dit is misschien niet een bevinding in de traditionele zin dat het een

uitzondering is de opvolging verdiend, maar het is wel een bevinding die nieuw is.

Voorheen zou het niet constateren van gebreken in de inrichting van de functiescheiding

slechts een gedeeltelijke zekerheid hebben opgeleverd. Nu de transacties ook echt zijn

nagelopen op functievermenging kan de accountant met zekerheid zeggen dat het zich niet

heeft voorgedaan in de ERP-applicatie. Dat is een resultaat dat in de traditionele methode,

controlemaatregels testen en steekproeven, niet mogelijk zou zijn geweest. Je zou in dat

geval slechts in beperkte mate zekerheid kunnen geven.

Hier moet wel gezegd worden dat slechts een beperkt aantal goedkeuringen gekoppeld

konden worden aan de bestellingen en dat hier verder onderzoek op zijn plaats zou zijn. In

gevallen waar de data wel 100% aansluit geldt dat er voor de accountant ook 100%

zekerheid is over wat er in het SAP systeem gebeurd is gedurende de controle periode.

Bevinding 2: Bestelling plaatsen vs. de goederenontvangst

Het is voor 31 bestellingen zo dat de persoon die de goederen ontvangen heeft ook de

bestelling heeft kunnen plaatsen. Het bedrag dat hiermee totaal gemoeid gaat is maximaal €

3,2 miljoen (overschatting, zie paragraaf 5.8). Het risico is hier dat deze persoon in kwestie

goederen kan bestellen voor eigen gebruik. Op deze wijze kan er waarde aan de

onderneming worden onttrokken zonder dat dit geconstateerd wordt.

Het bedrag van € 3,2 miljoen over een periode van ruim twee jaar is wellicht voor de

accountant niet materieel op de jaaromzet van € 2 miljard. Deze functievermenging is

echter geconstateerd in de gekoppelde bestellingen en goederenontvangsten, waar het

aantal koppelingen slechts aan fractie is van het totaal (363 koppelingen op 11.391

bestellingen en 329.415 goederenontvangsten). Mogelijk is het bedrag dat gemoeid is met

functievermenging dus nog een stuk groter. In dit geval is het aan te raden voor de

52

accountant om de oorzaak van de opgetreden functievermenging te achterhalen. Op het

moment dat te achterhalen is in welke specifiek situatie de functievermenging zich

voordoet, kan de accountant deze gevallen isoleren en verder onderzoeken. Dit onderzoek

kan een totaalcontrole of steekproefsgewijze controle zijn waarbij de brondocumenten

worden opgezocht en gevalideerd op rechtmatigheid van de betaling.

Bevinding 3: Mutaties stamgegevens crediteuren vs. transacties in het inkoopproces

Voor 18 gebruikers hebben we geconstateerd dat deze zowel transacties hebben verricht in

het inkoopproces als stamgegevens van crediteuren hebben gemuteerd. In deze analyse

hebben we alleen gekeken of het voorkomt dat een gebruiker beide acties uitgevoerd heeft.

We hebben nog niet kunnen nagaan of de 18 gebruikers ook daadwerkelijk een mutatie

hebben gedaan op de stamgegevens in een bepaalde transactie die zij ook zelf uitvoerde.

Die link is momenteel niet mogelijk omdat we alleen de data hebben voor mutaties op de

stamgegevens zonder dat deze een referentie bevat naar de bijbehorende crediteur,

bestelling, goederenontvangst, factuur en betaling. Dit zou wellicht nog te koppelen zijn op

basis van de datum van de documenten en de datum van de verandering aan de

stamgegevens. Dit geeft echter geen zekerheid over de juistheid van de daaruit

voortvloeiende bevindingen.

Voor de jaarrekeningcontrole is deze bevinding niet te kwantificeren in geld. De accountant

kan in dit geval kijken wat de totale waarde is van alle facturen die op enig moment zijn

behandeld door gebruikers waarbij deze functievermenging optreedt. Op het moment dat

deze waarde de materialiteit overstijgt, kan de accountant op deze groep facturen een

steekproef trekken. Hiermee kan hij testen of deze facturen terecht zijn betaald en of het

bedrag is overgemaakt naar de juiste bankrekening.

5.10 Conclusie

In dit hoofdstuk is het eerste casusbedrijf geïntroduceerd: het productiebedrijf. Bij dit

bedrijf is het mogelijk om een deel van de functiescheidingen geautomatiseerd te testen. Dit

hebben we vastgesteld op basis van de data uit de audit trail afgezet tegen de theoretische

kaders. Dat er een deel van de theoretisch mogelijke functiescheidingen niet te testen was

komt doordat een deel van de data die hiervoor nodig is, niet binnen de termijn van het

scriptieonderzoek uit de SAP-applicatie van het productiebedrijf gehaald kon worden (zie

paragraaf 5.8).

Door het geautomatiseerd gegevensgericht testen van functiescheidingen is het mogelijk

om functiescheidingsconflicten te kwantificeren. Er zijn drie soorten functiescheidingen

getest:

1. Bestelling plaatsen vs. goedkeuren bestelling

2. Bestelling plaatsen vs. de goederenontvangst

3. Mutaties stamgegevens crediteuren vs. transacties in het inkoopproces

53

Met betrekking tot de eerste twee functiescheidingen hebben wij in de data geconstateerd

dat een beperkt aantal bestellingen gekoppeld kon worden aan een goedkeuring van deze

bestelling of een goederenontvangst op deze bestelling. Dit vormt een kanttekening bij de

resultaten op het gebied van functievermenging, in de zin dat er wellicht meer

functievermenging is opgetreden, maar dat deze niet met de huidige analyse achterhaald

kan worden. Mogelijke verklaring voor de niet gekoppelde bestellingen, goedkeuringen en

goederenontvangsten, is dat deze informatie niet op de standaardwijze in de SAP-applicatie

wordt opgeslagen waardoor deze momenteel niet traceerbaar is.

De resultaten zijn als volgt. Bij punt één is er geen functievermenging opgetreden in de data

die wij hebben kunnen aansluiten. Er is voor € 3,2 miljoen aan transacties gevonden waarbij

functievermenging opgetreden is bij het tweede punt. Het betreft hier 31 gevallen. Op het

laatste punt hebben wij geconstateerd dat er 18 gebruikers zijn waar er functievermenging

is opgetreden tussen muteren in stamgegevens en verrichte transacties in het inkoopproces.

Voor alle drie de geautomatiseerd geteste functiescheidingen geldt dat er nog nader

onderzoek door de accountant nodig is om het daadwerkelijke risico’s voor de jaarrekening

te kunnen kwantificeren.

54

6 Casusbedrijf 2: Het detailhandelsbedrijf

6.1 Inleiding

In dit hoofdstuk introduceren we het tweede casusbedrijf. De opbouw van het hoofdstuk is

in overeenstemming met het voorgaande hoofdstuk over het productiebedrijf. Het

analyseproces en de analyseresultaten van het tweede casusbedrijf zullen in dit hoofdstuk

aan de orde komen.

We beginnen het hoofdstuk met een algemene introductie van het bedrijf in paragraaf 6.2.

Vervolgens behandelen we kort de door ons gekozen onderzoeksaanpak gevolgd door de

inrichting van het inkoopproces voor dit specifieke bedrijf. De inrichting van het

inkoopproces bij het detailhandelsbedrijf zetten we af tegen de theorie zoals geschetst in

hoofdstuk 2 in paragraaf 6.3. Hierna wordt beschreven hoe het detailhandelsbedrijf zich

verhoudt ten aanzien van de randvoorwaarden zoals beschreven in hoofdstuk 3 in paragraaf

6.4. Op basis van de karakteristieken van de ontvangen data (zie paragraaf 6.5) en de

uiteenzetting over analysetechnieken in hoofdstuk 4 zal vervolgens de analysetechniek voor

deze casus worden bepaald.

Na afronding van dit theoretische deel van de casus worden de resultaten van deze tweede

casus beschreven. Hierbij komen de te testen functiescheidingen (paragraaf 6.6) en

gebruikte analysetechniek (paragraaf 6.7) aan de orde. De resultaten van mogelijke

doorkruising van functiescheidingen worden beschreven in de resultaten in paragraaf 6.8.

Het geheel van dit hoofdstuk wordt afgesloten door een analyse van de resultaten in

paragraaf 6.9 en tot slot met de conclusie met daarin de impact die deze bevindingen

zouden hebben op de jaarrekeningcontrole in paragraaf 6.10.

6.2 Beschrijving organisatie

Evenals het eerste bedrijf heeft ook dit bedrijf de voorwaarde gesteld dat het anoniem

wenst te blijven. Daarom zal ook hier de beschrijving van het bedrijf op hoofdlijnen zijn en

geen herkenbare details bevatten.

In 1961 is het detailhandelsbedrijf opgericht dat in deze casus wordt beschreven. Het bedrijf

is een internationale keten met wereldwijd ongeveer 1600 vestigingen verdeeld over 15

landen. In de casus hebben wij specifiek de organisatie van de Benelux divisie bekeken. Dit is

een zelfstandig opererende organisatie. Als we in dit hoofdstuk over het

detailhandelsbedrijf spreken, dan bedoelen we de Benelux divisie van het

detailhandelsbedrijf. Het detailhandelsbedrijf beschikt over ongeveer 500 winkels in de

Benelux. De jaaromzet van het detailhandelsbedrijf is ongeveer € 200 miljoen per jaar.

55

6.3 Het inkoopproces bij het detailhandelsbedrijf

Dit detailhandelsbedrijf maakt sinds december 2004 gebruik van Navision als ERP-applicatie

voor het ondersteunen van alle financiële bedrijfsprocessen. Het inkoopproces wordt dus

ook ondersteund in de applicatie. In Navision worden alle handelingen in het inkoopproces

vanaf moment van bestelling tot betaling vastgelegd. Transactiedata is daardoor terug te

vinden, de goedkeuringsslagen (controle bestelling, controle factuur) vinden echter buiten

de applicatie plaats. Deze informatie is niet te achterhalen uit de applicatie.

Het detailhandelsbedrijf kent twee inkoopprocessen. Het ene inkoopproces is ingericht voor

handelsgoederen, het tweede richt zich op inkoop van goederen die niet voor de handel zijn

(o.a. kantoorartikelen). De processen verlopen in grote lijnen gelijk. De inkopen die worden

gedaan voor de handel worden geïnitieerd door de winkelmanager en vervolgens verzameld

op de inkoopafdeling. In sommige gevallen bestelt de winkelmanager direct bij de

leverancier. De bestellingen die niet voor de handel zijn, komen direct op de inkoopafdeling

binnen. Goederen worden in het centrale magazijn ontvangen en vervolgens gedistribueerd

naar de vestigingen.

De inkoopafdeling en crediteurenadministratie op het hoofdkantoor van het

detailhandelsbedrijf bestaan beiden uit ongeveer tien personen. Op het hoofdkantoor is de

organisatie dus van voldoende omvang om de functiescheidingen in het inkoopproces

organisatorisch te implementeren.

Nu duidelijk is dat functiescheiding organisatorisch haalbaar is bij het detailhandelsbedrijf,

gaan wij onderzoeken hoe het detailhandelsbedrijf zich verhoudt ten aanzien van de overige

randvoorwaarden.

6.4 Aanwezige randvoorwaarden

In hoofdstuk 3 zijn de randvoorwaarden uiteengezet waaraan een organisatie moet voldoen

om betrouwbaar de functiescheiding geautomatiseerd gegevensgericht te kunnen testen.

Deze paragraaf laat zien hoe bij het detailhandelsbedrijf de randvoorwaarden

geïmplementeerd zijn.


Als eerste de vastleggingen bij het detailhandelsbedrijf. De primaire vastlegging van het

plaatsen van de bestellingen vindt plaats in de ERP-applicatie. De registratie van

magazijnontvangstbonnen en facturen wordt secundair vastgelegd in de ERP-applicatie na

ontvangst van het fysieke document. De goedkeuring van de bestelling en goedkeuring van

de factuur vindt op papier plaats. Fysieke documenten gaan door de organisatie om de

benodigde goedkeuring te verkrijgen. De secundaire vastlegging van de goedkeuring is terug

te vinden in de applicatie. Dit gebeurt echter niet expliciet. Het daadwerkelijk bestellen van

goederen en betalen van een factuur impliceert dat de goedkeuring verkregen is. Het is

echter niet uit de ERP-applicatie wie op welk moment precies goedkeuring heeft verleend.

56


Met betrekking tot de organisatorische inrichting zouden de volgende zaken moeten gelden:

1. Het bewaren van de audit trail gegevens is niet in handen van iemand van wie de

acties geregistreerd zijn in de audit trail.

2. Het configureren van de audit opties is niet toegankelijk voor personen waarvoor

acties geregistreerd moeten worden.

3. De geautomatiseerde analyse op functiescheiding wordt niet uitgevoerd door een

persoon die zelf in de audit trail voor kan komen.

Bovenstaande elementen zijn zodanig geïmplementeerd bij het detailhandelsbedrijf. De

data die wordt opgeslagen naar aanleiding van transacties die worden uitgevoerd, is niet te

muteren door medewerkers die zelf transacties uitvoeren, alleen door beheerders. De audit

opties kunnen niet voorkomen dat deze informatie wordt opgeslagen. Aan deze

randvoorwaarde is daardoor ook voldaan. Ten aanzien van de uitvoering van de

geautomatiseerde gegevensgerichte analyse van de functiescheiding geldt dat deze in dit

geval niet door het detailhandelsbedrijf zelf wordt uitgevoerd, maar door de schrijvers als

externe partij. Aan de laatste voorwaarde is dus in deze ook voldaan.

Voor het geautomatiseerd gegevensgericht testen van de functiescheidingen is het van

belang dat de integriteit van de audit trail gewaarborgd is. De applicatiebeheerders zijn de

medewerkers die deze audit trail kunnen wijzigen. Organisatorisch heeft het

detailhandelsbedrijf er voor gezorgd dat deze beheerders geen rol hebben in het

inkoopproces en daarmee geen belang bij de inhoud van de audit trail. Daarnaast heeft het

detailhandelsbedrijf voor alle gebruikers een account aangemaakt, waarbij de regel is dat

elke gebruiker gebruik maakt van zijn eigen unieke account, ten behoeve van de

traceerbaarheid van de geregistreerde handelingen in de applicatie. Daarnaast geldt dat de

accountantscontrole van het jaar voorafgaande aan onze data extractie een positief oordeel

vormde over de IT-omgeving. Dit geeft ons extra zekerheid over de juiste naleving van de

maatregelen in het proces en in de IT-omgeving.

Het detailhandelsbedrijf voldoet dus aan de randvoorwaarden om geautomatiseerde

gegevensgerichte analyses op functiescheidingen te kunnen uitvoeren. Met deze kennis

kunnen we vervolgens bekijken welke analysetechniek het meest bruikbaar is in deze casus.

6.5 Dataset definitie

Het detailhandelsbedrijf maakt sinds december 2004 gebruik van Navision, wij hebben voor

de gehele periode dat Navision in gebruik is de transactiedata van het inkoopproces

opgevraagd en ontvangen. Dit houdt in dat wij de data hebben ontvangen voor de periode 8

december 2004 tot en met 14 januari 2009, een periode van ruim vier jaar.

De benodigde tabellen om de functiescheidingen te testen zijn bekend op basis van

documentatie en ervaring van collega’s van Deloitte met de ERP-applicatie Navision. Om de

benodigde informatie voor geautomatiseerd gegevensgericht testen van functiescheidingen

57

te achterhalen hebben wij een verzameling tabellen verkregen van het detailhandelsbedrijf.

De data voor het detailhandelsbedrijf hebben wij ontvangen als DAT-bestanden met data.

Deze bestanden hebben een vaste recordopbouw, zie het voorbeeld hieronder van een deel

van de data.

Wij hebben data ontvangen voor diverse geografische bedrijfsdelen van het

detailhandelsbedrijf. Het grootste bedrijfsonderdeel hebben wij geselecteerd voor onze

analyse, dit onderdeel betrof de Benelux.

6.6 Te testen functiescheidingen

Hieronder is een overzicht weergegeven van de benodigde informatie om de gewenste

functiescheidingen te testen, zoals gedefinieerd in paragraaf 2.3. Per item is vervolgens

aangegeven of de informatie wordt vastgelegd in de applicatie van het detailhandelsbedrijf

en of wij deze beschikbaar hebben kunnen maken voor de analyse.

Informatie Aanwezig Beschikbaar

Plaatsing bestelling Ja Ja

Controle bestelling Nee Nee

Goederenontvangst Ja Ja

Registratie factuur Ja Ja

Controle factuur Nee Nee

Betaling factuur Ja Ja

Mutatie stamgegevens crediteur Nee Nee

Tabel 5 - Beschikbare informatie detailhandelsbedrijf

Zoals eerder aangegeven in paragraaf 6.3 vinden de controleslagen plaats buiten de

applicatie, daardoor is deze informatie niet beschikbaar voor analyse. Ook mutaties in de

stamgegevens zijn niet te achterhalen uit de applicatie omdat het detailhandelsbedrijf de

zogenaamde “change log” niet heeft geactiveerd. Hierdoor worden wijzigingen op o.a.

stamgegevens crediteuren niet integraal vastgelegd.

Op basis van de informatie die wel beschikbaar is vanuit Navision van het

detailhandelsbedrijf is het mogelijk om de volgende functiescheidingen te testen:

Figuur 5 - Voorbeeld data detailhandelsbedrijf

58


in ontvangst neemt (oranje);

- Een medewerker die de factuur registreert, is niet de medewerker die de factuur

betaalbaar stelt (rood).

Zie ook de grafische weergave van de functiescheiding die in het bedrijf getest kunnen

worden in relatie tot het inkoopproces zoals dat is gedefinieerd in paragraaf 2.3 in de

onderstaande figuur.

Inkoopproces



Controle

bestelling


Magazijn

ontvangstbon

Magazijn

ontvangstbon

Goederen Goederen

Controle

met

bestelling

Factuur Factuur

Controle

factuur

Factuur

Boeken op

grbkrekg

crediteuren

Magazijn

ontvangstbon

BestellingBoeken op

rekening te

ontv fact

Bestelling

Voorraad

boeking

Magazijn

ontvangstbon

Voorraad

boeking

Betalen

factuur

Invoer stam

gegevens

crediteuren

Figuur 6 - Te testen functiescheidingen detailhandelsbedrijf

Bovenstaande functiescheidingen zullen dus bekeken worden, op grond van de ontvangen

data. De in paragraaf 2.3 genoemde vijf relevante functiescheidingen voor de

jaarrekeningcontrole kunnen dus niet allemaal getest worden voor het detailhandelsbedrijf.

De volgende drie functiescheidingen zullen niet getest worden:

• Een medewerker die mutaties in stamgegevens van crediteuren doorvoert,

verricht geen transacties in het inkoopproces;

• Een medewerker die een bestelling plaatst, is niet de medewerker die

goedkeuring verleent op die bestelling;

59


die de controle op de factuur uitvoert en andersom.

In de volgende paragraaf zullen wij onderzoeken welke analysetechniek het meest geschikt

is om de ontvangen data te gebruiken voor geautomatiseerd gegevensgericht testen.

6.7 Keuze analysetechniek

Zoals blijkt uit de uiteenzetting over mogelijke analysetechnieken in hoofdstuk 4, en zoals al

aangestipt in het voorgaande hoofdstuk, is ACL in het algemeen de meest geschikte tool bij

data analyse in het verband van dit onderzoek. Ook de data die wij nu hebben ontvangen is

het meest geschikt om met ACL te analyseren. Hieronder zullen we de verschillende

analysetechnieken bespreken in relatie tot de ontvangen data, om zo de voor- en nadelen

van de verschillende technieken in dit geval te bespreken.

ProM/LTL

Voor ProM + LTL geldt dat deze data eerst geconverteerd zal moeten worden naar een XML

format met een identifier. Dit vergt een aantal acties terwijl de data zonder extra acties

direct in ACL ingelezen kan worden.

SAS

Voor SAS geldt dat we handmatig de audit opties aan zullen moeten zetten en dat er niet

direct inzicht is in de data. Dit is een nadeel gezien de nieuwe onderzoeksmethode die wij

aan het ontwikkelen zijn. In deze onderzoeksituatie is het noodzakelijk om de data goed

inzichtelijk te hebben zodat de volgende stap in het onderzoek goed en snel te vinden is.

SQL

De ontvangen data betreft geen SQL database, de data zal eerst handmatig moeten worden

omgezet naar een database voordat SQL als techniek toegepast kan worden. Dit zal veel tijd

kosten gezien er geen standaard filter beschikbaar is voor deze data.

ACL

Met behulp van ACL kan snel bestandsonderzoek uitgevoerd kan worden om inzicht te

krijgen in de data. Nadeel van ACL is de hoeveelheid data die opgeslagen moet worden

gedurende de analyse. De bestanden zoals wij die hebben ontvangen voor deze analyse zijn

echter niet groter dan ongeveer 2 gigabyte, hiervoor is voldoende opslagcapaciteit

beschikbaar om de analyse probleemloos uit te voeren.

Op grond van bovenstaande overwegingen hebben wij ervoor gekozen om in deze casus ACL

als analysetechniek in te zetten.

60

6.8 Resultaten

In deze paragraaf zullen we de resultaten van de analyse bespreken. We bespreken eerst

het doorlopen analyseproces, hierbij zullen wij teruggrijpen naar de onderzoeksaanpak zoals

besproken in 1.4. Ook de resultaten van de analyse komen aan bod, in de volgende

paragraaf zullen we de impact van deze resultaten op de jaarrekening bespreken.

Analyseproces


We hebben van de interne audit afdeling van het bedrijf begrepen dat bij het inkoopproces

alleen maar gebruik wordt gemaakt van Navision. Er zijn verder geen andere applicaties

betrokken. De stappen die niet in Navision zitten worden handmatig uitgevoerd.


zit met betrekking tot de door ons gekozen functiescheidingen.

Navision is als ERP-applicatie aanzienlijk minder uitgebreid dan SAP. De tabelnamen die

worden gehanteerd zijn helder en verklarend en de relaties tussen tabellen zijn relatief

simpel. Op basis van de ervaring die de auteurs en collega’s van Deloitte hebben met

Navision hebben wij een lijst opgesteld met de tabellen die benodigd zijn voor de

geautomatiseerde gegevensgerichte analyse van functiescheidingen.

3) Extraheren van de data uit de ERP-applicatie.

Nu bekend was welke tabellen benodigd waren voor de analyse, hebben wij een collega

gevraagd deze tabellen te laten downloaden bij de klant. De tabellen zijn handmatig uit de

ERP-applicatie geëxporteerd. Wij hebben de data ontvangen voor diverse

bedrijfsonderdelen die bij het detailhandelsbedrijf in gebruik zijn. De omvang van de data

was handzaam en tijdens het exporteren hebben zich geen technische moeilijkheden

voorgedaan.


standaard inkoop proces.

De functiescheidingen die getest kunnen worden op basis van de data, zijn:


in ontvangst neemt.

- Een medewerker die de factuur registreert, is niet de medewerker die de factuur

betaalbaar stelt.


61

Met de beschikbare data hebben we vervolgens de tests geprogrammeerd en gedraaid in

ACL. De data bevatte de volgende informatie die bruikbaar was voor onze analyse:

Informatie Aantal rijen Bedrag

Geplaatste bestellingen 637.783 Niet bekend

Goederenontvangsten (soms meerdere per

bestelling)

860.218 € 39,8 miljoen

Goederenontvangsten gekoppeld

aan een bestelling

587.866 € 25,1 miljoen

Geregistreerde facturen 26.305 € 271,5 miljoen

Betaalbaar gestelde facturen 16.582 Niet bekend

Geregistreerde facturen gekoppeld

aan een betaling

9.040 € 88,0 miljoen

Tabel 6 - Karakteristieken van beschikbare data

Op basis van deze informatie is het mogelijk twee functiescheidingen geautomatiseerd

gegevensgericht te testen. Hieronder zullen per geteste functiescheiding de resultaten

beschrijven.

Bestelling plaatsen vs. de goederenontvangst

De ongeveer 638.000 bestellingen hebben ongeveer 860.000 goederenontvangsten als

gevolg gehad. Van deze goederenontvangsten en bestellingen is het op basis van de

ontvangen informatie mogelijk om er 588.000 met elkaar in verbinding te brengen. De

koppeling van bestellingen met goederenontvangsten vindt plaats op basis van een

omschrijvingveld dat met vrije tekst kan worden gevuld. Hierbij wordt geen vast format

afgedwongen door de applicatie. Gezien de hoge hoeveelheid gekoppelde instanties wordt

het veld wel consequent gevuld, echter door kleine verschillen hierin kunnen niet

gekoppelde bestellingen en goederenontvangsten verklaard worden. We hebben ervoor

gekozen om deze gevallen uit te sluiten in ons onderzoek omdat het handmatig uitzoeken

van elk verschil te veel tijd gaat kosten (we hebben het hier over enkele duizenden).

Voor de gevallen waar wel een koppeling is gemaakt is op basis van de data te constateren

dat alle gevallen de bestelling en de goederenontvangst door dezelfde persoon

geregistreerd zijn. Voor 550.000 gevallen geldt dat de bestellingen en goederenontvangst

door één van de twee batch-users zijn geplaatst. Hierbij zou dus geen sprake hoeven zijn

van functievermeningen. Enige navraag bij het bedrijf gaf wel aan dat de functionarissen die

deze batch accounts gebruiken wel in staat zijn om deze informatie te wijzingen. Het betreft

hier dus niet een volledig automatisch proces dat afgeschermd is van de eindgebruikers.

Registratie factuur vs. betaling factuur

62

De ruim 26.000 geregistreerde facturen hebben uiteindelijk geleid tot ruim 16.500

betalingen. Betalingen worden hierbij ook regelmatig gecombineerd uitgevoerd voor

facturen. De connectie tussen de geregistreerde facturen en de betalingen bestaat uit een

combinatie van het leveranciersnummer met het externe factuurnummer, het

factuurnummer dat de leverancier opgeeft. Bij de registratie van de factuur wordt ook dit

veld middels een vrij tekstveld ingegeven in Navision, dit maakt dat het format niet

eenduidig is. Bij de factuurregistratie wordt dit nummer wel redelijk consequent zonder

verdere toevoegingen ingegeven. Bij de betalingen is vaak een toevoeging qua tekst

opgegeven, of is zijn meerdere factuurnummers ingegeven. In veel gevallen is het veld niet

gevuld en kan het factuurnummer uit het veld factuuromschrijving gehaald worden, dit is

echter ook een vrij tekstveld met de bijbehorende moeilijkheden voor geautomatiseerde

analyse. Van de 16.500 betalingen zijn er krap 10.000 die een factuurnummer bevatten op

basis waarvan de koppeling met de registraties gemaakt kan worden.

In 9.040 gevallen is het mogelijk een koppeling te maken tussen factuurregistratie en

betaling. Van de gekoppelde facturen zijn er 286 door dezelfde user geregistreerd en

betaalbaar gesteld. Deze facturen vertegenwoordigen een totale waarde van € 2,9 miljoen.

Het betreft één factuur van bijna € 500.000, 11 facturen tussen de € 250.000 en €50.000. De

resterende 274 facturen hebben een waarde van onder de € 50.000 per factuur.


Deloitte is niet bij het detailhandelsbedrijf betrokken als controlerend accountant, maar als

onderdeel van de afdeling internal audit van het detailhandelsbedrijf. De resultaten van

beide functiescheidingen zijn teruggelegd bij het team van Deloitte dat onderdeel uitmaakt

van dit internal audit team.

Het detailhandelsbedrijf zelf heeft momenteel niet voldoende capaciteit om de resultaten te

interpreteren. Het team van Deloitte heeft aangegeven dat het waarschijnlijk is dat de

geconstateerde functievermengingen zich daadwerkelijk hebben voorgedaan. De volledige

functievermenging bij de medewerkers die bestellingen plaatsen en goederen ontvangen zal

nader verklaard moeten worden door de medewerkers van het detailhandelsbedrijf zelf.

6.9 Analyse

Bij het tweede casusbedrijf is het mogelijk geweest een tweetal functiescheidingen te testen

op basis van de gegevens uit de audit trail. In het casusbedrijf is op twee punten

doorkruising van de functiescheiding te constateren. Het gaat hierbij specifiek om de

functiescheiding tussen het boeken van de bestelling en de goederenontvangst evenals om

de registratie van de factuur en de betaling van de factuur. Hieronder zullen we bespreken

wat deze bevindingen precies omvatten.

Bevinding 1: Bestelling plaatsen vs. de goederenontvangst

De medewerker die de bestelling plaatst is in alle gevallen ook de medewerker is die de

goederenontvangst registreert. Dit impliceert dat bij het detailhandelsbedrijf de

63

transactiedata van deze stappen niet apart worden geregistreerd. Als deze functiescheiding

niet organisatorisch is ingeregeld, is het wel onwaarschijnlijk dat in alle gevallen dezelfde

medewerker de bestelling plaatst en de goederenontvangst registreert. Een mogelijkheid is

dat de goederen wel door een andere medewerker in ontvangst zijn genomen maar dat de

magazijnontvangstbon vervolgens op de inkoopafdeling wordt geregistreerd in de

applicatie.

In het geval dat de functiescheiding voor deze transacties werkelijk niet is ingeregeld loopt

de organisatie het risico dat een medewerker goederen bestelt, deze zelf in ontvangst

neemt en ontvreemdt. Het totale bedrag van € 25 miljoen (periode 8 december 2004 t/m 14

januari 2009) aan gekoppelde bestellingen en goederenontvangsten, op een jaaromzet van

€ 200 miljoen, is een punt om te bekijken in de jaarrekeningcontrole. De accountant zou in

dit geval een steekproef van bestellingen kunnen trekken om te kijken of de bestellingen

gerechtvaardigd zijn en geen waarde ongezien aan het bedrijf is onttrokken.

Bevinding 2: Registratie factuur vs. betaling factuur

Ruim 9.000 facturen en betalingen zijn aan elkaar gekoppeld, hierin is in 286 gevallen

geconstateerd dat de factuur door eenzelfde persoon geregistreerd en betaalbaar is gesteld.

Deze facturen vertegenwoordigen een totale waarde van € 2,9 miljoen. Het is de vraag of

deze post materieel is voor de jaarrekeningcontrole van dit bedrijf, zeker gezien het feit dat

deze analyse over data over een periode van 4 jaar is uitgevoerd.

De accountant zou in ieder geval steekproefsgewijs kunnen onderzoeken of de facturen

terecht betaalbaar zijn gesteld, en dat er geen sprake is van fraude. Kanttekening bij het

bedrag van € 2,9 miljoen in relatie tot de materialiteit is dat niet alle facturen en betalingen

gekoppeld zijn. Hierdoor is het bedrag waarbij functievermenging is opgetreden mogelijk

groter dan de eerder genoemde € 2,9 miljoen. De niet gekoppelde facturen zullen ook nog

door de accountant moeten worden onderzocht op mogelijke functievermenging.

6.10 Conclusie

De geautomatiseerde gegevensgerichte analyse van functiescheidingen heeft voor het

detailhandelsbedrijf ingehouden dat een tweetal functiescheidingen zijn getest:

1. Bestelling plaatsen vs. de goederenontvangst

2. Registratie factuur vs. betaling factuur

Door gebruik van vrije tekstvelden op basis waarvan bestellingen, goederenontvangsten en

facturen gekoppeld moeten worden, is het niet in alle gevallen mogelijk geweest deze zaken

te koppelen. Voor de regels die wel gekoppeld zijn, zijn de functiescheidingsanalyses

uitgevoerd. In het geval van de eerste functiescheiding is geconstateerd dat de scheiding in

functies niet is aangetoond op basis van de geautomatiseerde gegevensgerichte analyse. De

test op de tweede functiescheiding gaf aan dat in 286 gevallen met een waarde van € 2,9

miljoen functievermenging is opgetreden. In beide gevallen geldt dat de accountant in de

64

jaarrekeningcontrole steekproefsgewijs met behulp van brondocumentatie kan achterhalen

of er sprake is van onttrekking van waarde aan het bedrijf waar dit niet gewenst is.

Hiermee sluiten we de praktijkcasussen af. In het volgende hoofdstuk volgt een algemene

analyse van het proces en de resultaten. Daarbij zullen we de resultaten vertalen naar de

impact voor de accountantscontrole op de jaarrekening.

65

7 Algemene analyse en conclusie

7.1 Inleiding

In dit hoofdstuk zullen wij, op basis van de voorafgaande hoofdstukken, de onderzoeksvraag

bevestigen dan wel weerleggen. De onderzoeksvraag luidde als volgt:




In paragraaf 7.2 geven we een terugblik op de theorie uit de hoofdstukken 1, 2, 3 en 4 en

deze in de context plaatsen van de resultaten van de casusbedrijven uit hoofdstuk 5 en 5.

We zullen de theoretische randvoorwaarden vergelijken met wat we in de praktijk hebben

aangetroffen (paragraaf 7.3). Met de gevonden resultaten evalueren we de door ons

gekozen aanpak voor de analyse en geven de suggesties tot verbetering van deze analyse

aanpak (paragraaf 7.4). Dan volgt een korte terugblik op de resultaten vanuit de

casusbedrijven in paragraaf 7.5 als inleiding op de analyse. Dan analyseren we de impact

van deze nieuwe manier van testen van functiescheiding op de jaarrekeningcontrole van de

accountant (paragraaf 7.6). De accountant zal namelijk ook kritisch moeten kijken naar zijn

huidige aanpak in het licht van de nieuwe ontwikkelingen. Tot slot zullen we de

probleemstelling van onze scriptie beantwoorden en afsluiten met een conclusie in

paragraaf 7.7.

7.2 Discussie terugkoppeling van de resultaten naar het theoretische model

In hoofdstuk 2 hebben we een theoretisch kader geschetst om de resultaten van de

casusbedrijven te kunnen interpreteren en te kunnen vergelijken. Hier zullen we evalueren

in hoeverre dit model valide en bruikbaar is.

Voor beide casusbedrijven geldt dat het inkoopproces van het bedrijf te modelleren valt in

termen van de algemene beschrijving gegeven in hoofdstuk 2. Dit is te zien in de paragrafen

5.3 en 6.3. Voor beide bedrijven geldt ook dat de door ons gedefinieerde functiescheidingen

ook relevant zijn en binnen het bedrijf als kritisch worden gezien. Dit blijkt uit de

procesbeschrijvingen en informatie vanuit de accountant. De bedrijven hebben namelijk

preventieve maatregelen ten behoeve van functiescheiding. Dit is geïmplementeerd door

middel van gebruikersbeheer configuratie opties in de ERP-applicatie. Dit bevestigt ook de

behoefte van de bedrijven om deze functiescheidingen te bewaken. Dat model kunnen we

dus beschouwen als een juiste abstractie om het geautomatiseerd en gegevensgericht

testen op te baseren.

66

In gesprekken met de accountant en de IT-auditor over de resultaten van ons onderzoek

bleek dat deze functiescheidingen ook voor de jaarrekeningcontrole relevant zijn. De

gekozen scope van het standaardmodel is dus relevant. De scope is uiteraard niet volledig

aangezien het hier een abstractie betreft.

Verder wordt bij geen van de bedrijven, zowel intern als door de accountant, een controle

gedaan op transactieniveau om na te gaan of de functiescheidingsmaatregelen ook

daadwerkelijk gewerkt hebben gedurende het jaar. De uitgevoerde analyse heeft hen dan

ook nieuwe resultaten en inzichten opgeleverd ten aanzien van de voorgaande

functiescheidingstesten. Het productiebedrijf gaf ook aan dat het gelijk helder was welke

gebruikers betrokken waren en welke transacties het betrof. Hierdoor is voor hen de follow-

up makkelijker te doen dan in de traditionele situatie.

In de traditionele situatie levert de IT-auditor wel een lijst op met mogelijke

functiescheidingrisico’s maar niet of deze ook daadwerkelijk zijn opgetreden. Hierop moest

het bedrijf zelf uitzoeken om welke transacties (als deze er al waren) het mogelijk zou

kunnen gaan. Dit is precies de exercitie die wij getracht hebben te automatiseren zodat er

gelijk geïdentificeerd kan worden over welke transacties het gaat, maar ook dat het

betrokken bedrag gekwantificeerd kan worden. Deze conclusie brengt ons gelijk bij het

volgende onderwerp; zijn alle randvoorwaarden vervult voor de analyse?

7.3 Randvoorwaarden

In hoofdstuk 3 zijn de randvoorwaarden voor geautomatiseerde gegevensgerichte analyse

beschreven. Dit betreft randvoorwaarden op het gebied van primaire vastlegging en de

organisatorische inrichting.


Met betrekking tot de organisatorische inrichting zijn de randvoorwaarden ongewijzigd

gebleven op basis van de analyseresultaten bij de casusbedrijven. De volgende zaken dienen

te gelden voor de organisatie waarvoor de analyse wordt uitgevoerd:

1. Het bewaren van de audit trail gegevens mag niet in handen zijn van een functionaris

wiens acties geregistreerd zijn in het audit trail.

2. Het configureren van de audit trail instellingen die bepalen wat in het audit trail

wordt vastgelegd, mag niet toegankelijk zijn voor functionarissen wiens acties inde

audit trail worden opgeslagen.

3. De geautomatiseerde gegevensgerichte testwerkzaamheden en de configuratie

daarvan mogen niet worden uitgevoerd door een functionaris wiens acties

geregistreerd zijn in het audit trail.


67

In de casusbedrijven was de benodigde informatie om de functiescheidingen te testen

grotendeels primair of secundair beschikbaar. In de praktijk bleek het echter lastig om de

benodigde informatie terug te vinden in de ERP-applicatie. Hiervoor bleek, zeker in het geval

van het productiebedrijf, specialistische kennis van de ERP-applicatie en de inrichting van

het inkoopproces bij het bedrijf een randvoorwaarde.

Een deel van de informatie bleek niet in digitale vorm in de ERP-applicatie beschikbaar te

zijn. Concreet gaat hier erom dat de goedkeuringen op een bestelling in een externe

applicatie of op papier werden geregistreerd. In het geval van papieren goedkeuring zonder

terugkoppeling naar de ERP-applicatie is geautomatiseerde analyse niet mogelijk. In het

geval van de externe applicatie voor goedkeuringen, bij het productiebedrijf, was er wel

terugkoppeling aan de ERP-applicatie, maar dit werd niet opgeslagen op de standaard plek

in het datamodel. In beide gevallen zijn er dus geen testen mogelijk geweest om de

aanvrager van de bestelling te vergelijken met de persoon die de bestelling goedkeurde.

Op basis van deze is ervaring is het aan te bevelen om een volgende keer eerst helemaal in

kaart te brengen welke informatie waar geregistreerd wordt en dan pas aan de data

extractie en het analyseproces te beginnen. Deze benodigde kennis kan worden gezien als

een aanvullende randvoorwaarde.

Op basis van bovenstaande ervaringen ten aanzien van de randvoorwaarden is het goed om

nog eens kritisch te kijken naar de analyse aanpak en dan de geleerde lessen hierop te

projecteren. Dit komt in de volgende paragraaf aan de orde.

7.4 De gevolgde analyse aanpak

Voor de analyse geldt dat we een keuze in de analysetechniek hebben gemaakt en dat we

het stappenplan gevolgd hebben bij beide casussen. Laten we beginnen met de

analysetechniek.

Analysetechniek

De criteria (zie paragraaf 4.2) hielpen ons met het maken van de keuze van een juiste

techniek voor de analyse van de aangeleverde data. De analysetechniek die we in beide

casussen gebruikt hebben is ACL. Deze techniek blijkt in staat om de gevraagde hoeveelheid

data te verwerken en doet dit ook in een acceptabele tijd van enkele tientallen minuten per

onderzoeksvraag.

Daarnaast werkten de inleesfilters om de beide datasets in te lezen (met enige handmatige

aanpassingen). De analysetechniek heef in dit onderzoek geen beperking veroorzaakt.

Omdat de analysetijd sterk afhangt van de gebruikte rekenkracht geven we hier even ter

referentie een beschrijving van het platform dat wij gebruikt hebben:

• Een dual core processor draaiende op 2000 MHZ

• 500 GB Raid 1 opslagconfiguratie

68

Het systeem heeft een aanschafwaarde van ongeveer € 1.500 en levert acceptabele

prestaties op de door ons geanalyseerde datasets. Dit geeft dus voor de grotere

binnenlandse klanten en middelgrote multinationals de optie om geautomatiseerd

gegevensgericht functiescheidingen te testen. Laten we dan nu kijken naar de door ons

gevolgde aanpak en de verbeterpunten hierin.

Onderzoeksaanpak

De aanpak die we volgden leverde ons een aantal uitdagingen op. Wij zullen de drie

belangrijkste hiervan bespreken.

Als eerste bleek het in de praktijk lastig om een bedrijf te vinden dat de benodigde dat

beschikbaar wilde stellen. Bij veel bedrijven heerst culturele weerstand om de data die

nodig is voor een geautomatiseerde gegevensgerichte analyse beschikbaar te stellen aan

een externe partij. Dit heeft vooral te maken met privacy en met vertrouwelijkheid van de

gegevens. Feitelijk zijn deze bezwaren wel op te lossen met encryptietechnieken maar het

zal dit blijft een bezwaar voor bedrijven. Op termijn zal een bedrijf hier meer aan gewend

raken.

Ten tweede bleek dat de extractie zelf moeilijk kon zijn. De hoeveelheden data die we nodig

hebben voor een analyse waren geen standaard downloads voor de diverse

applicatiebeheerders. Zij hadden dan ook moeite om aan onze verzoeken te voldoen. Het

gebruik van automatische technieken heeft wel geholpen maar deze hebben wij pas later

ingezet. Dit leverde verschillen op in de tijdigheid van de data tijdens de analyse.

De derde uitdaging is dat veel standaard ERP-applicaties bij bedrijven niet standaard zijn

geïmplementeerd. Er is regelmatig sprake van aanpassingen in de goedkeuringsprocedure of

van maatwerk op het inkoopproces. Hierbij is in de analyse dus ook altijd een stukje

maatwerk nodig. Dit wordt vaak als verlies gezien en werkt demotiverend zowel bij de

analisten als bij de klant. Een betere voorlichting over het proces en inschatting van de

tijdsvereisten kan hierbij helpen.

De derde genoemde uitdaging had minder invloed gehad als wij meer aandacht hadden

besteed aan het vooraf juist in kaart brengen van de informatiestromen tussen de

verschillende applicaties. Deze informatie is nodig om de juiste informatie uit het systeem

het halen en om dus ook zoveel mogelijk van de functiescheidingen te kunnen testen.

Echter, de benodigde detailkennis van de ERP-applicaties om dit in een keer goed te doen

ontbrak. Voor beide bedrijven was beperkte gelegenheid om gebruik te kunnen maken van

experts van het bedrijf zelf om het proces in detail uit te leggen. Bij een vervolgtraject is dit

wel een factor die meegenomen moet worden om het project succesvol te maken.

Het gebrek aan kennis heeft tot gevolg gehad dat we met een aantal aannames moesten

werken en daar bleek een deel niet van te kloppen in de praktijk. Dit heeft impact gehad op

het proces. Het eerste effect was dat de doorlooptijd van het proces is hierdoor erg lang

geweest omdat elk stapje proefondervindelijk vastgesteld moest worden. Een tweede effect

69

is dat onze analyse niet volledig is ten aanzien van de theoretische functiescheidingen en de

uitwerking daarvan in de praktijk. Wij beschouwen deze lessen als een eenmalige

investering. Bij een volgend onderzoek verwachten we op basis van de geleerde lessen

efficiënter en vollediger te kunnen zijn of in ieder geval op voorhand al in te kunnen

schatten dat bepaalde tests niet mogelijk zijn.

In het geval van de in dit onderzoek al geanalyseerde bedrijven is het mogelijk om zonder

veel moeite de tests te herhalen. Uiteraard moeten we dan eerst de aangetroffen

uitzonderingen op het standaardproces verder uitzoeken en bekijken hoe de volledige set

aan functiescheidingen te testen is.

Voor een nieuw bedrijf en een nieuwe ERP-applicatie zal de leercurve waarschijnlijk weer

vergelijkbaar groot zijn. Een goede voorbereiding op basis van de geleerde lessen zal

bijdragen aan een efficiënter verloop. Hieronder volgt dus een aangepast stappenplan voor

een nieuw of herhalingsonderzoek, het betreft de oorspronkelijke onderzoeksaanpak

aangevuld met twee stappen hieraan voorafgaand:

1) Draagvlak creëren binnen het bedrijf om het onderzoek uit te voeren

a) Commitment op het beschikbaar stellen van de benodigde data

b) Beschikbaarheid van 8 uur per functioneel- en technisch applicatiebeheerder voor

elke applicatie in het inkoopproces

c) Beschikbaarheid van 4 uur voor een sleutelgebruiker

2) Informatie verzamelen over de registratie van de handelingen in het inkoopproces

a) Interviews met inkoop, magazijn, en financiële managers (+- 1,5 uur per persoon)

b) Documentatie van de accountant over de processen


a) Breng de datastroom van het inkoopproces in kaart

b) Onderzoek of de ERP-applicatie op een standaardwijze is geïmplementeerd of dat

een maatwerkoplossing in gebruik is


zit met betrekking tot de door ons gekozen functiescheidingen

a) Zorg ervoor dat alle benodigde velden in kaart zijn gebracht in de klantsystemen

b) Zorg ervoor dat ook de contextvelden (bijvoorbeeld de hoeveelheid artikelen per

standaard prijs)

5) Extraheren van de data uit de ERP-applicatie

a) Automatische tools gebruiken indien er een mogelijkheid is tot herhaling van de test.

b) Testen op de QA-omgeving en ook de performance voor grote tabellen testen (niet

alleen de juiste werking van de tool)

c) Zorg ervoor dat alle data stamt uit eenzelfde periode, vooral met stamgegevens en

transacties die in de tijd veranderen is het van belang om het interval tussen

downloads zo kort mogelijk te houden


standaard inkoopproces



70

Vooral het creëren van het draagvlak is heel belangrijk omdat er in geval van tegenslagen

wel helder moet zijn wat de maximale en minimale investering gaat zijn. Dit was in ons geval

niet helder en de minimale investering was vaak te minimaal om het onderzoek nog volledig

af te ronden. De benodigde tijd om een analyse met goede voorbereiding volledig te kunnen

uitvoeren zal per gebruikte ERP-applicatie en per organisatie verschillen. Op basis van de

opgedane kennis over het analyseproces schatten wij in dat een analyse bij een nieuwe

organisatie met een nieuwe ERP-applicatie drie tot vijf werkdagen zal kosten. Bij uitvoering

van een tweede analyse voor hetzelfde bedrijf zal deze echter binnen een dag afgerond

kunnen worden.

In deze paragraaf hebben we gezien dat de analysetechniek geen beperking oplevert voor

het onderzoek en dat we met een nieuwe aanpak wellicht sneller en vollediger kunnen zijn

in de resultaten. In de volgende paragraaf bespreken we de behaalde resultaten.

7.5 Resultaten

De resultaten van beide casusbedrijven geven aan dat we geautomatiseerd gegevensgericht

testen op functiescheidingen mogelijk is. Wij hebben kunnen constateren, zij het met een

aantal kanttekeningen, of op transactieniveau functievermenging is opgetreden in het

inkoopproces. Dit hebben wij gedaan op basis van de informatie in de audit trail, zijnde de

logbestanden en transactiedata. Het eerste deel van de onderzoeksvraag kunnen wij op

basis hiervan dus bevestigen.

We hebben gezien dat bij beide bedrijven transacties gedaan zijn waarbij een

functiescheiding doorbroken is. We kunnen, met behulp van de analysetechniek ACL, zelfs

op transactieniveau aangeven om welke gebruikers het gaat en welke bedragen hiermee

gemoeid zijn. De totaalbedragen waar het om gaat voor het productiebedrijf en

detailhandelsbedrijf zijn interessant voor de accountant om verder te onderzoeken in het

kader van de jaarrekeningcontrole. De invulling van dit onderzoek zullen we in de volgende

paragraaf verder bespreken.

De resultaten met betrekking tot het testen van functiescheidingen zijn weliswaar bekend,

maar bij beide casusbedrijven is het niet gelukt de volledige massa aan bestellingen,

magazijnontvangsten en facturen aan elkaar te koppelen en de functievermenging in het

proces te analyseren. Om verschillende redenen deed zich uitval voor van bestellingen,

goederenontvangsten of facturen die niet gekoppeld konden worden op basis van hun

kenmerken. Eerste reden hiervoor zijn de verschillende tijdstippen van data extractie

waardoor de databestanden verschillende tijdsperiodes beslaan. Een tweede reden is de

koppeling van vastleggingen op basis van een vrij tekst veld dat niet in door de ERP-

applicatie afgedwongen formaat wordt gevuld. Vastlegging van bestellingen,

goederenontvangsten, facturen en afgeleide informatie op een niet standaard plek als

gevolg van maatwerk in de ERP-applicatie, is een derde reden waarom de instanties

mogelijk niet te koppelen zijn.

71

De resultaten die wij hebben aangetroffen met betrekking tot de opgetreden

functievermenging hebben in een aantal gevallen dus betrekking op een deel van

vastleggingen. Bij de interpretatie van de resultaten en de gevolgen voor de

jaarrekeningcontrole is het van belang de niet gekoppelde gegevens niet uit het oog te

verliezen. Voor deze data zal binnen de jaarrekeningcontrole ook een controleaanpak

moeten worden bepaald.

Een nadeel van de analyse is dat er is gebleken dat het theoretisch model niet altijd uit te

voeren is in de praktijk. Van de vijf gedefinieerde functiescheidingen in het theoretisch

model zijn er voor geen van beide casusbedrijven alle vijf ook daadwerkelijk geanalyseerd.

Er zijn veel factoren waar van het af kan hangen of de analyse gedaan kan worden. Sommige

van deze factoren zijn binnen de invloedssfeer van de accountant, zoals goede

voorbereiding, goed in kaart brengen van de verschillende vastleggingen, goed in kaart

brengen van maatwerk aan de ERP-applicatie, maar er zijn ook zaken buiten de

invloedssfeer van de accountant zoals de mogelijkheid om de data in een redelijke tijd te

downloaden, het digitaal beschikbaar zijn van vastleggingen etc.

Een aanbeveling op basis van ons onderzoek zou dan ook zijn om een standaard vragenlijst

op te stellen waarmee een vooronderzoek gedaan kan worden over welke automatische

analyses in de praktijk ook daadwerkelijk haalbaar zijn. Dit kan voor de accountant

betekenen dat hij eerst moet investeren om dit te onderzoeken voordat hier de vruchten

van geplukt kunnen worden. Dit moet wel helder zijn voor het gehele traject begint om

teleurstelling en mogelijke verborgen kosten te voorkomen.

Er zijn nog meer facetten relevant voor de accountant en dit behandelen we in de volgende

paragraaf.

7.6 Gevolgen voor de jaarrekeningcontrole

Er zijn een aantal gevolgen voor de jaarrekening te noemen indien op transactieniveau een

totaalcontrole kan worden uitgevoerd op het inkoopproces zonder gebruik te hoeven

maken van steekproeven. Dit is een methode die tot nog toe niet toegepast is in de

accountantscontrole omdat de inspanning niet redelijk was. Met de resultaten van de

geautomatiseerde analyse is hier een nieuwe optie bij gekomen. De geautomatiseerde

gegevensgerichte analyse heeft twee belangrijke voordelen voor de accountant in de

jaarrekeningcontrole.

Ten eerste stelt de analyse het de accountant in staat om zelf de risicoanalyse te maken

voor een cliënt zonder gebruik te hoeven maken van de inschatting van de IT-auditor over

het risico van functievermenging in de IT-omgeving. Nu is immers feitelijk een lijst met

transacties beschikbaar waarbij functievermenging is opgetreden en die kan een accountant

onderzoeken door terug te gaan naar de brondocumentatie. Daarnaast is ook het bedrag

wat gemoeid gaat met deze transacties bekend, dat betekent dat de accountant de

functievermenging direct op waarde kan schatten ten opzichte van de materialiteit.

72

Ten tweede kan de accountant een meer efficiënte controlestrategie opzetten voor nader

onderzoek, als het bedrag waarvoor functievermenging dusdanig groot is ten opzichte van

de materialiteit. De accountant kan een gerichte steekproef doen naar de instanties waarin

functievermenging is opgetreden. Hij hoeft dus niet meer een willekeurige steekproef te

trekken maar kan de “goede” transacties van de “slechte” transacties scheiden en

verschillende controlestrategieën toepassen op de twee verschillende sets. Er vanuit gaande

dat de hoeveelheid transacties waarin functievermenging optreedt slechts een fractie is van

het totaal aantal transacties, is er dan een kleine massa waarop een grote steekproef (hoog

risico op basis van de analyse) getrokken zal moeten worden en een grote massa waarop

een kleine steekproef (laag risico op basis van analyse) getrokken kan worden. In het

traditionele geval moest een relatief grote steekproef getrokken worden op de volledige

massa (onbekend dus hoog risico). Dit onderscheid in transacties maakt de controlestrategie

in zijn geheel dus efficiënter.

Deze voordelen vereisen ook wel extra inspanning in de jaarrekeningcontrole. Er is namelijk

aanzienlijk meer kennis nodig van de ERP-applicaties om een audit op deze manier uit te

voeren. Dit is ook een van de leerpunten uit het proces dat wij doorlopen hebben. Met veel

inspanning hebben wel via proberen en corrigeren toch resultaten weten te behalen maar

een dergelijke inspanning is commercieel niet haalbaar. Voor onze analyse hebben wij

uiteindelijk slechts een beperkt aantal van de functiescheidingen kunnen testen. Dit kwam

veelal ook door het gebrek en specifieke kennis over de ERP-applicatie. Zeker als er

maatwerk in het systeem zit is het belangrijk om een expert te betrekken zodat er toch de

juiste informatie opgeleverd wordt voor een analyse. Expertise op het vereiste detailniveau

is schaars en al helemaal als het kennis over de hele breedte van de applicatie betreft. Vaak

is deze alleen aanwezig bij de klant en moet er dus worden samengewerkt met experts van

de klant. In ons geval was dit niet mogelijk wegens werkdruk en economische zorgen bij de

casusbedrijven. Deze ervaringen zijn een les geweest en hebben wij opgenomen in onze

aangepaste onderzoeksaanpak naar aanleiding van de resultaten, zie paragraaf 7.4. Een

meer uitgebreide voorbereiding en consultatie van expert voorafgaand aan de

testwerkzaamheden was het resultaat van dit onderzoek zeker ten goede gekomen. De

mate waarin kennis over de ERP-applicatie bestaat bij het audit team en de organisatie en

de mate waarin gebruik wordt gemaakt van een standaardinrichting van de ERP-applicatie,

vormen twee belangrijke punten op basis waarvan de accountant de afweging kan maken

tussen geautomatiseerd gegevensgericht of traditioneel testen van functiescheidingen.

Dan rest nog de vraag of de accountant wel zoveel inzicht in de gegevens van haar klant wil

hebben. De accountant heeft een controleverplichting om elke geconstateerde fout uit te

zoeken. Dit kan betekenen dat er door dit soort controle wel in eerste instantie veel extra

werk geleverd moet worden om te onderzoeken waarom de transacties niet volgens het

voorgeschreven proces zijn verlopen. Zeker in het geval de geautomatiseerde analyse nog

niet is afgestemd op eventueel maatwerk van de controleklant, betekent dit dat relatief veel

vals alarm situaties kunnen optreden in de eerste paar testrondes. Vanaf wanneer moet de

accountant dus alle gevonden transacties gaan nalopen? Dat is op dit moment niet

voorgeschreven.

73

Zoals u begrijpt zal de impact van volledige inzage in de data van cliënten voor de

accountant een nieuw speelveld opleveren waar de traditionele controletechnieken wellicht

vervangen kunnen worden door deze nieuwe gegevensgerichte technieken. Gebruik van

audit software als ACL kan hier een rol in spelen. De methodologie van controletechnieken

kan op basis hiervan heroverwogen worden om een nieuwe controlestrategie met

bijbehorende technieken te ontwikkelen.

Dit ligt echter niet in de scope van dit onderzoek en wij zullen ons dan nu beperken tot het

beantwoorden van de probleemstelling. Naar aanleiding van de huidige paragraaf waarin wij

een aanzet hebben gedaan tot het bepalen van de gevolgen van geautomatiseerde

gegevensgerichte analyse op functiescheiding voor de jaarrekeningcontrole, kunnen wij ook

het tweede deel van de onderzoeksvraag bevestigend beantwoorden.

7.7 Conclusie

In deze afsluitende paragraaf geven we de conclusie op de probleemstelling. De

probleemstelling luidde:




Op basis van de voorgaande twee paragrafen en het onderzoek in zijn geheel kunnen wij de

onderzoeksvraag bevestigend beantwoorden. Op basis van de resultaten van de tests

kunnen wij concluderen dat het eerste deel van de probleemstelling zeker mogelijk is. We

hebben bij twee bedrijven op basis van de data uit de financiële administratie inderdaad

met succes functiescheidingsanalyses kunnen doen op een geautomatiseerde wijze.

Ook het tweede deel van de onderzoeksvraag, de gevolgen voor de jaarrekeningcontrole, is

een onderdeel dat haalbaar is gebleken. De gevolgen voor de jaarrekeningcontrole zijn dat

er nu een mogelijkheid is om geautomatiseerd gegevensgericht naar functiescheidingen te

kijken. Daarnaast kan de accountant zelf opvolging geven aan mogelijke functievermenging

zonder te hoeven steunen op een inschatting van de IT-auditor over het risico op

functievermenging. In het geval van vervolgwerkzaamheden op de geconstateerde feitelijke

functievermenging is het ook de mogelijkheid om de controlestrategie meer efficiënt op te

zetten. Dit is mogelijk door differentiatie in de risico’s in de totale massa aan transacties

door te voeren in de steekproefgroottes op deze twee verschillende populaties. In deze

steekproef wordt vervolgens vastgesteld of de transacties rechtmatig zijn.

Onze suggestie voor vervolgonderzoek is tweeledig:

1) Ontwikkel een standaardmethodologie voor het uitvoeren van geautomatiseerde

gegevensgerichte analyse van functiescheidingen

2) Onderzoek de wijze van verwerking van geautomatiseerde gegevensgerichte controle in

de controleaanpak van de accountant

74

Met deze suggesties voor vervolgonderzoek sluiten we dit onderzoek af.

75

Literatuur

ACL_Services_Ltd. (2009). ACL Technology for Business Assurance. (ACL Services Ltd.)

Opgeroepen op April 13, 2009, van ACL Homepage: http://www.acl.com/

ANP. (2009, Februari 12). NU Economie. (Ilse Media Groep BV) Opgeroepen op Juli 4, 2009,

van NU.NL: http://www.nu.nl/economie/1915977/bedrijven-kunnen-volledig-elektronisch-

factureren.html

Apgar, C., & Lynch, M. (2004). HIPAA Security Auditing: How To Create a Consistent,

Repeatable and Documented Program. Healthcare Intelligence Network.

Arens, A. A., & Loebbecke, J. K. (1980). Auditing, an integrated approach. Englewood Cliffs,

N.J.: Prentice-Hall.

Bolluijt, J. (2001). Accountant en e-business: de praktijk tussen hype en werkelijkheid.

Kluwer.

Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., & Yergeau, F. (2008, November 26 ).

Extensible Markup Language (XML) 1.0 (Fifth Edition). (The World Wide Web Consortium

(W3C)) Opgeroepen op April 13, 2009, van The World Wide Web Consortium (W3C):

http://www.w3.org/TR/REC-xml/

Ellard, D. (1997, July 21). Big-O notation and algorithm analysis. (President and Fellows of

Harvard College) Opgeroepen op June 04, 2009, van Hardvard School of Engineering and

Applied Sciences: http://www.eecs.harvard.edu/~ellard/Q-97/HTML/root/node8.html

Idehen, K. (1993). Open Database Connectivity Without Compromise. (OpenLink Software)

Opgeroepen op 04 13, 2009, van Open Database Connectivity Without Compromise:

http://www.openlinksw.com/info/docs/odbcwhp/tableof.htm

ISACA. (2005). www.isaca.org. Opgeroepen op April 4, 2009, van www.isaca.org:

http://www.isaca.org/ContentManagement/ContentDisplay.cfm?ContentID=39525

ISO/IEC. (2009). Information technology -- Database languages -- SQL -- Part 1. Opgeroepen

op April 13, 2009, van ISO:

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4549

8

Jans, E. (1989). Grondslagen van de administratieve organisatie. Alphen aan de Rijn:

Samsom.

76

Kemp, S. (2006). Auditing and assurance handbook: incorporating all the standards.

Brisbane: John Wiley.

Moore, G. E. (1965). Cramming more components onto integrated circuits. Electronics

Magazine , 4.

NIVRA. (2009). Handleiding Regelgeving Accountancy. Deel 1.

OrangeBook. (1985). Trusted computer system evaluation criteria. U. S. Department of

Defense, Computer Security Center.

Paul E. Black, e. (2008, November 20). "big-O notation", in Dictionary of Algorithms and

Data Structures [online]. ( U.S. National Institute of Standards and Technology) Opgeroepen

op April 13, 2009, van Big-O Notation: http://www.itl.nist.gov/div897/sqg/dads/

Pnueli, A. (1997). The Temporal Logic of Programs. Mathematics & Computer Science ,

Technical Report CS97-14.

ProcessMiningGroup. (2008). The PRoM Framework. (Eindhoven Technical University)

Opgeroepen op January 2009, van The PRoM Framework:

http://prom.win.tue.nl/tools/prom/

SAS_Institute_Inc. (2009). SAS Institute Homepage. (SAS Institute Inc) Opgeroepen op April

13, 2009, van Homepage: http://www.sas.com/

Senft, S., & Gallegos, F. (2008). Information Technology Control and Audit. Auerbach

Publications.

Shafranovich, Y. (2005, October). Common Format and MIME Type for Comma-Separated

Values (CSV) Files. (The Internet Society) Opgeroepen op 04 13, 2009, van The Internet

Engineering Task Force: http://tools.ietf.org/html/rfc4180

Starreveld, R., van Leeuwen, O., & van Nimwegen, H. (2002). Bestuurlijke-

informatieverzorging / 1 Algemene grondslagen. Groningen: Noordhoff Uitgevers B.V.

Sun Microsystems, I. (2009, April 13). Developer Resource for Java Developers. (Sun

Microsystems, Inc.) Opgeroepen op April 13, 2009, van Sun Developer Network:

http://java.sun.com/

van der Aalst, W., de Beer, H., & van Dongen, B. (2005). Process Mining and Verification of

Properties: An Approach based on Temporal Logic.

van der Aalst, W., de Beer, H., & van Dongen, B. (2005). Process Mining and Verification of

Properties: An Approach Based on Temporal Logic. In Lecture Notes in Computer Science

(pp. 130-147). Berlin / Heidelberg: Springer.

77

Walter, C. (2005, July). Kryder's Law: Scientific American. (Scientific American) Opgeroepen

op January 2009, van Scientific American: http://www.sciam.com/article.cfm?id=kryders-

law

Weele, A. v. (2008). Inkoop in strategisch perspectief. Alphen aan den Rijn: Samson.

WikiMedia. (2009, April 13). Comparison of Filesystems. (WikiMedia) Opgehaald van

Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Documents

Onderzoek naar het geautomatiseerd gegevensgericht testen ...€¦ · 1.4 Onderzoeksaanpak 9 1.5 Leeswijzer 9 2 Theoretische studie: inkoopproces, functiescheiding en vastlegging