Разработчик написал код, отправил счета и несколько месяцев обсуждал работу с заказчиком в Telegram. В репозитории осталось 392 коммита. Но когда дело дошло до суда, взыскать оплату не получилось.
Эта история показывает проблему, которая возникает в IT-проектах. Разработчики считают главным доказательством сам результат: вот код, вот рабочая система, вот история изменений. Заказчики смотрят в договор и отвечают: акт мы не подписывали, этап не принимали.
Иногда суд действительно поддерживает заказчика. Иногда подписи на акте нет, но платить всё равно приходится. Бывает и третий вариант: исполнитель оформил даже односторонний акт, а денег всё равно не получил.
392 коммита, которые не помогли взыскать деньги
Один из самых свежих примеров - дело № А56-47032/2025. Кассация по нему состоялась 27 августа 2026 года.
Индивидуальный предприниматель почти два с половиной года работал с ООО "ЮДС Медиа" по договору разработки программного обеспечения. Что именно представлял собой продукт, из опубликованного судебного акта не видно: договор был рамочным, а конкретный объём, сроки и стоимость стороны должны были определять в отдельных заданиях.
Оплата была почасовой. Изначально час разработки стоил 1 500 рублей, а с апреля 2022 года ставку подняли до 2 000 рублей. Заказчик должен был перечислять деньги каждые две недели за фактически отработанное время. При этом договор отдельно предусматривал, что выполненные работы оплачиваются по подписанному акту сдачи-приёмки.
Спор возник из-за работ, которые, по версии исполнителя, выполнялись с 22 мая по 11 сентября 2023 года. Разработчик представил собственные отчёты по задачам с указанием затраченного времени и выставил четыре счета:
- 90 500 рублей;
- 141 500 рублей;
- 74 750 рублей;
- 173 000 рублей.
Всего - 479 750 рублей. Именно эту сумму исполнитель потребовал взыскать как основной долг. Дополнительно в иск вошли неустойка и проценты за пользование чужими денежными средствами.
Причём последний счёт на 173 000 рублей был выставлен только 10 ноября 2025 года, хотя относился к работам за период с 28 августа по 3 сентября 2023 года. То есть к моменту судебного разбирательства сторонам приходилось восстанавливать события более чем двухлетней давности.
Договор был интересен ещё одной деталью. В нём прямо говорилось, что программное обеспечение может передаваться заказчику на материальном носителе либо путём загрузки в его Git-репозиторий. Git здесь был не просто рабочим инструментом команды - стороны сами вписали его в договор как допустимый способ передачи ПО.
Исполнитель утверждал, что результат заказчику передан, и ссылался на 392 коммита, переписку в Telegram, выставленные счета и предыдущую практику расчётов.
Но договор отдельно описывал процедуру приёмки работ и связывал расчёты с актами. Исполнитель не смог показать, что по спорному объёму он запустил эту процедуру так, как стороны заранее договорились. Акты по этим работам заказчику не направлялись.
Возник и ещё один неприятный для разработчика вопрос: можно ли вообще доказать, что заказчик поручал выполнить именно тот объём работ, за который теперь требовали деньги?
Для почасовой разработки это принципиально. Сам по себе факт, что программист что-то делал в проекте, ещё не означает, что заказчик заказал каждую из этих работ и согласился оплачивать соответствующие часы.
Исполнитель пытался опереться на переписку и сложившуюся практику. Суд не увидел доказательств того, что стороны отказались от предусмотренной договором процедуры и заменили её схемой "коммиты + счёт = принятые работы".
В иске отказали.
Получился на первый взгляд парадоксальный результат: договор признавал Git способом передачи программы, код в репозитории был, сотни коммитов тоже были, а доказать возникновение обязанности оплатить спорный объём не удалось.
Передать код технически и предъявить результат к приёмке юридически - не обязательно одно и то же.
А если подписи на акте нет, но системой уже пользуются?
Дело № А56-38685/2024 касалось разработки веб-платформы для предпринимателей. В апреле 2026 года Суд по интеллектуальным правам оставил в силе решения о взыскании с заказчика 4 992 000 рублей.
Подписи заказчика на спорных актах тоже не было, но набор доказательств был.
Исполнитель не просто утверждал, что где-то существует написанный им код. Суд видел работающий сайт, передачу административного доступа, демонстрации продукта, переписку в Telegram и фактическое использование платформы заказчиком. Часть интернет-доказательств дополнительно зафиксировали нотариально.
По дополнительному объёму исполнитель направил заказчику акт и архив с материалами через EMS.
Двусторонне подписанного акта не было. Но исполнитель со своей стороны акт и результат направил.
Договор предоставлял заказчику срок на проверку и мотивированные возражения. Если в этот срок отказ не поступал, результат считался принятым.
При такой совокупности доказательств версия о том, что результат заказчику не передавался, суд не убедила. У компании был работающий ресурс, административный доступ и фактический контроль над продуктом, а исполнитель подтвердил направление документов и материалов.
СИП сослался в том числе на общую позицию Верховного Суда: акт является привычным и удобным доказательством выполнения работ, но не единственным. И здесь есть оговорка. Первоначально эта позиция появилась не в споре программистов, а в строительном деле. В 2026 году Суд по интеллектуальным правам применил тот же подход уже к спору о разработке веб-платформы.
Поэтому формула "нет подписи на акте - платить не нужно" работает далеко не всегда. Если исполнитель доказал сам результат, его передачу и запуск предусмотренной договором процедуры приёмки, а заказчик получил возможность пользоваться системой и не заявил вовремя предусмотренных договором возражений, отсутствие второй подписи может перестать быть решающей в споре.
Когда не помогает односторонний акт
Дело № А67-4626/2024 показывает обратную ситуацию.
Исполнитель разрабатывал онлайн-сервис бронирования. По основной части проекта задолженность действительно удалось взыскать, но отдельно возник спор ещё по одному сервису - INNBIVI. За него потребовали 1 144 000 рублей.
У исполнителя был односторонний акт. В нём указывались 572 часа работ, документ направлялся заказчику через электронный документооборот. На первый взгляд такая позиция даже сильнее, чем у разработчика с 392 коммитами: здесь есть не просто код, а оформленный документ о сдаче.
Именно эти 1,144 млн рублей суд во взыскание не включил.
Исполнитель не смог убедительно показать, какой дополнительный результат стороны согласовали, в каком виде он был создан и каким образом передан заказчику. Позднее стороны оформляли передачу исходного кода по проекту, однако спорный сервис в соответствующем документе отдельно не фигурировал.
К моменту судебного разбирательства не оказалось и надёжно сохранённой версии продукта, которую можно было бы исследовать и сопоставить с требованиями сторон.
Односторонний акт остался, а самого результата, который за этим актом должен был стоять, доказать не получилось. При этом по другим этапам проекта доказательств хватило, и суд взыскал 2 555 000 рублей задолженности.
Отсюда получается практичное правило:
односторонний акт может защитить исполнителя от уклонения заказчика, но не способен превратить непереданный или неопределённый результат в выполненную работу.
Как выглядит приёмка в T&M-проекте
Не все IT-проекты вообще похожи на классический подряд. Есть команды, где заказчик каждую неделю меняет приоритеты, добавляет задачи в backlog, оценивает их вместе с разработчиками и оплачивает фактически затраченное время.
Такая ситуация рассматривалась в деле № А40-30042/2024 по разработке мобильного приложения "Честный знак Бизнес".
Юридически суд характеризовал договор как смешанный, поэтому называть его просто T&M-договором было бы не совсем точно. Но фактически проект строился по знакомой T&M-механике: задачи велись в Jira, заказчик участвовал в определении приоритетов, по задачам согласовывались оценки, учитывались часы специалистов, использовались электронная почта и Telegram.
Договор предусматривал, что после предъявления результата у заказчика есть пять рабочих дней на мотивированный отказ. Если такого отказа нет, работы считаются принятыми.
Заказчик прислал письмо с вопросами и замечаниями, но суд не признал его тем мотивированным отказом, который предусматривал договор: в нём не было достаточно конкретного перечня недостатков предъявленного результата.
В итоге с заказчика взыскали 2 901 738 рублей.
Этот спор интересно сопоставить с историей про 392 коммита. Оба проекта были далеки от модели "один раз написали ТЗ - через три месяца принесли готовую программу". Однако в первом случае цифровые следы не позволили связать спорные трудозатраты с нормальной процедурой сдачи, а здесь Jira, согласованные оценки, часы, акты и договорный порядок работы сложились в доказательственную цепочку.
Установили программу - значит внедрили?
Ещё один свежий спор хорошо показывает разницу между установкой программы и полноценным внедрением. В деле № А49-10227/2025 заказчиком выступала медицинская организация - ООО "МРТ на Мальцева", а исполнителем ООО "АрхиМед Плюс". В апреле 2024 года они заключили договор на внедрение медицинской информационной системы ArchiMed+.
Речь шла не просто об установке программы на сервер. Исполнитель должен был установить продукт, собрать вместе с сотрудниками клиники необходимую для его работы информацию и обучить персонал. В спецификации было 19 позиций: сама платформа, рабочие места регистратора, врача, процедурной медсестры и менеджера по работе с юрлицами и ДМС, онлайн-запись, интеграция с СберЗдоровьем, ЕГИСЗ и лабораторной системой "СитиЛаб", а также несколько отдельных модулей. Среди них - "Интеграция с IP-телефонией + CRM". Общая стоимость договора составляла 523 360 рублей, и заказчик перечислил эту сумму полностью уже 16 апреля 2024 года.
Договор при этом разделял два разных события. После установки программы стороны должны были оформить акт передачи права пользования, а после завершения всего внедрения - отдельный акт сдачи-приёмки внедрения. На его подписание или мотивированный отказ заказчику отводилось три рабочих дня.
Исполнитель ссылался на то, что программа установлена, а лицензионный ключ активирован. Однако одного из согласованных элементов - модуля интеграции с IP-телефонией и CRM - в системе не оказалось. В ноябре 2024 года клиника потребовала установить и запустить этот модуль в течение 14 дней. Требование не выполнили, и в декабре заказчик отказался от договора.
Сам исполнитель позднее признавал отсутствие этого модуля, но настаивал, что остальные части ArchiMed+ способны работать самостоятельно, и даже предлагал вернуть только стоимость недостающего компонента. Суды с этим не согласились. Для заказчика ценность имел именно комплектный продукт, а доказательств того, что поставленная часть системы могла нормально использоваться медицинской организацией без отсутствующего модуля, исполнитель не представил.
Не помог и скриншот с установленной программой и активированным ключом. Суд указал: установка ПО и активация лицензии сами по себе не подтверждают исправную работу всего комплекса и возможность использовать его по назначению. Тем более что отдельный акт сдачи-приёмки работ по внедрению исполнитель вообще не составлял и заказчику не направлял.
В результате заказчик потребовал вернуть все 523 360 рублей как неотработанный аванс, а также 90 895,12 рубля процентов за пользование его деньгами за период с 16 апреля 2024 года по 20 марта 2025 года - с дальнейшим начислением процентов до фактического возврата. Итого на момент уточнения иска требования составляли 614 255,12 рубля. Первая инстанция удовлетворила иск полностью, апелляция поддержала решение, а 1 сентября 2026 года Арбитражный суд Поволжского округа оставил судебные акты в силе.
Установить продукт и внедрить систему - разные результаты.
Что происходит с такими спорами непосредственно в 1С
Есть и более прямой пример - дело № А76-25599/2023, связанное уже непосредственно с 1С.
Заказчиком было Челябинское монтажно-наладочное управление "Спецэлеватормельмонтаж", исполнителем - "Центр сопровождения 1С-Рарус Челябинск". Помимо лицензионного договора на "1С:Управление нашей фирмой 8 на 5 пользователей", стороны заключили отдельный рамочный договор на адаптацию программных продуктов на платформе "1С:Предприятие" под бизнес-процессы заказчика.
Работы шли не одним большим этапом, а отдельными заданиями. В каждом должны были фиксироваться состав работ, сроки, стоимость и критерии приемки. За период с февраля 2022-го по март 2023 года стороны оформили 25 таких заданий.
Среди претензий, которые заказчик позднее предъявлял в суде, были некорректный перенос данных из заказа покупателя в заказ на производство, проблемы синхронизации УНФ и бухгалтерского учета, ошибки со складами при выгрузке документов, некорректный расчет НДС и непопадание "заказ-наряда" в 1С:Бухгалтерию.
Всего заказчик уже оплатил работы по 23 заданиям на сумму 2 190 300 рублей. Неоплаченными остались задания № 18 и 25 - именно по ним "1С-Рарус" потребовал еще 231 000 рублей.
Договор предусматривал схему приемки: после завершения очередного задания исполнитель направляет акт, а у заказчика есть пять рабочих дней, чтобы либо подписать его, либо представить письменный мотивированный отказ. Если в установленный срок такого отказа не поступало, работы считались принятыми.
Когда спор дошел до суда, заказчик занял жесткую позицию. Он заявил, что программный продукт фактически не работает, и потребовал уже встречным иском вернуть все ранее уплаченные 2 190 300 рублей.
Суд предложил сторонам провести совместное обследование системы.
Часть замечаний во время обследования заказчик не продемонстрировал вообще. По документам - приходным и расходным накладным, выпуску продукции и движениям денежных средств - заказчик отказался показывать данные, на которых можно было бы проверить заявленные проблемы. Основной список претензий появился уже на следующий день после осмотра.
Суд отдельно обратил внимание и на то, что заказчик не смог нормально связать многие поздние претензии с конкретными заданиями, которые выполнял подрядчик. А это было принципиально: договор был рамочным, и каждое из 25 заданий представляло собой самостоятельный объем работ со своим предметом и критериями приемки.
Кроме того, значительная часть работ состояла вообще не в программировании, а в консультациях конечных пользователей. Проверить спустя год, насколько качественно была проведена конкретная консультация, гораздо сложнее, особенно если во время ее оказания заказчик претензий не предъявлял.
В итоге суд взыскал с заказчика 231 000 рублей задолженности и еще 5 629,43 рубля процентов. В удовлетворении встречного требования о возврате 2 190 300 рублей отказали. Апелляция и кассация этот вывод сохранили.
Что в итоге имеет значение
Все эти споры сводятся не к поиску одного "правильного" документа. Суду приходится восстанавливать весь путь результата: что именно заказал заказчик, какой результат должен был получить, что разработчик действительно создал и передал, как договор предписывал предъявить работу к приёмке и что стороны сделали после передачи.
Для разработчика наиболее безопасная схема: сохранить постановку задачи, зафиксировать сдаваемую версию, передать её согласованным способом, отдельно сообщить о готовности к приёмке и направить документы, которые требует договор. Если заказчик действительно пользуется системой, полезно сохранить и следы такого использования.
Заказчику, со своей стороны, лучше не рассчитывать на стратегию "просто ничего не подпишем". Если результат не соответствует ТЗ, необходимо вовремя отправить конкретные замечания и сохранить ту версию системы, на которой они воспроизводились.