Next generation Journal Entry Testing – Een nieuwe manier om informatie uit het grootboek te halen

11 juni 2014
In dit artikel:

Iedere organisatie is verplicht om een financiële administratie bij te houden. De boekhoudvorm die gewoonlijk wordt gebruikt, is het dubbel boekhouden. Hierbij staat tegenover iedere debitering van een grootboekrekening  een even grote creditering van een andere grootboekrekening en tegenover iedere creditering een even grote debitering. Deze vorm werd voor het eerst gebruikt in Italië tijdens de renaissance. Er is sindsdien op het vlak van bedrijfsadministratie echter veel veranderd, vooral in de laatste decennia door de opkomst van ERP-systemen.

 

Met het gebruik van ERP-systemen zijn de complexiteit en het volume van de gegevenstransacties enorm toegenomen en is het voeren van een boekhouding meer en meer een geautomatiseerd en gestandaardiseerd proces geworden. Medewerkers zijn zich er niet altijd van bewust dat hun interactie met een ERP-systeem indirect leidt tot een transactie in het grootboek. Een ander gegeven is dat het vandaag de dag  geen uitzondering meer is als een organisatie jaarlijks miljoenen transacties produceert.
Door deze enorme hoeveelheid data ontstaat het probleem dat de auditor belast met de controle van de jaarrekening, het overzicht verliest en relevante transacties niet gemakkelijk meer kan identificeren en analyseren. Dit is een groot probleem, aangezien grootboek-
analyses noodzakelijk zijn om fouten en/of fraude te identificeren. Grootboekgegevens worden vaak in een tabelstructuur met rijen (boekingsregels) en kolommen (boekingskenmerken) aangeleverd door klanten, waarbij meerdere boekingsregels samen een boeking vormen. De huidige analyses zijn meestal gebaseerd op bepaalde boekingskenmerken waardoor specifieke boekingsregels worden geselecteerd waarna de analyse zich richt op deze specifieke regels. De selectie bestaat vaak  uit een groot aantal regels die lang niet allemaal relevant zijn voor de auditor, waardoor de analyse een tijdrovend en moeilijk proces is. Is er misschien een slimmere manier om snel inzicht te krijgen in het grootboek en de processen van de organisatie, waarmee je op een eenvoudigere manier fouten of fraude op het spoor kunt komen?

Is er een slimme manier om snel inzicht te krijgen in het grootboek en de processen van de organisatie, waarmee je eenvoudig fouten of fraude kunt opsporen?

 

Waarom grootboekanalyses?

In de jaren negentig van de vorige eeuw heeft het risico van fraude in financiële verslaggeving een steeds grotere nadruk gekregen in de internationale auditstandaarden. De AICPA (American Institute of Certified Public Accountants) publiceerde daarom in 2000 het rapport ‘Panel on audit effectiveness’. In dit rapport deed de AICPA verslag van een externe review op een groot aantal audits om vast te stellen hoe auditors met het identificeren van fraude omgaan. De uitkomsten van deze review waren zorgwekkend; auditors bleken niet in staat om niet-standaard grootboektransacties te identificeren en te beoordelen op eventuele frauderisico’s. Niet-standaard grootboektransacties zijn voor een auditor de meest problematische transacties aangezien ze door reguliere proces-audits niet worden beoordeeld. In 15 procent van de gevallen bleek de auditor niet op de hoogte te zijn van de mogelijkheid om in de systemen niet-standaard grootboektransacties aan te maken. In 33 procent van de overige audits bleek dat de auditor geen werkzaamheden had verricht om niet-standaard grootboektransacties te beoordelen. De aanbeveling uit het AICPA-rapport was dan ook dat er een betere auditstandaard moest worden ontwikkeld om grootboektransacties te beoordelen, waardoor de auditor beter presteert en daarbij de detectiekans van frauduleuze financiële verslaggeving wordt vergroot.

Als antwoord op deze bevindingen is het SAS 99-verslag  ‘Consideration of Fraud in a Financial Statement Audit’ van de Auditing Standards Board (ASB) ontwikkeld. SAS 99 bevat gedetailleerde informatie voor het selecteren van transacties die door een auditor beoordeeld moeten worden. Op basis van een aantal kenmerken zou volgens dit rapport een frauduleuze transactie gedetecteerd kunnen worden. Deze kenmerken zijn:

  • transacties die gemaakt zijn op ongebruikelijke rekeningen of rekeningen die zelden worden gebruikt;
  • transacties die geboekt zijn door ongeautoriseerde gebruikers;
  • transacties die rondom periode-einde zijn gemaakt;
  • transacties die geen omschrijving bevatten;
  • transacties die een waarde hebben die afgerond is op hele getallen.

Deze standaarden zijn nu alweer tien jaar geleden geïntroduceerd in de auditwereld. Sindsdien zijn er verschillende CAAT’s (Computer Aided Audit Tools) ontwikkeld waarin deze analyses zijn geïntegreerd. In een uitzonderlijk geval worden nieuwe audittechnieken toegepast, waaronder het gebruik van de Wet van Benford om de getallenanalyse nog verder uit te breiden. En toch blijven grootboekanalyses een lastig onderwerp voor de auditor. Kunnen auditors meer halen uit alle data die in het grootboek wordt verzameld en is dit verder te integreren in de audit-
aanpak?

In de volgende paragraaf richt dit artikel zich op het identificeren van hersteltransacties, waarbij wordt ingegaan op de problematiek indien deze identificatie zich beperkt tot de kenmerken binnen een transactieregel. In de loop van dit artikel wordt er gerefereerd naar een aantal voorbeeldtransacties die zijn opgenomen  in Tabel 1.


 

Schermafbeelding 2014-06-11 om 15.13.35Tabel 1: Voorbeeldtransacties


 

 

Hersteltransacties

Zodra een transactie in het grootboek terecht is gekomen, mag deze niet meer worden gewijzigd of verwijderd. Dit wordt in ieder boekhoudpakket afgedwongen via de application controls, en in sommige gevallen zelfs op databaseniveau. Toch kan het zijn dat een transactie foutief is ingevoerd. Om dit te corrigeren wordt een transactie gemaakt die de foute transactie in zijn geheel tegenboekt en daardoor herstelt. De tegenboeking wordt in dit artikel gezien als een hersteltransactie; de oorspronkelijke transactie die tegengeboekt is, wordt gezien als de herstelde transactie.

Hersteltransacties zijn voor een auditor interessant om te beoordelen, vooral als ze rondom periode-einde worden gemaakt, aangezien dit een indicatie kan zijn  dat de cijfers de situatie rooskleuriger voorstellen dan daadwerkelijk het geval is. Niet alle hersteltransacties zijn echter direct te relateren aan fraude, ze kunnen immers ook gebruikt worden om foutieve boekingen te corrigeren. Daarnaast blijkt in de praktijk dat grote ERP-systemen veel automatische transacties in het grootboek registreren (op tussenrekeningen) en deze op een later moment automatisch herstellen.

Hersteltransacties kunnen gebruikt worden om vast te stellen dat de cijfers een juiste weergave zijn van de financiële situatie op een bepaald moment. Aan de andere kant zijn herstelde transacties en de bijbehorende hersteltransacties niet relevant voor vele andere analyses omdat ze per saldo geen impact hebben gehad op de cijfers. Een herstelde transactie kan bijvoorbeeld onnodig veel aandacht krijgen van de auditor, terwijl deze eigenlijk al door de klant zelf is gecorrigeerd. Voor het analyseren van een transactie moet dus ook rekening worden gehouden met andere transacties.

Het identificeren van hersteltransacties kan problematisch zijn indien het identificeren wordt beperkt tot de kenmerken binnen een transactie(regel). Wordt er bijvoorbeeld op rekening Nog te ontvangen facturen 1.210 euro geboekt en binnen een vooraf vastgesteld aantal dagen (bijvoorbeeld tien dagen) op dezelfde rekening 1.210 euro gecrediteerd, dan zou dit mogelijk een hersteltransactie kunnen zijn. Om vast te stellen of het daadwerkelijk om een herstelboeking gaat moet worden vastgesteld wat de tegenrekeningen zijn van deze twee transacties. Zijn deze niet gelijk, zoals in transacties 1 en 4 van Tabel 1, dan is dit geen hersteltransactie.

Transactietypen

In de bovenstaande situatieschets met hersteltransacties blijkt dat er meer informatie uit grootboekgegevens gehaald kan worden indien de kenmerken van de totale transactie worden meegenomen. Een transactietype is een aanduiding van een groep transacties die bepaalde kenmerken delen. Het gebruik van transactietypen vereenvoudigt de analyse door de auditor. Om het aantal verschillende soorten transactietypen te beperken is het verstandig om niet teveel kenmerken te gebruiken bij het bepalen van de transactietypen. In Tabel 1 is voor iedere transactie een transactietype  gegeven.

Bij het bepalen van een transactietype moet onderscheid gemaakt worden tussen de debet- en creditrekeningen. Wijkt  een rekening af van de standaard, dan moet dit worden gezien als een nieuw soort type. Transactie 9 is bijvoorbeeld gekenmerkt als nieuw type D, ondanks dat het dezelfde rekeningen bevat als transactietype C. Dit komt omdat de rekeningen in transactie 9 anders over credit/debet zijn verdeeld. Toch is het handig om transactie 9 een kenmerk te geven dat aangeeft dat deze veel overeenkomsten heeft met het bestaande transactietype C (zoals ‘C’). Hierdoor is het gemakkelijker om later inzicht te krijgen in de transacties die niet het standaardproces volgen. Hersteltransacties, waarbij de debet en credit-rekeningen zijn omgedraaid, moeten wel hetzelfde transactietype krijgen zodat snel inzichtelijk is welke boekingen gecorrigeerd zijn en hoe vaak dit voorkomt. Dit is te zien in transactie 2 en transactie 3 (beide transactietype ‘B’).

Transactie 8 is ook gekenmerkt als transactietype B, ondanks het feit dat de debiteurenrekening erin voorkomt. Dit komt omdat er per saldo geen mutatie heeft plaatsgevonden op deze rekening binnen deze transactie.

In tegenstelling tot de hersteltransacties wordt voor het bepalen van het transactietype geen rekening gehouden met de waardeveranderingen in de transactie: een factuur ter waarde van 100 euro wordt door hetzelfde (geautomatiseerde) proces in het grootboek geboekt als een factuur van  1.000 euro. Het is niet aan te raden om meer kenmerken, zoals factuurnummers of transactiedatum toe te voegen bij het bepalen van het transactietype. Deze kenmerken kunnen wel meegenomen worden in de specifieke analyses (bijvoorbeeld iedere goederenontvangst moet gekoppeld zijn aan een crediteur).

Uit ervaring blijkt dat transacties in grote ERP-systemen, die jaarlijks miljoenen boekingsregels produceren, op deze manier uiteindelijk teruggebracht kunnen worden naar een maximum van 2.000 verschillende transactietypen. Dit is logisch, aangezien ERP-systemen veel processen hebben gestandaardiseerd. Het inboeken van een factuur bestaat uit gemiddeld vier regels, maar kan dagelijks meerdere malen voorkomen. Toch kunnen de 2.000 verschillende soorten transactietype nog verder teruggebracht worden door grootboekrekeningen te standaardiseren en door te ontclusteren.

Standaardisatie

Heeft een organisatie bijvoorbeeld meerdere bankrekeningen, dan bestaat de kans dat iedere bankrekening zijn eigen grootboekrekening krijgt. Een betaaltransactie van bankrekening X zou dan een ander transactietype krijgen dan een betaling  van bankrekening Y. Vaak is het niet nodig om dit onderscheid in de analyses te maken. Het kan verstandig zijn om alle grootboekrekeningen die betrekking hebben op de verschillende bankrekeningen samen te voegen naar één algemene rekening. Het omzetten van grootboekrekeningen naar een algemene rekening wordt in dit artikel het standaardiseren van rekeningen genoemd.Het standaardiseren van grootboekrekeningen moet wel aansluiten op de analyses die benodigd zijn en mag niet leiden tot verlies van relevante informatie. Indien er een analyse gemaakt moet worden op een juiste btw-afhandeling is het niet logisch om de grootboekrekening die betrekking heeft op het hoge btw-tarief samen te voegen met de grootboekrekening die betrekking heeft op het lage btw-tarief.
Het grootste voordeel van het samenvoegen en standaardiseren van rekeningen is dat de auditor bij verschillende opdrachtgevers dezelfde transactietypen definieert. Het transactietype dat wordt gebruikt voor factuurbetalingen is na de standaardisatie bij ieder bedrijf gelijk. Is dit in de audit een belangrijk transactietype, dan kan dit type snel geïdentificeerd worden. Daarnaast kunnen er specifieke analyses gebouwd worden die van toepassing zijn bij alle organisaties die dit transactietype gebruiken. Al het werk en de kennis die bij eerdere audits zijn vergaard zijn onmiddellijk toepasbaar in latere onderzoeken, en daarnaast biedt het de mogelijkheid tot onderlinge vergelijking en benchmarking. Het aantal nieuwe transactietypen zal daarbij per nieuwe klant fors dalen.

Het standaardiseren van de grootboekrekeningen naar een algemene rekening is voor iedere audit een eenmalig proces dat met uiterste precisie moet worden uitgevoerd. Na de eerste audit moet iedere volgende keer bekeken worden of er nieuwe grootboekrekeningen zijn gemaakt die ingedeeld en gestandaardiseerd moeten worden. Daarnaast kan het voorkomen dat er een herindeling moet plaatsvinden. Een herindeling kan nodig zijn indien er gedurende het jaar besloten is om een analyse toe te voegen waarvoor een onderscheid gemaakt moet worden tussen internationale en nationale bankrekeningen, of tussen de valutasoorten van de bankrekeningen. Hoewel er eerst besloten was om al deze rekeningen onder één noemer te brengen, kan het nu handig zijn om deze opsplitsing alsnog toe te passen.

 

Het standaardiseren van de grootboekrekeningen naar een algemene rmoet met uiterste precisie worden uitgevoerd

 

Ontclusteren van transacties

Het komt voor dat een boekhoudpakket transacties in (dagelijkse) batches verwerkt. Hierdoor kan het zijn dat een batchboeking bestaat uit meer gelijke transacties, of zelfs meer verschillende soorten transacties van hetzelfde subgrootboek. Hierdoor kan het aantal gebruikte rekeningen binnen een transactie oplopen tot meer dan 100. Dit kan nog wel eens voor een uitdaging zorgen bij het bepalen van het juiste transactietype, waardoor er veel nieuwe en unieke transactietypen worden gecreëerd terwijl dit eigenlijk niet nodig is. De batchboeking zal in dit geval opgesplitst moeten worden in meerdere transacties, waarbij iedere transactie nog steeds moet voldoen aan de basisregel van het dubbel boekhouden (totaal credit = totaal debet). Het opsplitsen kan op meer manieren en is vaak afhankelijk van hoe de transactie door het systeem wordt gemaakt. Mogelijk kan dit op basis van de volgorde van de transactieregels waarbij iedere set regels waarbij debet en credit gelijk lopen, geclusterd worden (bijvoorbeeld de eerste drie geboekte regels van 25 en 10 euro debet en 35 euro credit horen bij elkaar). Een andere methode is door te analyseren welke transactietypen, die in eerdere onderzoeken al zijn geïdentificeerd, passen in de batchboeking om zo de batchboeking te ontclusteren. Transactie 10 in het voorbeeld is gekenmerkt als nieuwe transactie E, maar kan met ontclustering eigenlijk opgesplitst worden in twee bestaande transactietypen, B en A. Moderne ERP-applicaties registreren vaak een transactie tot op het laagste niveau in het grootboek, waardoor het probleem van ontclusteren dan beperkt is tot een kleine set transacties die vaak niet via het reguliere proces worden geboekt.

Nadat iedere rekening is gestandaardiseerd en iedere transactie een transactietype toebedeeld heeft gekregen kan ieder transactietype worden ingedeeld in een van de volgende categorieën:

  1. Transactietypen die onregelmatig voorkomen; dit zijn meestal handmatig ingevoerde transacties waarbij onderscheid gemaakt kan worden tussen transacties met hoge impact op de rekeningen die ze muteren (waarbij de impact boven een bepaalde materialiteit is) en transacties met een lage impact (komt weinig voor én is niet materieel). Het is aan te raden om de transacties met een hoge impact te selecteren voor nader (handmatig) onderzoek.
  2. Transactietypen die veelvuldig voorkomen; dit zijn transacties die met grote regelmaat worden gegenereerd en daardoor een hoge impact hebben op de rekeningen die ze muteren. Voor deze transactietypen kunnen analyses ontworpen worden die bepaalde patronen identificeren; valt de transactie binnen de norm of wijkt het teveel af van het patroon? Omdat deze transacties veelvuldig voorkomen, is de kans groot dat ze onderdeel zijn van een geautomatiseerd proces, waardoor ze bijvoorbeeld gebruikt  kunnen worden om te valideren of ieder relevant (geautomatiseerd) proces voldoende behandeld is door de audit, of om zelfs om de scope van de auditplanning te bepalen.

Bij een organisatie die miljoenen transacties per jaar produceert, is met standaardisatie en ontclustering het aantal transactietypen terug te brengen naar 1.000 – 1.500. Een significant deel van deze transactietypen komt in grote aantallen voor en is hierdoor geschikt voor patroonanalyses. Van transactietypen die niet vaak voorkomen heeft een groot deel weinig impact op de grootboekrekeningen en deze zijn daardoor niet materieel. Met dit nieuwe inzicht in het grootboek kunnen analyses gebouwd worden die mogelijke fouten en/of fraude kunnen identificeren.

Patroonherkenning

Zoals hierboven aangegeven zijn transactietypen die veelvuldig voorkomen geschikt om patroonanalyses op uit te voeren aangezien met deze typen een groot aantal transacties correspondeert. De patronen kunnen op meerdere manieren worden geanalyseerd, en zijn vaak afhankelijk van het transactietype. Zo zou voor ieder relevant transactietype een boxplot gemaakt kunnen worden, waarbij de uitschieters snel inzichtelijk worden gemaakt. In figuur 1 is bijvoorbeeld te zien dat transactietype B grote uitschieters heeft die afwijken van de norm. Hieruit is op te maken dat de waarde van de transactie in 75% van de gevallen onder de 60 is, terwijl de maximale waarde van dit type transactie tot drie keer zo hoog is. De transacties die deze uitschieters veroorzaken kunnen nader worden onderzocht door de auditor.

Een ander patroon zou vastgesteld kunnen worden bij analyse van  de onderlinge verhouding van de waarden; zo is er een vaste verhouding bij verkopen en de btw-behandeling, of kan de auditor nagaan of de gegeven kortingen in verhouding zijn met de verkopen. Wijkt een transactie af van dit patroon dan is deze het onderzoeken waard. Tenslotte kan het handig zijn om vast te stellen of ieder transactie van type A een bepaald kenmerk heeft, zoals een factuurnummer of een leveranciersnummer.

Bij het uitvoeren van patroonherkenning is het daarnaast verstandig om de herstelde en hersteltransacties niet mee te nemen in de analyse omdat deze het patroon kunnen verstoren.


 

Schermafbeelding 2014-06-11 om 15.13.56Een boxplot van de waarden van drie transactieypes


 

 

Verboden transactietypen

Een analyse die in SAS 99 werd benoemd, is het identificeren van rekeningen die niet gepaard mogen gaan met een transactie, zoals facturen aan de bank. Het is echter in de praktijk een lastige analyse om uit te voeren, en vaak wordt die analyse gedaan op een selectie van grootboekrekeningen. Men kan er bijvoorbeeld voor kiezen om een rekening te selecteren waarop het kasgeld wordt geboekt. Op basis van deze rekening wordt iedere transactie geselecteerd die hierop heeft gemuteerd. Daarna wordt er gekeken welke andere rekeningen in deze transacties voorkomen, waarna geconcludeerd kan worden of de (tegen)rekeningen wel/niet acceptabel zijn. Dit proces zou voor iedere interessante rekening herhaald moeten worden en kan veel tijd kosten.

Met behulp van transactietypen is deze analyse een stuk makkelijker uit te voeren. Nu bekend is welke rekeningen gepaard worden aan de hand van het transactietype, kan er per transactietype aangeven worden of deze wel/niet is toegestaan. Een voorbeeld kan zijn dat transactietype D uit tabel 1 transacties bevat die afwijken van de norm en daarom fout zijn. Een ander voorbeeld kan zijn dat een directe betaling van een betaalrekening naar een debiteurenrekening niet is toegestaan. Dit kan een business rule zijn die wordt gekoppeld aan het transactietype.

Relaties tussen transactietypen

Met het analyseren van losse transactietypen en het creëren van patroonanalyses kan de auditor in korte tijd al veel inzicht krijgen in het grootboek en in afwijkende transacties. Het wordt echter nog interessanter als de verschillende transactietypen aan elkaar gekoppeld kunnen worden om zo het volledige proces te reconstrueren. De procesgang van de transacties wordt op die wijze inzichtelijk gemaakt. De onderlinge relaties tussen transactietypen zijn het best inzichtelijk te maken met behulp van visualisering. De meest logische en makkelijke manier van relaties leggen tussen transactietypen is door gelijke debetrekeningen te koppelen met creditrekeningen van een ander transactietype (zie figuur 2). Het zou echter ook mogelijk zijn om relaties te leggen tussen boekingstypen die in eerste instantie niets met elkaar delen. Bijvoorbeeld: het boeken van een verkoop leidt automatisch tot een verkooptransactie maar tegelijkertijd ook tot een verplaatsing van goederen in de voorraad. Indien deze twee transacties gekoppeld zijn zou het dus mogelijk moeten zijn om voor iedere verkoop de goederenverplaatsing te achterhalen.


Schermafbeelding 2014-06-11 om 15.14.06Figuur 2: Relaties tussen transactietypes op basis van rekeningen


 

In figuur 2 is te zien dat transactietype A een relatie heeft met transactietype B en B leidt tot F en G. Door deze onderlinge relaties te leggen kan er snel geanalyseerd worden of ieder  ontvangen goed (A) is betaald (F). Of, misschien interessanter, is iedere betaling (F) binnen dit proces te relateren aan een goederenontvangst (A)? En hoe komt het dat type B een hogere waarde heeft? Is dit een timing-issue of komen facturen ook van een ander transactietype dan type A? Hoeveel dagen kost het om van transactietype A naar F te gaan? Daarnaast kunnen aanvullende analyses gemaakt worden op het gebied van functiescheiding: worden er bijvoorbeeld goederenontvangsten geboekt door dezelfde persoon die de betaling boekt. Met behulp van deze relaties kunnen processen in theorie worden gemodelleerd, het blijft echter een uitdaging om iedere transactie in het proces te volgen. De relatie tussen transactietype A en transactietype B is in dit voorbeeld het factuurnummer. Wil je weten of de factuur betaald is, dan moet het factuurnummer ook beschikbaar zijn in transactietype F. Of dit wordt geregistreerd in het grootboek is afhankelijk van het boekhoudpakket. Dit zou betekenen dat er een benadering moet worden gemaakt of dat er aanvullende bronnen gebruikt moeten worden om dit te realiseren.

 

Miljoenen transacties zijn terug te brengen naar een aantal dat voor de auditor beter inzichtelijk is

 

Conclusie

Door transacties in hun volle omvang te analyseren op basis van transactietypen, standaardisatie en ontclustering, kan de huidige analyseset van de auditor uitgebreid worden met nieuwe mogelijkheden. Miljoenen transacties zijn terug te brengen naar een aantal dat voor de auditor beter inzichtelijk is. Data wordt weer omgezet naar informatie en de niet-standaard boekingen die speciale aandacht van de auditor vereisen kunnen snel worden geïdentificeerd en geanalyseerd. Daarnaast kunnen de resultaten van de analyse gemakkelijk worden vergeleken met die van vergelijkbare andere organisaties of van voorgaande jaren. In dit artikel is een aantal mogelijkheden besproken, maar het houdt hier zeker niet op. Hoewel het een investering vereist om deze technieken toe te passen, biedt het zeker nieuwe kansen om efficiënter en effectiever naar grote hoeveelheden data te kijken om zo sneller de transacties te isoleren die voor een audit interessant zijn.


 

Handelstransacties beoordelen

Om hersteltransacties te herkennen moeten twee transacties gekoppeld worden waarbij de saldi van iedere grootboekrekening van deze transacties samen uitkomen op nul. In Tabel 1 is transactie 2 een herstelde transactie, en transactie 3 een hersteltransactie. Het is echter belangrijk dat de waarden elkaar ook op rekeningniveau opheffen: transacties 5 en 6 lijken elkaar op te heffen als er gekeken wordt naar de rekeningen en de totale waarde. Bij nadere inspectie blijkt echter dat er per saldo een waarde van 100 op rekening ‘BTW HOOG 21%’ is geboekt en een waarde van 100 op ‘Ontvangen goederen’. Omdat er per saldo wel een transactie heeft plaatsgevonden tussen twee rekeningen is hier dus geen sprake van een hersteltransactie. Doordat er veel gelijkenis is tussen deze twee transacties bestaat de mogelijkheid dat deze transacties niet juist zijn ingevoerd; hersteltransacties worden vaak niet via een gestandaardiseerd proces verwerkt, wat kan leiden tot fouten.

Zoals hierboven aangegeven zijn rekeningnummers en de waarden relevant, maar het is aan te raden om ook andere elementen mee te nemen zoals klantnummers/leveranciernummers, factuurnummers, boekingsdatum en dergelijke. Als laatste moet er nog rekening gehouden worden met het feit dat iedere transactie maximaal één hersteltransactie mag hebben. Kijkend naar ons voorbeeld zou transactie 7 een correctie kunnen zijn van transactie 2. Transactie 2 is echter eerder al gekoppeld aan transactie 3, waardoor transactie 7 geen hersteltransactie kan zijn van transactie 2.


 

Alper Söylemez