Как собственнику бизнеса выстроить контроль дублирующихся платежей
Дублирующийся платеж — не техническая мелочь, а прямой убыток и признак слабого финансового контура. Деньги уходят дважды по одному счету, по двум похожим счетам, по повторной заявке или из-за ручной ошибки при загрузке платежей. Собственник обычно видит проблему поздно: остаток на счете ниже плана, поставщик подтверждает лишнее поступление, бухгалтерия ищет расхождение, а возврат растягивается. Я смотрю на такие случаи не как на разовые промахи сотрудников, а как на сбой в устройстве процесса.
Причины почти всегда повторяются. Нет единого номера обязательства внутри компании. Один отдел заводит заявку по договору, другой — по счету, третий — по письму менеджера. В платежной системе нет проверки по ключевым полям. У счета и акта разный маршрут согласования. Предоплата и окончательный расчет не связаны в одной карточке. Поставщик отправил документ повторно с новым номером файла, сотрудник принял его как новый. При большой долей ручных операций ошибка становится вопросом времени.
Где возникает риск
Я начинаю не с покупки программы, а с карты движения платежа. Нужна простая схема: кто создает основание, кто проверяет реквизиты, кто согласует сумму, кто формирует реестр, кто отправляет платеж в банк, кто сверяет исполнение. На этой схеме видны места, где дубль проходит незамеченным. Обычно их четыре.
Первое место — входящий документ. Счет попадает в компанию из почты, мессенджера, через менеджера или закупщика. Если у канала нет единой точки регистрации, один и тот же документ заходит дважды под разными именами файлов и у разных сотрудников.
Второе место — заявка на оплату. Инициатор создает новую заявку, потому что не видит старую, не понимает ее статус или не находит по поиску. При слабой дисциплине полей система хранит похожие записи, но не связывает их.
Третье место — платежный реестр. Казначей включает в него строки из разных источников: ручной список, выгрузку из учетной системы, письмо руководителя подразделения. На стыке форматов дубль проходит без сигнала.
Четвертое место — повторная отправка в банк. Сбой обмена, отклонение по подписи, неверное предположение об отсутствии платежа. Сотрудник отправляет документ повторно, а первый экземпляр уже исполнен.
Чтобы закрыть риск, я разделяю контроль на три уровня. Первый уровень — профилактика на входе. Второй — автоматическая проверка перед оплатой. Третий — постконтроль после списания денег. Если оставить только последний уровень, компания будет ловить уже совершенный убыток.
Что проверить в процессе
На входе нужен единый журнал обязательств. Не для красоты, а для привязки каждого будущего платежа к понятному основанию. В журнал заносят контрагента, договор, счет, сумму, валюту, дату, статью бюджета, подразделение, срок оплаты, статус. Главный принцип: одна хозяйственная причина — одна карточка. Предоплата, доплата, частичная оплата и закрытие остатка живут внутри нее, а не в россыпи независимых записей.
Дальше я ввожу набор обязательных совпадений, по которым система или сотрудник ищет дубль. Минимум: ИНН или иное устойчивое обозначение контрагента, номер договора, номер счета, сумма, дата счета, банковские реквизиты, назначение платежа. Если хотя бы три-четыре поля совпали, запись уходит на ручную проверку. Если совпали счет, контрагент и сумма, платежа блокируется до подтверждения финансовым контролером.
Отдельное правило нужно для случаев, когда поставщик меняет номер счета, а содержание остается прежним. Тут помогает контроль по периоду, договору и сумме. Если в коротком интервале появляется новый документ на ту же сумму по тому же договору, система помечает его как подозрительный. Сотрудник проверяет основание: новый этап, исправление ошибки в реквизитах или простая копия старого счета.
Еще один узел — частичные оплаты. Без отдельного признака они создают шум и мешают поиску дублей. Я всегда ввожу поле «остаток к оплате» по каждой карточке обязательства. Пока остаток не равен нулю, новая заявка по тому же основанию сверяется не с полной суммой счета, а с незакрытым остатком. Иначе первая оплата на половину счета будет выглядеть как дубль, а вторая — как новая независимая операция.
Роли и правила
Система контроля ломается не из-за отсутствия инструкций, а из-за смешения ролей. Инициатор платежа не проверяет уникальность документа. Его задача — корректно завести основание и приложить подтверждение. Проверку на дубль я отдаю функции финансового контроля или казначейству, но не тому, кто заинтересован в срочной оплате. Подписание реестра руководителем фиксирует управленческое решение, а не заменяет проверку данных.
Для работы нужны короткие правила. Первое: оплата идет только из зарегистрированной карточки обязательства. Второе: изменение реквизитов счета не создает новую карточку без ссылки на прежнюю. Третье: срочный платеж не обходит проверку, а получает ускоренный маршрут с теми же контрольными точками. Четвертое: повторная отправка в банк возможна только после сверки статуса первого документа по выписке или банковскому ответу. Пятое: возврат ошибочно перечисленных денег фиксируется как отдельный инцидент с разбором причины, а не как бытовой эпизод.
Если в компании несколько юридических лиц, я добавляю межконтурную сверку. Иначе один счет поставщика оплачивают из двух компаний группы. Формально платежи разные, по сути дубль в масштабе бизнеса. Для этого нужен общий реестр обязательств хотя бы по ключевым полям и единая проверка по контрагенту, сумме и основанию.
Автоматизация без иллюзий
Автоматизация дает эффект, когда процесс уже описан. Без правил система лишь ускоряет хаос. Я обычно прошу внедрить три механизма. Первый — дедупликация, то есть поиск совпадающих записей по заданным признакам. Второй — жесткие блокировки для критичных совпадений. Третий — журнал решений по спорным случаям: кто снял блокировку, на каком основании и с каким комментарием.
Не нужно строить сложную модель с десятками исключений на старте. Достаточно начать с набора рисковых сценариев: одинаковый счет, одинаковая сумма по одному договору в одном месяце, одинаковое назначение платежа при совпадении контрагента, повторная отправка в банк в течение короткого интервала. После первого месяца работы список уточняют по реальным случаям.
Хорошо работает контроль перед банковской выгрузкой. Реестр платежей проходит финальную проверку пакетом, а не поштучно. На этой стадии видны дубли внутри одного дня, между подразделениями и по несколькоким источникам формирования. Если компания платит из нескольких банковских клиентов, сверка нужна до разнесения пакетов по счетам.
Я не полагаюсь только на внутреннюю систему. После списания денег нужен быстрый пост контроль по выписке: совпадение сумм, контрагентов, назначений и оснований с уже исполненными платежами за период. Такой отчет выявляет пропущенные дубли и показывает, где блокировки не сработали.
Для собственника главный вопрос не в названии программы, а в трех показателях: сколько подозрительных дублей система поймала до оплаты, сколько реальных дублей прошло в банк, сколько денег компания вернула и за какой срок. Если эти цифры растут в правильную сторону, контроль заработал. Если отчет красивый, а возвраты идут месяцами, процесс еще сырой.
Я оцениваю качество системы по простому признаку: любой платеж в компании можно проследить от основания до выписки без разрывов, а повтор одной и той же хозяйственной причины упирается в проверку еще до отправки в банк. Когда цепочка собрана, дубли перестают быть случайностью и превращаются в управляемое исключение.
