AI против мошенничества в отчётности: как ChatGPT и Claude находят аномалии, которые пропустили аудиторы

Мошенничество в отчётности обнаруживают в среднем через 12 месяцев после начала схемы, и за это время компания успевает потерять заметно больше, чем стоила сама проверка. По данным международного исследования профессиональных случаев мошенничества ACFE «Report to the Nations» за 2024 год, типичная организация теряет около 5% годовой выручки, медианный убыток по одному делу составляет 145 000 долларов, а самый дорогой вид схем, подделка финансовой отчётности, длится в среднем 24 месяца до обнаружения. Классический аудит эти схемы часто не ловит: выборочная проверка по определению смотрит на малую часть операций, а схемы строятся так, чтобы не выделяться в выборке.

Я Натали Васильева, эксперт по нейросетям и продюсер онлайн-школы «Финансовый директор | Мастер CFO» (основатель школы это Софья Бурцева, 45 000 подписчиков в @findir_pro, 13 000 в «АИ с Софьей и Натали», 5 000+ в MAX, 800+ выпускников курса AI-навыков). Тема поиска аномалий в финансовых данных регулярно всплывает на консультациях: у большинства компаний выгрузка за месяц это тысячи операций, которые никто не смотрит построчно, а внутренний аудит проверяет выборку по крупным суммам.

В этой статье я показываю, как ChatGPT и Claude находят аномалии, которые пропустили аудиторы: закон Бенфорда, фильтры подозрительных операций, работа с дублями и круглыми суммами. Внутри одиннадцать готовых промптов, четыре кейса из практики учениц школы и сравнительная таблица моделей. Актуально на август 2026 года, актуальные модели это GPT-5.5, Claude Sonnet 4.6, Gemini 2.5, DeepSeek V3.2. Сайт chatgpt.com в России открывается через специальные средства доступа, упоминаю это один раз и дальше к теме не возвращаюсь.

Если вы уже пробовали использовать нейросеть для проверок, у меня есть отдельная статья про внутренний аудит через ChatGPT с автоматизацией аналитических процедур и чек-листов. Здесь же речь про точечный поиск аномалий и статистических признаков схем, которые не видны при выборочной проверке.

Что такое аномалии в отчётности и почему аудитор их пропускает

Аномалия в отчётности это операция или группа операций, которые статистически и логически выбиваются из общего массива данных: необычная сумма, странная дата, подозрительная частота, отклонение от естественного распределения чисел. Сама по себе аномалия не означает мошенничество, но она указывает на место, куда стоит посмотреть внимательнее.

Классический аудит устроен как выборочная проверка. Из тысяч операций аудитор берёт выборку, чаще всего по крупным суммам или случайным образом, и проверяет её досконально. Этого требует стандарт и ограниченный бюджет часов. Схемы мошенничества строятся так, чтобы не попасть в выборку: суммы разбивают на части, каждая из которых ниже порога контроля, платежи проводят круглыми суммами, которые при беглом взгляде не вызывают вопросов, или вставляют операции в «нормальные» даты.

По данным того же исследования 2024 года, схемы с подделкой отчётности в среднем длятся дольше всех: около двух лет. За это время искажение накапливается в данных, и именно накопленный след статистика видит лучше человека: распределение чисел, дубли, кластеры по датам, платежи под порогом. Человек при выборочной проверке смотрит на отдельные операции, а статистика видит картину целиком.

Ещё пара цифр из того же исследования, чтобы оценить масштаб. Чаще всего схему находили не по документам и проверкам, а по наводке или жалобе: на такие сигналы приходится около 43% выявленных случаев. Формальные процедуры — внутренний и внешний аудит, проверка документов, ревизии — в сумме находят меньшинство схем, а на случайное обнаружение приходится около 5%. Чем позже схема обнаружена, тем дороже обходится: за 24 месяца подделки отчётности накопленный ущерб легко перекрывает годовой бюджет на усиление контроля.

Почему аудитор не замечает аномалию? Три причины. Первая: он смотрит на выборку, а не на весь массив. Вторая: он проверяет операции на соответствие документам, а не на статистическую необычность. Третья: у него ограниченный бюджет часов, и глубокий анализ каждой тысячи операций физически невозможен. AI-проверка закрывает именно эти три дыры.

На практике разница выглядит так. Аудитор открывает реестр платежей за квартал, отсортировывает крупные суммы и проверяет по ним первичку: счета, акты, договоры. Транзакцию на 95 000 рублей при пороге контроля в 100 000 он даже не посмотрит: сумма обычная, документы в порядке, в выборку она не попала. А таких транзакций одному контрагенту может быть тридцать за месяц, и вместе они складываются в миллионы. Отдельно каждая операция невинна, вместе это схема. Статистический анализ видит этот кластер целиком, потому что смотрит на все строки разом, а не на выборку.

Что такое закон Бенфорда и почему он работает как детектор

Закон Бенфорда это статистическая закономерность о том, как часто разные цифры встречаются в начале чисел в естественных наборах данных. В суммах платежей, накладных, остатках по счетам цифра 1 стоит первой примерно в 30,1% случаев, цифра 2 примерно в 17,6%, цифра 3 в 12,5%, а цифра 9 всего в 4,6%. Люди, когда выдумывают числа, распределяют первые цифры почти равномерно: примерно по 11% на каждую. Поэтому сильное отклонение реальных данных от закона Бенфорда это маркер того, что числа могли быть сфабрикованы или подогнаны.

Почему это работает именно на финансовых данных? Потому что суммы операций образуются естественным образом: из цен, количеств, тарифов, курсов. Никто специально не подгоняет распределение первых цифр, и оно подчиняется закону. А когда человек вручную вводит выдуманные суммы, он интуитивно выбирает «красивые» числа: те, что начинаются на 5, 7, 9, и распределяет их примерно равномерно. Это отклонение от закона и выдаёт подгонку.

Простой пример. В выгрузке 1 200 платежей за квартал. По закону Бенфорда первые цифры должны распределиться так: около 361 платежа на цифру 1 (30,1%), около 211 на цифру 2 (17,6%), около 150 на цифру 3 (12,5%) и примерно 55 платежей на цифру 9 (4,6%). Если в реальной выгрузке на девятку приходится 180 платежей, то есть в три с лишним раза больше ожидаемого, в данных явно что-то не так: либо подгонка сумм, либо систематическая ошибка ввода, либо осознанная схема. Один такой срез не даёт ответа, кто и зачем это сделал, но он точно указывает, в какой категории данных стоит копать.

Закон работает не на любых данных, и это важно понимать, чтобы не получить ложную тревогу. Он применим к естественным наборам чисел, которые не ограничены искусственными рамками: суммы платежей, остатки, количества. Он не работает на назначаемых номерах вроде номеров счетов или договоров, на ценах с круглыми тарифами и на данных с жёсткими лимитами, где пороги сами по себе искажают распределение.

Аудиторы используют закон Бенфорда десятилетиями, но вручную это медленная работа. GPT-5.5 через код-интерпретатор считает распределение первых цифр по выгрузке за минуты и сразу показывает, по каким категориям данных распределение ломается. Это превращает статистический приём из редкой экспертной процедуры в рутинный фильтр, который можно запускать каждый месяц.

Чтобы не получить ложные срабатывания, полезно заранее знать, какие данные подходят для проверки по Бенфорду, а какие нет.

Эта таблица пригодится и при настройке промптов: в инструкции модели стоит явно указать, какие поля проверяем по Бенфорду, а какие исключаем. Иначе модель может включить в расчёт номера документов, и отклонение окажется ложным.

Важный нюанс про пороги: если в компании есть жёсткие правила, например «платежи от 300 000 рублей только по решению правления», то суммы будут скапливаться на границе диапазона. Это не подгонка, а следствие регламента. Такой срез либо исключают из теста Бенфорда, либо интерпретируют отдельно, с учётом порогов. Иначе ложные срабатывания неизбежны.

Какие пять статистических признаков схем ищет нейросеть

Нейросеть не «читает мысли» мошенника. Она применяет набор формальных проверок, каждая из которых оставляет статистический след, и сводит результаты в единый список. Вот пять признаков, которые ищет модель.

Отклонение от закона Бенфорда. Распределение первых цифр по суммам отличается от естественного. Это первый и самый общий фильтр: он показывает, в каких категориях данных вообще стоит копать.

Дубли платежей. Операции с одинаковой суммой, контрагентом и датой, которые прошли дважды. Ошибка двойной оплаты встречается часто, а умышленный дубль это классическая схема вывода денег через повторную оплату одного счёта.

Круглые суммы без копеек. Реальные платежи редко бывают ровно 100 000, 50 000 или 17 000 рублей без копеек. Высокая доля круглых сумм в определённой категории это признак ручного ввода, подгонки или схемы.

Платежи точно под порогом контроля. Если в компании контроль второй подписи срабатывает от 100 000 рублей, а в данных плотный кластер платежей по 99 500-99 900 рублей, это классический признак разбиения сумм для обхода контроля. Тот же след виден в данных о закупках и расходах.

Аномальные кластеры по датам и частоте. Серия операций по одному контрагенту в узком окне дат, платежи в выходные дни, операции с нетипичной для категории частотой. Такие кластеры человек при выборочной проверке не видит, а статистика ловит мгновенно.

Каждый из этих признаков по отдельности может быть случайностью. Поэтому в финальном реестре рисков находки пересекаются: сочетание двух и более признаков у одной операции или контрагента получает более высокий приоритет, чем одиночное отклонение.

Например, отдельно взятая круглая сумма в 100 000 рублей может быть обычным платежом за аренду. Но если эта же сумма повторяется у одного контрагента шесть раз подряд, каждый раз ровно под порогом контроля и с оплатой в выходной день, это уже четыре признака в одной точке. Именно такие сочетания и есть настоящие зоны риска.

Отдельная тема: где искать признаки, если данных в одном месте не хватает. Начинать стоит с самых «чистых» источников: выписки по расчётному счёту, реестры платежей, оборотно-сальдовые ведомости. Они полные, структурированные и редко содержат ручные правки. Хуже подходят для первичного прогона ручные таблицы с подтяжками формул и агрегированные отчёты, где видна только итоговая картина, а не отдельные операции. Чем ближе данные к первичному источнику, тем надёжнее статистические выводы.

Если в компании есть несколько учётных систем, у каждого источника своя роль. Допустим, платежи идут через банк, а накладные регистрируются в ERP: сравнение двух независимых потоков по суммам и контрагентам само по себе даёт третий фильтр. Расхождение между выпиской банка и реестром накладных по одному контрагенту это сильный сигнал, который не увидит ни одна выборочная проверка. Поэтому полезно смотреть не только внутри одного массива, но и между массивами.

Какие промпты нужны: от Бенфорда до реестра рисков и отчёта руководству

Первый практический шаг: прогнать выгрузку через тест Бенфорда. Промпты ниже рассчитаны на GPT-5.5 с код-интерпретатором, потому что распределение должно считаться кодом, а не приблизительно.

Промпт для проверки данных по закону Бенфорда

Ты аналитик финансовых данных. Я загружаю выгрузку операций
в табличном виде (CSV/Excel).

Столбцы: дата, сумма, категория, внутренний идентификатор,
контрагент (обезличен).

Задача: проверь суммы операций на соответствие закону Бенфорда.
1. Посчитай через код распределение первых цифр всех сумм.
2. Сравни с ожидаемыми значениями: 1 = 30,1%, 2 = 17,6%,
   3 = 12,5%, 4 = 9,7%, 5 = 7,9%, 6 = 6,7%, 7 = 5,8%,
   8 = 5,1%, 9 = 4,6%.
3. Найди категории, где отклонение от ожидаемого больше
   5 процентных пунктов.
4. Построй таблицу: категория, фактический процент, ожидаемый
   процент, отклонение, вывод (в норме / требует проверки).
5. В конце дай краткую сводку: какие категории выбиваются и
   сколько операций в них попадает.

Важно: считай точно через код, не оценивай на глаз.

Такой промпт с код-интерпретатором даёт таблицу отклонений по категориям за один запуск. Это стартовая карта: по ней видно, какие срезы данных стоит разбирать дальше, а какие в норме.

Промпт для поиска дублей и двойных платежей

Дубли платежей это самый простой для автоматизации признак. Модель через код перебирает все строки и находит пары с одинаковой суммой, датой и идентификатором контрагента.

Ты проверяешь выгрузку платежей на дубли и двойные оплаты.

Данные: CSV/Excel со столбцами дата, сумма, контрагент
(обезличен), номер документа (если есть), назначение платежа.

Задача:
1. Найди операции, где совпадают сумма, дата и контрагент.
   Это потенциальные дубли.
2. Найди операции с одинаковой суммой и одинаковым номером
   документа, но разными датами.
3. Для каждой пары укажи: даты, суммы, номер документа,
   разницу в днях.
4. Посчитай общую сумму потенциальных двойных оплат.
5. Выведи результат таблицей и отдельной строкой итог по сумме.

Не считай дублями обычные регулярные платежи по договору
(например, аренда ежемесячно одинаковой суммой). Если не
уверен, отметь строку как "требует ручной проверки".

Один нюанс: регулярные платежи по договору одинаковой суммой это не дубль. Поэтому в промпт добавлена оговорка, и спорные строки уходят в ручную проверку, а не в обвинение.

Промпт для поиска круглых сумм и платежей под порогом контроля

Круглые суммы и платежи под порогом это два признака, которые удобно проверять одним прогоном. Порог контроля подставляете свой: сумму, с которой в компании нужна вторая подпись или дополнительное согласование.

Ты анализируешь выгрузку платежей на два типа аномалий.

Данные: дата, сумма, контрагент (обезличен), категория.

1. Круглые суммы. Найди операции, где сумма кратна 1 000 рублей
   без копеек (100 000, 250 000, 17 000 и т.п.). Сгруппируй
   по категориям и посчитай долю круглых сумм в каждой
   категории. Если доля больше 40%, это аномалия.

2. Платежи под порогом контроля. Порог компании:
   [вставить сумму, например 100 000 руб]. Найди операции
   в диапазоне от 90% порога до самого порога
   (например 90 000-99 999 руб). Сгруппируй по контрагентам.
   Если один контрагент платит многократно чуть ниже порога,
   отметь как признак разбиения сумм.

Выведи два отдельных списка с итоговыми суммами по каждому типу.

Признак «многократные платежи чуть ниже порога» это один из самых показательных в корпоративном мошенничестве. Человек при ручной проверке видит отдельные платежи и не связывает их между собой, а статистика видит кластер мгновенно.

Второй набор промптов работает с хронологией операций и превращает разрозненные находки в рабочий документ для финансового директора.

Промпт для поиска аномальных кластеров по датам и частоте

Хронология операций это отдельный источник сигналов. Платежи в выходные, всплеск операций по одному контрагенту в узком окне, нетипичная частота по категории.

Ты анализируешь хронологию операций на аномальные кластеры.

Данные: дата, сумма, контрагент (обезличен), категория.

Задача:
1. Найди операции, которые прошли в выходные и праздничные дни
   (суббота, воскресенье). Сгруппируй по контрагентам.
2. Найди контрагентов, у которых за период есть серия операций
   из 3 и более в течение 7 календарных дней. Укажи окно дат
   и общую сумму серии.
3. Посчитай среднее число операций в день по каждой категории
   и отметь категории, где реальная частота выше среднего
   более чем в 3 раза.
4. Выведи три списка с итогами. Для каждого пункта укажи,
   чем операция может объясняться (добросовестно) и когда
   это подозрительно.

Не делай выводов о виновности. Твоя задача: перечислить
места, которые стоит проверить вручную.

Платежи в выходные в российских компаниях иногда бывают легальными, например автосписание по кредиту. Поэтому промпт требует для каждого пункта объяснение, и финальный вывод оставляется человеку.

Промпт для реестра рисков и приоритизации находок

Когда модель находит аномалии по всем фильтрам, их нужно свести в единый список и расставить приоритеты. Это отдельный промпт, который превращает разрозненные находки в рабочий документ.

У меня есть результаты проверок выгрузки на аномалии:
отклонения от закона Бенфорда, дубли, круглые суммы,
платежи под порогом, кластеры по датам.

Данные по каждой находке: тип аномалии, дата, сумма,
контрагент (обезличен), причина по данным.

Собери единый реестр рисков и расставь приоритеты:

1. Приоритет высокий: пересечение двух и более признаков
   у одной операции или контрагента (например, круглые суммы
   и платежи под порогом).
2. Приоритет средний: один признак, но крупная сумма или
   повторяемость.
3. Приоритет низкий: одиночное отклонение с понятным
   добросовестным объяснением.

Формат вывода: таблица с колонками приоритет, тип аномалии,
сумма, дата, контрагент, рекомендованное действие.
В конце: сводка, сколько находок по каждому приоритету
и общая сумма потенциальных рисков.

Правило пересечения признаков работает надёжно: одна аномалия часто бывает случайностью, а вот сочетание «круглая сумма + платёж под порогом + один контрагент» это уже статистически значимый сигнал.

Промпт для сравнения двух периодов и поиска новых схем

Разовый анализ находит то, что уже случилось. Сравнение периодов показывает, что изменилось: новые контрагенты, смена частоты, всплеск в конкретной категории.

Ты сравниваешь две выгрузки операций за [период 1] и [период 2].

Данные по каждому периоду: дата, сумма, контрагент (обезличен),
категория.

Задача:
1. Найди контрагентов, которые появились во втором периоде
   и отсутствовали в первом. Укажи общую сумму по каждому.
2. Найди контрагентов, у которых объём операций вырос
   более чем в 2 раза. Укажи абсолютный рост.
3. Найди категории, где появились новые виды операций.
4. Сравни распределение по закону Бенфорда в двух периодах:
   в каком периоде отклонение сильнее.
5. Выведи результат четырьмя блоками с цифрами.

По каждому изменению укажи возможное добросовестное объяснение
(новый поставщик, рост бизнеса, сезонность) и признак,
при котором это стоит проверить отдельно.

Такой сравнительный анализ удобно запускать раз в месяц на одном и том же наборе данных. Постепенно накапливается история, по которой видно, как меняется структура операций, и новые схемы ловятся на ранней стадии.

Промпт для итогового отчёта руководству

Когда реестр рисков готов, его нужно превратить в короткий документ для генерального директора или собственника. Руководству не нужны детали распределений, ему нужны выводы и цифры.

У меня есть реестр рисков по результатам проверки финансовых
данных на аномалии: тип аномалии, сумма, период, статус
подтверждения.

Составь отчёт для генерального директора (350-400 слов):

1. Сколько операций проверено и за какой период.
2. Сколько аномалий найдено, сколько подтвердилось после
   ручной проверки документов.
3. Общая сумма потенциальных рисков и сумма подтверждённых.
4. Топ-3 наиболее значимые находки с коротким описанием.
5. Рекомендации: какие регламенты стоит ужесточить.

Пиши простым языком, без жаргона. Руководитель должен понять
пользу проверки за 2 минуты чтения.

Такой отчёт заодно служит обоснованием пользы AI-проверки: собственник видит конкретные цифры, а не абстрактное «мы усилили контроль».

Как проверить авансовые отчёты и закупки на признаки схем

Поиск аномалий не ограничивается платежами по расчётному счёту. Отдельные виды первички дают свои, специфические следы, и их удобно проверять своими промптами.

Авансовые отчёты. Здесь классические признаки: суммы точно под лимитом, который не требует утверждения руководителя, отсутствие чека при крупных тратах, авансовые отчёты, поданные один за другим одним сотрудником. Если сотрудник стабильно сдаёт отчёты ровно на 4 900 рублей при лимите 5 000, это систематический обход лимита, а не случайность.

Закупки. Один и тот же поставщик выигрывает тендеры с разницей в один рубль, закупки у единственного источника без обоснования, рост цен у одного поставщика при падении у остальных. Такие паттерны видны только на полной истории закупок, а не на отдельном тендере.

Промпт для проверки авансовых отчётов:

Ты проверяешь авансовые отчёты сотрудников на аномалии.

Данные: CSV/Excel со столбцами дата, сотрудник (обезличен),
сумма, назначение, статус утверждения.

Задача:
1. Найди отчёты, где сумма попадает в диапазон 90-100% от
   лимита, не требующего дополнительного утверждения.
   Лимит: [вставить сумму, например 5 000 руб].
2. Сгруппируй по сотрудникам: кто чаще других сдаёт отчёты
   точно под лимитом. Посчитай общую сумму по каждому.
3. Найди сотрудников с серией отчётов подряд в течение
   короткого окна дат (например, 5 и более за 10 дней).
4. Выведи две таблицы: по лимитам и по частоте, с итоговыми
   суммами и приоритетом проверки.

Не делай выводов о намеренности. Просто перечисли места,
которые стоит проверить по первичным документам.

Если авансовые отчёты у вас уже автоматизированы, у меня есть отдельная статья про проверку авансовых отчётов на нарушение лимитов и учётную политику: там про готового AI-агента, который ловит превышения до утверждения, а не после.

Аналогичный принцип работает для закупок. Отдельный промпт ищет поставщиков, которые стабильно выигрывают с минимальным отрывом от конкурентов, и сделки с одним поставщиком без конкурентных процедур. Модель через код сортирует все закупки по поставщикам и считает долю «почти выигранных» лотов, где разница в цене меньше 1%. Такой кластер в закупках не виден при разборе отдельного тендера.

Для наглядности сведу типовые следы по видам первички в одну таблицу: она пригодится, когда будете настраивать свои промпты.

Таблица показывает главное: у каждого типа документов свой статистический след, и фильтры под него подбираются отдельно. Универсального промпта «найди всё» не существует, зато связка из пяти-шести точечных промптов закрывает практически все типовые схемы.

Какие типовые схемы мошенничества встречаются в отчётности

Чтобы искать аномалии осмысленно, полезно знать, как выглядят типовые схемы. Вот несколько распространённых, и у каждой есть статистический след.

Фиктивные поставщики. Создаётся компания-провайдер, на которую оформляются платежи за несуществующие работы или товары. След в данных: регулярные круглые суммы, платежи точно под порогом контроля, отсутствие сезонности, которую можно ожидать от реального поставщика, рост объёмов без связи с бизнесом.

Подделка накладных и актов. Документы создаются задним числом или изменяются суммы. След в данных: аномальные кластеры по датам, документы, оформленные в выходные, скачки объёмов в конце отчётных периодов, когда нужно «закрыть» показатели.

Манипуляции с резервами и оценками. Руководство сознательно завышает или занижает резервы, чтобы сгладить прибыль. След в данных: отклонения от Бенфорда в суммах резервов и корректировок, повторяющиеся «красивые» значения, резкие пересмотры из периода в период.

Разбиение платежей. Крупный платёж делится на части ниже порога контроля. След в данных: кластер платежей одному контрагенту чуть ниже порога, одинаковая сумма с разницей в дни, совпадение назначений платежа.

Двойная оплата. Один счёт оплачивается дважды, часть денег возвращается или остаётся. След в данных: дубли по сумме и дате, повторная оплата с минимальной разницей в днях.

Промпт для углублённой проверки одного контрагента, когда подозрение уже сформировалось:

У меня есть полная история операций по одному контрагенту
(обезличенному) за [период]: дата, сумма, назначение платежа,
номер документа.

Проанализируй историю и найди признаки, которые могут указывать
на необычные операции:

1. Частота и регулярность: есть ли операции, выбивающиеся
   из обычного ритма (резкий рост, разовые всплески).
2. Суммы: доля круглых сумм, операции точно под порогом,
   резкие отклонения от среднего.
3. Хронология: операции в выходные, серии в узком окне дат,
   скачки в конце отчётных периодов.
4. Документы: повторные номера, номера с необычной структурой,
   операции без номера документа.

По каждому признаку укажи: что именно найдено, насколько это
отличается от нормы по этому контрагенту, и возможное
добросовестное объяснение. Не делай выводов о намеренности.

Такой точечный разбор полезен, когда контрагент уже вызывает вопросы у отдела закупок или финансового директора: модель быстро структурирует всю историю, а человек принимает решение.

Отдельный приём, который используют при маскировке: схемы прячутся в регулярных операциях. Если в компании есть привычные ежемесячные платежи одному поставщику, схему легко встроить в этот поток: та же сумма, тот же контрагент, та же дата каждый месяц. Статистические фильтры по отдельности такую операцию не поймают, потому что она не выбивается из ряда. Помогает сравнение периодов: когда объём по «обычному» поставщику вдруг вырастает в полтора раза без изменения договора и объёмов закупок, это уже отклонение от собственной нормы контрагента, и модель его подсветит.

Как подготовить и обезопасить выгрузку данных

Финансовая выгрузка это данные, которые нельзя загружать как есть. Перед любой проверкой их приводят в безопасный вид, и от качества подготовки зависит половина результата.

Удаляйте контрагентов. Названия компаний заменяйте на внутренние коды: Контрагент-001, Контрагент-002. Для поиска аномалий важна повторяемость и суммы, а не название.

Убирайте реквизиты. ИНН, КПП, номера договоров, банковские счета и адреса не нужны для статистических тестов. Их удаляют полностью.

Оставляйте даты, суммы, категории и внутренние идентификаторы. Этого достаточно для Бенфорда, дублей, кластеров и сравнения периодов.

Отключайте использование данных для обучения модели. В настройках ChatGPT и Claude есть соответствующая опция в разделах приватности. Для компаний с высокими требованиями это корпоративный тариф, где данные по умолчанию не используются для обучения.

Для сверхчувствительных данных используйте локальную модель. Если компания работает с данными, которые нельзя выносить за периметр, подойдёт локально установленная модель. Качество будет ниже, чем у GPT-5.5, но данные не покидают сервер.

Качество данных важнее объёма. Битые даты, задвоенные строки в самой выгрузке, смешанные форматы сумм ломают статистику: закон Бенфорда покажет отклонения там, где их нет, а дубли окажутся просто дублями в исходнике. Перед загрузкой выгрузку чистят: убирают задвоения, приводят суммы к единому виду, проверяют форматы дат. Потраченные на это 30-60 минут окупаются отсутствием ложных тревог.

Промпт для обезличивания выгрузки

Если выгрузок несколько и они приходят регулярно, обезличивание тоже удобно передать модели. Один и тот же промпт превращает любой экспорт в безопасный формат за минуты.

Ты получаешь сырую выгрузку операций из учётной системы.
Преобразуй её в обезличенный вид по правилам:

1. Замени названия контрагентов на коды: Контрагент-001,
   Контрагент-002. Одному названию всегда один код.
2. Удали ИНН, КПП, номера договоров, банковские счета,
   адреса, телефоны и ФИО сотрудников.
3. Оставь даты, суммы, категории, назначение платежа
   и внутренние идентификаторы операций.
4. Приведи суммы к единому формату: два знака после запятой,
   без пробелов и буквы «р».
5. Проверь, что в получившемся файле нет ни одного названия
   компании и ни одного реквизита.
6. Выведи итоговую таблицу и список того, что удалил.

Этот результат можно загружать в облачную модель.

После прогона стоит вручную просмотреть первые строки результата: модель могла оставить одно-два названия в поле «назначение платежа». Контроль первых десяти строк занимает пару минут и полностью закрывает риск случайной утечки.

Ещё один момент, который часто упускают: период проверки. Для первого прогона лучше брать не один месяц, а квартал или полгода. На коротком периоде статистика неустойчива, сезонность даёт ложные сигналы, а кластеры по датам не успевают проявиться. Полугодовой массив показывает устойчивую картину, по которой уже можно судить о структуре операций.

А если хочется автоматизировать подготовку выгрузки целиком, сценарий в n8n может сам собирать данные из учётной системы, обезличивать их по правилам и отправлять в модель на проверку. Это следующий уровень после ручного запуска, и он оправдан, когда проверка становится регулярной. Для старта достаточно ручной подготовки: она даёт полный контроль над тем, что именно попадает в модель.

Если в компании ещё не зафиксированы правила работы с нейросетями, до загрузки первых выгрузок стоит закрыть этот вопрос отдельно: у меня есть готовый шаблон AI-политики для финансового отдела с перечнем того, что можно загружать, что нельзя и кто отвечает за настройку.

Что нашли нейросети в реальных выгрузках: четыре кейса

Четыре кейса из практики учениц школы. Названия компаний и цифры приведены с их разрешения в обезличенном виде.

Кейс 1: производственная компания, 5 200 операций за квартал

Ученица школы, финансовый директор производственной компании, решила проверить данные за квартал после того, как внешний аудит дал оговорку по спорным расходам на закупку. Аудит проверил выборку из 150 операций из 5 200, и подозрительные платежи в неё не попали.

Было: выгрузка за квартал это 5 200 операций на общую сумму около 48 млн рублей. Ручная выборочная проверка по крупным суммам занимала 2-3 рабочих дня и закрывала около 3% операций.

Что сделали: обезличили выгрузку (замена контрагентов на коды, удаление реквизитов), загрузили в GPT-5.5 с код-интерпретатором, прогнали через проверку по Бенфорду, дублям, круглым суммам и платежам под порогом. Вся обработка заняла около двух часов.

Стало: модель нашла 23 подозрительные позиции. Разбор вручную подтвердил 9 из них: четыре двойные оплаты одному поставщику на общую сумму 187 000 рублей, пять платежей, разбитых на суммы чуть ниже порога контроля в 100 000 рублей. Двойные оплаты удалось вернуть через претензию, разбитые платежи ушли в пересмотр регламента контроля. На проверку всего массива ушёл один рабочий день вместо двух-трёх, и закрыт был весь массив, а не 3%.

Кейс 2: оптовая компания, подозрение на фиктивные накладные

Финансовый директор оптовой компании получил сигнал от отдела закупок: у одного поставщика стали странно расти объёмы. Прямых доказательств не было, ревизия выборку не находила.

Было: в данных за полгода 6 100 операций. Подозреваемый поставщик проводил платежи регулярными круглыми суммами, но каждая операция по отдельности выглядела нормальной и в выборку аудита не попадала.

Что сделали: загрузили выгрузку в Claude Sonnet 4.6 с инструкцией найти контрагентов с аномальной структурой платежей и круглыми суммами. Дополнительно прогнали распределение по Бенфорду по категориям расходов.

Стало: модель показала, что у подозреваемого поставщика 85% платежей это круглые суммы без копеек (при норме по этой категории около 15%), а также серия из 6 платежей в течение 5 дней, каждый ровно под порогом контроля. Пересчёт по первичке подтвердил: часть накладных не имела подтверждающих документов о фактической поставке. Компания приостановила платежи, провела ревизию и закрыла отношения с поставщиком. Оценка предотвращённых потерь около 1,4 млн рублей за полугодие.

Кейс 3: розничная сеть, двойная оплата из-за сбоя интеграции

Не всякая аномалия это мошенничество. Иногда это технический сбой, и AI-анализ помогает найти его раньше, чем он вырастет в потерю.

Было: у розничной сети в данных платежей появились дубли с разницей в 1-2 дня по одним и тем же счетам. Бухгалтерия списывала их на человеческий фактор, но количество росло.

Что сделали: прогнали выгрузку за месяц через промпт поиска дублей. Модель нашла 14 пар оплат с одинаковыми суммами и номерами документов.

Стало: разбор показал, что дело не в мошенничестве, а в сбое интеграции с банком: часть файлов подгружалась дважды. Компания нашла и устранила причину, вернула 3 из 14 ошибочных платежей через заявления в банк на 96 000 рублей. Для команды это стало наглядным примером: AI-проверка находит и технические аномалии, а не только умышленные схемы.

Кейс 4: строительный подрядчик, кластер платежей под порогом

Четвёртый случай показывает, как один и тот же фильтр работает на разных типах данных. У компании, которая занимается отделкой, порог контроля был 50 000 рублей, и бухгалтерия считала, что обходных схем нет: все платежи проходят с документами.

Проверка через промпт круглых сумм и платежей под порогом показала иное. В данных за два месяца нашёлся кластер из 40 платежей одному субподрядчику в диапазоне 45 000-49 500 рублей, часть из них круглыми суммами. Каждый платёж был оформлен отдельным договором на мелкие работы, и ни один не превышал порог. Разбор вручную показал: большая часть этих договоров закрывала один и тот же объём работ, разбитый на части. Компания пересмотрела регламент: порог контроля заменили на контроль по совокупному объёму с одним контрагентом за месяц. Такой фильтр по совокупности модель считает так же легко, как и одиночные платежи, просто в промпте добавляется группировка по контрагентам и периодам.

Общий итог по четырём кейсам простой: на массивах в 4 000-6 000 операций проверка занимает час-два машинного времени и один день ручного разбора вместо двух-трёх дней выборочной проверки, а подтверждённые находки в каждом случае дали суммы, которые окупили внедрение с первого месяца.

Если вам интересна похожая тема контроля финансовых потоков, у меня есть статья про проверку дебиторской задолженности через AI-scoring: там про автоматическую оценку рисков неплатежей, а не только про поиск аномалий в данных.

Какая модель лучше для поиска аномалий в отчётности

Актуально на август 2026 года. Задача поиска аномалий требует двух разных сильных сторон: точного статистического счёта и качественной интерпретации подозрительных схем.

Рабочая связка, которую используют ученицы школы: GPT-5.5 для статистической части (Бенфорд, дубли, кластеры, расчёт сумм), Claude Sonnet 4.6 для интерпретации сложных схем и составления понятных пояснений для руководства.

Почему именно такая связка? Код-интерпретатор в GPT-5.5 выполняет Python-код по-настоящему: он пересчитывает распределение первых цифр, а не угадывает его. А Claude Sonnet 4.6 с большим контекстным окном спокойно держит выгрузку на 6 000 строк и пишет объяснения, которые руководитель читает без перевода. Две модели закрывают две разные половины задачи, и это дешевле, чем кажется: черновые статистические прогоны можно делать в бесплатных тарифах, а на платную связку переходить, когда проверка становится регулярной.

Если вы выбираете нейросеть под свои задачи и хотите понять разницу на практических примерах, у меня есть отдельная статья про сравнение нейросетей для финансовых задач: там разбор на реальных задачах финансиста, включая работу с таблицами и текстами.

Что нейросеть не может и где решение остаётся за человеком

AI-поиск аномалий это фильтр, а не следователь. Есть зоны, где модель бессильна, и об этом стоит говорить прямо.

Аномалия не равна мошенничеству. Отклонение от Бенфорда или кластер круглых сумм может быть ошибкой ввода, сменой тарифов, добросовестной сделкой или сбоем системы. Вывод о намеренности делает только человек после проверки документов.

Доказательная база. Модель формирует гипотезы и список мест для проверки. Официальное заключение, сбор доказательств, взаимодействие с правоохранительными органами это работа профессионального аудитора или юриста, а не нейросети.

Контекст бизнеса. Модель не знает, что для вашей компании нормально: сезонные всплески, специфику отрасли, особенности работы с конкретными поставщиками. Этот контекст есть только у финансового директора.

Ложные обвинения. Подсветка «подозрительной» операции в отношении добросовестного сотрудника это репутационный риск. Поэтому каждая аномалия сначала разбирается вручную, и только подтверждённые факты идут в официальный процесс.

Качество данных. Если выгрузка грязная (битые даты, задвоенные строки, сменные форматы сумм), статистика даст ложные сигналы. Подготовка данных это половина успеха проверки.

Независимость от модели. Модель проверяет то, что её попросили проверить. Если схема не оставляет статистического следа в данных (например, мошенничество через неучтённые наличные вне системы), AI её не увидит. Это ограничение любого анализа данных, а не конкретной модели.

Как встроить AI-поиск аномалий в систему внутреннего контроля

Регулярная проверка на аномалии это не разовая акция, а элемент системы контроля. На практике это работает так.

Сначала зафиксируйте методологию: какие фильтры запускаете, на каких данных, с какой периодичностью. Один и тот же набор промптов и одна и та же выгрузка каждый месяц дают сопоставимые результаты, по которым видно динамику.

Затем определите периодичность. Для компаний с потоком операций в несколько тысяч в месяц разумно прогонять проверку ежемесячно. Для малых объёмов: раз в квартал. Важна регулярность, а не разовый глубокий анализ.

Потом настройте передачу результатов. Реестр рисков из промпта выше должен попадать к финансовому директору и, при необходимости, во внутренний аудит. Хорошо, если он становится частью регулярной управленческой отчётности собственнику: собственник видит не абстрактный «контроль», а конкретные суммы предотвращённых потерь.

Если в компании уже выстроен AI-контур для проверки авансовых отчётов на лимиты и учётную политику, результаты поиска аномалий логично подключать туда же: один и тот же массив данных проверяется и на соответствие правилам, и на статистические отклонения. Это даёт два независимых взгляда на одни и те же операции.

Для компаний, которые только начинают, отдельно стоит посмотреть на тест ChatGPT против живого бухгалтера на задачах 1С: там видно, где нейросеть объективно сильнее человека на рутине, а где уступает. Это помогает трезво оценить границы инструмента до внедрения.

Если тема вам близка и вы хотите посмотреть, как такие проверки встраиваются в рабочие процессы целиком, у меня есть статья про армию AI-агентов, которые закрывают месяц в одиночку: там про связку нескольких агентов от первички до закрытия периода.

Постоянно работающий AI-контур контроля это уже следующий уровень автоматизации. Когда проверка на аномалии работает стабильно несколько месяцев, её результаты можно подавать в сводку по кэшу, марже и дебиторке как отдельную строку про выявленные риски. Собственник видит не просто «мы проверяем», а цифры: столько-то операций проверено, столько-то аномалий найдено, на такую-то сумму подтверждены риски.

Какие ошибки мешают проверке и как ловить галлюцинации модели

Загрузка грязных данных. Битые даты, дубли строк в самой выгрузке, смешанные форматы сумм ломают статистику. Перед загрузкой выгрузку чистят: убирают задвоения, приводят суммы к единому виду, проверяют форматы дат.

Проверка слишком малого массива. Закон Бенфорда и статистические фильтры работают на сотнях и тысячах значений. Проверка 40 операций через Бенфорд бессмысленна, результат будет случайным.

Полное доверие флагам модели. Каждая подсветка требует ручной проверки по первичке. Если разбирать флаги некому, инструмент превращается в источник ложных тревог и теряет доверие.

Обвинение сотрудников по результатам одного прогона. Аномалия без подтверждения документами это гипотеза, а не факт. Нарушение этого правила разрушает команду и создаёт репутационные риски для компании.

Остановка после одного анализа. Разовый прогон показывает срез. Схемы эволюционируют, и именно регулярное сравнение периодов ловит новые схемы на ранней стадии.

Игнорирование объяснений модели. Промпты выше требуют от модели указывать добросовестное объяснение для каждой аномалии. Этот шаг нельзя выбрасывать: он фильтрует ложные срабатывания ещё до ручной проверки.

Отдельно про галлюцинации. Модель может «досчитать» то, чего в данных нет: придумать дубль, где его нет, или назвать сумму, которая не совпадает с исходником. Это случается реже, когда расчёты идут через код-интерпретатор, потому что код выполняется реально, а не воображается. Но защита всё равно нужна, и она простая.

Требуйте от модели ссылки на строки. Каждая находка должна указывать номер строки или идентификатор операции в исходнике. Если модель не может показать строку, находка не принимается.

Просите пересчёт через код. Для сумм и дублей настаивайте, чтобы проверка выполнялась кодом, а не «на глаз». Код-интерпретатор в GPT-5.5 считает по-настоящему.

Сверяйте контрольные суммы. Итоговая сумма найденных аномалий должна сходиться с контрольным расчётом. Расхождение это сигнал, что модель что-то придумала.

Прогоняйте один и тот же массив дважды с разными формулировками. Если две проверки дают сильно разные результаты по простым признакам (дубли, суммы), значит, где-то ошибка в интерпретации задачи.

Есть и практический приём, который экономит время на проверку качества ответа: просите модель вывести первые пять строк таблицы, на которых основан вывод. Если сами строки выглядят корректно и соответствуют исходнику, доверие к результату выше. Если модель не может показать промежуточный срез, скорее всего, она срезала угол и не считала по-настоящему.

Как проверить результат нейросети: независимая верификация

Полученные находки сами по себе не являются истиной в последней инстанции. Их нужно проверить так же тщательно, как и данные, которые вы загрузили. Три правила ниже убирают почти все ложные срабатывания ещё до передачи реестра руководству.

Первое правило: сверка с исходником. Каждая находка должна ссылаться на конкретную строку или внутренний идентификатор операции. Без этого любой «подозрительный» платёж бесполезен: его всё равно придётся искать руками, а если модель ошиблась в сумме, вы будете искать несуществующую операцию. Промпт с требованием ссылок на строки отсекает большинство выдумок сразу.

Второе правило: две модели как два независимых мнения. Прогоните один и тот же массив через GPT-5.5 и Claude Sonnet 4.6 с одинаковым набором фильтров. Совпадение находок по конкретным операциям это сильный сигнал, что аномалия реальная. Расхождение это повод разобраться в методологии, а не в модели: чаще всего одна из моделей поняла задачу иначе, чем вторая.

Третье правило: правило «трёх объяснений». Для каждой находки модель обязана дать три версии: добросовестное объяснение, ошибку учёта и схему. Если добросовестное объяснение очевидно (сезонность, регулярный платёж по договору), находка уходит в низкий приоритет. Если объяснения нет ни для одной версии, это уже повод для ручной проверки.

Эти три правила не занимают много времени, но именно они превращают список флагов в рабочий документ, который можно показывать собственнику без страха за репутацию сотрудников.

Важный психологический момент: верификация защищает не только компанию, но и команду. Если модель подсветила добросовестного сотрудника, а вы сразу понесли флаг руководству, доверие к инструменту рухнет, и следующие прогоны будут восприниматься как охота на людей. Три правила верификации дают козырь на обе стороны: и компания получает подтверждённые находки, и сотрудники защищены от ложных обвинений, потому что в реестр попадают только позиции, прошедшие сверку с исходником. Отдельный промпт для верификации:

У меня есть список аномалий из проверки финансовых данных.
Для каждой: тип аномалии, дата, сумма, контрагент (обезличен),
внутренний идентификатор операции.

Данные выгрузки: CSV/Excel со столбцами дата, сумма,
контрагент, категория, идентификатор.

Задача:
1. Для каждой аномалии найди строку в исходной выгрузке
   по идентификатору и покажи её содержимое.
2. Сверь сумму и дату из аномалии с фактическими значениями
   в строке. Если расхождение больше 0,01%, отметь
   как "ошибка модели".
3. Дай три версии для каждой аномалии: добросовестное
   объяснение, ошибка учёта, схема. Для каждой версии
   укажи, насколько она правдоподобна по данным.
4. Итоговая таблица: идентификатор, тип аномалии,
   статус сверки, приоритет ручной проверки.

Промпт с этой инструкцией полезно запускать сразу после первого прогона, пока выгрузка ещё загружена в контекст. Он занимает один запуск, а экономит часы ручной сверки: часть флагов модель сама же и отменяет, если научить её сверяться с исходником.

Когда реестр прошёл верификацию, он готов к разбору по чек-листу ниже.

Как запустить первую проверку на аномалии: чек-лист

1. Соберите выгрузку операций за период в табличном виде: дата, сумма, категория, контрагент, идентификатор. Чем полнее массив, тем надёжнее статистика.
2. Обезличьте данные. Замените контрагентов кодами, удалите ИНН, реквизиты, личные данные сотрудников.
3. Почистите выгрузку. Уберите задвоения, приведите суммы к единому формату, проверьте форматы дат.
4. Загрузите данные в GPT-5.5 с код-интерпретатором и запустите проверку по закону Бенфорда.
5. Прогоните фильтры аномалий: дубли, круглые суммы, платежи под порогом, кластеры по датам.
6. Сравните периоды, если есть данные за два периода: новые контрагенты, рост объёмов, смена распределения.
7. Соберите реестр рисков с приоритетами: пересечение признаков выше, одиночные отклонения ниже.
8. Прогоните верификацию по промпту сверки с исходником и сведите флаги двух моделей.
9. Разберите флаги вручную по первичным документам. Подтверждённые аномалии идут в официальную процедуру, остальные закрываются с пометкой.
10. Зафиксируйте методологию и повторяйте проверку ежемесячно на одном и том же наборе промптов.
11. Покажите результаты руководству с цифрами: сколько операций проверено, сколько аномалий найдено, на какую сумму подтверждены риски.

Частозадаваемые вопросы

Смотрите блок FAQ в начале статьи: там собраны ответы про точность проверки по закону Бенфорда, безопасность данных, выбор моделей и границы AI-поиска аномалий. Если ваш вопрос не нашёлся, напишите в комментарии или в наш канал, разберу отдельно.

Заключение: нейросеть не заменяет аудитора, но закрывает его слепую зону

Главная ценность AI-поиска аномалий не в том, что нейросеть «умнее» аудитора, а в том, что она видит весь массив данных, а не выборку. Схемы, разбитые на части ниже порога контроля, дубли, круглые суммы и кластеры по датам статистика ловит мгновенно, тогда как человек при ограниченном бюджете часов физически не может проверить тысячи операций построчно.

Решение по каждой аномалии, подтверждение документами и ответственность за выводы остаются за человеком. Модель готовит список мест, куда посмотреть, и делает это за часы, а не за дни. Внедрение занимает один день, а регулярный прогон раз в месяц стоит меньше, чем час работы специалиста.

Если подводить итог простой формулой: AI-поиск аномалий это способ смотреть на все операции компании, а не на выборку из них, и делать это каждый месяц без роста затрат. Аудит остаётся обязательным и независимым, но теперь у него появляется подготовленный список зон риска, с которого можно начинать, а не бессистемный облёт тысяч операций.

Для тех, кто хочет не просто разово проверить данные, а построить систему: начните с методологии из чек-листа ниже, прогоните первый квартал, зафиксируйте цифры по найденным аномалиям и уже на этих данных решайте, что автоматизировать дальше. Цифры первого квартала это лучший аргумент и для руководства, и для самого финансового директора, который отвечает за контроль.

Если вы только начинаете работать с нейросетями в финансовых процессах, поиск аномалий это хорошая точка входа: результат виден с первого прогона, риск ошибки контролируем (модель только подсвечивает, не обвиняет), а сэкономленные часы и предотвращённые потери окупают вложенное время быстро.

Если хотите разобраться глубже, не только с поиском аномалий, а со всем набором задач, которые нейросети закрывают в работе финансиста и бухгалтера, подписывайтесь на наши каналы:

• @findir_pro, 45 000 подписчиков, основной канал школы «Финансовый директор | Мастер CFO»
• «АИ с Софьей и Натали», 13 000 подписчиков, канал про нейросети для финансистов
• MAX, 5 000+ подписчиков, актуальные новости и практика применения AI в финансах

800+ выпускников курса «AI-навыки финансиста» уже внедрили похожие сценарии в свою ежедневную работу.