Accountant
NBA-platform voor accountants en financials
Overig
Magazine Podcast Dossiers Nieuwsbrief Contact
Home >Vaktechniek> 2015 > 2 > Hoe vind je een fraude van 186.000 euro: steekproeven of data-analyse?
Statistical auditing (40)

Hoe vind je een fraude van 186.000 euro: steekproeven of data-analyse?

Leestijd van ongeveer 1 minuut 13 reacties

Elke keer als ik in een column iets over steekproeven wil uitleggen, niet te moeilijk maar ook niet te gemakkelijk, iets handigs, zoals waarom uitbreiden na het vinden van fouten nadelen heeft, krijg ik reacties die helemaal niet over steekproeven gaan.

Paul van Batenburg

Hele colleges controleleer krijg ik aangeboden, allerlei prachtige constructies met verschillende methoden voor verschillende deelmassa's, waarbij zwaar wordt gesteund op de vermoedelijke kwaliteit en de verschillen daar in. Zonder aan te geven of en hoe je die vermoedens achteraf kunt valideren en wat je doet als die validatie niet lukt. Ik krijg dan de indruk van die reacties dat men vindt dat professional judgement en slimme software veel efficiënter zijn dan steekproeven.

Maar daar gaat mijn column niet over: ik wil wat vertellen over steekproeven, want daar heb ik verstand van, en professional judgment heb ik niet.

Natuurlijk moet je bij het controleren nadenken (voordat je een steekproef trekt). Natuurlijk moet je zaken die je integraal kunt checken, ook integraal doen. Ik ben nog steeds verbaasd over die collega die dankzij een data-analysetool niet meer met een steekproef hoefde te controleren of prijs maal hoeveelheid in de voorraadlijst wel gelijk was aan waarde. Pas op het moment dat de soll-positie van een bestand niet onafhankelijk en bewezen correct elektronisch beschikbaar is komen steekproeven aan de orde.

Daarom maar eens een casus: de gemeente Amsterdam die door factuurfraude achteraf onterecht 186.000 naar een Brabantse man overmaakte en nu probeert dat geld via de rechter terug te vorderen.

Hoe vind je een fraude van 186.000?

Een systematische steekproef met een interval van € 186.000 zal met 100 procent kans alle posten van € 186.000 of groter bevatten. Zo'n steekproef hoort bij een toegelaten afwijking van € 558.000, dus bij een uitvoeringsmaterialiteit van - pak 'm beet - € 750.000.

Bij deze de uitdaging voor de data-analyseadepten: zijn er, behalve een query op Brabanders, of een query op alle posten van € 186.000, efficiëntere manieren om met data-analyse deze fraude te ontdekken?

Stuurgroep Statistical Auditing

De Stuurgroep Statistical Auditing is verbonden met het Limperg Instituut en heeft als doel 'het bevorderen van het correcte (effectief en efficiënt) gebruik van statistische methoden en technieken bij accountantscontroles en daarmee verwante controles op financiële verantwoordingen en overzichten'.

Reageer

Drs. Paul van Batenburg is zelfstandig adviseur die als statisticus met verstand van controleren de eenmanszaak en website steekproeven.eu voert.

Gerelateerd

13 reacties

Hein Kloosterman

AT: Marion Ik heb de casuïstiek over die fraude nagelezen. De artikelen in de pers die over deze fraude gaan hebben het over het vervalsen van een (interne) nota van de Gemeente Amsterdam. Daar leid ik uit af dat het stadsdeel een gemaltraiteerde nota kreeg. Het stadsdeel heeft vervolgens overgemaakt op de foute bankrekening die op de nota was vermeld (die zou zijn veranderd). Als intern de gegevens van de nota waren overgenomen zou al de fout aan het licht zijn gekomen. Kennelijk werden hier de gegevens van de factuur gevolgd, niet die van het systeem. Misschien was het zo dat de leveranciersgegevens overruled werden. Weet ik niet. Maakt niet uit: er zou geen autorisatie mogen zijn voor een betaling naar een bankrekening die niet bij de (interne) crediteur hoort. Als bij iedere betaling aan een crediteur altijd de gegevens van de factuur worden ingevoerd, zonder confrontatie met de leveranciersgegevens, is de registratie van die facturen foute boel.

Marlon

Weet iemand of in die casus de IBAN in de stamgegevens is aangepast of in de .xml welke naar de bank is gegaan? In het laatste geval zal een IB maatregel van functiescheiding tussen crediteuren stamgegevens aangegevens en klaar zetten betalingen niet afdoende zijn. Als het in de .xml is aangepast gaat geen overzicht vanuit de boekhouding dit inzichtelijk kunnen maken waarschijnlijk. (Als iemand die wel weet hou ik me aanbevolen) Zou wellicht een query op de databasetabel in het bankdagboek teruggemeldde crediteurenfactuurbetalingen op IBAN in relatie tot uit de stamgegevens crediteurnummers met IBAN een dergelijke fraude aan het licht brengen? Er zou dan toch een mismatch moeten ontstaan tussen de gevonden IBAN bij de crediteur ten opzichte van die uit de stamgegegevens?

Ferry Geertman

Als data-analyse adept én liefhebber van steekproeven ben ik van mening dat ik niet op een efficientere manier deze fraude had kunnen ontdekken dan door gebruik te maken van steekproeven. Dit onder de aanname dat er geen of nagenoeg geen interne controle aanwezig is. Met de kennis dát er een fraude is gepleegd kunnen we achteraf allerlei queries bedenken waarmee dit naar voren komt. Maar om vóóraf een query te bedenken waarmee een dergelijke fraude naar voren komt is moeilijk en zal in veel gevallen lijken op overkill (dus inefficientie). En omdat je geen benchmark hebt (is € 186.000 een uitzonderlijk bedrag?, zijn veranderende banknummers uitzonderlijk? ) zul je simpelweg veel te analyseren hebben - en dat kost tijd. Waar ik wel van overtuigd ben is dat er een heleboel fout is gegaan in de interne controle van de gemeente Amsterdam. En daar had data-analyse wel kunnen helpen. Het goed definieren van risico's ("wat kan er fout gaan") betekent dat je meetbare gebeurtenissen kunt definieren en - over tijd - mbv data-analyse een benchmark kunt neerzetten. Bijvoorbeeld, banknummers van gemeentelijke instellingen wijzigen nooit of er vinden zeer zelden betalingen plaats boven, de zeg € 10.000 aan niet eerder gebruikte banknummers. Dan had de interne controle van de gemeente Amsterdam dit kunnnen voorkomen. Achteraf vaststellen - dan zal echt een steekproef het meest effcient zijn.

Glenn Mungra

Leuke vraag van Paul. Betalingen vloeien in dit geval naar een bankrekening. Kun je ook efficient vaststellen of die bankrekening juist is? bijv. naam/nummer volgens mutatiedata (betalingen) = naam/nummer volgens de met waarborgen omgeven statische data (leveranciers). In de steekproef kun je je dan uiteindelijk beperken tot nader onderzoek van die gevallen waar dat nog niet automatisch is vastgesteld (is het een nog onbekend nieuw nummer en juist of een onbekend nummer en fout?) Ik vraag me zelfs af of je je ook kunt beperken tot (steekproeven uit) de reguliere uitzonderingsrapportage daarover (indien standaard beschikbaar). Vergelijking van de bankrekening waar het naar toe gaat en waar het naar toe zou moeten gaan lijkt me efficienter, maar het nadeel hiervan is wel dat je zo nog niet gekeken hebt naar de juiste datum van betaling of dubbele betaling van die betreffende leverancier of naar evt. betaling gemaskeerd in kleinere porties)

Hein Kloosterman

Het was de bedoeling een data-analyse te noemen die het probleem bij de kop pakt. In deze casus is de controle achteraf niet goed genoeg! Bij een organisatie als de Gemeente Amsterdam is denk ik de materialiteit van de externe controle groot genoeg om niets te hoeven zien in een steekproef. Dit is een controlprobleem. Er is gehannest in een of meer van de betalingsbestanden. Dat spul dat naar de bank wordt gestuurd. De gegevens van dat bestand horen overeen te komen met het grootboek (of iets equivalents). Per bestand moet die aansluiting zijn gemaakt. Wel het te verzenden bestand gebruiken. Vrienden van ACL of IDEA weten hoe dat moet. En dan het liefst nog die controle uitvoeren voordat er iets naar de bank wordt gestuurd. Als de accountant niet weet of die interne controle (adequaat) plaatsvond, moet hij hem doen. Is extra werk, meerwerk. Dat is een data- analyse die Ferry Geertman en ik consistentiecontrole noemden (column 36). Degene die data-analyse wil doen op alleen het grootboek vindt niets van dergelijk gerommel met betaalgegevens.

Pieter de Kok

Paul, Hoe vind je een fraude van 186.000? Antwoord: steekproef Zo simpel is het. Maar ik moet nog een controleprogramma tegenkomen waar die vraag zo letterlijk in staat. Dus krijg je de reacties hieronder. Hulde toch voor de lezers die actief meedoen. Ik zou deze rubriek elke dag wel willen. Ik kan zo vierentwintig of vijfentwintig (hoe zat het ook alweer) waar de afweging: inzetten steekproef, process mining of data-analyse afweging gemaakt moet worden. Kunnen alle lezers, en elke denkrichting wordt gewaardeerd, reageren

Paul van Batenburg

Leuk hoe toch nog velen de neiging hebben om antwoord te geven op vragen die niet gesteld zijn. Natuurlijk kan je een query maken op rekeningnummer en naam. Dan heb je dit aspect van de juistheid van de betaling (correcte begunstigde) afgetikt. Nu alle andere aspecten nog. In een steekproef van de omvang die ik schetste, komt deze post met 100% zekerheid voor. En dan kan die post worden gecontroleerd op alle aspecten van juistheid, ook die aspecten waarvoor geen query bedacht is. Want dat is de makke van geprogrammeerde controles: ze vinden alleen wat je hebt geprogrammeerd... Lijkt op je eigen paaseieren zoeken! Die accountant die de kostenrekening kritisch wil doorlezen wens ik niet al te omvangrijke klanten toe. En vice versa.

Geert de Jonge

In het kader van de efficiency zou ik het bestandsonderzoek in ieder geval doen voor het bestand met betaalopdrachten naar de bank gaat. Maar ook dan blijft het dweilen met de kraan open. Rinus en Pieter gaven hiervoor al de echte oplossing. Overigens is de fraude aan het licht gekomen doordat de bank argwaan kreeg. Daar doen ze ook aan bestandonderzoek.

Hein Kloosterman

Volgens mij was de vraag of het efficiënter kon dan met een steekproef. Achteraf redenerend kun je afleiden uit de casus dat men in het bestand met betalingsopdrachten had zitten hannesen. Ik kreeg de indruk dat de voorstellen voor cijferanalyses gingen over de grootboekapplicatie, het ERP-pakket, zeg maar. Maar niet over het controleren van de betaaldata (soll) met het grootboek (ist). Wel een schok ook om tot de ontdekking te komen dat wat er echt is gebeurd (soll) fout is! En in het grootboek de transactie is weergegeven zoals had gemoeten. Ingewikkeld vak, controle. In ieder geval staat in de betaalapplicatie, althans in de dataset met de betaalopdrachten wat de bank heeft overgeboekt. Die set is geautoriseerd maar niet echt gecontroleerd (net als bij de verschoven komma, ook van Amsterdam). De volgende keer dus wel antwoord geven op de vraag, graag.

Gerard Dirven

Kritisch doorlezen van de kostenrekeningen in het grootboek en daarbij letten op periodiciteit en dergelijke. Het moet hier gaan om een 'extra' factuur die gezien omvang daarin al haast moet opvallen. Niet erg sophisticated maar waarschijnlijk wel effectief.

Martin Koelewijn

Volgens mij gaat het bij de toepassing van steekproeven over de doelstelling een uitspraak te doen over de onderzochte (homogeen veronderstelde) populatie: kwalitatief dan wel kwantitatief en met een antwoord "valt binnen/buiten bandbreedte" of "verwerpen/niet verwerpen". Een onderzoek naar fraude in een populatie gaat m.i. uit van de veronderstelling dat de populatie niet homogeen is. Immers, er zit een (fraude-)post in die er niet in thuis hoort. Deze zou in de steekproef kunnen vallen door de toevallige trekking, of door de omvang (afhankelijk van de gekozen trekkingswijze) of omdat de post sowieso door zijn omvang tot de integraal te controleren posten van de steekproef behoort. Achteraf hebben we altijd gelijk, zo ook Rinus. Fraude-ontdekking is niet de doelstelling van een accountantscontrole, hoewel het lijkt of dit langzaam naar de achtergrond verdwijnt vanuit de maatschappelijke roep om fraude tegen te gaan.

Pieter de Kok

Leuk Paul! En goede input Rinus! De vraag is of we een dergelijk data script (technisch zeker mogelijk) ook "allemaal" standaard in ons werkprogramma meenemen. Dit risico zal in menig controle worden geflagged als mogelijk, inclusief verwijzingen naar ITGC rondom stamgegevens. Ik denk dat deze verwijzing, inclusief nog wat verwijzing naar detail cijfebeoordeling in praktijk het werkprogramma is. Paul heeft gelijk met belang op input en output controls wanneer het gaat om data-analyse (en ja, daar zullen we beter mee moeten omgaan), maar voor dit specifieke voorbeeld is Rinus zijn insteek prachtig. Ik heb blog gedeeld op onze Coney Yammer, eens kijken of er nog andere suggesties komen. To be continued.

Rinus Leemans

Afgezien van het feit of het technisch mogelijk is, zou volgens mij een mogelijk zijn om een query te draaien van alle rekeningnummers, met naam en met bedragen waarop gedurende het jaar betalingen gedaan zijn. Hierop zou een trendanalyse gedaan kunnen worden (bekende voorbeelden zoals grote bedragen, ronde bedragen, periodieke bedragen of juist afwijkingen in de periodiciteit). In dit specifieke geval betreft het een betaling aan een afvalverwerkingsbedrijf (waar het bankrekeningnr. veranderd is in dat van de beruchte Brabander). Uit de analyse zou voorkomen dat op er op enig moment aan een ander bankrekeningnr. is betaald of aan twee verschillende nummers om het te verhullen). Wellicht valt op dat het bedrag afwijkt ten opzichte van een trend. Interessant(er) vind ik als accountant de vraag hoe dit had kunnen worden voorkomen? Ik denk dat in dit geval een controletechnische functiescheiding ontbrak bij het aanpassen van de crediteurenstamgegevens (wellicht geen logging, of niemand die er naar keek). Onvoldoende controle bij het verrichten van de betaling, of wellicht samenspanning gezien het feit dat er 5 personen bij betrokken zijn (niet bekend of deze ook bij de Gemeente werkzaam waren).

Reageren op een artikel kan tot drie maanden na plaatsing. Reageren op dit artikel is daarom niet meer mogelijk.

Aanmelden nieuwsbrief

Ontvang elke werkdag (maandag t/m vrijdag) de laatste nieuwsberichten, opinies en artikelen in uw mailbox.

Bent u NBA-lid? Dan kunt u zich ook aanmelden via uw ledenprofiel op MijnNBA.nl.

Relevantie Datum