Onderzoek naar het geautomatiseerd gegevensgericht testen van functiescheidingen in het inkoopproces

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 Deloitte Accountants B.V. E-mail [email protected] Telefoon +31 (0)6 5111 0742

Student Drs. Suzanne de Vries (1005294) Deloitte Accountants B.V. E-mail [email protected] Telefoon06 1258 0225

Begeleider VU Dr. Bob van Kuijck RA RC E-mail [email protected] Telefoon +31 (0)6 5136 6752

1

Inhoudsopgave Voorwoord

4

1

Inleiding

5

1.1 1.2 1.3 1.4 1.5

5 8 8 9 9

2

3

4

Aanleiding voor het onderzoek Probleemstelling Onderzoeksvragen Onderzoeksaanpak Leeswijzer

Theoretische studie: inkoopproces, functiescheiding en vastlegging

11

2.1 2.2 2.3 2.4

Inleiding Inkoopproces Functiescheiding Minimaal benodigde informatie 2.4.1 Vastlegging van data in ERP-applicaties 2.4.2 Rijkdom van de informatie 2.4.3 Benodigde informatie voor testen functiescheiding in het inkoopproces 2.5 Conclusie

11 11 14 16 16 17 18 20

Theoretische studie: randvoorwaarden voor geautomatiseerde gegevensgerichte analyse

21

3.1 Inleiding 3.2 Primaire vastleggingen in de ERP-applicatie 3.3 Organisatorische inrichting 3.3.1 Implementatie van functiescheidingen in logische toegangsbeveiliging 3.3.2 Logische beveiliging van de audit trail 3.4 Conclusie

21 21 22 23 24 24

Theoretische studie: analysetechnieken

26

4.1 Inleiding 4.2 Criteria ter beoordeling van automatische analysetechnieken 4.2.1 Integriteit van de data tijdens de analyse 4.2.2 Data Volumes en Formaten 4.2.3 Data Verwerking en Analyse 4.2.4 Analysesnelheid 4.2.5 Conclusie 4.3 Mogelijke analysetechnieken 4.4 Beoordeling Process Mining (ProM) en Linear Temporal Logic (LTL) 4.5 Beoordeling Audit Command Language (ACL) 4.6 Beoordeling SAS

26 26 27 27 28 29 29 30 30 32 33

2

5

6

7

4.7 Beoordeling Structured Query Language (SQL) 4.8 Analyse 4.9 Conclusie

34 35 38

Casusbedrijf 1: Het productiebedrijf

39

5.1 Inleiding 5.2 Beschrijving organisatie 5.3 Het inkoopproces bij het productiebedrijf 5.4 Aanwezige randvoorwaarden 5.5 Dataset definitie 5.6 Te testen functiescheidingen 5.7 Keuze analysetechniek 5.8 Resultaten 5.9 Analyse 5.10 Conclusie

39 39 40 40 42 43 44 45 51 52

Casusbedrijf 2: Het detailhandelsbedrijf

54

6.1 Inleiding 6.2 Beschrijving organisatie 6.3 Het inkoopproces bij het detailhandelsbedrijf 6.4 Aanwezige randvoorwaarden 6.5 Dataset definitie 6.6 Te testen functiescheidingen 6.7 Keuze analysetechniek 6.8 Resultaten 6.9 Analyse 6.10 Conclusie

54 54 55 55 56 57 59 60 62 63

Algemene analyse en conclusie

65

7.1 7.2 7.3 7.4 7.5 7.6 7.7

65 65 66 67 70 71 73

Inleiding Discussie terugkoppeling van de resultaten naar het theoretische model Randvoorwaarden De gevolgde analyse aanpak Resultaten Gevolgen voor de jaarrekeningcontrole Conclusie

Literatuur

75

3

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.

4

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.

5

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.

6

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.

7

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)

8

•

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.

9

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.

10

2 2.1

Theoretische studie: inkoopproces, functiescheiding en vastlegging 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.”

11

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.

12

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 Leverancier

Inkoop

Magazijn

Bestelsignaallijst

Voorraadadm.

Factuurcontrole

Bestelling

Goederen

Invoer stam gegevens crediteuren

Bestelling

Bestelling

Goederen

Voorraad boeking

Controle met bestelling

Magazijn ontvangstbon

Grootboek

Bestelsignaallijst

Controle bestelling

Bestelling

Crediteurenadm.

Magazijn ontvangstbon

Magazijn ontvangstbon

Magazijn ontvangstbon

Voorraad boeking

Factuur

Boeken op rekening te ontv fact

Bestelling

Factuur

Boeking crediteur

Factuur

Betalen factuur

Controle factuur

Boeken op grbkrekg 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

13

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;

14

• • •

Er moeten mogelijkheden worden geschapen tot het verkrijgen van elkaar wederzijds controlerende verantwoordingsverslagen van personen met nietidentieke 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.

15

Inkoopproces Leverancier

Inkoop

Magazijn

Bestelsignaallijst

Voorraadadm.

Factuurcontrole

Bestelling

Goederen

Invoer stam gegevens crediteuren

Bestelling

Bestelling

Goederen

Voorraad boeking

Controle met bestelling

Magazijn ontvangstbon

Grootboek

Bestelsignaallijst

Controle bestelling

Bestelling

Crediteurenadm.

Magazijn ontvangstbon

Magazijn ontvangstbon

Magazijn ontvangstbon

Voorraad boeking

Factuur

Boeken op rekening te ontv fact

Bestelling

Factuur

Boeking crediteur

Factuur

Betalen factuur

Controle factuur

Boeken op grbkrekg 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 ERPapplicatie. Deze informatie heeft direct met de verrichte transactie te maken. Bijvoorbeeld, bij het aanmaken van een bestelling wordt de leverancier, het bedrag, de hoeveelheid

16

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.

17

•

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/magazijnontvangstbon/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)

18

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.

19

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.

20

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

21

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 ERPapplicatie 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 ERPapplicatie. 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.

22

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

23

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 ERPapplicatie slechts dient ter registratie van een primaire vastlegging.

24

•

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.

25

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. 2. 3. 4.

integriteit van de data tijdens de analyse de volumes en data formaten die verwerkt kunnen worden de analyse mogelijkheden tijdens de verwerking van de data de analyse snelheid

26

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.

27

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.

28

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: 1. 2. 3. 4. 5. 6.

Onveranderlijkheid van de data Herhaalbaarheid van de testresultaten Audit trail van de handelingen Maximale verwerkingscapaciteit Opslag data tijdens verwerking Data formaten - Ontsluiting van de data voor analyse a. Database via Open DataBase Connectivity b. CSV files

29

c. XML-based files 7. Inzicht in de data 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.

30

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. 1. Onveranderlijkheid van de data 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. 2. Herhaalbaarheid van de testresultaten 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. 3. Audit trail van de handelingen 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. 4. Maximale verwerkingscapaciteit 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. 5. Opslag data tijdens verwerking 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. 6. Data formaten - Ontsluiting van de data voor analyse 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

31

betekent dat elke inkooporder en alle bijbehorende acties zoals goederenontvangst en goedkeuring allen eenzelfde unieke identifier moeten hebben die ze groepeert. 7. Inzicht in de data 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. 1. Onveranderlijkheid van de data 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. 2. Herhaalbaarheid van de testresultaten 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. 3. Audit trail van de handelingen Zoals genoemd in het voorgaande punt is een audit trail beschikbaar in ACL. 4. Maximale verwerkingscapaciteit ACL heeft geen limiet op de maximale verwerkingscapaciteit. Een limiet is de maximale bestandsgrootte op het Microsoft Windows operating system (WikiMedia, 2009).

32

5. Opslag data tijdens verwerking 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. 6. Data formaten - Ontsluiting van de data voor analyse ACL heeft een uitgebreide set aan import filters en kan ODBC, CSV en XML formaten aan. 7. Inzicht in de data Zoals eerder gezegd, bij ACL wordt voor elke tussenstap een tussenbestand gemaakt, dit bestand geeft inzicht in het verloop van de analyse. Subjectieve argumenten 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. 1. Onveranderlijkheid van de data SAS voert geen mutaties uit op brondata en laat deze dus gegarandeerd in tact. 2. Herhaalbaarheid van de testresultaten SAS verandert de data niet en maakt gebruik van deterministische algoritmen zodat bij herhalen van de test het resultaat gelijk zal zijn. 3. Audit trail van de handelingen 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.

33

4. Maximale verwerkingscapaciteit 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. 5. Opslag data tijdens verwerking 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. 6. Data formaten - Ontsluiting van de data voor analyse SAS heeft een uitgebreide set aan import filters en kan ODBC, CSV en XML formaten aan. 7. Inzicht in de data Bij SAS bestaat de mogelijkheid om de tussenresultaten in bestanden weer te geven zodat deze inzichtelijk zijn ter analyse. Subjectieve argumenten 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. 1. Onveranderlijkheid van 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. 2. Herhaalbaarheid van de testresultaten 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.

34

3. Audit trail van de handelingen 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. 4. Maximale verwerkingscapaciteit SQL heeft geen limiet op de verwerkingscapaciteit. Dit zal afhangen van het bron database systeem waarop gewerkt wordt. 5. Opslag data tijdens verwerking 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. 6. Data formaten - Ontsluiting van de data voor analyse 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. 7. Inzicht in de data 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. Subjectieve argumenten 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.

35

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.

36

ProM + LTL 1 Onveranderlijkheid van de data 2 Herhaalbaarheid van de testresultaten 3 Audit trail van de handelingen 4 Maximale verwerkingscapaciteit 5 Opslag data tijdens verwerking

ACL

SAS

SQL

Ja, brondata wordt Ja, brondata wordt Ja, indien door Ja, indien de gekopieerd voor gekopieerd voor gebruiker expliciet gebruiker dit zelf analyse analyse aangezet waarborgt in de code 2 3 4 Ja, voor LTL Ja Ja Ja Nee5

Ja6

Ja

Nee7

Geen vastgestelde Geen vastgestelde Geen vastgestelde Geen vastgestelde beperkingen beperkingen beperkingen beperkingen ± tien keer de Voor elke Een maal de Een maal de dataset brondata-set8 tussenstap extra dataset grootte grootte 9 bestand nodig

6 Data formaten Database via Open DataBase Connectivity CSV files XML-based files 7 Inzicht in de data

Ja

Ja

Ja

Nvt

Nee

Ja

Ja

Ja

Ja

Ja

Ja

Nee

Nee

Ja

Alleen handmatig10 Alleen handmatig11

Tabel 1 - Vergelijking van de analysetechnieken

Legenda Groen Geel Oranje Rood

= Tool voldoet standaard aan dit criterium = Tool voldoet wel indien de gebruiker handmatig maatregelen treft = Tool voldoet wel maar tijdens de analyse kan er een probleem optreden = De tool voldoet niet voor dit criterium

2

Niet alle algoritmen in ProM zijn deterministisch. LTL is dit wel. 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. 3

37

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): 1. 2. 3. 4. 5. 6.

Onveranderlijkheid van de data Herhaalbaarheid van de testresultaten Audit trail van de handelingen Maximale verwerkingscapaciteit Opslag data tijdens verwerking Data formaten - Ontsluiting van de data voor analyse a. Database via Open DataBase Connectivity (Idehen, 1993) b. CSV files (Shafranovich, 2005) c. XML-based files (Bray, Paoli, Sperberg-McQueen, Maler, & Yergeau, 2008) 7. Inzicht in de data 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.

38

5 5.1

Casusbedrijf 1: Het productiebedrijf 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.

39

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.

40

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

41

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 ERPapplicatie 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.

42

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.

43

Inkoopproces Leverancier

Inkoop

Magazijn

Bestelsignaallijst

Voorraadadm.

Factuurcontrole

Grootboek

Bestelsignaallijst

Invoer stam gegevens crediteuren

Controle bestelling

Bestelling

Crediteurenadm.

Bestelling

Goederen

Bestelling

Bestelling

Goederen

Voorraad boeking

Controle met bestelling

Magazijn ontvangstbon

Magazijn ontvangstbon

Magazijn ontvangstbon

Boeken op rekening te ontv fact

Bestelling

Magazijn ontvangstbon

Voorraad boeking

Factuur

Factuur

Factuur

Controle factuur

Betalen factuur

Boeken op grbkrekg 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: • •

Een medewerker die een factuur ontvangt en registreert, is niet de medewerker 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.

44

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

45

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. 2) Verkrijgen van het schema dat aangeeft waar in de applicatie de benodigde informatie 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 ERPapplicatie 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 SAPapplicatie 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.

46

4) Plotten van de ontvangen data naar de mogelijk te testen functiescheidingen in het 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

931

Niet bekend

329.415

€ 213,6 miljoen

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.

Bestellingen gekoppeld aan goedkeuring Goederenontvangsten in periode Goederenontvangsten gekoppeld aan een bestelling

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

47

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

48

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 SAPexperts 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 # gebruikers die ook NAW wijzigden 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

49

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 NAWgegevens 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. 6) Validatie van de resultaten met de gecontroleerde partij 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.

50

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

51

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

52

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.

53

6 6.1

Casusbedrijf 2: Het detailhandelsbedrijf 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.

54

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. Primaire vastlegging in de ERP-applicatie 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.

55

Organisatorische inrichting 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

56

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.

Figuur 5 - Voorbeeld data detailhandelsbedrijf

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:

57

-

Een medewerker die een bestelling plaatst, is niet de medewerker die de goederen 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 Leverancier

Inkoop

Magazijn

Bestelsignaallijst

Voorraadadm.

Factuurcontrole

Crediteurenadm.

Bestelsignaallijst

Invoer stam gegevens crediteuren

Controle bestelling

Bestelling

Bestelling

Goederen

Bestelling

Bestelling

Goederen

Voorraad boeking

Controle met bestelling

Magazijn ontvangstbon

Grootboek

Magazijn ontvangstbon

Magazijn ontvangstbon

Boeken op rekening te ontv fact

Bestelling

Magazijn ontvangstbon

Voorraad boeking

Factuur

Factuur

Factuur

Controle factuur

Betalen factuur

Boeken op grbkrekg 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;

58

•

Een medewerker die een factuur ontvangt en registreert, is niet de medewerker 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.

59

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 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 Navision. Er zijn verder geen andere applicaties betrokken. De stappen die niet in Navision zitten worden handmatig uitgevoerd. 2) Verkrijgen van het schema dat aangeeft waar in de applicatie de benodigde informatie 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. 4) Plotten van de ontvangen data naar de mogelijk te testen functiescheidingen in het standaard inkoop proces. De functiescheidingen die getest kunnen worden op basis van de data, zijn: -

Een medewerker die een bestelling plaatst, is niet de medewerker die de goederen in ontvangst neemt.

-

Een medewerker die de factuur registreert, is niet de medewerker die de factuur betaalbaar stelt.

5) Geautomatiseerd gegevensgericht testen van de functiescheidingen

60

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

587.866

€ 25,1 miljoen

Geregistreerde facturen

26.305

€ 271,5 miljoen

Betaalbaar gestelde facturen

16.582

Niet bekend

9.040

€ 88,0 miljoen

Goederenontvangsten gekoppeld aan een bestelling

Geregistreerde facturen gekoppeld aan een betaling

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

61

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. 6) Validatie van de resultaten met de gecontroleerde partij 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

62

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

63

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.

64

7 7.1

Algemene analyse en conclusie Inleiding

In dit hoofdstuk zullen wij, op basis van de voorafgaande hoofdstukken, de onderzoeksvraag bevestigen dan wel weerleggen. De onderzoeksvraag luidde als volgt: “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?” 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.

65

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 followup 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. 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. Primaire vastlegging in de ERP-applicatie

66

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

67

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

68

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 3) Onderzoeken van de softwarepakketten die betrokken zijn bij het inkoopproces 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 4) Verkrijgen van het schema dat aangeeft waar in de applicatie de benodigde informatie 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 6) Plotten van de ontvangen data naar de mogelijk te testen functiescheidingen in het standaard inkoopproces 7) Geautomatiseerd gegevensgericht testen van de functiescheidingen 8) Validatie van de resultaten met de gecontroleerde partij

69

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 ERPapplicatie 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.

70

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.

71

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.

72

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: “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?” 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

73

Met deze suggesties voor vervolgonderzoek sluiten we dit onderzoek af.

74

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-elektronischfactureren.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.

75

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). Bestuurlijkeinformatieverzorging / 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.

76

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=kryderslaw 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

77