Акт по разработке должен отвечать на один вопрос: что именно вы приняли. Формулировка «услуги по договору оказаны в полном объёме, стороны претензий не имеют» отвечает на него словом «всё», и это худший из возможных ответов. Через полгода, когда отвалится обмен или всплывёт непокрытый сценарий, из такого акта нельзя установить ни что входило в этап, ни на какой версии требований работу принимали.
Обычное возражение — «бухгалтерии больше и не нужно». Это правда: для учёта расходов достаточно одной строки. Но акт по разработке выполняет вторую функцию, о которой вспоминают позже: он фиксирует границу между тем, что подрядчик чинит бесплатно по гарантии, и тем, за что выставит счёт. Эта граница проходит ровно по перечню в акте.
Ниже — минимальный состав акта, четыре приложения к нему, формулировка оговорок и разбор типичной ошибки в связке акта со счётом. Порядок самой процедуры — уведомление, сроки, протокол замечаний — разобран отдельно в материале про поэтапную приёмку в договоре; здесь речь только о документе, которым всё это закрывается.
Восемь строк минимального акта
Это не бюрократия, а перечень вопросов, которые придётся задать себе через год. Каждая строка добавляется ровно потому, что без неё возникает конкретный спор.
| Строка акта | Что в ней пишется | Какой спор она закрывает |
|---|---|---|
| 1. Договор и этап | Номер и дата договора, номер этапа по календарному плану | «Это был третий этап или часть второго» |
| 2. Версия требований | Номер и дата редакции ТЗ и приложения с приёмочными сценариями | «В той версии ТЗ этого пункта не было» |
| 3. Перечень принятых требований | Номера требований из ТЗ, вошедшие в этап, — списком, а не общей фразой | «Мы думали, выгрузка входит в этот этап» |
| 4. Перечень проверенных сценариев | Номера сценариев, дата прогона, результат по каждому | «Это никто не проверял, значит, и не принимали» |
| 5. Дата фактической передачи | День, когда результат стал доступен заказчику; она обычно раньше даты подписи | Отсчёт гарантийного срока и срока проверки |
| 6. Перечень переданного | Доступы, документация, исходники, конфигурации — со ссылкой на опись | «Доступы обещали передать потом» |
| 7. Оговорки | Незакрытые замечания с классом и датой устранения либо явное «оговорок нет» | «Мы же говорили про это на приёмке» |
| 8. Сумма и основание оплаты | Цена этапа и пункт договора, по которому она платится | «С какой даты считать срок оплаты» |
Строки 3 и 4 занимают в акте больше всего места и дают больше всего пользы. Их не пишут заново: номера требований берутся из приложения с ТЗ, номера сценариев — из протокола приёмочных проверок. Если и то и другое существует, оформление акта — это копирование двух списков и примерно два рабочих часа. Если не существует, проблема не в акте: принимать было нечего, и разбираться надо на уровне техзадания как приложения к договору.
Детализация — это граница гарантии
Заказчики иногда считают, что подробный акт выгоден только им, а подрядчик будет сопротивляться. На практике наоборот: подрядчику детализация нужна не меньше. Акт с перечнем — единственная защита от разрастания гарантийных обязательств, когда через полгода заказчик приносит требование, которого в этапе не было, и предлагает починить его бесплатно. Обе стороны выигрывают от одного и того же документа, и это редкий случай в договорной работе.
Из этого следует практический совет заказчику: если какое-то поведение системы для вас критично, оно должно быть в акте как проверенный сценарий, а не в переписке как договорённость. И совет подрядчику: не соглашайтесь на общие формулировки, даже если заказчик не настаивает. Общая формулировка позже читается против того, кто выполнял работу.
Дальше — во что обходится акт из одной строки. Модельный проект: внедрение на 2 400 000 ₽, этап «Интеграция с 1С:УТ» на 640 000 ₽, акт подписан формулировкой «работы выполнены в полном объёме». Через пять месяцев обмен перестал корректно проводить часть заказов, и выяснилось, что стороны по-разному помнят, входила ли спорная часть выгрузки в этот этап.
Никто здесь не действовал недобросовестно. Через пять месяцев участники честно помнят разное, а переписка в трёх чатах и на почте не является перечнем — её можно читать в обе стороны. Именно поэтому детализация акта окупается не на конфликтных проектах, а на обычных.
Сравнение в две колонки. Левая — «Акт из одной строки»: под ним широкая серая зона с подписью «граница гарантии не определена» и ценник «159 000 ₽ через 5 месяцев». Правая — «Акт из восьми строк»: под ним чёткая линия, выше линии подпись «покрыто гарантией: перечисленные требования и сценарии», ниже — «оценивается как новая работа», ценник «2 часа, 6 000 ₽». Между колонками вертикальная надпись «разница более чем в 25 раз». Чертёжный стиль, подписи по-русски.
Четыре приложения к акту
Сам акт остаётся коротким документом на страницу-полторы, потому что содержательная часть выносится в приложения. Их четыре, и каждое подписывается вместе с актом, а не «в течение месяца после».
| Приложение | Что в нём | Что теряется без него |
|---|---|---|
| Протокол приёмочных проверок | Номера сценариев, дата прогона, результат, класс каждого замечания | Нечем подтвердить, что проверка вообще была и что именно проверяли |
| Опись переданных доступов | Перечень учётных записей и сервисов с указанием владельца по каждому | Через полгода выясняется, что домен или репозиторий оформлены не на вас |
| Состав документации | Схема развёртывания, описание обменов, инструкции по ролям — с именами файлов | Документация «есть», но никто не может сказать, полная ли она |
| Перечень открытых замечаний | Косметические и отложенные пункты с классом и датой устранения | Мелкие недоделки исчезают вместе с памятью участников проекта |
Вторая строка таблицы — самая недооценённая. Акт подписан, деньги ушли, а через год оказывается, что часть системы держится на учётных записях подрядчика. Перечень позиций, которые обязаны быть оформлены на вас, разобран в материале про передачу доступов при завершении проекта, а полный состав пакета передачи — в статье о передаче системы в эксплуатацию.
Схема: в центре блок «Акт по этапу, 8 строк». От него вниз четыре ветки-приложения: «Протокол приёмочных проверок», «Опись переданных доступов», «Состав документации», «Перечень открытых замечаний». Вправо от акта одна стрелка с подписью «дата подписания» в блок «Счёт», от счёта — стрелка «5 банковских дней» в блок «Оплата этапа». Влево от акта стрелка в блок «Версия ТЗ и приёмочные сценарии» с подписью «откуда берутся перечни». Чертёжный стиль, подписи по-русски.
Акт с оговорками: принять и не потерять замечания
Ситуация типовая: этап в целом работает, но остались мелочи — подписи, порядок колонок, один отчёт выводится не в том формате. Отказывать в приёмке из-за этого неправильно: работа сделана, деньги подрядчик заработал. Подписывать «как есть» — значит потерять замечания. Решение — акт с оговорками, и это обычный рабочий документ, а не признак конфликта.
- 1Прямое утверждение, что работы приняты и оплата производится в полном объёме по этапу. Без этой фразы бухгалтерия и подрядчик читают документ как отказ.
- 2Перечень оговорок по номерам замечаний из протокола, с классом каждого. В оговорки идут только косметические и отложенные пункты — блокирующее замечание не оговаривают, из-за него акт не подписывают вовсе.
- 3Дата устранения по каждому пункту, а не «в рабочем порядке». Дата — единственное, что отличает оговорку от пожелания.
- 4Указание, что устранение оговорок входит в цену этапа и отдельно не оплачивается. Иначе через месяц перечень вернётся в виде коммерческого предложения.
Здесь проходит граница нашей компетенции. Как формулировка оговорки повлияет на возможность предъявить требование позже, что считается принятием без оговорок и как это соотносится с вашей конструкцией договора — вопросы юриста. Инженер отвечает за другое: чтобы каждая оговорка была привязана к номеру сценария и имела дату. Юристу стоит нести не весь договор, а акт, протокол проверок и перечень оговорок — тогда разбор занимает пару часов.
Акт, счёт и оплата: где ошибается почти каждый договор
Ошибка выглядит безобидно и встречается постоянно: оплата этапа привязана к календарной дате из графика, а не к подписанию акта. Формулировка «оплата второго этапа производится до 30 октября» означает, что платить надо независимо от того, сдан этап или нет. Дальше начинается неприятное: заказчик задерживает платёж, потому что работа не сдана, и формально становится просрочившей стороной, а не подрядчик.
- Правильная связка: «оплата производится в течение 5 банковских дней с даты подписания акта по этапу». Дата в календарном плане остаётся как плановый срок сдачи, но платёж к ней не привязан.
- Счёт выставляется после акта, а не вместе с уведомлением о готовности. Счёт, пришедший вместе с «мы всё сделали», создаёт давление и мешает нормальной проверке.
- Аванс этапа не считается приёмкой. Если в схеме есть предоплата, в договоре должно быть явно сказано, что она зачитывается при подписании акта и не означает принятия работ.
- Один акт — один этап. Соблазн закрыть два этапа одним документом в конце квартала обычно исходит от бухгалтерии, а стоит дорого: перечни склеиваются, и границу гарантии по каждому этапу восстановить уже нельзя.
Когда акт можно оставить коротким
Полный состав из восьми строк и четырёх приложений имеет смысл там, где есть что терять. В трёх случаях это избыточно, и настаивать на нём — тратить время обеих сторон.
- Разовая работа до 100 000 ₽ без последующей поддержки. Настроили выгрузку, показали, приняли. Границу гарантии здесь проще определить одной фразой: «гарантия 30 дней на работу выгрузки в описанном формате».
- Подписка на готовый сервис. Ежемесячный акт по SaaS фиксирует факт оказания услуги за период, и детализировать в нём нечего: вы не принимаете результат разработки, вы платите за доступ.
- Работа по часам с открытым объёмом. Принимать нечего по определению — принимается отчёт о затраченном времени. Здесь важна не детализация акта, а лимит часов и право остановиться, и это другой разговор.
И честное ограничение по всему материалу: аккуратный акт не делает работу лучше. Он делает её описанной. Если сценарии не прогонялись, а перечень в акт переписали из коммерческого предложения, документ будет выглядеть безупречно и не значить ничего. Порядок проверки, при котором перечни заполняются по факту, разобран в чек-листе приёмки этапа; акт — это его результат, а не замена.
