Фрод в чековых программах: типовые схемы и защита бюджета
16 июля 2026
Чек — удобная основа для программы мотивации продавцов. Участник загружает покупку, система проверяет фискальные данные, производитель видит дату, товар, точку продаж и участника, который загрузил чек.
Но одного чека недостаточно, чтобы закрыть все риски. Документ может быть чужим, старым или повторным. Товар могли вернуть после начисления бонуса. Одну и ту же продажу могли подтвердить дважды: например, чеком и накладной.
Правильный вопрос перед запуском — не “принимаем чеки или нет”, а какие начисления нельзя проводить автоматически.
С этого и начинается антифрод: с правил для чека, сроков загрузки, лимитов, ручной проверки и понятного сценария на случай возврата товара.
Что в чековой программе считается фродом
Фрод — это не только поддельный чек или заранее продуманная схема. В программах мотивации сюда попадают разные ситуации: чужой чек, повторная загрузка, старый документ, формальная регистрация продавца, возврат товара после начисления, ошибка в правилах.
Для команды это не одно и то же. Если продавец действительно продал товар, но сфотографировал чек так, что QR-код не читается, ему нужен понятный отказ и возможность загрузить документ заново. Если участник регулярно приносит сомнительные чеки, начисления нужно остановить и передать заявку на проверку.
«У нас 20 процентов чеков не проходит модерацию по разным причинам, и они кажутся довольно объективными. Плохое качество чека, не читается QR-код или еще что-то.»
— Марина, бренд-менеджер, производитель ветпрепаратов
В этом и сложность. Антифрод должен защищать бюджет, но не должен заставлять честного продавца каждый раз доказывать, что он ничего не нарушил. Ошибка в фото и попытка накрутки должны обрабатываться по-разному.
Чужой, старый или повторный чек
Самая частая проблема — чек есть, но он не подтверждает нужную продажу.
Участник может взять чек, который покупатель оставил у кассы. Может получить фото от коллеги. Может загрузить старый документ, где есть нужный товар, но продажа произошла до участия в программе. Может отправить один и тот же чек еще раз.
Поэтому чек проверяют сразу по нескольким признакам:
- существует ли фискальный документ;
- не загружали ли его раньше;
- попадает ли дата покупки в период программы;
- есть ли в чеке нужный товар;
- не нарушены ли лимиты участника;
- не требует ли заявка ручной проверки.
Срок давности чека лучше задать до запуска. В нашей практике была программа, где продавцу давали 7 дней после покупки, чтобы загрузить чек.
ФНС позволяет проверить кассовый чек по QR-коду или реквизитам и сопоставить его с данными службы. Это подтверждает существование и содержание фискального документа, но не заменяет правила самой программы: срок загрузки, нужный товар, уникальность и лимиты участника. Источник: приложение ФНС «Проверка чеков».
Это ограничение не про недоверие к каждому участнику. Оно помогает сохранить связь между продажей и бонусом. Чем старше чек, тем сложнее понять, относится ли он к работе конкретного продавца.
Возврат товара после бонуса
Даже настоящий чек не всегда означает, что бонус можно начислять сразу.
Покупатель купил товар, продавец загрузил чек, бонус начислился. Через несколько дней товар вернули. В отчете программы продажа уже есть, но для бизнеса результата нет.
Этот риск важен в категориях, где возвраты обычны: техника, оборудование, товары для дома, часть косметики, медицинские изделия. В фармацевтической категории отдельно обсуждали, что одни товары возврату не подлежат, а другие можно вернуть.
При работе над одной из программ нас прямо спросили о сценарии, где продавец сначала регистрирует продажу, получает бонус, а затем возвращает товар.
Если товар маркирован, часть риска закрывает проверка уникального кода и статуса товара. Мы работали с программой, где проверка Честного Знака использовалась как защита от возвратов и повторной загрузки одного товара. При этом сценарий зависит от товарной группы и настроенной интеграции: официальный порядок возврата маркированного товара различается по группам, а часть операций проходит через ККТ и ОФД. Источник: «Честный Знак»: возврат маркированного товара.
Если маркировки нет, чек сам по себе может не показать возврат. Такой вопрос отдельно поднимали в строительных материалах: без маркировки по чеку не всегда видно, что товар позже вернули.
В таких случаях нужны другие настройки: задержка начисления, лимиты, сверка с отчетами партнера, ручная проверка крупных выплат.
Мы работали с производителем оборудования, у которого антифрод был устроен через двухнедельную задержку начисления: это время оставляли на проверку возврата.
Задержка не нужна в каждой категории. Для недорогого товара она может только мешать участию. Но если возврат заметно влияет на экономику продажи, мгновенный бонус становится риском.
Формальные регистрации вместо участников
Накрутка может начаться еще до первого чека.
Например, торговому представителю ставят KPI по подключениям. Он регистрирует продавцов сам: с одного телефона, в один день, с разницей в несколько минут. В отчете база выросла, в программе появились новые аккаунты. Но эти люди не загружают чеки и не возвращаются в программу.
«С одного устройства 10 человек из Ялты, Новороссийска, все в один день с разницей в 5 минут. Из 10, которых она подключила сама, ни один в течение месяца не загрузил ни один чек.»
— Светлана, трейд-маркетолог, производитель зоотоваров
Регистрация в такой ситуации не равна участию. Участие начинается, когда продавец понял правила, сделал первое подтвержденное действие, увидел начисление и вернулся снова.
В той же программе выявили 36 подозрительных участников и передали их в отдел продаж для проверки.
Поэтому в аналитике важно смотреть не только на число регистраций. Нужны устройство, время подключения, город, точка, торговый представитель, первый чек и дальнейшая активность.
«Я хочу выводить, допустим, по этому устройству: вдруг этот подключающий будет заходить со своего телефона в аккаунт. И вот мы посмотрим, что с этого телефона еще пять участников работает.»
— Алексей В., директор по маркетингу, производитель никотиновой продукции
Иначе отчет покажет рост базы, хотя реальных участников может почти не прибавиться. 500 активных продавцов и 500 формально заведенных аккаунтов требуют разных решений.
Одна продажа в двух документах
Не все программы работают только с кассовым чеком. В B2B и сложной рознице продажу могут подтверждать накладная, серийный номер, гарантийный талон, фото установки или другой документ.
Это расширяет охват программы, но создает риск двойного учета. Если чек и накладная не связаны между собой, одна продажа может попасть в программу дважды.
«Если мы говорим про накладные, а потом по этой же продаже будет чек, то двоение объема, потому что один проверяется по одной базе, а другой по другой базе.»
— трейд-маркетолог, производитель строительной химии
Задача не в том, чтобы запретить альтернативные документы. Иногда без них программа не охватит нужный канал. Задача — заранее определить главный источник данных, правила сверки и порядок действий при совпадениях.
Без такой логики отчет может показать рост, которого на самом деле нет: продажа одна, а бонусы и аналитика учитывают ее дважды.
Фотоотчеты и ручные подтверждения
В некоторых программах участник подтверждает не покупку, а действие: установку оборудования, выкладку, консультацию, заказ, использование материала.
У таких механик свои риски. Один и тот же снимок можно отправить несколько раз. Старую установку можно выдать за новую. Фото может быть настоящим, но не относиться к той продаже, за которую участник просит бонус.
Для фотоотчетов нужно заранее закрепить простое правило: если участник загружает одинаковые фотографии, заявку нужно отклонять.
Для фотоотчетов условия должны быть конкретными: что должно быть видно в кадре, можно ли загружать один объект повторно, какие признаки считаются ошибкой, а какие ведут к блокировке.
Чем точнее эти правила, тем меньше спорных начислений и ручных разборов после запуска.
Что настроить до запуска
Антифрод плохо работает в режиме “посмотрим по ходу”. Первые спорные чеки быстро превращаются в спор с участниками, нагрузку на поддержку и ручной разбор правил, которые нужно было написать заранее.
Минимальный набор:
| Что настроить | Зачем это нужно |
|---|---|
| Срок давности чека | Чтобы участники не загружали старые покупки, к которым они могли не иметь отношения |
| Уникальность чека или маркировки | Чтобы один товар не приносил бонус несколько раз |
| Лимит чеков на участника | Чтобы замечать резкие всплески и нетипичную активность |
| Задержка выплаты для рискованных категорий | Чтобы увидеть возврат до вывода бонуса |
| Статусы участника | Чтобы подозрительные аккаунты не получали бонусы автоматически |
| Ручная модерация исключений | Чтобы не проверять все подряд, но разбирать сомнительные заявки |
Почему нельзя проверять все руками
Ручная модерация нужна, но не для каждого чека.
Пока чеков мало, модератор может открыть заявку, посмотреть документ, участника, товар, точку и историю загрузок. Когда программа растет, такой подход тормозит начисления и раздражает честных участников.
Продавец сделал продажу, загрузил чек и ждет бонус. Если статус непонятен, а ответ приходит через несколько дней, мотивационный эффект слабеет. Для участника это выглядит не как защита программы, а как лишнее препятствие.
Рабочая логика другая:
- понятные чеки проходят автоматически;
- спорные получают отдельный статус;
- подозрительные участники уходят на проверку;
- крупные выплаты и ценные призы проверяются строже;
- причина отказа пишется обычным языком.
В Robobill для этого есть автоматическая и ручная модерация чеков, участников и заказов, отметка подозрительных участников, проверка уникальности данных и аналитика по 60+ метрикам.
Так модератор разбирает исключения, а не просматривает каждый нормальный чек.
Какие сигналы смотреть в аналитике
Антифрод нельзя оценивать только по числу заблокированных участников. Важнее видеть повторяющиеся признаки.
Например:
- у одного участника резко выросло количество чеков;
- несколько аккаунтов появились с одного устройства;
- в одной точке слишком много участников;
- торговый представитель подключает продавцов, которые потом не загружают чеки;
- доля отклоненных чеков выше обычного;
- участники массово загружают чеки в последний день срока;
- после начислений появляются возвраты.
Ни один сигнал сам по себе не доказывает накрутку. Но каждый показывает, где нужно открыть данные и проверить, что произошло.
Как не отпугнуть честных продавцов
Слишком жесткая проверка может остановить не только накрутку, но и нормальную активность.
Продавец проходит обучение, загружает чек, ждет модерацию, потом получает отказ без понятной причины. Для команды это корректный статус, для продавца — лишняя работа без результата.
Поэтому правила должны быть строгими к сомнительным заявкам и простыми для обычных продаж:
- до первой загрузки объяснить, какие чеки подходят;
- писать причину отказа обычным языком;
- давать возможность исправить ошибку, если это не накрутка;
- не требовать лишние документы на старте;
- не задерживать маленькие понятные начисления без причины.
Хорошая проверка почти незаметна для честного участника. Он продал товар, загрузил нормальный чек и получил бонус.
Если чек старый, повторный, чужой или связан с подозрительным аккаунтом, начисление нужно остановить. Но обычная продажа должна проходить коротким путем.
Чек-лист перед запуском
Перед запуском чековой программы стоит ответить на 12 вопросов:
- Какой чек считается подходящим?
- Какой срок давности чека принимаем?
- Что делаем с повторной загрузкой одного чека?
- Проверяем ли маркировку или уникальный код товара?
- Можно ли вернуть товар после начисления бонуса?
- Нужна ли задержка выплаты для рискованных категорий?
- Какие лимиты ставим на участника, точку и период?
- Что считаем подозрительной регистрацией?
- Как видим несколько аккаунтов с одного устройства?
- Какие случаи уходят на ручную модерацию?
- Как участник узнает причину отказа?
- Кто внутри команды смотрит сомнительные заявки и как быстро принимает решение?
Если эти вопросы не разобрать заранее, антифрод все равно появится — только уже в пожарном режиме, когда спорные начисления начались, а участники ждут объяснений.
Как Robobill помогает с антифродом
В чековой программе важно контролировать всю цепочку: регистрацию участника, загрузку чека, проверку, спорные статусы, начисление бонуса и аналитику.
Robobill помогает собрать эту цепочку в одной платформе. Команда может проверять чеки, настраивать условия участия, работать со статусами, видеть подозрительных участников, использовать 60+ метрик аналитики и разбирать исключения без ручных таблиц.
Для программы мотивации продавцов это принципиально. Бонус уходит конкретному человеку за конкретное действие. Значит, действие должно быть подтверждено, а сомнительные заявки не должны проходить так же легко, как нормальная продажа.
Частые вопросы
Чековая программа полностью защищает от фрода?
Нет. Чек хорошо подтверждает продажу, но не закрывает все риски сам. Нужны правила по сроку чека, уникальности, возвратам, лимитам, статусам участников и ручной проверке спорных случаев.
Что опаснее: фрод или слишком жесткая модерация?
Опасно и то и другое. Фрод уводит бонусный фонд не туда, где была нужная продажа. Слишком жесткая модерация отпугивает честных продавцов. Рабочая схема — автоматически пропускать понятные случаи и вручную разбирать исключения.
Нужно ли задерживать выплаты всем участникам?
Не всегда. Для дешевых товаров и низких бонусов задержка может мешать участию. Для дорогих товаров, возвращаемых категорий и ценных призов задержка помогает проверить возвраты и спорные действия до вывода бонуса.
Какие сигналы чаще всего говорят о накрутке?
Повторные чеки, несколько аккаунтов с одного устройства, резкий рост чеков у одного участника, странная география регистраций, высокая доля отказов, участники без чеков после регистрации и возвраты после начисления.
Можно ли бороться с фродом без ручной модерации?
Полностью — нет. Автоматизация должна принимать обычные чеки, а человеку лучше оставлять исключения: крупные выплаты, ценные призы, возвраты, повторные документы и подозрительные группы участников.