О стандарте
Для юридических департаментов, отделов договорной работы, отделов закупок, финансовых служб и ИТ-команд в компаниях-покупателях.
Для кого этот стандарт
Мы подготовили стандарт для юридических департаментов, отделов договорной работы, отделов закупок, финансовых служб и ИТ-команд в компаниях-покупателях, которые регулярно заключают расходные договоры поставки товаров, оборудования и материалов с юридическими лицами.
Стандарт описывает процесс со стороны покупателя по расходным договорам поставки. Доходные договоры (где компания выступает поставщиком) живут по другой логике и требуют отдельного стандарта.
Стандарт будет полезен в трёх ситуациях:
- Когда нужен аудит текущего процесса: сравнить, как устроены подготовка и согласование договоров поставки сегодня, с тем, как это работает у лидеров рынка.
- Когда внедряете новую ИТ-систему, меняете или улучшаете старую: сформулировать требования к процессу до начала автоматизации.
- Когда вводите в должность новых сотрудников: передаёте стандарт инициаторам, закупщикам, юристам и специалистам по договорной работе как рабочий регламент.
Как использовать стандарт
Стандарт описывает два состояния для каждого этапа:
Текущее состояние
Текущее состояние (AS IS) — как большинство компаний заключает договоры поставки вручную или в базовых системах. Это помогает провести диагностику и найти узкие места.
Целевое состояние
Целевое состояние (TO BE) — как настроить процесс, чтобы он работал оптимально (методологически и технологически), в том числе с использованием ИТ-платформы для управления контрактами и сделками.
Мы описали целевое состояние на примере платформы Doczilla. Большинство практик работают и в других системах управления контрактами, если они отвечают функциональным требованиям, описанным в этом документе.
Специфика договора поставки
Договор поставки — один из самых распространённых типов договоров в коммерческой практике.
Договор поставки — один из самых распространённых типов договоров в коммерческой практике. В крупной компании их заключают сотнями или тысячами в год. Под каждую категорию закупки, схему оплаты и тип отношений с поставщиком заведён свой шаблон. Под единым названием скрываются принципиально разные сценарии: от разовой сделки до многолетних рамочных отношений с сотнями заявок в год.
Классификация договоров поставки
Прежде чем выстраивать процесс, определите, к какому типу относятся сделки, которые вы заключаете. От этого зависит маршрут согласования, роль юриста и то, что происходит после подписания.
| Тип | Суть сделки | Типичные категории | Ключевая особенность процесса |
|---|---|---|---|
| 1. Разовая поставка | Один договор фиксирует одну поставку конкретного товара в конкретном объёме. После исполнения договор закрывается. | Оборудование под проект, сырьё для разового производства, товары для мероприятий. | Наиболее короткий маршрут: подписали — поставили — закрыли. Всё согласование в одном документе. |
| 2. Рамочный договор + заявки | Договор устанавливает общие условия сотрудничества. Конкретные поставки оформляются отдельными заявками или спецификациями в рамках уже подписанного договора. | Регулярные закупки расходных материалов, продуктов питания, топлива, стандартной периферии. | После подписания появляется повторяющийся цикл согласования каждой заявки. Критичны два риска: заявка не соответствует договору по предмету или стоимости; договор исполнен по лимиту, а заявки продолжают подписываться. |
| 3. По форме контрагента | Стороны договариваются работать по шаблону поставщика. Как правило, это крупные или монопольные поставщики, не готовые принимать чужие условия. | Например, закупка уникального оборудования, не имеющего аналогов, или контракт с «Роснефтью» на поставку нефтепродуктов. | Юрист включается с первого шага и оценивает условия с нуля. Маршрут согласования длиннее, риски выше — каждое условие требует экспертной оценки. |
Большинство практик стандарта применимы ко всем трём типам — они описывают общий процесс. Там, где поведение существенно отличается, в тексте стоит пометка [Рамочный] или [По форме контрагента]. Полная карта различий — в разделе 6.
Факторы, влияющие на договорный процесс
| Фактор | Почему это важно для договорного процесса |
|---|---|
| Контрагент — юридическое лицо | Реквизиты, полномочия подписанта и благонадёжность поставщика нужно проверять по реестрам (ЕГРЮЛ, ФНС, ФССП, Федресурс, арбитраж) и его корпоративным документам. Ошибка в реквизитах или истёкшая доверенность могут привести к рискам по договору и срыву поставки. |
| Связь с тендером | Цена, состав работ и сроки в договоре должны совпадать с итогами закупки. Любое расхождение — правовой и финансовый риск, если вы работаете по 44-ФЗ или 223-ФЗ, и основание для возврата договора на доработку согласующими и затягивания сроков закупки. |
| Несколько победителей | Компании часто сталкиваются с ситуацией, когда победителей в тендере несколько — по разным позициям или лотам. На каждого нужен отдельный договор с одинаковыми общими условиями и разными переменными частями. |
| Учётные атрибуты | Тип расхода (CAPEX/OPEX), центр затрат, бюджетный идентификатор и доступный остаток бюджета определяют согласование. Ошибка в атрибутах откатывает весь маршрут. |
| Десятки похожих шаблонов | Под каждую категорию, схему оплаты и тип сделки — свой шаблон. Взять не тот — типичная ошибка, её замечают уже после отправки поставщику или на согласовании юристами. |
| Много схем оплаты | Полная оплата, аванс, несколько траншей, оплата по этапам поставки, валютный коридор. Каждый вариант — отдельная логика формирования договора и свой график платежей. |
| Корпоративный контроль | Крупные сделки и сделки с заинтересованностью требуют корпоративного одобрения с обеих сторон. Отсутствие одобрения делает договор оспоримым. Важно предусмотреть автоматическую проверку на крупность и заинтересованность. |
| Много согласующих | Помимо юриста договор проходит через закупки, финансовый блок, казначейство и руководство. Каждый смотрит со своей стороны и с учётом своего опыта. Без согласованной матрицы рисков согласующие упускают важное или создают много шума за счёт правок и замечаний, которые можно было бы не давать. |
Типичные причины задержек и ошибок
- Инициатор вручную выбирает шаблон из нескольких похожих файлов в базе знаний (SharePoint, Confluence, общий диск) или у себя на компьютере и берёт не тот: перепутал тип поставки, схему оплаты или взял устаревшую версию. Ошибку замечают уже на согласовании.
- Данные о параметрах сделки определяются в электронной переписке, содержатся в закупочной заявке, протоколе об итогах тендера, в учётных системах. Одни и те же реквизиты и параметры сделки вводятся трижды: в тело договора, в каждое приложение, в карточку учётной системы или СЭД, в систему управления закупками.
- Поставщики самостоятельно считают НДС в коммерческом предложении — итоговые суммы расходятся с расчётами компании из-за разных методик округления, и договор возвращают на доработку.
- При нескольких победителях инициатор для подготовки контрактов копирует договор и изменяет переменные части вручную; широкие таблицы спецификаций из Excel и PDF не помещаются в Word — часы уходят на форматирование одного комплекта.
- Задача юристу и специалисту по договорной работе приходит без необходимого контекста и описания сделки примерно в 97% случаев — юрист вынужден вытаскивать щипцами из инициаторов условия сделки через мессенджеры, электронную почту, по телефону или искать информацию в CRM, в системе управления закупками и в других системах.
- Юрист вычитывает каждый типовой договор целиком, хотя ни одного отклонения от шаблона нет.
- Правки поставщика оценивают на глаз, по опыту, без понятных критериев: что можно принять самостоятельно, что эскалировать юристу, что точно требуется отклонить. Итерации идут по почте, история переписки теряется.
- Договор зависает у согласующего, и об этом узнают, только когда поставщик или бизнес начинает звонить и требовать ускориться.
Участники процесса: ролевая модель (TO BE)
Ниже — роли, которые пишут, проверяют и подписывают договор поставки в типичной крупной компании-покупателе. Конкретный состав зависит от внутренней структуры; названия ролей в разных компаниях отличаются.
| Роль | Подразделение | Зона ответственности в процессе |
|---|---|---|
| Инициатор | Бизнес-подразделение / проектный офис | Формирует потребность в закупке, выбирает шаблон, заполняет договор, ведёт согласование с поставщиком, передаёт задачу дальше. Также: бизнес-заказчик, категорийный менеджер, руководитель проекта. |
| Специалист по закупкам | Отдел закупок / снабжения | Организует тендер, формирует техническое задание и тендерный комплект, готовит протокол по итогам тендера, передаёт результаты в договорный модуль. Также: тендерный менеджер, категорийный закупщик. |
| Юрист | Юридический департамент | Проверяет договор и согласовывает отклонения от типовой формы. В типовых сделках без правок в договор не участвует в согласовании. Поддерживает шаблоны и матрицу рисков в актуальном состоянии. Также: юрисконсульт, юрист отдела по договорной работе. |
| Специалист по договорной работе | Юридический департамент / ОДР | Сопровождает договор от получения документов до подписания и начала исполнения: проверяет корректность, заводит карточку, строит маршрут, контролирует согласование. Также: контрактный менеджер, специалист контрактного отдела. |
| Финансовый партнёр | Финансово-экономический блок | Проверяет бюджетную обоснованность и корректность учётных атрибутов, согласовывает нестандартные условия оплаты. Также: финансовый контролёр, бюджетный аналитик. |
| Подписант | Руководство | Подписывает договор от имени компании, проверяет ключевые параметры сделки и наличие всех согласований. Как правило, генеральный или финансовый директор либо лицо по доверенности. |
| Контрагент (поставщик) | Внешняя сторона | Проверяет договор, делает правки, пишет замечания или направляет протокол разногласий, передаёт пакет документов по своей компании, подписывает договор. |
| ИТ-специалист / аналитик автоматизации | ИТ-департамент | Поддерживает интеграцию между системой управления закупками, ERP/учётной системой, справочниками контрагентов и платформой управления договорами. |
Преддоговорный этап
Большинство проблем, которые проявляются на этапе подготовки и согласования, рождаются здесь.
Большинство проблем, которые проявляются на этапе подготовки и согласования, рождаются здесь: нет актуального каталога шаблонов, не структурировано техническое задание, не проверен контрагент, не закрыт вопрос корпоративных одобрений, не выстроена связь между системой закупок и платформой управления договорами.
Каталог шаблонов и единый мастер-шаблон
В крупной компании одновременно живут несколько похожих шаблонов договора поставки: рамочный, разовый, с графиком поставки, с валютным коридором и оговорками, под разные схемы оплаты и категории товара. Это главный источник ошибок при выборе формы.
Чем больше шаблонов, тем выше риск ошибки. Три типичных сценария:
- Инициатор или закупщик берёт не тот файл — иногда версию с рабочего стола — и ошибку замечают только когда договор доходит до юриста.
- При изменении закона или внутренней позиции компании нужно обновить все шаблоны одновременно. Один забывают — по нему договоры идут с устаревшими условиями.
- Новая категория закупки или новый тип сделки — это новый набор шаблонов. Если подходящего шаблона нет, обращаются к юристу за разработкой нового, и подготовка удлиняется на несколько дней.
Чтобы собрать мастер-шаблон, задокументируйте правила применения формулировок:
- Тип сделки: разовая поставка, рамочный договор, заявка/спецификация в рамках рамочного, договор по форме контрагента.
- Категория и предмет: товар, оборудование, материалы; требования к качеству, комплектности, упаковке.
- Схема оплаты: полная оплата, аванс, несколько траншей, оплата по этапам поставки, валютный коридор. Для каждой — свой блок условий и график платежей.
- Обеспечение и ответственность: банковская гарантия, обеспечительный платёж, неустойки, гарантийный срок, уровень сервиса (SLA).
Структурированное техническое задание
| Что делаем | AS IS (как сейчас) | TO BE (целевое состояние) |
|---|---|---|
| Формирование ТЗ | Закупщик формулирует техническое задание с нуля для каждой закупки, дозапрашивая у инициатора характеристики, адреса поставки по юрлицам, требования к поставщику и критерии выбора. Шаблона нет — каждый раз в свободной форме. | Структурированный шаблон ТЗ с обязательными полями по категории закупки. Инициатор заполняет его до передачи в отдел закупок — закупщик получает готовую основу, сопоставимые предложения и не перезапускает тендер из-за упущенного параметра. |
Проверка контрагента (KYC)
Проверяйте поставщика до того, как начнёте готовить и согласовывать договор. Это один из самых частых источников задержек: договор уже готов, а служба безопасности только начинает проверку.
| Что проверяем | AS IS (как проверяют сейчас) | TO BE (целевое состояние) |
|---|---|---|
| Реестры и базы | Проверяют вручную в Федресурсе, КАД, ФССП, ФНС — последовательно в каждом источнике отдельно. | Система автоматически проверяет все реестры при создании сделки. Результат — в карточке контрагента. |
| Пакет документов поставщика | Запросы приходят дозированно: сначала один список, потом дополнительный. Поставщик отправляет документы по почте. | Система формирует полный и окончательный список с первого запроса. Поставщик грузит документы прямо в систему и видит, чего не хватает. |
| Повторная проверка перед подписанием | Не проводят системно — между первой проверкой и подписанием проходят недели или месяцы. | Система автоматически перепроверяет реестры непосредственно перед подписанием. При появлении негативных событий договор не уходит на подписание. |
Проверка полномочий подписанта
Если договор подпишет человек без полномочий, его можно оспорить. Обязательно проверьте полномочия с обеих сторон, перед тем как отдавать договор на подпись.
| AS IS (как сейчас) | TO BE (целевое состояние) | На что обращать внимание |
|---|---|---|
| Юрист или специалист по договорной работе вручную запрашивает устав, доверенность и/или приказ о назначении, проверяет срок действия и объём полномочий, сверяет с ЕГРЮЛ. Данные своего подписанта ищут в корпоративном справочнике или на общем диске вручную. | Система ведёт справочник своих подписантов и при формировании договора подставляет подписанта автоматически. Документы-основания полномочий контрагента запрашиваются и проверяются автоматически при помощи AI. Истёкшая или недостаточная доверенность — блокировка. | Три типичные ошибки: доверенность истекла; полномочия ограничены суммой меньше цены договора или доверенность выдана на другие типы сделок; подписант действует по доверенности лица, которое само не вправе её выдавать. |
Тендер: что должно перейти в договор
Если вы заключаете договор после тендера, текст может разойтись с тем, что согласовали в ходе закупки. Это правовые и финансовые риски. Три параметра обязательно должны соответствовать итогам тендера:
- Цена договора: совпадает с ценой, указанной в заявке победителя. Любое отклонение требует обоснования и согласования. НДС считается по единой методике на основе цен за единицу — иначе суммы в заявке, протоколе и договоре расходятся.
- Состав и объём поставки: точно соответствуют лоту тендера. Добавление или исключение позиций без повторной закупки может быть нарушением.
- Сроки и условия поставки: совпадают с предложением победителя.
Несколько победителей тендера
Иногда в тендере может быть несколько победителей — по разным позициям или лотам. Инициатор копирует договор, создаёт отдельный файл на каждого и подставляет переменные части вручную. В каждый договор необходимо вставить правильные реквизиты и спецификацию. Таблицы из Excel и PDF не помещаются в Word, копируются и вставляются неправильно, часы уходят на форматирование одного комплекта, и легко допустить расхождение между копиями.
Система формирует комплект договорных документов на всех победителей автоматически: общие условия формируются из мастер-шаблона, переменные части и реквизиты — из сводной таблицы по победителям или из протокола. Расхождений между копиями нет, ручной перенос данных исключён.
Корпоративные одобрения
Одобрение нужно получить до подписания — причём с обеих сторон. Отсутствие одобрения создаёт риск оспаривания договора.
1. Одобрения со стороны заказчика (покупателя)
| Основание | Что проверяем | Последствия при пропуске |
|---|---|---|
| Крупная сделка | Сумма договора превышает 25% балансовой стоимости активов компании (если иное не предписано уставом). | Участник или акционер может оспорить договор в суде. |
| Сделка с заинтересованностью | Должностные лица или бенефициар поставщика аффилированы с руководством или участниками компании. | Договор оспорим. |
2. Одобрения со стороны поставщика
Убедитесь, что поставщик одобрил сделку внутри своей компании. Если директор подписал договор без необходимого одобрения, поставщик может попытаться оспорить сделку. Проверьте, является ли сделка крупной для поставщика, есть ли у директора полномочия на подписание без одобрения (по уставу) и получено ли решение уполномоченного органа. Устав поставщика, финансовая отчётность — обязательная часть стандартного KYC-пакета.
Матрица рисков и маршрутов
Матрица — правила, по которым параметры сделки определяют состав согласующих и порядок их участия. Это центральный инструмент управления процессом: без матрицы все сделки идут по одному маршруту независимо от того, какие правки вносятся в типовой договор.
| Параметр сделки | Значение / условие | Влияние на маршрут согласования |
|---|---|---|
| Типовой договор без правок | Нет отклонений от шаблона | Система автоматически исключает юриста из маршрута. |
| Сумма договора | Выше порогового значения | Добавляют руководителя и при необходимости — корпоративное одобрение. |
| Наличие аванса / нестандартная оплата | Аванс, транши, оплата по этапам | В маршрут включают финансового партнёра и казначея для проверки графика платежей и кассового плана. |
| Новый поставщик | Контрагент работает впервые | Полная проверка СБ, включая ручную верификацию. |
| Повторный поставщик | Ранее проверен, верификация актуальна | СБ выдаёт визу автоматически, без ручной проверки. |
| Нерезидент / валютный договор | В сделке участвует нерезидент | Добавляют специалиста по валютному контролю и налогового консультанта. |
| Крупная сделка / заинтересованность | Превышение установленного порога или аффилированность | Требуется корпоративное одобрение до подписания. |
| Нетиповые условия / правки контрагента | Отклонение за пределы матрицы отклонений | Юриста включают в маршрут в обязательном порядке. |
| По форме контрагента | Работа по шаблону поставщика | Юрист обязателен с первого шага по материальным сделкам; добавляют смежных специалистов по отдельным условиям. |
Договорный этап
Подготовка драфта, пакет приложений, профиль сделки, внутреннее согласование, работа с правками контрагента, финальные проверки, подписание и ввод в действие.
Подготовка драфта
Выбор шаблона
Выбор неправильного шаблона — одна из самых частых ошибок на этом этапе. У крупной компании несколько похожих файлов для разных ситуаций: разные типы поставки, схемы оплаты, формы обеспечения, структуры цены.
Обязательный пакет приложений
Договор поставки без приложений и других документов по сделке влечёт проблемы на этапе исполнения. Перечень определяется шаблоном и типом сделки.
| Приложение | Содержание | Последствие отсутствия |
|---|---|---|
| Спецификация / перечень позиций | Наименования и описание товара, объёмы, цены за единицу, итоговая сумма. Основание для расчётов и приёмки. | Невозможно провести приёмку товара. Закрывающие документы не подписать. |
| График поставки | Сроки поставки по партиям или этапам. Основание для контроля и начисления неустоек. | Невозможно применить ответственность за нарушение сроков. |
| Требования к качеству / ТЗ | Характеристики товара, комплектность, упаковка, сертификаты. | Нет основания для оценки качества поставленного товара. |
| Документ об обеспечении | Банковская гарантия, обеспечительный платёж или поручительство (если предусмотрено). | Договор без обеспечения — нет защиты при нарушении обязательств. |
| График платежей | Аванс, транши, оплата по этапам — с суммами и датами. | Нестандартная оплата нигде структурно не зафиксирована — конфликт при закрытии сделки. |
Заполнение договора и профиль сделки
Договор поставки содержит десятки полей, которые должны быть заполнены корректно и синхронизированы между собой. Ручное заполнение из 4–5 источников — основная причина ошибок: одни и те же данные вводятся в тело договора, в каждое приложение и в карточку учётной системы.
Ключевые поля и источники данных:
- Реквизиты поставщика — из ЕГРЮЛ, карточки контрагента в учётной системе или из документов поставщика (с помощью AI).
- Предмет, наименования и цены позиций — из итоговой таблицы тендера и/или спецификации / протокола о подведении итогов тендера.
- Цена, аванс, схема оплаты — из тендерного предложения, системы управления закупками, согласованных ключевых условий сделки.
- Учётные атрибуты — тип расхода (CAPEX/OPEX), центр затрат, бюджетный идентификатор — из закупочной заявки.
- Сроки и условия поставки — из графика поставки.
- Реквизиты подписантов сторон — из доверенностей, приказов и справочника подписантов.
Профиль сделки — структурированный набор данных с ключевыми параметрами: поставщик, предмет, цена, схема оплаты, учётные атрибуты, состояние документов. Параметры профиля определяют шаблон и маршрут и остаются на 100% синхронизированы с текстом документов на всём цикле сделки.
Заполнение карточки в учётной системе
| AS IS (как сейчас) | TO BE (целевое состояние) |
|---|---|
| Специалист по договорной работе или инициатор вручную создаёт карточку договора в учётной системе (1С, SAP, Microsoft Dynamics) и переносит данные из договора: тип расходов, центр затрат, бюджетный идентификатор, условия оплаты. Те же реквизиты вводятся повторно. Нестандартные условия оплаты справочник не поддерживает — ставится пометка «ручной контроль». | Карточка учётной системы заполняется автоматически из данных договора и закупочной заявки. Реквизиты вводятся один раз и распространяются на все связанные документы. Нестандартный график платежей фиксируется структурно — аванс, транши, этапы с суммами и датами, — а не текстовой пометкой. Карточки в учётных системах руками не заполняются. |
Внутреннее согласование
Когда юрист не участвует
Ключевой принцип эффективного процесса: юрист — это эскалация для нестандартных ситуаций, а не обязательный участник каждой сделки. В договорах поставки подавляющее большинство типовых сделок проходит без правок контрагента — это главный резерв экономии.
Юристы не готовят типовые договоры поставки. Юристы утверждают мастер-шаблон, методологию его сборки и матрицу рисков / отклонений от типовых условий.
| Ситуация | Юрист | Основание |
|---|---|---|
| Типовой договор, собранный из мастер-шаблона без отклонений | Не участвует | Юристы утвердили шаблон. Отклонений нет — проверять нечего. |
| Несущественные правки контрагента в пределах матрицы отклонений | Не участвует | Зелёный уровень: правки в пределах допустимого — инициатор принимает их самостоятельно. |
| Нестандартная схема оплаты, валютный коридор, участие нерезидента | Участвует | Жёлтый уровень: нетиповые условия требуют индивидуальной проверки. |
| Правки контрагента за пределами матрицы отклонений | Участвует — оценивает только спорные пункты | Жёлтый уровень: юрист изучает только спорные моменты, а не весь договор. |
| Правки контрагента, которые ни при каких условиях не принимаются компанией | Не участвует | Красный уровень: инициатор или специалист по закупкам видят, что подобные правки никогда не принимаются компанией, и сразу их отклоняют. Не тратят время команды на их согласование. |
| Нетиповые условия, новый тип сделки, договор по форме контрагента | Участвует с этапа подготовки первого драфта | Жёлтый уровень: нет шаблона или прецедента — условия оцениваются с нуля. |
| Новая категория, новый тип сделки | Участвует с этапа настройки мастер-шаблона | Нужно один раз описать условия и включить их в правила сборки. |
Целевые показатели согласования
| Показатель | AS IS | TO BE | Как измеряется |
|---|---|---|---|
| Время от создания сделки до подписания (типовой договор) | 7–14 раб. дн. | 2–3 раб. дн. | Дата создания сделки / подведение итогов закупки → дата подписания |
| Доля договоров с ошибками в реквизитах или суммах | ~20–30 % | < 2 % | Количество возвратов на доработку |
| Доля типовых договоров без участия юриста | 0 % (юрист смотрит все) | > 80 % | Доля маршрутов без этапа «Юрист» |
| Среднее время ответа на правки контрагента | 3–5 раб. дн. | 1 раб. дн. | Дата получения правок → дата ответа |
Согласование с контрагентом
Три модели работы с правками
| Модель | Описание | Когда применяется | Риски |
|---|---|---|---|
| А. Правки в тексте (режим рецензирования) | Поставщик вносит изменения прямо в текст договора с отслеживанием изменений. | Частая практика. | Трудно отследить изменения без инструментов сравнения. Версии множатся. |
| Б. Протокол разногласий (до подписания) | Поставщик предлагает свои варианты спорных пунктов. | Частая практика, но есть тренд на отказ от такого подхода. | ПРГ — отдельный юридический документ, требует отдельного подписания и хранения. |
Матрица отклонений от стандартных условий
Матрица отклонений определяет, какие изменения инициатор вправе принять самостоятельно, какие нужно согласовать с профильным подразделением, а какие неприемлемы в принципе.
| Тип правки | Кто принимает решение | Пример | Срок ответа |
|---|---|---|---|
| Косметические — формулировки без смены смысла | Инициатор самостоятельно | Изменили порядок слов, заменили синонимы | В день получения |
| Технические — реквизиты, адреса, даты в допустимых пределах | Инициатор самостоятельно | Уточнили адрес поставки | В день получения |
| Коммерческие — оплата, сроки, обеспечение в допустимых пределах | Инициатор + согласование с профильным отделом (финансы, казначей) | Увеличили срок оплаты с 15 до 20 рабочих дней | 1–2 раб. дн. |
| Правовые — ответственность, гарантии, порядок расторжения | Юрист | Снизили размер неустойки, изменили гарантийный срок за рамками матрицы отклонений, но в пределах возможного | 2–3 раб. дн. |
| Блокирующие — выход за пределы допустимых отклонений | Отклонить или передать руководителю | Отказались от банковской гарантии, исключили ответственность за качество | Отклонение — в день получения |
Проверки перед подписанием
Финальные проверки — последний рубеж контроля до того, как договор вступит в силу. Они обязательны независимо от того, как прошло согласование.
| Проверка | AS IS (как сейчас) | TO BE (целевое состояние) |
|---|---|---|
| Реквизиты и арифметика | Специалист вручную сверяет суммы и ставки НДС, копируя данные в Excel и перемножая. | Платформа автоматически проверяет арифметику и сверяет данные с тендером и спецификацией. При расхождении — предупреждение и блокировка перехода к подписанию. |
| Повторная проверка контрагента | Как правило, не проводится — между первой проверкой и подписанием проходят недели. | Автоматическая проверка по Федресурсу, КАД, ФССП, ФНС перед подписанием. При негативных событиях — стоп. |
| Полномочия подписанта | Ручная проверка доверенности или устава. Часто откладывают на последний момент. | Платформа проверяет наличие полномочий. Нет полномочий — блокировка. |
| Комплектность пакета | Ручная проверка. Под высокой нагрузкой легко пропустить документ. | Платформа блокирует переход к подписанию при неполном пакете обязательных приложений и вторичных документов. |
| Финальная версия | Версии живут в почте. Риск подписать не ту. | Платформа фиксирует финальную версию — изменить её нельзя. На подписание уходит только финальная версия. |
Подписание и ввод в действие
- Договор подписывают усиленной квалифицированной электронной подписью (УКЭП) или в порядке, установленном соглашением об ЭДО с контрагентом (Диадок, СБИС и др.).
- Подписант получает документ с автоматически сформированным резюме: контрагент, предмет, сумма, срок, схема оплаты, статус всех согласований, согласованные командой отклонения от типовых условий компании — без чтения договора целиком.
- Система блокирует редактирование после завершения согласования: подписант гарантированно получает версию, которую видели все участники маршрута.
- При бумажном подписании система фиксирует все этапы движения оригинала: отправлен, получен контрагентом, возвращён с подписью — без звонков и переписки.
- Дата, стороны, предмет, цена и ключевые условия фиксируются системой автоматически. Маршрут подписания и ввода в действие запускается автоматически.
Постдоговорный этап
Подписать договор — это только начало.
Подписать договор — это только начало. Постдоговорный этап включает контроль исполнения, приёмку и закрывающие документы, работу с дополнительными соглашениями, контроль качества и гарантийного срока, возврат обеспечения, претензионную работу при нарушении сроков поставки.
Для рамочных договоров [Рамочный] после подписания запускается повторяющийся цикл: формирование заявки на новую поставку → согласование → подписание → поставка. Здесь критичны два контроля: соответствие заявки рамочному договору по предмету и сумме и контроль исполнения по лимиту — договор может быть исчерпан, а заявки продолжают подписываться.
Постдоговорный процесс по договору поставки — самостоятельная и сложная область. Эффективно заниматься ею имеет смысл после того, как наведён порядок до подписания: собран мастер-шаблон, настроены матрица рисков и маршруты, автоматизированы подготовка, проверка, согласование и подписание.
Метрики процесса
Управлять договорным процессом и находить узкие места можно только через измерения.
Управлять договорным процессом и находить узкие места можно только через измерения ключевых метрик, которые мы приводим ниже.
Скорость
| Метрика | AS IS | TO BE | Как измеряется |
|---|---|---|---|
| Типовой договор: время от создания сделки до подписания | 7–14 раб. дн. | 1–2 раб. дн. | Дата создания сделки / подведение итогов закупки → дата подписания обеими сторонами |
| Нетиповой договор с правками контрагента: время от создания сделки до подписания | 14–30 раб. дн. | 3–4 раб. дн. | Дата создания сделки / подведение итогов закупки → дата подписания обеими сторонами |
| Время подготовки первого драфта | 1–4 ч. | < 0,2 ч. | Начало поиска шаблона → отправка на согласование |
| Среднее время проверки одного согласующего | 2–5 раб. дн. | < 1 раб. дн. | Дата отправки на этап → дата визы |
Качество
| Метрика | AS IS | TO BE | Как измеряется |
|---|---|---|---|
| Доля договоров с ошибками в реквизитах, суммах, условиях, спецификациях | ~20–30 % | < 2 % | Количество возвратов из-за ошибок |
| Доля типовых договоров с ошибками, выявленными после подписания | Не измеряется | 0 % | Дополнительная работа, претензии и споры, связанные с некорректными условиями |
| Доля заявок, не соответствующих рамочному договору [Рамочный] | Не измеряется | 0 % | Заявки с превышением лимита или предмета / все заявки |
Эффективность юридической функции
| Метрика | AS IS | TO BE | Как измеряется |
|---|---|---|---|
| Доля типовых договоров без участия юриста | 0 % | > 80 % | Доля завершённых сделок без этапа «Юрист» в маршруте |
| Время юриста на один договор (при участии) | 2–4 ч. | < 60 мин. | Тайм-трекинг или оценка загрузки команды |
| Количество шаблонов, поддерживаемых вручную | Несколько на категорию | 1 мастер-шаблон на тип договора | Инвентаризация файлов шаблонов |
Как ИТ-решение поможет управлять контрактами
Люди принимают решения, а платформа берёт на себя рутину.
Что автоматизируем, а что остаётся за человеком
Мы автоматизируем работу с договорами не для того, чтобы заменить людей. Люди принимают решения, а платформа берёт на себя рутину: сама готовит черновики, контролирует сроки и отклонения от стандартных условий сделок, а также уведомляет участников о дедлайнах, рисках и отклонениях.
| Действие | Кто выполняет | Роль системы |
|---|---|---|
| Выбор шаблона и сборка пакета приложений | Система | Автоматически по параметрам сделки: тип поставки, категория товара, схема оплаты. |
| Заполнение реквизитов и ключевых полей | Система + проверка человеком | Автозаполнение из интегрированных систем или из документов с помощью AI. Человек проверяет, а не перепечатывает. |
| Расчёт цены и НДС, сверка с тендером и спецификацией | Система | Единая методика расчёта; расхождение — предупреждение и блокировка перехода к подписанию. |
| Формирование комплекта на нескольких победителей | Система | Общие условия из шаблона, переменные части и реквизиты — из сводной таблицы тендера или протокола о подведении итогов тендера. |
| Проверка контрагента и подписанта | Система + СБ (новые контрагенты) | Автоматическая проверка по реестрам; СБ включается только для новых или проблемных поставщиков. |
| Определение маршрута согласования | Система | По матрице рисков — автоматически при создании сделки. |
| Оценка правок контрагента | Система + инициатор + юрист (по матрице) | AI классифицирует правки и даёт рекомендации, определяет маршрут. Инициатор и согласующие принимают решения, юрист проверяет только договоры с отклонениями. |
| Контроль соотносимости рамочного договора и заявок [Рамочный] | Система | Наследование условий в заявке, проверка соответствия предмету и сумме, уведомление при приближении к лимиту и блокировка заявки при превышении лимита. |
| Подписание | Уполномоченные лица + система | Блокировка финальной версии, электронное подписание, сохранение информации о подписанном договоре и его условиях в системе управления контрактами и в учётных системах. |
| Принятие решений в нестандартных ситуациях | Инициатор / юрист / финансы / руководство | Платформа показывает контекст, отклонения от стандартов и историю правок документа, а также даёт рекомендации. Решение — за человеком. |
Стек систем для автоматизации договоров поставки
| Компонент | Подход | На что обращать внимание при выборе |
|---|---|---|
| Система управления закупками | Готовое (SAP SRM, 1С:Закупки, отраслевые SRM) | Открытый API, передача итогов тендера и закупочной заявки, справочники категорий и поставщиков. |
| Платформа управления контрактами | Готовое (Doczilla или аналог) | Конструктор документов с условной логикой, маршруты согласования, AI-парсинг и оценка правок, собственный workflow и таск-менеджмент, AI-агенты, текстовый редактор, усиленный AI, интеграция по API. |
| AI-парсинг и оценка правок | Готовое — внутри платформы | Парсинг документов поставщика, сравнение редакции с шаблоном, рекомендации по каждому пункту. Точность распознавания критичных полей > 98%. |
| ERP / учётная система | Готовое (1С, SAP, Microsoft Dynamics) | Двусторонняя интеграция: автозаполнение карточки договора, учётные атрибуты, график платежей. |
| Электронная подпись и ЭДО | Готовое (Диадок, СБИС, УЦ) | Не разрабатывать самостоятельно. Интеграция по API, поддержка УКЭП и соглашений об ЭДО. |
| Мастер-шаблон договора | Настройка под себя | Собрать один раз с привлечением юриста. Заменяет несколько существующих файлов. Настраивается через конструктор, не пишется кодом. |
| Матрица рисков и маршрутов | Настройка под себя | Документируется юристом и Head of Legal. В платформе — набор правил. |
| Самописная разработка | Не рекомендуется | Собственный конструктор, AI-парсинг или шлюз почти всегда дороже и медленнее интеграции готовых сервисов. Исключение — крупные компании со специфическими требованиями и с сильной командой разработки, готовые вывести потом такой продукт на рынок. |
Карта вариативности по типам договоров
Карта показывает только то, что отличается между типами договоров поставки. Общий процесс описан в разделах выше.
| Этап процесса | Разовая поставка | Рамочный + заявки | По форме контрагента |
|---|---|---|---|
| Выбор шаблона | Типовой шаблон покупателя по параметрам сделки. | Два шаблона: рамочный договор + шаблон заявки/спецификации. | Шаблон отсутствует — юрист анализирует форму контрагента с нуля. |
| Роль юриста | Исключается при типовом договоре без отклонений. | Исключается при согласовании типовой рамки или заявки; при нестандартной заявке или рамочном договоре подключается точечно. | Обязателен с первого шага по всему тексту. |
| Согласование с контрагентом | Одна итерация по полному тексту. | Одна итерация по полному тексту. | Многократные итерации по всему тексту; история согласований критична. |
| Маршрут внутри компании | Стандартный: договорная служба / закупки → финансы → руководитель. | Стандартный для рамки; упрощённый для заявок — часто только финансы и инициатор. | Расширенный: обязательно юрист + смежные специалисты. |
| После подписания | Процесс завершён. | Повторяющийся цикл: заявка → согласование → подписание → поставка. | Процесс завершён (если не рамка). Особое внимание к архивированию нестандартной формы. |
| TO BE — что решает система | Автозаполнение по итогам тендера; расчёт цены и НДС по единой методике. | Условия рамки наследуются в заявки; проверка соответствия и лимита; уведомление при приближении к лимиту и блокировка при его превышении. | AI проверяет договор от контрагента и маркирует каждое отклонение от стандартов компании по степени риска. |
Применимость в других системах управления контрактами
Практики из этого стандарта можно внедрить в любой ИТ-системе (не только в Doczilla), которая поддерживает:
- Конструктор документов с AI, логикой ветвления и автозаполнением из справочников.
- Настройку маршрутов согласования с условиями включения и исключения участников с интеграцией матрицы рисков и маршрутов.
- Сравнение и контроль версий документов и анализ изменений в редакторе при помощи AI.
- Интеграцию с системой закупок, ERP, справочниками контрагентов и реестрами.
- Хранение всех версий, документов и истории сделки в единой карточке.
- Интеграцию с облачными или локальными большими языковыми моделями (AI) для парсинга и оценки правок.
- AI-агентную архитектуру.