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

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

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

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

Что именно контролировать в договоре

Контроль сроков действия договора — только один слой задачи. Кроме начала и окончания действия, в документе могут быть сроки оплаты, поставки, оказания услуг, предоставления отчёта, подписания акта, возврата имущества, направления претензии или уведомления об отказе от продления.

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

Удобно разделять три сущности:

Такое разделение защищает от ложной точности. Если договор говорит «оплата в течение пяти рабочих дней после получения оригинала счёта», нельзя просто сохранить найденное число пять. Сначала нужно зарегистрировать получение счёта, затем рассчитать дату по утверждённому календарю и сохранить источник расчёта.

Календарная дата и срок от события

Календарная дата известна заранее: «оплатить до 15 ноября». Её можно поставить в календарь после проверки документа.

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

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

Условия, которые подтверждает специалист

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

Человек подтверждает как минимум:

• какое событие запускает отсчёт;
• по какому календарю считать рабочие дни;
• достаточно ли электронного уведомления или нужен другой способ;
• состоялось ли автопродление;
• какой документ доказывает исполнение.

Если ответ неясен, карточка получает статус «требует толкования» и ссылку на спорный фрагмент. Неизвестное нельзя заменять предполагаемой датой только ради заполненного поля.

Как устроить реестр и карточку обязательства

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

Минимальная карточка выглядит так:

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

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

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

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

Как настроить напоминания и эскалацию

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

Сроки напоминаний задаёт процесс. Универсального правила «за 30, 7 и 1 день» нет: срок подготовки платежа, отказа от продления и передачи отчёта различается. Для каждого типа события определите, сколько времени нужно сотруднику на действие и согласование.

Карточка правила напоминаний может содержать:

Простой маршрут выглядит так:

1. Система создаёт уведомление и записывает время отправки.
2. Ответственный подтверждает получение или меняет статус обязательства.
3. При отсутствии подтверждения уведомление повторяется по правилу процесса.
4. После контрольной точки задача уходит заместителю или руководителю, а первоначальная запись сохраняется.

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

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

Как учитывать оплаты, исполнение и изменения

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

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

• одна карточка хранит план, накопленную оплату и остаток;
• основная карточка связана с отдельными платёжными событиями.

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

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

Версия договора и допсоглашение

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

1. Какой документ был исходным?
2. Какое условие изменилось?
3. С какого момента действует изменение?
4. Кто подтвердил связь новой версии с обязательством?

Ниже — синтетический пример, а не файл, клиентский кейс или результат внедрения Switch On AI.

В договоре D-104 есть обязательство PAY-02: оплатить второй этап до 15 ноября. Для него создано напоминание на 8 ноября. Стороны подписывают допсоглашение DS-01, которое переносит срок этого же этапа на 30 ноября.

Ожидаемая обработка выглядит так:

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

Отмена прежнего напоминания

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

1. Найти действующее обязательство по постоянному ID.
2. Добавить новую версию условия со ссылкой на допсоглашение.
3. Пометить прежнюю дату и её напоминания как отменённые новой версией.
4. Создать напоминания для новой даты и проверить, что активный маршрут один.

Если операция оборвалась после третьего шага, обязательство может остаться без напоминания. Если после второго — появятся два маршрута. Поэтому при приёмке проверяйте не только успешное изменение, но и повторную обработку того же допсоглашения, а также сбой между этапами.

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

После такого примера уже можно оценивать состав автоматизации. Switch On AI помогает спроектировать обработку документов, правила обновления карточек и действия в рабочих системах в рамках услуги разработки ИИ-агентов. Если маршрут всегда одинаков и не требует выбора следующего шага, для него может быть достаточно обычной интеграции. ИИ-агент уместен там, где нужно разбирать текст, выбирать разрешённый источник или передавать неоднозначность человеку. Чат-бот нужен только тогда, когда диалог — подходящий интерфейс процесса.

Как выбрать инструмент и связать системы

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

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

Отдельно проверьте:

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

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

Официальная документация Microsoft описывает предобученную модель Contract на платформе Azure AI Document Intelligence v4.0 с идентификатором prebuilt-contract. Согласно документации, модель анализирует текст договора и возвращает структурированные данные, включая стороны, идентификатор и название; там же указана поддержка англоязычных форматов документов. Это пример доступной функции конкретного продукта, а не доказательство качества на русскоязычных договорах, личного запуска или готовности всего процесса контроля. Извлечение полей не заменяет реестр, правила версий, напоминания и подтверждение специалиста.

Как внедрить на одном типе договора

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

1. Подготовьте учебную карточку

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

2. Разделите извлечение и утверждение

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

Если для учебного сценария рассматривается Azure AI Document Intelligence v4.0, последовательность строится по документации продукта: передать поддерживаемый документ модели prebuilt-contract, получить структурированный ответ и показать найденные поля сотруднику. Это учебная последовательность по официальной документации, а не утверждение о личном запуске, измеренной точности или пригодности для русскоязычного архива.

3. Проверьте повторы и версии

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

4. Проверьте права

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

5. Проверьте сбои

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

6. Обучите участников на их действиях

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

7. Перенесите старый реестр

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

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

Риски, ошибки и ограничения ИИ

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

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

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

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

ИИ не должен:

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

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

Как оценивать результат и что обсудить со специалистом

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

Для пилота полезны четыре показателя:

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

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

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

Switch On AI может разобрать такой процесс, определить границы обычной интеграции и ИИ-агента, подготовить требования и проверочный сценарий. До договора показывается бесплатный прототип ключевого фрагмента; он не равен полноценному внедрению. Состав разработки, подключения, эксплуатацию, сроки и стоимость согласуют после разбора задачи.

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