crmamocrm

Договор с чужими реквизитами: как это ловится автоматом

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

Договор с чужими реквизитами: как это ловится автоматом

Одна цифра в реквизитах — и договор недействителен

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

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

Откуда берётся ошибка

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

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

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

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

Как выглядит сборка без ручного ввода

Реквизиты вводятся один раз — в карточку клиента. Дальше договор собирается из шаблона подстановкой: система берёт данные из карточки и вставляет в нужные места документа. Менеджер не печатает ИНН — он нажимает «сформировать договор» и получает готовый файл, где реквизиты гарантированно совпадают с карточкой, потому что взяты из неё. Одно место ввода вместо трёх убирает два шанса из трёх на ошибку сразу. Оставшийся — сам ввод в карточку — закрывается двумя слоями проверки.

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

Два слоя защиты на вводе

  • Проверка формата и контрольной суммы. ИНН организации — 10 цифр, ИНН физлица и ИП — 12. Контрольные цифры вычисляются из остальных по алгоритму ФНС, так что случайная опечатка почти всегда ломает контрольную сумму. Важная деталь, в которой часто путаются: у 10-значного ИНН контрольная цифра одна — последняя, а у 12-значного их две: 11-й и 12-й знаки. Структура закреплена в Порядке и условиях присвоения, применения, а также изменения ИНН (приказ ФНС России от 29.06.2012 № ММВ-7-6/435@): для организации формат вида NNNNXXXXXC с одним контрольным знаком, для физического лица — NNNNXXXXXXCC с двумя. У расчётного счёта есть контрольный ключ, который проверяется вместе с БИК банка, — то есть счёт нельзя проверить в отрыве от банка. Кривой номер система отклонит на вводе.
  • Подтягивание из официальных источников. По ИНН можно автоматически получить название и адрес организации из открытых данных ФНС, чтобы менеджер не набирал их руками. Ввёл ИНН — остальное подставилось и сошлось.

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

Сразу оговорюсь: мы не юристы и не консультируем по налоговому праву. Всё, что касается формата и структуры реквизитов, стоит сверять с действующими документами ФНС и Банка России — они меняются, и проверку в системе надо уметь обновлять, а не заливать в код навсегда.

Отдельно стоит помнить, что контрольная сумма ловит опечатку, но не ловит подмену. Если менеджер ввёл существующий ИНН другой компании, все проверки пройдут — номер корректный, просто не тот. Против этого работает только второй слой: подтянутое из ФНС наименование, которое менеджер видит и сверяет с тем, с кем он вообще разговаривает.

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

Автоматика закрывает класс ошибок ввода, но не заменяет здравый смысл. Короткий список того, что человек всё равно смотрит перед отправкой:

  1. Совпадает ли наименование в договоре с тем, с кем вы вели переговоры. Самая частая нестыковка: говорили с одним юрлицом группы, договор собрался на другое.
  2. Актуален ли расчётный счёт. Счёт — самый подвижный из реквизитов. Подтверждение от контрагента по текущей сделке надёжнее, чем то, что лежит в карточке с прошлого года.
  3. Кто подписант и на основании чего. Устав, доверенность, её срок. Автоподстановка возьмёт то, что записано, а записанное могло устареть.
  4. Предмет и сумма. То, что подставляется из сделки, а не из карточки контрагента, — отдельный источник ошибок, если сделку правили после формирования документа.
  5. Версия шаблона. Формируется ли документ по той форме, которую вы считаете актуальной.

Этот список короткий именно потому, что остальное закрыто машиной. В том и смысл: внимание человека — дефицитный ресурс, и тратить его надо на то, что машина проверить не может.

Порядок внедрения

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

  1. Соберите все версии шаблонов, которые сейчас в ходу. На этом шаге обычно выясняется, что их больше, чем предполагал руководитель, и они отличаются не только шапкой.
  2. Выберите одну эталонную форму и согласуйте её с тем, кто отвечает за юридическую часть. Не автоматизируйте то, в чём не уверены, — иначе размножите ошибку.
  3. Разметьте в шаблоне места подстановки. Каждое место должно ссылаться на конкретное поле карточки, а не на «примерно то же самое».
  4. Наведите порядок в карточке контрагента до автоматизации. Проверки на ввод, единый формат, обязательность там, где без реквизита документ не собрать.
  5. Прогоните пакет реальных договоров и сравните с тем, что подписывали руками. Расхождения покажут и ошибки шаблона, и ошибки в накопленных данных.
  6. Закройте ручную сборку. Пока остаётся возможность собрать документ по-старому, часть менеджеров будет собирать по-старому, и вы получите два процесса вместо одного.

Шестой шаг чаще всего пропускают, и именно он определяет, приживётся автоматизация или нет.

Побочный плюс — скорость

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

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

Грабля, которой стоит поучиться на нашем опыте

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

Для генерации документов это ровно тот же риск, только последствия материальнее. Шаблон поправили, у себя проверили, а система на проде продолжает собирать договоры по прежней форме. Внешне всё в порядке: документы формируются, ошибок нет, менеджеры довольны.

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

Возражения

«У нас мало договоров, проще руками». Экономика тут не в объёме, а в цене одной ошибки. Один сорванный платёж или переподписание съедает выигрыш от всех «сэкономленных» настроек сразу.

«У нас договоры нетиповые, шаблон не подойдёт». Нетиповая обычно предметная часть, а реквизиты, подписанты и шапка — типовые всегда. Автоматизируйте эту часть, остальное оставьте человеку.

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

«А если ФНС не ответит или сервис недоступен». Подтягивание из открытых данных — удобство, а не единственный барьер. Проверка контрольных сумм работает локально и не зависит от доступности внешних сервисов, поэтому её и ставят первым слоем.

Подводные камни

  • Автоподстановка надёжна ровно настолько, насколько чиста карточка: один раз завели кривой ИНН — он поедет во все договоры. Поэтому проверка контрольной суммы стоит именно на вводе в карточку, а не потом.
  • Данные ФНС по ИНН подтягивают наименование и адрес, но не заменяют актуальный расчётный счёт от клиента — счёт и подписанта всё равно подтверждают у контрагента.
  • Шаблон должен быть один и версионируемый; если у менеджеров расплодятся личные копии в Word, автоматизация соберёт документ по устаревшей форме.
  • Контрольная сумма ловит опечатку, но не ловит корректный ИНН чужой компании. От подмены спасает только сверка наименования.
  • Обновлённый шаблон надо проверять на проде, а не только у себя. Мы на этом уже обжигались.
  • Мы не юристы: формат реквизитов и требования к документам меняются, сверяйтесь с первоисточниками ФНС и Банка России и держите проверки обновляемыми.

Чем это оборачивается в деньгах

В нашей CRM под кредитный бизнес (БизнесКредит96), где документы — основа сделки, генерация договоров из карточки убрала этот класс ошибок: реквизиты в документе всегда те же, что в системе. Там же видно, что даёт автоматизация документооборота в связке с остальной системой: ежедневный контроль у собственника сократился с 12 часов до 2, а количество договоров выросло втрое без найма новых людей. Это результат работы всей системы за 15 месяцев, а не одной только генерации документов, — но документы в кредитном брокеридже узкое место, и без них остальное не разгонялось бы.

Если договоры собираются руками и иногда «горят» из-за опечаток — оставьте заявку через форму или напишите в Telegram.