Home Magazine

RPA en de impact op de jaarrekeningcontrole

15 november, 2023
De Kennisgroep IT en Financial Audit biedt in dit artikel twee praktijkcasussen die ingaan op de samenwerking tussen de Financial en IT-auditors om de impact van RPA te kunnen inschatten voor de jaarrekeningcontrole
Inleiding
Robotic Process Automation (RPA) is een actueel onderwerp waar al eerder over geschreven is. In 2020 is een artikel in de IT-Auditor gepubliceerd waarin riskmanagers en auditors worden geïnformeerd hoe RPA-risico’s beheerst kunnen worden. In een ander artikel uit 2019 wordt ingegaan op de impact van RPA op de audit. In dit artikel geven wij met twee concrete casussen een vervolg aan deze publicaties. De focus ligt hierbij op de samenwerking tussen de Financial en IT-auditors om de impact van RPA te kunnen inschatten voor de jaarrekeningcontrole. En ook om te illustreren welke stappen gevolgd kunnen worden om RPA-toepassingen in het kader van de jaarrekeningcontrole te beoordelen. Bij dit artikel maken we ook gebruik van het door de NOREA gepubliceerde RPA best-practices-raamwerk.

Maar wat is RPA nu eigenlijk?
Met RPA bedoelen we softwareoplossingen waarbij handmatige handelingen worden geautomatiseerd die gebruik maken van dezelfde onderliggende informatiesystemen en schermen (de user interface) die een medewerker ook gebruikt.

De voorbeelden in dit artikel gaan over menselijke handelingen die een deterministisch (rule-based) en repetitief karakter hebben. Er bestaan ook RPA-toepassingen waarbij gebruik wordt gemaakt van data-science-technieken om bijvoorbeeld ongestructureerde data om te zetten naar gestructureerde data (OCR). In andere toepassingen neemt de RPA-beslissingen op basis van data-science-technieken, zoals het intelligent toe- of afwijzen van een aanvraag op basis van kenmerken van andere toe- dan wel afgewezen aanvragen. De intelligentie in een dergelijke RPA-toepassing kan een dynamisch algoritme zijn dat leert op basis van de definitieve resultaten van eerdere aanvragen. Deze laatste 2 vormen van RPA-toepassingen komen wellicht in een volgende publicatie aan de orde.

In dit artikel beschrijven we twee praktijkvoorbeelden van RPA-toepassingen om te laten zien wat de mogelijke impact is op de jaarrekeningcontrole en welke auditactiviteiten gedaan kunnen worden rondom de RPA-oplossing. In deze voorbeelden beschrijven we specifieke risico’s voor de betreffende RPA-toepassing. Na de praktijkvoorbeelden geven we in de conclusie van dit artikel een evaluatie van de generieke risico’s van RPA-toepassingen en de mogelijke respons daarop voor de jaarrekeningcontrole.

Praktijkvoorbeeld 1: Samenvoegen van bedrijfsonderdelen
Situatieschets
Deze casus heeft betrekking op een organisatie die opereert in de telecommunicatiemarkt, een markt met zeer veel data die bovendien in hoge snelheid beschikbaar komt.

Na een overname staat deze organisatie voor de uitdaging om het nieuwe bedrijfsonderdeel samen te voegen met de bestaande organisatie. Het nieuwe bedrijfsonderdeel levert andersoortige diensten aan klanten waar ook de bestaande organisatie aan levert. De doelstelling is om één view op de klanten te krijgen en men wil daarom de data van het nieuwe onderdeel overbrengen naar de bestaande systemen. Vervolgens wil de organisatie een korting geven aan klanten die van beide onderdelen diensten afnemen.
RPA-toepassing

Het overbrengen van de data naar het bestaande systeem dient op dezelfde wijze te gebeuren als wanneer een medewerker een klant/dienst combinatie zou opvoeren. Het bestaande systeem wordt niet aangepast. Dit waren de randvoorwaarden die gesteld zijn. Het bestaande systeem is een workflow-based-systeem, waarbij in iedere stap vastleggingen worden gemaakt inzake de dienst en klant.

Na analyse is ervoor gekozen om een RPA-toepassing te ontwikkelen die alle stappen in het proces geautomatiseerd uitvoert: openen van het juiste scherm, het selecteren en vullen van de velden, bevestigen en goedkeuren van de vastlegging. Alternatieve oplossing was het inschakelen van zeer veel menskracht, bijvoorbeeld een shared services center, voor het handmatig verwerken van de gegevens.

Audit impact
Deze casus heeft als kenmerk en als uitgangspunt dat het eenmalig extra audit werk met zich meebrengt in het kader van de jaarrekeningcontrole. Ongeacht welke oplossing was gekozen door de organisatie, deze eenmalige activiteit om data over te brengen zal beoordeeld moeten worden om vast te stellen dat er geen issues van materieel belang zijn opgetreden. Als eerste stap heeft de controlerend accountant vastgesteld dat dit RPA-proces een materieel effect op de jaarrekening heeft. Daarom wordt er vooraf aan de implementatie gekeken naar de detailrisico’s en detailmaatregelen in dit RPA-proces om vast te stellen dat de controledoelstelling wordt behaald.

Voor het bepalen van de scope is gebruik gemaakt van het NOREA RPA best-practices-raamwerk welke in combinatie met de standaard ITGC-frameworks toegepast wordt.

De volgende aandachtspunten zijn van belang in deze specifiek casus

  1. Risico’s inzake change management
    Het change proces werd niet als verhoogd risico gezien. De gangbare controlemaatregelen worden in de scope meegenomen met een nadruk op het proces rondom het testen van de kwaliteit van de oplossing. Daarnaast was vastgesteld dat de RPA-toepassing wordt beheerd door de onafhankelijke IT-afdeling.

  2. Risico’s inzake operationele werking
    Hier werd een verhoogd risico gedefinieerd ten aanzien van de foutafhandeling. Wat doet de RPA-toepassing als de data nét iets anders is dan verwacht? Wordt er gebruikgemaakt van een default-waarde? Wordt een waarde ingevuld op basis van vergelijkbare andere gegevens? Of worden deze records naar een ‘error-lijst’ weggeschreven voor handmatige opvolging? En hoe worden eventuele incidenten (tijdig en juist) opgevolgd?

  3. Bevoegdheden van het RPA-account
    Omdat het systeem een workflow-based-systeem is, dat normaal gesproken volgordelijk door meerdere medewerkers wordt uitgevoerd (functiescheiding), heeft het RPA-account maximale gebruikersrechten nodig om alle stappen te kunnen uitvoeren. Alle functiescheidingen zijn daarmee doorbroken.

    Dit werd niet gezien als een verhoogd risico, simpelweg omdat een RPA-toepassing geen incentive heeft om misbruik te maken van rechten voor persoonlijk gewin. Tevens is de noodzaak voor een tweede paar ogen om fouten te corrigeren minder, omdat de robot onvermoeid en consistent de geprogrammeerde handelingen uitvoert.

  4. De beschikbaarheid van het RPA-wachtwoord
    Dit werd wel gezien als een verhoogd risico. Het RPA account is voorzien van een wachtwoord, maar dit wachtwoord is bij minimaal één medewerker bekend (en in de praktijk bij meerdere medewerkers). Hiermee is het risico op misbruik van het RPA-account voor persoonlijk gewin aanwezig.

    De maatregelen die aanbevolen zijn, betreft een ‘envelop-procedure’, waarbij minimaal 2 medewerkers elke een deel van het wachtwoord invoeren en deze delen, en welke op een veilige locatie worden bewaard.

    Voor het periodiek wijzigen van het RPA-wachtwoord werd voorgesteld om dit niet te doen, vanwege problemen bij de praktische uitvoerbaarheid van een wachtwoordwijziging. De discussie rondom de risico’s die hiermee samenhangen werden ‘on-hold’ gezet, omdat het overbrengproces in principe binnen de tijd van een reguliere wachtwoordwijziging uitgevoerd zou moeten zijn.

  5. Beveiliging van de input bestanden
    Dit werd gezien als een verhoogd risico. De RPA-toepassing leest de input bestanden en brengt deze gegevens over naar het bestaande systeem. De RPA-toepassing veronderstelt dat de kwaliteit van de data voldoende is, er worden geen checks op de datakwaliteit (bijv. plausibiliteit) gedaan, vóórafgaand aan de verwerking . Toegang tot de inputbestanden door medewerkers werd als een verhoogd risico gezien met name voor het ongeautoriseerd verlenen van kortingen. Strikte toegangsbeveiliging werd ingericht evenals loggen en beoordelen van toegangspogingen op de inputbestanden.
Daarnaast is het nodig om voor de werking van de robot minimaal een test-of-one van een registratie uit te voeren om te verifiëren dat de logica naar behoren werkt. Het enige scenario dat getest wordt betreft of een registratie juist en volledig in de workflow van het bestaande systeem wordt geschoten. Dit in combinatie met het beoordelen van de configuratie van de RPA-toepassing.

Conclusie
In deze casus gaat het om het kunnen steunen op de werking van een RPA oplossing die fungeert als een automatische interface inclusief de afgedwongen workflows in het bestaande systeem, om data van twee verschillende systemen te combineren. In de voorbereidende fase van de jaarrekeningcontrole is besloten dat het efficiëntie met zich meebrengt om te steunen op de werking van de RPA-oplossing. Op basis van het RPA-framework zijn de risico’s in kaart gebracht en geclassificeerd. Dit heeft er toe geleid dat aanvullende maatregelen in de generieke IT-beheerprocessen en inrichting van het RPA-proces zijn afgedwongen. De business rules die borgen dat data juist wordt verwerkt en rechtmatige kortingen worden verstrekt zijn verankerd in de ingerichte workflows in het bestaande systeem. Dit valt buiten het RPA-project en zullen als reguliere geautomatiseerde beheersmaatregelen beoordeeld dienen te worden.

Praktijkvoorbeeld 2: Afhandeling afgekeurde facturen
Situatieschets
Deze casus betreft een groothandel met voornamelijk voedingsmiddelen in haar assortiment. De distributievorm die gehanteerd wordt is voor een groot deel zelfbediening, maar bezorging wordt ook gedaan. De typologie betreft een ‘wholesaler’, oftewel een organisatie met een dominante goederenstroom die levert aan andere industrieën.

Omdat de focus van het bedrijf ligt op het verhandelen van goederen zit er veel tijd in het controleren en fiatteren van goederenfacturen. Of de controle of facturen juist en volledig zijn, wordt geautomatiseerd uitgevoerd door middel van 3-way-matching in het ERP-systeem. Deze controle vergelijkt de inkooporder, goederenontvangst en factuur om te kijken of deze op elkaar aansluiten. Op basis van prijsverschil, leveringsverschil, of een combinatie van deze twee factoren wordt een factuur goedgekeurd of afgekeurd.

RPA toepassing
Wanneer een factuur door het ERP-systeem wordt afgekeurd op basis van de ingeregelde criteria, handelt een RPA-oplossing de factuur verder af. De RPA-oplossing neemt details, waaronder het soort artikel, hoeveelheid, prijsverschil en leveringsverschil, op in een nieuw digitaal formulierbestand. Vervolgens zet de oplossing het bestand door naar de handmatige factuurcontrole van de crediteurenbeheerafdeling. Hierna beslist een medewerker over de goedkeuring.

Wanneer een medewerker van crediteurenbeheer bepaalt dat de factuur alsnog wordt afgekeurd, vinkt deze hierbij de optie ‘inkoper niet akkoord aan’ in het digitale formulier. Deze knop geeft automatisch terugkoppeling aan het ERP-systeem. Hierna stelt de RPA-oplossing een verrekenbrief op en verstuurt deze naar de desbetreffende leverancier.

Als de crediteurenbeheerafdeling bepaalt dat de factuur goedgekeurd is door de optie ‘inkoper akkoord’ aan te vinken in het formulier, dan wordt hij betaalbaar gesteld onder een speciale code. Een overzicht van het proces zie je hieronder:
Audit impact
Hoewel de oplossing niet betrokken is bij de grootste financiële stroom in dit proces, is het opvolgen van de uitval, voorbereiden van goedkeuringsdocumentatie en het verzenden van verrekenbrieven naar leveranciers wel degelijk een stroom van materieel belang van de jaarrekeningcontrole voor deze klant. In de jaarrekeningcontrole wordt tot op heden voor deze stroom nog een handmatige aanpak gehanteerd door middel van de inspectie van een omvangrijke steekproef van verrekenbrieven. Het eventueel kiezen voor een procesgerichte auditaanpak waarbij gesteund wordt op de RPA-oplossing stelt andere eisen aan de controle-aanpak in vergelijking met de situatie waarin deze stappen handmatig worden ondernomen.

Ten eerste prepareert de eerste oplossing de gegevens van de uitgevallen factuur die ter goedkeuring wordt aangeboden, waarmee information used in the control (IUC) wordt gegenereerd. Maar middels de rapportagemogelijkheden van de digitale formulieren en het ERP-systeem kan deze efficiënt worden afgedekt door een integrale aansluiting tussen formulieren en de uitvalbak uit het ERP-systeem, met als resultaat dat dit deel van de RPA-oplossing buiten scope kan worden geplaatst.

Maar het opstellen en verzenden van de verrekenbrieven brengt wel een financieel risico met zich mee. Een te hoge verrekening is niet direct een risico op onjuiste of onvolledige gegevens, immers de leverancier controleert hierna of hij niet teveel geld verliest. Een te lage verrekening of zelfs géén verzonden verrekening betekent dat de organisatie geld zou verliezen.

Als hier dus gesteund zou worden op de RPA-oplossing, dan worden ook IT-beheersmaatregelen (zoals toegangs- en wijzigingsbeheer) over het RPA-platform, waarbinnen de oplossing gebouwd is, relevant. Afhankelijk van de materialiteit van de financiële stroom kan het toetsen van een integrale (volledige) set van beheersmaatregelen wenselijk zijn tegenover een beperktere set maatregelen op basis van risicoanalyse.
In de regel creëert het gebruik van RPA aanvullende toegangsrisico’s.

Risico A: de accounts die de oplossing gebruikt om in de financiële applicaties te komen moeten vaak interactief benaderbaar zijn zodat de robot de handelingen van een medewerker kan nabootsen. Dit is uiteraard ook gevoelig voor ongeautoriseerd gebruik wanneer de logingegevens bekend zijn bij reguliere gebruikers.

Risico B: Ook wordt aanvullende logica gemaakt die financiële bewerking doet, waarin dus foutieve verwerking kan ontstaan- vaak dan nog in bulk ook.

Risico C: Of in andere gevallen kan de robot te vaak- of juist niet vaak genoeg in gang worden gezet, of met foutieve input, leidend tot problemen met tijdigheid, volledigheid of juistheid van de verwerking van afgekeurde facturen. Minimaal kan dus worden verwacht dat met het volgende rekening moet worden gehouden:


 Risico

Controls over: AB       C      
Toegang tot de/het RPA-account(s) X

Toegang tot de werkvoorraad (te verwerken facturen en te verzenden verrekenbrieven) X

Toegang tot het rechtenbeheer van het robotiseringsplatform X

Toegang tot scheduling van de robot X
X
Rechten van de business-medewerkers die interacteren met de bot X

Monitoring en opvolging van fouten

X
Het wijzigingsmanagementproces van de logica van de robot
X

Daarnaast is het nodig om voor twee scenario’s (factuur handmatig goed- en afgekeurd) minimaal een test-of-one uit te voeren om te verifiëren dat de logica naar behoren werkt, in combinatie met het testen van de configuratie van de scenario’s. Ook dient de interface tussen het ERP-systeem en het RPA-platform te worden getest, waarin wordt gekeken of de output van verrekenbrieven uit het RPA-platform leidt tot dezelfde input in het ERP-systeem.

Conclusie
In geval van deze voorgestelde casus waarin slechts een enkelvoudige RPA-oplossing gebruikt wordt, is al in de voorbereidende fase van de jaarrekeningcontrole besloten dat bovenstaande te weinig efficiëntie met zich meebrengt ten opzichte van een steekproef-controle. Het biedt wel inzicht in: het vergroten van het aantal beheersmaatregelen dat door middel van een RPA-oplossing wordt uitgevoerd/ondersteund. Dit laatste verhoogt de meerwaarde van toetsing van de IT-beheersmaatregelen over het RPA-platform en de robots. Efficiëntie hoeft uiteraard niet altijd een valide argument te zijn om al dan niet gebruik te maken van RPA in de controle. Een klant ervaart over het algemeen meer toegevoegde waarde als zijn systeem van interne beheersing voldoende betrouwbaar wordt geacht, in plaats van een omvangrijke deelwaarneming, die in veel gevallen ook voor de klant tijdrovend is.

Conclusie RPA-oplossingen en impact op de jaarrekeningcontrole 
Uit de praktijkvoorbeelden in dit artikel is gebleken dat controlerisico’s binnen RPA zich vooral manifesteren in de technische inrichting: Doet de RPA-oplossing altijd wat deze moet doen? Als auditor zal je daarom de operationele werking moeten beoordelen of zekerheid verkrijgen dat de gebruiker in voldoende mate heeft vastgesteld dat het script in alle gevallen doet wat het moet doen. 

Verder zien we ook risico’s in het beheer van de RPA-oplossing, waarvoor logischerwijs de reeds bekende generieke IT-beheersmaatregelen (met name logische toegangsbeveiliging en wijzigingenbeheer) voldoende geborgd moeten zijn. Bovendien zijn deze generieke IT-beheersmaatregelen randvoorwaardelijk om de werking van de RPA-oplossing over een langere periode te kunnen beoordelen. 

Kortom, een RPA-oplossing lijkt wellicht op het eerste gezicht eenvoudig, maar niets is minder waar. Het in scope nemen van een RPA-oplossing kan tijdrovend en complex zijn, waardoor ook voor het steunen op RPA-oplossingen in de controle veelal een kosten-baten afweging gemaakt zal worden, of het leidt tot een effectievere en/of efficiëntere controle-aanpak. Daarom is een nauwe samenwerking tussen financial auditor en IT-auditor essentieel.