Заказчик требует вернуть аванс по ИТ-контракту: когда подписанные акты не спасут исполнителя

В ИТ-проектах особенно опасно считать, что подписание промежуточных актов окончательно закрывает вопрос об оплате каждого этапа. Если по итогам разработки заказчик получает систему, которой нельзя пользоваться по назначению, ранее принятые и оплаченные работы могут снова оказаться предметом спора.

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

Именно такой подход применен в споре Росстата с НИИ «Восход», дошедшем до Верховного Суда РФ по делу № А40-278199/2021.

Автор: адвокат, кандидат юридических наук, адвокат года 2026 (РБК, Торгово-промышленная палата России) Андрей Мильский. Более 10 лет защищаю интересы бизнеса в арбитражных судах, сопровождаю ИТ-, закупочные, подрядные, корпоративные и иные коммерческие споры.

Да, если выяснится, что оплаченный результат фактически не может использоваться для той цели, ради которой заключался контракт.

В рассматриваемом споре заказчик перечислил исполнителю 185,9 млн руб. за первый этап создания Единого хранилища первичных данных Цифровой аналитической платформы.

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

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

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

Можно формально завершить:

• проектирование;

• разработку отдельных компонентов;

• настройку инфраструктуры;

• интеграцию;

• тестовый этап.

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

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

Для бизнеса это ключевое понятие.

Потребительская ценность — это не просто наличие файлов, программного кода, документации или установленного программного обеспечения.

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

Например, информационная система должна:

• обрабатывать предусмотренный объем данных;

• выполнять заявленные функции;

• взаимодействовать с другими системами;

• обеспечивать нужную производительность;

• соответствовать техническому заданию;

• реально решать поставленную бизнес-задачу.

Если система существует технически, но основной функционал не работает, формальное наличие результата может не спасти исполнителя.

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

Для серьезных последствий недостатки должны затрагивать саму возможность нормального использования результата.

Особенно рискованны ситуации, когда:

• не работает ключевой функционал;

• систему нельзя запустить в промышленную эксплуатацию;

• данные обрабатываются некорректно;

• отсутствует необходимая интеграция;

• архитектура не позволяет достичь показателей технического задания;

• устранение недостатков требует фактически переделать значительную часть системы.

Чем ближе проблема к основной цели проекта, тем выше риск расторжения и возврата оплаты.

Да, такая конструкция может применяться после расторжения контракта, если основание для сохранения ранее полученной оплаты отпало.

В споре по цифровой платформе с исполнителя взыскали 185,9 млн руб. неосновательного обогащения, а также почти 4 млн руб. неустойки.

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

Получается двойной финансовый эффект:

затраты на проект остаются у исполнителя, а деньги заказчику приходится возвращать.

Самый высокий риск возникает, когда недостатки носят не локальный, а системный характер.

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

Для этого обычно анализируются:

• техническое задание;

• функциональные требования;

• критерии приемки;

• протоколы испытаний;

• результаты тестирования;

• переписка о недостатках;

• заключения специалистов или экспертов;

• попытки устранения ошибок.

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

Главная проблема многих ИТ-контрактов — слишком общий конечный результат.

Например:

«Создание информационной системы, обеспечивающей автоматизацию процессов заказчика».

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

Лучше заранее определить:

• функционал каждого этапа;

• конкретные критерии приемки;

• измеримые показатели производительности;

• порядок тестирования;

• допустимое количество и категории ошибок;

• процедуру устранения замечаний;

• какие недостатки препятствуют приемке, а какие нет.

Тогда спор будет идти вокруг объективных критериев, а не общего впечатления заказчика о том, что «система не работает».

Недостаточно просто подписать акт.

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

Это могут быть:

• протоколы тестирования;

• сценарии приемочных испытаний;

• журналы ошибок;

• видео демонстрации;

• отчеты о нагрузочном тестировании;

• акты опытной эксплуатации;

• переписка о согласовании функционала.

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

Это одна из самых частых причин последующих споров.

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

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

Поэтому каждое значимое изменение лучше фиксировать:

• дополнительным соглашением;

• новым техническим заданием;

• протоколом согласования;

• официальной перепиской;

• изменением стоимости и сроков.

Иначе исполнитель рискует отвечать уже за требования, которых не существовало при заключении контракта.

Первое — не спорить на уровне общих формулировок.

Нужно разложить претензию на конкретный функционал:

Так можно отделить реальные нарушения от новых пожеланий заказчика.

Очень часто — да.

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

Эксперту могут поставить вопросы:

• соответствует ли система техническому заданию;

• работает ли предусмотренный функционал;

• являются ли недостатки устранимыми;

• препятствуют ли они эксплуатации;

• какой объем работ фактически выполнен;

• имеет ли результат самостоятельную ценность.

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

Одного заявления руководителя проекта недостаточно.

Нужны объективные данные:

• результаты испытаний;

• перечень критических ошибок;

• невозможность промышленного запуска;

• заключение специалистов;

• доказательства безуспешных попыток устранения недостатков;

• подтверждение того, что ключевые функции отсутствуют.

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

Это разные ситуации.

Недостаток — функция реализована неправильно.

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

Если контракт разбит на этапы, нужно очень точно определить, какой результат должен существовать после каждого из них.

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

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

Лучше, если из документов можно установить:

• какой функционал передан;

• какие испытания проведены;

• какие замечания остались;

• являются ли они блокирующими;

• допускается ли дальнейшее развитие системы;

• подтверждает ли заказчик достижение результата конкретного этапа.

Это серьезно снижает риск того, что через год заказчик объявит весь этап бесполезным.

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

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

Именно поэтому в ИТ-проектах нужно одновременно защищать три вещи:

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

Подход подтвержден Определением Верховного Суда РФ от 04.06.2026 № 305-ЭС26-4741 по делу № А40-278199/2021.