Акт выполненных работ по разработке сайта - единственная бумага, которая доказывает, что проект закрыт и деньги отработаны честно. За последние пару лет я вёл десятки проектов на Tilda, WordPress и кастомных стеках, и почти в трети случаев заказчик подписывает акт не глядя, а через месяц присылает список претензий, которых не было в техзадании. Разбираю, что обязательно прописать в акте, как принимать проект по этапам и что делать, если исполнитель настаивает на подписи раньше времени.
Зачем акт выполненных работ нужен даже для лендинга на Tilda
Кажется, что для лендинга за 30 000 ₽ формальности ни к чему: обсудили в переписке, оплатили, сайт работает. Проблема всплывает через пару месяцев, когда заказчик хочет доработку бесплатно, ссылаясь на то, что «так и договаривались». Без подписанного акта у меня нет документа, который фиксирует объём работ на дату сдачи, и спор превращается в перечитывание переписки в Telegram, где формулировки всегда можно трактовать по-разному.
По статье 720 ГК РФ заказчик обязан принять результат работы и в разумный срок заявить об обнаруженных недостатках, иначе теряет право ссылаться на них позже. Акт - это как раз тот момент, когда фиксируется дата приёмки и состояние сайта. Без него отсчитывать этот срок не от чего, и претензия может прилететь спустя полгода по функциям, которых вообще не было в техзадании.
Что обязательно входит в акт приёмки сайта
Акт из одной фразы «работы выполнены в полном объёме, стороны претензий не имеют» не защищает ни исполнителя, ни заказчика. В документе должно быть:
- реквизиты сторон и номер договора, к которому привязан акт;
- перечень выполненных работ построчно, а не общей фразой - дизайн, вёрстка, интеграции указываются отдельными пунктами;
- ссылка на итоговый результат: боевой домен, доступ к админке, репозиторий с кодом;
- сумма и порядок расчёта, включая уже внесённую предоплату;
- срок, в течение которого заказчик может предъявить претензии по скрытым недостаткам - обычно 5-10 рабочих дней;
- подписи, дата и способ подписания (бумага, скан, ЭДО).
Если проект небольшой и делается по договору оферты, акт можно упростить до одной страницы, но перечень работ построчно всё равно нужен - это единственное, что потом можно предъявить, если возникнет спор о том, что именно было сделано.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как принимать этапы: дизайн, вёрстка, интеграции
На крупных проектах - веб-сервисах от 300 000 ₽, интернет-магазинах от 80 000 ₽ - я разбиваю работу на этапы и подписываю акт на каждый, а не жду финала. Так заказчик не копит претензии до конца проекта, а я не завишу от одной итоговой подписи, которую могут тянуть неделями.
Проверка каждого этапа зависит от того, что именно сдаётся. Интеграцию эквайринга T‑Bank в WooCommerce я не закрываю актом, пока не пройдёт тестовый платёж и возврат средств на реальную карту - в логах платёжного шлюза видно статус транзакции, и это прикладывается к акту как подтверждение. С доставкой СДЭК то же самое: смотрю расчёт стоимости по реальному адресу, а не по тестовому индексу из документации. Бота на aiogram проверяю по всем командам из сценария, включая обработку ошибок ввода, а не только счастливый путь. Автоматизацию в n8n тестирую на реальных данных из CRM, а не на тестовом вебхуке с подставными значениями - именно там чаще всего вылезают расхождения в форматах полей.
Чек-лист перед подписью
- все пункты техзадания отмечены как сделанные, а не «частично» или «в процессе»;
- переданы доступы к хостингу, админке и репозиторию под своим логином, а не под моим;
- тестовые платежи, формы и интеграции прогнаны на реальных данных;
- мобильная версия проверена отдельно, а не только десктоп;
- сделан экспорт или бэкап базы на момент сдачи.
| Этап | Что проверяю перед подписью | Что фиксирую в акте |
|---|---|---|
| Дизайн-макет | Соответствие ТЗ и брендбуку по всем экранам | Ссылку на макет и список утверждённых страниц |
| Вёрстка и фронтенд | Адаптивность, скорость загрузки, поведение в разных браузерах | Ссылку на тестовый домен и перечень готовых страниц |
| Интеграции (эквайринг, СДЭК, бот) | Реальный тестовый платёж, расчёт доставки, работу команд бота | Дату проверки и статус тестовых операций |
| Финальная сдача | Перенос на боевой домен, SSL, работу всех форм | Итоговый URL и дату передачи доступов |
Типичные ошибки при подписании акта, из-за которых теряют деньги
- Подписывают акт до того, как получили доступы к хостингу и админке - потом договориться о передаче становится сложнее, а рычагов давления уже нет.
- Принимают формулировку «работы выполнены в полном объёме» без перечня - при споре невозможно доказать, что именно входило в объём.
- Не фиксируют срок предъявления претензий - через полгода баг уже нельзя оспорить формально, но переписку с требованиями заказчик всё равно ведёт.
- Закрывают актом всю предоплату, хотя фактически сделана только часть этапа - разница потом всплывает при расчёте итоговой суммы.
- Не сверяют акт с итоговым счётом - суммы расходятся, и бухгалтерия одной из сторон отказывается проводить оплату.
Акт, УПД или оплата по счёту: как оформить закрытие проекта
Не для каждой задачи нужен полноценный акт. Разовую консультацию по архитектуре сайта я обычно закрываю счётом без отдельного акта - формальности здесь избыточны. А вот доработку или интеграцию всегда фиксирую документом, даже если она небольшая.
| Документ | Когда применяю | Что подтверждает |
|---|---|---|
| Акт выполненных работ | Разработка сайта, доработки, интеграции | Факт приёмки конкретного перечня работ |
| УПД | Заказчик на ОСН и работает с НДС | То же самое, плюс основание для налогового вычета |
| Оплата по счёту без акта | Разовая консультация или мелкая правка | Только факт платежа, без защиты от споров о качестве |
Консультация у меня стоит от 3 000 ₽ и обычно закрывается именно счётом - объём работы там оценить актом сложнее, чем зафиксировать сам факт платной консультации.
Что делать, если заказчик не подписывает акт
Если в договоре прописан срок на подписание или мотивированный отказ (обычно 5-10 рабочих дней), а заказчик молчит, акт можно закрыть односторонне - это законно, если условие заранее согласовано в договоре. Я отправляю акт по ЭДО или заказным письмом, фиксирую дату отправки и жду ответа. Если мотивированный отказ так и не пришёл, работы считаются принятыми.
Если заказчик просит доработки, которых не было в исходном техзадании, я не тяну старый акт на них, а оформляю отдельное допсоглашение с новой оценкой. Иначе объём работ по проекту размывается, а вместе с ним и ответственность за сроки. Если после сдачи нужна регулярная поддержка сайта - правки, мониторинг, обновления библиотек - оформляю это отдельным договором на техническую поддержку, а не довеском к акту по основному проекту.
Частые вопросы
Нужен ли акт, если сайт делали по переписке в мессенджере?
Да. Переписка в Telegram или WhatsApp не считается формальным документом о приёмке, даже если там есть фраза «всё устраивает». Для защиты обеих сторон нужен отдельный документ с подписью - на бумаге, сканом с подписью или через ЭДО.
Можно ли подписывать акт, если на сайте остались мелкие баги?
Можно, но с приложением - списком оставшихся замечаний и сроком их устранения. Тогда акт не описывает работу как выполненную «в полном объёме без замечаний», и у обеих сторон остаётся понятная точка отсчёта по оставшимся правкам.
Что делать, если исполнитель просит подписать акт до передачи доступов к хостингу?
Не подписывать. Доступы к хостингу, админке и домену - часть результата работы, а не бонус после подписи. Если акт подписан раньше, требовать доступы становится сложнее: формально работы уже приняты.
Как оформить акт при поэтапной приёмке большого проекта?
На каждый этап отдельный акт со ссылкой на договор и номер этапа. Финальный акт по проекту ссылается на все промежуточные и фиксирует, что работа завершена целиком, включая перенос на боевой домен и передачу всех доступов.