IPE testing: 'wat' is belangrijker dan 'hoeveel'
Onlangs had ik een discussie met accountants over de steekproefomvang bij IPE-testing (IPE=Information provided by entity). Conclusie: gebruik je eigen professionele oordeel, maar kies er geen 25.
Het rapport van de IFIAR (de overkoepelende organisatie van toezichthouders) vermeldt het gebrek aan onderbouwing van de aanvaardbaarheid van schattingen als meest gemaakte opmerking over wereldwijd beoordeelde dossiers. De juistheid en volledigheid van de data die voor die schattingen worden gebruikt, zijn daarvan belangrijke onderdelen. Het wordt dus tijd voor helderheid over een normenkader voor de noodzakelijke hoeveelheid werk. In de genoemde discussie kwam al snel de SOx-tabel op tafel, wat mij tot de hartenkreet bracht: doe er desnoods 24 of 26 maar geen 25!
Wat is IPE testing?
De huishouding deelt bestanden en berekeningen met de accountant ten behoeve van een effectieve en efficiënte controle. Voordat de accountant daarop kan steunen moet natuurlijk worden vastgesteld dat die berekeningen en gegevens kloppen. Zo kan de accountant bijvoorbeeld bij een cijferanalyse op de omzet van een filiaalbedrijf gebruikmaken van een model waarin de omzet van een filiaal wordt verklaard door de personeelskosten en de vloeroppervlakte.
Zo'n model is niet perfect, want niemand zal meer omzet genereren door enkel en alleen maar een extra personeelslid aan te nemen, of door het magazijn bij de winkel te trekken. Maar achteraf bezien, aannemend dat het bedrijf stuurt op efficiënte bedrijfsvoering, bestaat er een flinke correlatie tussen deze gegevens. Zo'n extra medewerker trek je niet voor niets aan.
Een ander voorbeeld is de viskraam die tweemaal per week voor mijn appartement staat. Bij elke 5 euro aankopen krijg je een stempel op een kaart, en 10 stempels geven recht op een haring van 2,25 euro. De ondernemer moet dus een deel van zijn opbrengst reserveren vanwege de toekomstige verplichting om gratis haringen te verstrekken. Maar welk deel? Een aandeel van 2,25/(10*5) = 4,5 procent van de opbrengst is zeker genoeg. Eigenlijk te veel, onder meer omdat vier haringen maar drie stempels opleveren en omdat niet iedereen al zijn kaarten inlevert. Als de zaak echt groeit, kan het de moeite waard worden om een analyse uit te voeren op aankoopbedragen en een onderzoek te doen naar de omloopsnelheid van de stempelkaarten. En de accountant zal dan over de aannames die de ondernemer doet en over de gebruikte data een oordeel moeten geven.
IPE testing is nu het samenstellen van werkzaamheden dat de controleur uitvoert om vast te stellen dat de aangeleverde gegevens bruikbaar zijn voor de gewenste analyse.
Geen gegevensgerichte controle
In het hierboven geschetste voorbeeld van het filiaalbedrijf lijkt het mij overbodig om IPE testing uit te voeren op omzet of op personeelskosten. Er volgt immers een jaarrekeningcontrole op de omzet, dus waarom de bruikbaarheid testen als je de getrouwheid al aan het testen bent? En in dat zelfde kader worden de personeelskosten ook gecontroleerd; wel is van belang dat als de cijferanalyse bedoeld is om de omzet op volledigheid te toetsen, de personeelskosten ook op volledigheid moeten worden getoetst. Het enige dat in aanmerking komt voor IPE testing is de vloeroppervlakte, want die wordt niet door de jaarrekeningcontrole geraakt. Kom ik op terug.
Geen proceduretest
Het lijkt er weleens op dat als een accountant het niet meer weet, het juiste antwoord 25 is. (Hoeveel verzorgingshuizen mogen er weer bezoek ontvangen?) Volgens de Hitchhiker's Guide to the Galaxy zou dat 42 moeten zijn, maar het getal van 25 komt natuurlijk uit de SOx-tabel voor het testen van een procedure die dagelijks of nog vaker wordt uitgevoerd.
Maar, de bruikbaarheid van data-testen is toch geen proceduretest? Sterker nog, om de bruikbaarheid van data te testen zou het nuttig zijn om procedures rondom die data te beoordelen om daarmee zo mogelijk te kunnen stellen dat er minder IPE-controle nodig is. Een controleur die de omvang van een IPE test op 25 kiest, wekt daarmee de schijn die test als proceduretest op te vatten. Vandaar mijn advies: doe er geen 25!
Wat is IPE testing dan wel?
Wie een bestand met vloeroppervlaktes van filialen wil toetsen op bruikbaarheid kan niet zo maar een statistische steekproef toepassen. De omvang daarvan wordt immers bepaald door de uitvoeringsmaterialiteit en het toelaatbare risico, los even van de omvang van de populatie en het verwacht aantal fouten. Welke materialiteit is nu aan de orde? De populatie luidt niet eens in geld.
NBA Handreiking 1141 verwijst naar de Standaarden over gegevensgerichte controles. Als we niet oppassen gaan we net zo veel werk in de IPE testing steken als nodig zou zijn om de betrokken jaarrekeningpost gewoon met een steekproef te controleren.
Standaard 500, paragraaf A31 adviseert om externe bronnen te gebruiken. Misschien is dat in mijn voorbeeld van de vloeroppervlaktes te doen, maar het kadaster of het WOZ-waardeloket zullen waarschijnlijk een andere definitie van oppervlakte hanteren dan de winkelketen. Ik denk dat een steekproef dan toch maar nodig is voor het bepalen van de betrouwbaarheid van de door de onderneming gebruikte winkeloppervlaktes.
Maar hoe groot moet die steekproef zijn? Een normenkader ontbreekt. Genoemde Standaard 500 A31 geeft een aantal voor de hand liggende adviezen, maar geeft niet aan hoeveel controlewerk op die data moet worden uitgevoerd. Als de IFIAR stelt dat het (te) vaak gebeurt dat dergelijke steekproeven te klein zijn, zie ik uit naar het antwoord op de vraag hoe het dan wel moet.
Natuurlijk is er heel veel heel nuttig werk te doen om de betrouwbaarheid van gebruikte gegevens te onderzoeken. We kunnen de sensitiviteit van de gegevens voor de uitkomsten in kaart brengen. We kunnen de reproduceerbaarheid van die gegevens nagaan. Maar hoe vaak en hoeveel blijft onbeantwoord. In het zicht van mijn pensioen kom ik tot de conclusie: doe maar wat je zelf het beste vindt. A matter of professional judgement. Als dat maar niet op 25 uitkomt, want IPE is geen proceduretest.
Gerelateerd
Machine learning in de audit: stratificeren van bedrijfslocaties
In dit derde en laatste deel van een reeks columns over machine learning in de audit gaat het over clusteren. De auteurs laten zien hoe je met een open-source statistiekprogramma...
Machine learning in de audit: uitschieters bij vastgoedwaardering
Regressie is een vorm van machine learning met als doel het voorspellen van cijfers op basis van een aantal kenmerken. Met open-sourcesoftware kun je zonder programmeerkennis...
Machine learning in de audit: voorspellen van klantverloop
Het doel van machine learning is om voorspellingen te maken aan de hand van data. Binnen dit veld worden doorgaans drie hoofdtoepassingen onderscheiden: classificatie,...
De steekproefomvang ontmaskerd - deel 5
In vorige columns hebben we verschillende manieren besproken om tot een steekproefomvang te kunnen komen. Deze column is de laatste van de serie waarin we verschillende...
De steekproefomvang ontmaskerd - deel 4
Een accountant die gebruikmaakt van software om een steekproefomvang te berekenen, moet zeker weten dat die software dat goed doet. Daarvoor moet je de rekenmethode...