Автоматизация проверок контрагентов: чек-лист и перепроверка

Что не так с ручной проверкой контрагентов

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

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

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

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

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

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

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

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

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

Перед стартом сделки и перед деньгами

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

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

При изменениях и сомнительных сигналах

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

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

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

Если нужно короткое правило для команды, достаточно пяти строк:

• Новый партнер - проверка до первой оплаты или отгрузки.
• Условия сделки стали рискованнее (сумма, аванс, отсрочка) - проверка перед согласованием.
• Изменились реквизиты или ключевые данные - проверка до применения новых данных.
• Тендер или закупка - проверка перед подачей и перед контрактом.
• Появились красные флаги - внеплановая проверка в день сигнала.

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

Чек-лист данных: что собирать в карточке партнера

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

Сначала зафиксируйте идентификацию: полное наименование, БИН, юридический и фактический адрес, рабочие контакты (телефон, e-mail), ответственный менеджер. Важно держать один источник правды: если БИН или адрес меняется, это должно отражаться и в текущих полях, и в истории изменений.

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

Минимальный набор полей

Чтобы карточка оставалась удобной, оставьте только то, что реально влияет на решение:

• Идентификация: наименование, БИН, адрес, контакты.
• Реквизиты: счет, банк, валюта, дата подтверждения.
• Право подписи: руководитель, доверенность (номер и срок).
• Параметры сделки: предмет, сумма, сроки, отсрочка, штрафы.
• Внутренние отметки: инициатор, уровень риска, краткий комментарий.

Блок про право подписи часто забывают. В итоге компанию проверили, но кто подписывает - нет. В карточке должны быть ФИО руководителя и данные доверенностей с датой окончания, чтобы система могла напоминать об истечении сроков еще до подписания допсоглашений.

Простой пример

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

Внутренние отметки тоже экономят время. Укажите, кто инициировал партнера, какой риск присвоен (низкий, средний, высокий) и коротко - почему так решили и какие ограничения действуют (например, "только предоплата"). Тогда решение можно проверить и объяснить.

Как задать периодичность перепроверки без лишней бюрократии

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

Разделите данные на две группы. Стабильные меняются редко (наименование, регистрационные данные, лицензии). Часто меняющиеся обновляются быстрее (банковские реквизиты, адрес для отгрузок, статус по задолженности, судебные споры). Для первой группы достаточно планового пересмотра, для второй нужен более короткий цикл плюс триггеры на события.

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

Практичная сетка, которую легко объяснить:

• Низкий риск: небольшой объем, нет отсрочки, поставки не критичны по срокам. Перепроверка раз в 12 месяцев.
• Средний риск: регулярные поставки или услуги, есть отсрочка, заметное влияние на процессы. Перепроверка раз в 6 месяцев.
• Высокий риск: крупные суммы, длинные контракты, высокая зависимость, доступ к критичным системам или данным. Перепроверка раз в 1-3 месяца.

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

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

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

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

Начните с простых статусов, одинаковых для всех. Обычно хватает четырех:

• В работе
• Проверено
• Нужен пересмотр
• Стоп

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

• Дата и время проверки (и дата следующей перепроверки)
• Исполнитель и кто утвердил (если требуется)
• Источник: реестр, входящее письмо, договор, счет, анкета
• Идентификатор подтверждения: номер письма, номер заявки, номер документа
• Итог и краткое обоснование (1-2 предложения)

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

Пример итоговой записи: "Реквизиты совпадают с договором N12 от 10.01.2026, адрес подтвержден по анкете, ограничений не выявлено. Статус: Проверено. Следующая проверка: 10.07.2026".

Исключения фиксируйте отдельно и строго: что именно разрешили, кто разрешил и на какой срок. Например: "Несовпадение адреса в анкете и в счете. Разрешено к оплате один раз по согласованию с финдиректором, срок до 31.01.2026. Далее: нужен пересмотр".

Сценарий со сменой реквизитов: вместо "реквизиты обновлены" лучше написать так: "Получено письмо N45 от 09.01.2026, проверено совпадение БИН и наименования, обновлены реквизиты в карточке. Оплата разрешена только на новый счет с 12.01.2026. Утвердил: руководитель закупок".

Пошагово: как настроить процесс автоматизации

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

Шаги настройки

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

2. Задайте сроки (SLA). Для новых контрагентов это часто 1-2 рабочих дня, для пересмотра действующих - быстрее. Сразу решите, что происходит при просрочке: приостановка оплат, запрет на новый заказ или эскалация руководителю.

3. Сделайте шаблон записи. Вместо свободного текста лучше короткие поля: что проверено, чем подтверждено, итоговый статус, дата следующей перепроверки.

4. Настройте уведомления и напоминания. Обычно нужны два типа: запуск проверки (новый партнер, смена реквизитов) и плановая перепроверка. Уведомление должно уходить конкретному исполнителю и его резерву, а не в общий чат.

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

Пример: отдел закупок выбирает нового поставщика для проекта (например, поставка оборудования в госорган). Инициатор создает запрос в CRM, система назначает проверяющего и ставит дедлайн. Проверяющий заполняет чек-лист, прикладывает подтверждения по реквизитам и статусу компании, отмечает риски. Утверждающий видит итоговый статус и условия (например, лимит первой поставки). После этого система ставит дату перепроверки и создает напоминание.

Типовые ошибки и ловушки

Автоматизация часто ломается не из-за техники, а из-за организационных решений. В системе все "зеленое", а при споре или проверке нечего показать.

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

Вторая ловушка - статус "проверено" без доказательств. Если не фиксировать дату, источник и что именно смотрели, запись не помогает.

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

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

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

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

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

Быстрый чек: 5 проверок, которые стоит сделать сегодня

Если у вас в базе уже сотни партнеров, начните с малого: выберите 10-20 самых важных (по сумме, частоте сделок или доступу к данным) и пройдитесь по одному шаблону. Это быстро покажет, где дыры в данных и что именно стоит автоматизировать.

1) Карточка партнера заполнена так, чтобы по ней можно было работать

Проверьте, что есть БИН, актуальные реквизиты для оплаты, юридический адрес и контакты, и что они совпадают с документами. Отдельно убедитесь, что указано право подписи и основание (доверенность, приказ).

2) Понятно, когда проверяли в последний раз и когда проверять снова

В карточке должны быть две даты: последняя проверка и следующая перепроверка. Без них невозможно понять, можно ли опираться на старый результат.

3) Есть уровень риска и короткое объяснение

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

4) Итоги подтверждены файлами или заметкой

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

5) Статус партнера не серый

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

Пример из практики: новый поставщик и смена реквизитов

Компания добавляет нового поставщика расходных материалов. Поставщик просит 50% предоплаты и присылает счет, а через два дня пишет: "У нас сменились банковские реквизиты, оплатите по новым". Это типовая ситуация, где автоматизация помогает не полагаться на переписку и "на глаз".

Сначала менеджер заводит карточку партнера в CRM и заполняет базовые поля: полное наименование, БИН/ИИН, юридический адрес, телефон, e-mail, сайт (если есть), ФИО контактного лица. Дальше включается сценарий проверки перед оплатой.

Что делаем по шагам

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

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

Одна понятная запись в карточке

Главная цель - чтобы любой коллега понял, что проверили и на чем основано решение. Пример записи:

"05.01.2026: запрос на предоплату 50%. 07.01.2026: уведомление о смене реквизитов. Подтверждено звонком на основной номер, приложено письмо с подписью и доверенность №12 от 03.01.2026. Совпадение БИН и наименования - да, изменился только ИИК/банк. Статус: Проверено с условиями. Ограничения: оплата только по новым реквизитам, сумма предоплаты не выше 50%, следующий платеж - после акта/накладной".

Следующую перепроверку лучше назначать по событию: перед первой оплатой по новым реквизитам или через 30 дней после первой поставки (что наступит раньше). Напоминание уходит ответственному за контрагента и сотруднику, который согласует платежи.

Следующие шаги: как закрепить процесс и кому поручить внедрение

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

Рабочий план на запуск:

• Назначить владельца процесса (обычно комплаенс, безопасность или финконтроль) и владельца данных в карточке партнера (закупки или продажи).
• Оставить 3-4 статуса проверки и правило, кто имеет право менять статус.
• Определить сроки: когда проверяем перед договором и как часто перепроверяем по риску.
• Согласовать обязательные поля в карточке партнера и что считается доказательством.
• Запустить пилот на одном подразделении на 2-4 недели.

Пилот быстро показывает реальную боль: сколько проверок зависает, какие поля чаще всего пустые, какие причины отказа повторяются.

Что попросить у системы (или у вашей CRM)

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

Кому поручить внедрение

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

Если вам нужна инфраструктура под CRM и связанные процессы (серверы, рабочие места, поддержка, интеграция), это можно обсудить с GSE.kz (gse.kz) как с технологическим производителем и системным интегратором, который работает с организациями в госсекторе и крупном бизнесе.