Как проверить график платежей в договоре на разработку ПО для защиты от срыва сроков

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

Контракт с календарной привязкой траншей выглядит простым: 1-е число месяца — перечисление, независимо от того, что реально сделано. Заказчик теряет рычаг влияния на второй-третий месяц, когда обнаруживается, что подрядчик отстаёт от плана, но деньги уже перечислены за два-три этапа вперёд.

Типичная ситуация: бюджет 4 млн рублей, график — равными долями по 800 тыс. каждый квартал. К концу второго квартала перечислено 1,6 млн, а реально готов только технический дизайн и часть backend-логики. Подрядчик получает «подушку» и теряет стимул ускоряться. Юридически взыскать неустойку можно, если она прописана, — но обычно штрафные санкции в типовых договорах составляют 0,1 % в день от суммы просрочки, что при 800 тыс. даёт всего 24 тыс. за месяц. Это не компенсирует даже аренду команды на стороне заказчика.

Что именно ломается при календарном графике:

• Нет связи между деньгами и измеримым результатом — невозможно доказать, что этап не выполнен.

• Проектное управление уходит в формальность: статус-встречи превращаются в отчёты вместо контроля.

• При расторжении договора у заказчика нет чёткого перечня артефактов, за которые уже заплачено.

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

По данным отраслевых обзоров 2024 года, более 60 % проектов по разработке ПО, завершившихся спором в досудебном или судебном порядке, имели именно календарную модель оплаты без привязки к milestone.

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

---

Критерии проверки графика платежей на соответствие этапам разработки

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

1. Каждый транш привязан к named-артефакту.

Артефакт — не «завершение первого этапа», а конкретный объект: «UI-kit в Figma, согласованный заказчиком», «backend API v0.9, покрытый автотестами на 70 %+», «сборка staging-среды с деплоем на тестовый сервер». Если в приложении к договору написано «этап 1 — проектирование», потребуйте расшифровки: какие именно deliverable передаются.

2. Для каждого артефакта указаны приёмочные критерии.

Критерии должны быть проверяемыми: не «качественный интерфейс», а «все экраны из мактов верстки проходят верификацию в BrowserStack на разрешениях 1920×1080, 1366×768 и 375×812; отклонения от макта не более 2 px». Для backend — покрытие unit-тестами не ниже 70 % (замер через SonarQube или аналог).

3. Объём аванса не превышает 30 % от общей стоимости.

Для проектов до 3 млн рублей аванс 25–30 % нормален — подрядчик закупает лицензии, резервирует ресурс. Свыше 30 % на старте оправдано только при высокой стоимости инфраструктуры (собственные серверы, лицензии на enterprise-компоненты). Для типового SaaS-проекта на 5 млн рублей аванс свыше 1,5 млн — перебор.

4. Последний транш — не менее 10 % и привязан к UAT.

Финальный платёж блокирует незакрытые дефекты. Приёмка (User Acceptance Testing) проводится в течение 10–15 рабочих дней после передачи релизной сборки. Если за это время заказчик не направил мотивированный отказ с перечнем дефектов, этап считается принятым. Условие должно быть прямо в договоре.

5. Сроки оплаты после подписания акта — не менее 10 рабочих дней.

Стандарт для B2B-контрактов: 10–15 рабочих дней на оплату после подписания акта приёмки. Если подрядчик требует оплату в течение 3 рабочих дней, это создаёт кассовый разрыв у заказчика и не обосновано ничем, кроме желания быстрее получить деньги.

6. Валюта платежа и курсовые риски распределены.

Если подрядчик выставляет счёт в долларах или евро, в договоре должен быть зафиксирован курс (например, курс ЦБ РФ на дату выставления счёта или на дату оплаты) и сторона, несущая курсовые риски. Для контрактов свыше 2 млн рублей курсовая разница может составить 5–12 % за квартал — это значимая сумма.

7. Условия переноса сроков оплаты при просрочке этапа подрядчиком.

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

---

Таблица проверки: сопоставление траншей с артефактами разработки

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

Как читать таблицу:

• Если подрядчик предлагает структуру, где аванс — 40 %, а финальный транш — 5 %, пересчитайте: риски заказчика увеличиваются, а рычаг — уменьшается.

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

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

---

Риски размытых формулировок в разделе оплаты и способы их нейтрализации

Формулировки в договоре — это не бюрократия, а инструкция арбитру на случай спора. Вот типовые ловушки и конкретные контрмеры.

«Оплата после завершения этапа»

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

Контрмера: замените на «Оплата в течение 10 рабочих дней после подписания обеими сторонами Акта приёмки результатов этапа N. Подрядчик передаёт Акт не позднее 3 рабочих дней после устранения замечаний, указанных в Протоколе проверки».

«Подрядчик вправе приостановить работы при задержке оплаты»

Проблема: подрядчик приостанавливает работу из-за просрочки оплаты на 1 день, а потом ссылается на эту паузу, чтобы обосновать срыв собственных сроков.

Контрмера: укажите порог — «при задержке оплаты более 15 рабочих дней» — и обязанность письменно уведомить заказчика за 5 рабочих дней до приостановки.

«Стоимость этапа может быть пересмотрена»

Проблема: подрядчик пересчитывает стоимость в одностороннем порядке, ссылаясь на изменение объёма работ.

Контрмера: «Изменение стоимости допускается только по письменному Дополнительному соглашению, подписанному обеими сторонами, с указанием объёма дополнительных работ и обоснования изменения цены. Без ДС работы не оплачиваются сверх согласованной сметы».

«Приёмка в течение 5 рабочих дней»

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

Контрмера: увеличьте до 10–15 рабочих дней. Для крупных этапов — до 20. Укажите, что «молчание заказчика не является принятием результата» — это ключевая формулировка.

«Штрафные санкции — 0,01 % в день»

Проблема: 0,01 % от 1 млн рублей — это 100 рублей в день. За месяц просрочки — 3 000 рублей. Это не мотивирует подрядчика.

Контрмера: договоритесь о 0,1–0,5 % в день от стоимости просроченного этапа, но не более 10–15 % от общей стоимости контракта. Для проекта на 4 млн рублей при 0,1 % в день просрочка этапа в 1 млн обойдётся подрядчику в 300 тыс. за 30 дней — ощутимо.

---

Когда стоит отказаться от авансовой системы в пользу поэтапной оплаты

Авансовая система не универсальна. Есть чёткие условия, при которых стоит перейти на поэтапную оплату без аванса или с минимальным авансом (до 10 %).

Случай 1: бюджет проекта свыше 5 млн рублей и срок — более 6 месяцев.

При длительном проекте аванс 25 % — это 1,25 млн рублей, замороженных у подрядчика на полгода и более. Если подрядчик не справится и потребуется смена команды, возврат аванса — судебная процедура на 3–6 месяцев. Решение: аванс 10 % + первый платёж после передачи технического задания и UI-kit (2–3-я неделя проекта).

Случай 2: подрядчик — новая для вас компания без рекомендаций.

Если вы не работали раньше и не получили три независимые рекомендации от реальных клиентов с проектами аналогичного масштаба, минимизируйте аванс до 5–10 % и перенесите основные транши на более поздние milestone.

Случай 3: проект содержит R&D-компонент (ML-модели, нестандартные интеграции).

Когда результат заранее не гарантирован, авансовая система финансирует неопределённость. Структурируйте оплату так: первый транш — на proof of concept (4–6 недель), второй — на решение об инвестиции в полную разработку. PoC стоит 10–15 % от бюджета и даёт ответ: технически ли реализуема задача.

Случай 4: параллельная работа нескольких подрядчиков.

Если frontend и backend разные команды, аванс каждой — это двойная заморозка средств. Перейдите на единую milestone-модель: оплата за интегрированный результат на каждом этапе.

Что теряется при отказе от аванса: подрядчик может поставить вас в очередь при нехватке ресурсов — у заказчиков с авансом приоритет выше. Компенсируйте это: зафиксируйте в договоре состав команды и загрузку (не менее 0,5 FTE на ключевых специалистах).

---