Full populasjonstesting med dataanalyse: Fra prøve til helhet

Gevinster:

• Forstå prøvetakingsrisiko og logikken i fullpopulasjonstesting (100 % testing) og kunne bruke kunstig intelligens til dataforberedelse, regelskriving og resultattolkning.
• Evne til å designe og implementere matching, fullstendighet og nøyaktighetstester i store datasett med støtte for kunstig intelligens
• Evne til å forstå at unntakslisten i hele populasjonstesten ikke er et resultat, men en begynnelse som revisor vil undersøke, og at den endelige evalueringen tilhører revisor.

En av de mest grunnleggende begrensningene ved revisjonsfaget var at revisor måtte jobbe med prøvetaking over mange år. Du kan ikke manuelt gjennomgå de 180 000 fakturaene en bedrift utsteder i løpet av et år; Så du velger noen hundre poster ved hjelp av en statistisk eller dømmende metode, tester dem og generaliserer resultatet til hele befolkningen. Prøvetaking er en kraftig og legitim teknikk, men den har en iboende risiko: prøvetakingsrisiko – utvalget du velger er kanskje ikke representativt for populasjonen, og den sanne feilen i den faller kanskje ikke akkurat der du ser.

Dataanalyse og AI endrer dette bildet: du kan nå teste hele populasjonen, dvs. 100 %. Dette kalles fullstendig populasjonstesting. Vi bruker denne enheten til å forstå overgangen fra «prøve til helhet», kraften den gir, og det nye ansvaret som mange mennesker overser. Fordi full populasjonstesting ikke letter inspeksjon; Det endrer testens karakter og legger nye belastninger på sensoren.

Forskjellen mellom prøvetaking og fullpopulasjonstesting

I klassisk sampling er logikken: "La meg teste en liten, men representativ gruppe grundig, og tolke resultatet som en helhet." I hele populasjonstesten er logikken snudd: «La meg skanne helheten etter visse regler, finne unntakene som faller utenfor regelen og undersøke dem grundig». I den første tilnærmingen er risikoen "å velge feil utvalg"; I den andre er risikoen "å skrive feil regel" og "arbeide med ufullstendige/feilaktige data".

Følgende tabell sammenligner de to tilnærmingene:

Størrelse

prøvetaking

Full populasjonstesting (100 %)

Omfang

en del av befolkningen

hele befolkningen

Hovedrisiko

Prøvetakingsrisiko (representasjonsfeil)

Regelfeil + dataintegritetsfeil

utgang

Begrenset antall testresultater

Liste over unntak som ikke er i samsvar med regelen

Revisors byrde

valg + test

Regeldesign + unntaksevaluering

Rollen til AI

Hjelp med prøvevalg

Dataforberedelse, regelskriving, unntaksmerking

Merk: full populasjonstesting betyr ikke "jeg testet alt, jobb utført". Tvert imot gir det deg vanligvis flere ting å undersøke. Når du kjører alle 180 000 fakturaene gjennom en regel for godkjenning av datobeløp, finner du kanskje 900 unntak. Hver av disse er et spørsmål; ikke et svar. Det er her revisjonsrettsvesenet spiller inn.

Datafullstendighet: det usynlige grunnlaget for testing

Den største fallgruven ved testing av hele befolkningen er at kvaliteten på testen avhenger av kvaliteten på dataene. "Jeg testet 100 % av dataene" gir bare mening hvis dataene du har faktisk er 100 % av befolkningen. Hvis et filter var feil da data ble hentet fra systemet, noen poster ble utelatt, eller beløpskolonnen ble overført med en desimalfeil, vil din "fullstendige" test faktisk bli utført på ufullstendige eller korrupte data. Derfor er bekreftelse av datafullstendighet og nøyaktighet det første og uunnværlige trinnet i full populasjonstesting.

Praktiske kontroller for fullstendighetsverifisering:

• Avstemming av postantall: Tilsvarer antall rader i datasettet du hentet det totale antallet poster i systemet?
• Beløpsavstemming: Stemmer totalbeløpet i datasettet med den aktuelle kontosummen i prøvebalansen/datterselskapet?
• Datoperiode: Er de første og siste dagene i perioden inkludert i dataene; Mangler det en måned/dag?
• Tom og dårlig plassskanning: Er det mellomrom eller meningsløse verdier i obligatoriske felt (dato, beløp, kontokode)?

AI hjelper med alle disse kontrollene: gjennomsøker data, får totaler, teller tomme mellomrom, rapporterer datoperiode. Men det er revisor som avgjør om avtalen «holder», undersøker forskjellen, og bekrefter at dataene er egnet for revisjonsformålet.

Forsiktig: Ikke skriv "Jeg testet alle dataene" på regnearket uten å bekrefte at dataene er fullstendige. En fullstendig populasjonstest på manglende data gir tilsynelatende fullstendig, men misvisende sikkerhet.

Full populasjonstesting med AI: trinn for trinn

1. Klargjør data sikkert. Anonymiser personlige/private felt eller erstatt dem med plassholdere. Hvis det er mulig, bruk en bedriftsbil.
2. Bekreft fullstendighet. Avstem antall poster og beløp.
3. Definer testregelen tydelig. Hva regnes som et "unntak"? (For eksempel: ikke-godkjent faktura, faktura utstedt i helgen, stor rundbetaling, inntekt registrert etter skjæringsdatoen.)
4. Bruk regelen med AI. AI bruker regelen på dataene og produserer en liste over unntak; Skriv regelen tydelig slik at den kan revideres.
5. Prioriter og gjennomgå unntak. Undersøk hvert unntak med bevis; adressere falske positive, begrunne faktiske funn.
6. Dokumenter resultatet. Koble regelen, antall unntak, undersøkte elementer og konklusjon til regnearket.

tre minisaker

Tilfelle 1 - Skjæretest. En revisor ønsket å teste inntektsgrensen ved årsskiftet. Han tok 42 000 salgsfakturaer som hele populasjonen og fikk AI til å håndheve "listepostene med fakturadatoer innen 31. desember, men leverings-/leveringsdatoer på eller etter 1. januar". YZ merket 118 poster. Revisor undersøkte disse: 96 var legitime transaksjoner uten tidsforskjeller (levering samme dag), 22 var faktisk inntekt for det påfølgende året og ble registrert i forrige periode. Disse 22 elementene ble rapportert fordi de viste et mønster, om enn under signifikans. AI stilte 118 spørsmål; Revisor fant 22 svar.

Tilfelle 2 — Når fullstendighet er utelatt. Et teammedlem sa at han utførte full populasjonstesting på 180 000 fakturaer; Det var ingen unntak og han var lettet. Den ansvarlige sammenlignet den totale mengden av datasettet med prøvebalansen: data 155 millioner TL, prøvebalanse 210 millioner TL. Det viser seg at mens data ble trukket fra systemet, ble en gren filtrert og utelatt. Den "fulle" testen gikk faktisk glipp av en fjerdedel av dataene. Testen ble overkjørt med riktige data. Leksjon: det er ingen fullstendig populasjonstesting uten fullstendighetsbekreftelse.

Tilfelle 3 – Regelfeil. En revisor fikk AI til å skrive regelen "List opp ikke-godkjente betalinger over 50 000 TL", men skjønte ikke at feltet "godkjenning" ble holdt i to forskjellige kolonner i systemet (elektronisk godkjenning og manuell godkjenning). AI-en markerte 300 betalinger som "ikke godkjent" fordi den bare så på én; Ved undersøkelse så man at de fleste ble godkjent i den andre kolonnen. Feil regel ga hundrevis av falske positiver. Revisor korrigerte regelen til å inkludere begge kolonnene. Leksjon: Revisor verifiserer at regelen er i samsvar med dataene og forretningsprosessen.

Svak forespørsel / Sterk forespørsel

Svak melding:

Finn problematiske poster i disse fakturadataene.

Problem: Ingen definisjon av "problematisk." AI vet ikke hva jeg skal anse som et unntak; Han jobber enten etter tilfeldige signaler eller etter et kriterium han har laget. Det er ikke repeterbart og reviderbart.

Kraftig ledetekst:

Din rolle: du er en dataanalyseassistent for en uavhengig revisor. Dommen er min; Du vil bruke regelen og generere en unntaksliste.Kontekst: Nedenfor er anonymiserte salgsfakturadata (kolonnene: fakturanr, fakturadato, leveringsdato, beløp, godkjenningsstatus, filial). Årsavslutning: 31.12.TRINN 1 - Fullstendighet: Oppgi totalt antall poster og totalbeløp slik at jeg kan sammenligne det med prøvesaldoen. Rapporter om det er noe tomt/manglende mellomrom.TRINN 2 - Cutting test rule: List postene med invoice_date <= 31.12 OG leveringsdato >= 01.01 som "cutoff exception".TRINN 3 - Skriv regelen i ren tekst (hvilken betingelse brukte du) slik at den kan revideres.Regler: Jeg ga den regelen, ikke endre regelen. Send inn postene du flagger som "unntak for gjennomgang"; Ikke si "feil/finning". Ikke gjør opp det du ikke kan utlede fra dataene.

Denne forespørselen er kraftig fordi den først bekrefter fullstendighet, tydelig definerer unntaksregelen, krever klarteksten til regelen (auditabilitet), og posisjonerer utdata som "unntak".

Vanlige feil

• Hopp over fullstendighetsverifisering. Utføre "fullstendig" testing på ufullstendige/korrupte data og gi falsk forsikring.
• Forveksler unntaket med et funn. Telle feil uten å verifisere posten merket av AI; unngå å eliminere falske positiver.
• Sjekker ikke regelen. Generer hundrevis av falske flagg uten å sjekke om regelen samsvarer med dataene og forretningsprosessen.
• Skrive vage regler. Få resultater som ikke kan gjentas med udefinerte spørsmål som "finn problematiske poster".
• Være fornøyd med en enkelt start. Ikke spørre regelen eller dataene hvis antallet unntak er svært forskjellig fra det som er forventet.

Tips: Bli skremt hvis antallet unntak er for lite (nær null) eller for stort. Null betyr vanligvis "regel skrevet feil" eller "data mangler"; Et ekstremt stort antall indikerer at regelen er for vid. En god revisor mistenker både "ingen unntak" og "alt er unntak".

Oppsummert

Full populasjonstesting er et stort sprang fremover innen revisjon: det eliminerer prøvetakingsrisiko, og screener 100 % av dataene. Men det er ikke gratis. Det medfører to nye ansvarsområder: (1) verifisere datafullstendighet og nøyaktighet, (2) evaluere individuelle unntak som oppstår. AI forbereder dataene, bruker regelen, flagger unntaket og reduserer timer med skanning til sekunder; Men nøyaktigheten av regelen, fullstendigheten av dataene og evalueringen av unntak tilhører revisor. Unntak er ikke et resultat, det er en begynnelse.

Søknadsoppgave

Vurder et eksisterende (eller hypotetisk) transaksjonsdatasett. Definer først to fullstendighetskontroller (antall poster og beløpsavstemming). Skriv deretter en klar unntaksregel for et revisjonsformål (f.eks. fakturaer utstedt i helgen, eller kutte unntak). Med det kraftige ledetekstmønsteret ovenfor, la AI utføre fullstendigheten først og deretter regelen. De første 10 av unntakene som vises er "reelle funn eller falske positive?" Øv deg på å klassifisere som følger og skriv ned hvilke bevis du vil se etter for hver.

sjekkliste

• [ ] Jeg anonymiserte dataene og kjørte trygt.
• [ ] Jeg bekreftet fullstendigheten av data ved å avstemme antall poster og beløp.
• [ ] Jeg skannet etter ledig/dårlig plass.
• [ ] Jeg definerte unntaksregelen på en klar, repeterbar måte.
• [ ] Jeg mottok klarteksten til regelen fra AI og bekreftet at den samsvarer med dataene og forretningsprosessen.
• [ ] Jeg stilte spørsmål ved rimeligheten av antall unntak (for få / ikke for mange).
• [ ] Jeg behandlet hvert unntak som et spørsmål som skulle undersøkes, ikke et funn; Jeg eliminerte falske positiver.