Печалби:
- Разберете риска от вземане на проби и логиката на пълното тестване на популацията (100% тестване) и можете да използвате изкуствен интелект за подготовка на данни, писане на правила и тълкуване на резултатите.
- Възможност за проектиране и прилагане на тестове за съвпадение, пълнота и точност в големи набори от данни с поддръжка на изкуствен интелект
- Способност да се разбере, че списъкът с изключения в теста за пълна популация не е резултат, а начало, което одиторът ще провери, и че крайната оценка принадлежи на одитора.
Едно от най-фундаменталните ограничения на одиторската професия беше, че одиторът трябваше да работи с извадки в продължение на много години. Не можете ръчно да прегледате 180 000 фактури, които бизнес издава за една година; Така че вие избирате няколкостотин записа с помощта на статистически или оценъчен метод, тествате ги и обобщавате резултата за цялата съвкупност. Вземането на проби е мощна и легитимна техника, но носи присъщ риск: риск от вземане на проби — избраната от вас извадка може да не е представителна за популацията и истинската грешка в нея може да не попада точно там, където търсите.
Анализът на данни и AI променят тази картина: вече можете да тествате цялата популация, т.е. 100%. Това се нарича пълно изследване на населението. Ние посвещаваме тази част на разбирането на прехода от „проба към цяло“, силата, която носи, и новите отговорности, които много хора пренебрегват. Тъй като пълното тестване на населението не улеснява проверката; Променя естеството на теста и поставя нови тежести върху изпитващия.
Разлика между вземане на проби и пълно изследване на популацията
При класическото вземане на проби логиката е: „Позволете ми да тествам задълбочено малка, но представителна група и да интерпретирам резултата като цяло.“ При теста за пълна популация логиката е обратна: „Нека сканирам цялото според определени правила, да намеря изключенията, които попадат извън правилото, и да ги разгледам обстойно“. При първия подход рискът е „избор на грешна проба“; Във втория рискът е „написване на грешно правило“ и „работа с непълни/грешни данни“.
Следната таблица сравнява двата подхода:
Размер
вземане на проби
Пълно тестване на населението (100%)
Обхват
част от населението
цялото население
Основен риск
Риск при вземане на проби (грешка при представяне)
Грешка в правилото + грешка в целостта на данните
изход
Ограничен брой резултати от тестове
Списък с изключения, които не отговарят на правилото
Тежестта на одитора
избор + тест
Дизайн на правило + оценка на изключение
Роля на AI
Помощ при избора на мостра
Подготовка на данни, писане на правила, маркиране на изключения
Забележка: пълното тестване на населението не означава „тествах всичко, работата е свършена“. Напротив, обикновено ви дава повече елементи за изследване. Когато пуснете всичките 180 000 фактури през правило за одобрение на дата-сума, ще откриете може би 900 изключения. Всеки от тях е въпрос; не е отговор. Тук влиза в действие одитната юрисдикция.
Пълнота на данните: невидимата основа на тестването
Най-големият капан на тестването на цялата популация е, че качеството на теста зависи от качеството на данните. „Тествах 100% от данните“ има смисъл само ако данните, които имате, всъщност са 100% от населението. Ако филтърът е бил неправилен при изтегляне на данни от системата, някои записи са били пропуснати или колоната със сумата е била прехвърлена с десетична грешка, вашият „пълен“ тест всъщност ще бъде извършен върху непълни или повредени данни. Следователно потвърждаването на пълнотата и точността на данните е първата и задължителна стъпка в пълното тестване на популацията.
Практически проверки за проверка на пълнотата:
- Съгласуване на броя на записите: Съвпада ли броят на редовете в набора от данни, който сте изтеглили, на общия брой записи в системата?
- Съгласуване на сумата: Съгласува ли се общата сума в набора от данни със съответната обща сметка в пробния баланс/дъщерно дружество?
- Период от време: Първият и последният ден от периода са включени в данните; Има ли липсващ месец/ден?
- Сканиране на празно и лошо пространство: Има ли интервали или безсмислени стойности в задължителните полета (дата, сума, код на сметка)?
AI помага при всички тези проверки: обхожда данни, получава общи суми, брои празни пространства, отчита период от време. Но одиторът е този, който решава дали споразумението „издържа“, проучва разликата и потвърждава, че данните са подходящи за целта на одита.
Внимание: Не пишете „тествах всички данни“ на работния лист, без да проверите пълнотата на данните. Пълният тест на популацията върху липсващи данни дава привидно пълна, но подвеждаща увереност.
Пълно тестване на населението с AI: стъпка по стъпка
- Подгответе данните сигурно. Анонимизирайте лични/лични полета или ги заменете с контейнери. Ако е възможно, използвайте корпоративно превозно средство с договор.
- Потвърдете пълнотата. Съгласувайте броя на записите и сумата.
- Ясно дефинирайте тестовото правило. Какво се счита за "изключение"? (Например: неодобрена фактура, фактура, издадена през уикенда, голямо кръгло плащане, приход, записан след крайната дата.)
- Приложете правилото с AI. AI прилага правилото към данните и създава списък с изключения; Напишете правилото ясно, за да може да бъде проверено.
- Приоритизирайте и прегледайте изключенията. Разследвайте всяко изключение с доказателства; адресирайте фалшиви положителни резултати, обосновете действителните констатации.
- Документирайте резултата. Свържете правилото, броя на изключенията, проверените елементи и заключението към работния лист.
три мини калъфа
Случай 1 — Тест за рязане. Одитор искаше да тества ограничението на приходите в края на годината. Той взе 42 000 фактури за продажби като пълна съвкупност и накара AI да наложи „списъчни записи с дати на фактури до 31 декември, но дати за доставка/доставка на или след 1 януари“. YZ отбеляза 118 записа. Одиторът ги провери: 96 бяха легитимни транзакции без разлики във времето (доставка в същия ден), 22 бяха действителни приходи за следващата година и бяха записани през предходния период. Тези 22 елемента бяха докладвани, защото показаха модел, макар и под значимостта. AI зададе 118 въпроса; Одиторът намери 22 отговора.
Случай 2 — Когато пълнотата е пропусната. Един член на екипа каза, че е направил пълно тестване на населението на 180 000 фактури; Нямаше изключения и той беше облекчен. Отговорното лице сравни общата сума на набора от данни с пробния баланс: данни 155 милиона TL, пробен баланс 210 милиона TL. Оказва се, че докато данните са били изтеглени от системата, един клон е бил филтриран и оставен. „Пълният“ тест всъщност пропусна една четвърт от данните. Тестът беше преминат с правилните данни. Поука: няма пълно тестване на популацията без потвърждение за пълнота.
Случай 3 — Грешка в правилата. Един одитор накара AI да напише правилото „Списък на неодобрени плащания над 50 000 TL“, но не разбра, че полето „одобрение“ се съхранява в две различни колони в системата (електронно одобрение и ръчно одобрение). AI маркира 300 плащания като „неодобрени“, защото погледна само едно; При прегледа се видя, че повечето от тях са одобрени в другата графа. Грешното правило доведе до стотици фалшиви положителни резултати. Одиторът коригира правилото, за да включи и двете колони. Урок: одиторът проверява дали правилото съответства на данните и бизнес процеса.
Слаба подкана / Силна подкана
Слаба подкана:
Намерете проблемни записи в тези данни за фактура.
Проблем: Няма определение за „проблемно“. AI не знае какво да счита за изключение; Той работи или по случайни сигнали, или по критерий, който е измислил. Не подлежи на повторение и одитиране.
Мощна подкана:
Вашата роля: вие сте асистент за анализ на данни на независим одитор. Преценката е моя; Ще приложите правилото и ще генерирате списък с изключения. Контекст: По-долу са анонимизирани данни за фактури за продажби (колони: invoice_no, invoice_date, delivery_date, сума, approval_status, клон). Край на годината: 31.12. СТЪПКА 1 - Пълнота: Дайте общия брой записи и общата сума, за да мога да я сравня с пробния баланс. Докладвайте, ако има някакво празно/липсващо място. СТЪПКА 2 - Правило за тест за изрязване: Избройте записите с invoice_date <= 31.12 И дата_на_доставка >= 01.01 като "изключение за прекъсване". СТЪПКА 3 - Напишете правилото в обикновен текст (какво условие сте приложили), така че да може да бъде одитирано. Правила: Дадох правилото, не го променяйте. Изпратете записите, които сте маркирали като „изключения за преглед“; Не казвайте "грешка/намиране". Не измисляйте това, което не можете да заключите от данните.
Тази заявка е мощна, защото първо потвърждава пълнотата, ясно дефинира правилото за изключение, изисква обикновен текст на правилото (проверяемост) и позиционира изхода като „изключение“.
Често срещани грешки
- Пропускане на проверката за пълнота. Извършване на „пълно“ тестване на непълни/повредени данни и даване на фалшива увереност.
- Объркайте изключението с констатация. Грешки при преброяване без проверка на записа, маркиран от AI; избягване на елиминиране на фалшиви положителни резултати.
- Без проверка на правилото. Генериране на стотици фалшиви флагове без проверка дали правилото е в съответствие с данните и бизнес процеса.
- Писане на неясни правила. Получаване на неповторими резултати с недефинирани подкани като „намерете проблемни записи“.
- Задоволяване с едно начало. Без запитване към правилото или данните, ако броят на изключенията е много различен от очаквания.
Съвет: Бъдете разтревожени, ако броят на изключенията е твърде малък (близо до нула) или твърде голям. Нула обикновено означава "правило, написано неправилно" или "липсващи данни"; Изключително голям брой показва, че правилото е твърде широко. Добрият одитор подозира както „няма изключения“, така и „всичко е изключение“.
В обобщение
Пълното тестване на популацията е огромен скок напред в одита: то елиминира риска от вземане на проби, скринирайки 100% от данните. Но не е безплатно. Той носи две нови отговорности: (1) проверка на пълнотата и точността на данните, (2) оценка на отделни изключения, които възникват. AI подготвя данните, прилага правилото, маркира изключението и намалява часовете на сканиране до секунди; Но точността на правилото, пълнотата на данните и оценката на изключенията принадлежат на одитора. Изключението не е резултат, то е начало.
Задача за приложение
Помислете за съществуващ (или хипотетичен) набор от данни за транзакции. Първо дефинирайте две проверки за пълнота (брой записи и съгласуване на суми). След това напишете ясно правило за изключение с цел одит (напр. фактури, издадени през уикенда, или намаляване на изключения). С мощния модел на подкана по-горе, накарайте AI да изпълни първо пълнотата и след това правилото. Първите 10 от изключенията, които се появяват, са "реални констатации или фалшиви положителни резултати?" Упражнявайте се да класифицирате както следва и запишете какви доказателства ще търсите за всяко.
контролен списък
- [ ] Анонимизирах данните и шофирах безопасно.
- [ ] Потвърдих пълнотата на данните чрез съгласуване на броя на записите и сумата.
- [ ] Сканирах за свободно/лошо място.
- [ ] Определих правилото за изключение по ясен, повторяем начин.
- [ ] Получих обикновения текст на правилото от AI и проверих съответствието му с данните и бизнес процеса.
- [ ] Поставих под въпрос разумността на броя на изключенията (твърде малко / не твърде много).
- [ ] Отнасях се към всяко изключение като към въпрос за изследване, а не като констатация; Елиминирах фалшивите положителни резултати.