Geen of onvoldoende getroffen maatregelen voor een beheerste verwerking van betaalbestanden betekent dat er een leemte bestaat in de betaalorganisatie. Van de controlerend accountant wordt verwacht dat hij zich bewust is van dit risico en hier effectief op inspeelt.
In april 2021 heeft het Compliancekantoor in een tweeluik van artikelen aandacht gevraagd voor frauderisico’s met betrekking tot de betaalorganisatie en het inspelen hierop. Op basis van het aantal downloads en reacties vanuit het werkveld blijkt dat deze artikelen invulling geven aan een behoefte bij (assistent-)accountants om dit specifieke frauderisico te begrijpen en te adresseren.
Onlangs kwamen wij over dit onderwerp in contact met Cygnus Atratus en dit heeft ons aangezet om een specifiek frauderisico met betrekking tot de betaalorganisatie onder de aandacht te brengen.
Een bijdrage door: drs. Edwin van der Wösten RA in samenwerking met Cygnus Atratus
Vanuit de fraudedriehoek wordt het voorhanden zijn van ‘gelegenheid’ gezien als een frauderisicofactor. Dit betekent dat als de AOIB in een organisatie leemten bevat, dit door een fraudeur kan worden aangegrepen om zichzelf opzettelijk oneigenlijk middelen toe te eigenen, die eigendom zijn van de organisatie waar hij of zij werkzaam is. Hiervan zijn genoeg voorbeelden voorhanden die met een simpele Google-search naar boven komen. Een willekeurige greep uit recente fraudecasussen levert het volgende op:
Deze gevallen hebben gemeen dat de AOIB van desbetreffende organisaties één of meerdere leemten bevat. In onze eerdere artikelen over dit onderwerp is voornamelijk ingegaan op tekortkomingen bij het toekennen van (zelfstandige) betaalbevoegdheden aan functionarissen in een organisatie.
Wat echter ook een leemte kan zijn, en zich kan voordoen in (ondermeer) het mkb, is dat er geen maatregelen zijn getroffen voor een beheerste verwerking van betaalbestanden[1]. Deze worden goedgekeurd in het financiële systeem (vaak onderdeel uitmakend van een ERP-systeem) en worden bijvoorbeeld op een beveiligde C-schijf gezet voordat deze ingelezen worden in de bankapplicatie. Bij dit ‘inlezen’ kan een fraudeur het betaalbestand nog manipuleren door het IBAN-nummer te wijzigen, waardoor hij zichzelf oneigenlijk geldmiddelen kan toe-eigenen. De gemanipuleerde versie van het betaalbestand wordt weggegooid en de originele blijft bewaard. Achteraf is dan niet meer vast te stellen welke betalingen daadwerkelijk zijn uitgevoerd en of een ander bestand dan het bewaarde bestand is verwerkt. Schematisch ziet dit er als volgt uit:
Pas op het moment dat crediteuren klagen over niet betaalde facturen kan de fraude aan het licht komen. Een ‘slimme’ fraudeur, die ook voldoende rechten heeft in zowel het ERP-systeem als op de beveiligde C-schijf, kan echter de ‘sleeptechniek’ toepassen waardoor fraude voor langere tijd verhuld kan blijven. Ook kan de fraudeur bijvoorbeeld de betaling van een geannuleerde order of gecrediteerde factuur aan zichzelf overmaken.
De controlerend accountant moet zich bewust zijn van dit risico en kan ‘detecterende’ werkzaamheden uitvoeren. Hiervoor moeten echter gedurende het jaar de daadwerkelijk uitgevoerde betaalbatches worden veiliggesteld. Dit kan door vier keer per jaar (per 3 maanden) hash totals op te zoeken in de bankapplicatie of de details van de betaalbatches te downloaden. Vervolgens kan een analyse worden uitgevoerd op bijvoorbeeld dubbele IBAN-nummers per crediteur. Alsblijkt dat een crediteurnaam is te koppelen aan betalingen op meer dan één IBAN-nummer,gaat de accountant na of de IBAN-nummers matchen met derechtmatigecrediteur.Bijvoorbeeld door een naam-nummercontrole in de bankapplicatie of het raadplegen van de website van de crediteur.
Op grond van Controlestandaard 260 en 265 wordt van de accountant verwacht dat hij effectief communiceert over onder meer significante tekortkomingen in de interne beheersing. Dit betekent dat de accountant vanuit zijn natuurlijke adviesfunctie adviseert om de interne beheersing te versterken. In dit geval bijvoorbeeld door de folder waarin de betaalopdracht wordt opgeslagen te beveiligen en het ERP-systeem ‘hash totals’ te laten genereren bij het digitaal autoriseren.
Hash totaal (hash total): Een hash is een controlegetal en bevat de som van alle velden in het betaalbestand, zowel cijfers, letters als spaties. De berekende hash is uniek voor elk bestand.
Vervolgens zal de bevoegde functionaris (autorisator van de betalingen) in de bankapplicatie het hash total moeten vergelijken met het hash total die de bankapplicatie heeft gegenereerd. Indien er manipulatie heeft plaatsgevonden in het betaalbestand, komt dit dan aan het licht. Dit is schematisch als volgt weer te geven:
Wil je meer lezen over de toepassing van het hash total, lees dan de paper van Betaalvereniging Nederland.
Fraude kan zich op verschillende manieren voordoen, ook in de betaalorganisatie. Uit bekende fraudecasussen blijkt dat dit een gewillige plek is voor fraudeurs om toe te slaan. Voldoende reden voor de accountant om de werkelijke werking van de betaalorganisatie te doorgronden!
Met dit artikel streven wij ernaar een bijdrage te leveren aan de kwaliteit van jaarrekeningcontroles.Andere artikelen in deze reeks zijn nog steeds actueel en bevelen wij van harte aan:
- Deel 1 over de frauderisico’s met betrekking tot de betaalorganisatie.
- Deel 2 over de controleaanpak van frauderisico’s als gevolg van een leemte in de betaalorganisatie.
[1] SEPA-bestanden
Terug naar het overzicht
Home>Nieuws>Artikelen>'Hash total': nog steeds een relevante beheersi...
