Акт выполненных работ на разработку сайта или программы: что в нём должно быть и какие документы ещё попросить

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

Зачем акт заказчику, если сайт и так работает?

Акт — единственный документ, который фиксирует, что именно вы приняли, когда и за какие деньги. Без него нельзя закрыть договор, оплатить остаток по правилам договора и отсчитать гарантию. Работающий сайт доказывает только то, что он работает сегодня.

В типовом договоре Roboweb, который можно скачать на странице типовых договоров, от акта зависят три вещи:

• Окончательный расчёт. Вторые 50 % оплачиваются в течение 3 рабочих дней с даты подписания акта (п. 2.2).
• Гарантия. Ошибки по вине исполнителя исправляются бесплатно 30 календарных дней с даты акта (раздел 7).
• Фиксация результата. В акте сказано, что результат, исходный код и доступы переданы, — это ваша опора, если потом выяснится, что чего-то нет.

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

Какие реквизиты обязательны в акте?

Единой формы акта на разработку нет — форму определяет руководитель компании. Но акт — первичный документ, и в нём должны быть семь реквизитов из закона о бухучёте: название, дата, кто составил, содержание работ, сумма, должности и подписи с расшифровкой.

Список дан в ч. 2 ст. 9 Федерального закона № 402-ФЗ. В переводе на акт по разработке это выглядит так:

1. Название документа — «Акт сдачи-приёмки выполненных работ» и ссылка на договор: номер и дата.
2. Дата составления. Пустая строка «___ 20__ г.» — частая причина споров о сроках.
3. Кто составил — наименование организации или ИП, составивших документ; в акте обычно указывают обе стороны так же, как в договоре.
4. Содержание — что сделано. Об этом подробнее ниже: это главная часть акта.
5. Сумма в рублях — по строкам спецификации и итог.
6. Должности подписантов: директор, индивидуальный предприниматель, представитель по доверенности.
7. Подписи с фамилиями и инициалами. Подпись без расшифровки — незаполненный обязательный реквизит.

Здесь мы разбираем акт как документ сдачи работ. Как сайт отражается в учёте, подробно написано в статье о расходах на разработку и нематериальных активах.

Как написать перечень работ, чтобы акт что-то доказывал?

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

В типовом договоре Roboweb состав работ задают два приложения: техзадание и спецификация со стоимостью, а акт — третье приложение — ссылается на оба. Это удобно: не нужно заново описывать функциональность, достаточно указать, что работы выполнены «в соответствии с ТЗ и спецификацией», и привести строки спецификации с суммами.

Что полезно добавить, если объём не совсем стандартный:

• адрес, где размещён результат: домен рабочего сайта или тестовый адрес, если запуск позже;
• версию или дату последнего изменения в репозитории — чтобы понимать, какое состояние кода принято;
• доработки сверх ТЗ отдельной строкой со ссылкой на допсоглашение: без него такие работы не входят в договор, и спорить о них потом сложно (п. 2.3 нашего договора: объём меняется только соглашением сторон);
• что из ТЗ не сделано по договорённости и почему — например, раздел перенесли на следующий этап.

Ниже — типичные формулировки и как их исправить.

Как написано	Чем плохо или хорошо	Как исправить
«Работы по разработке сайта выполнены»	Плохо: непонятно, какие работы и в каком объёме. Через полгода не докажете, что форма оплаты входила в заказ	«Работы по разработке корпоративного сайта по Техническому заданию и Спецификации (приложения 1 и 2) к Договору № … от …»
«Услуги оказаны в полном объёме»	Плохо: если договор говорит о работах и результате, «услуги» в акте расходятся с договором и не показывают, что именно вам передали	«Работы выполнены, Результат работ передан Заказчику» и список того, что передано
«Сайт сдан»	Плохо: ни адреса, ни версии. Неясно, что именно вы приняли	«Сайт размещён по адресу https://… на хостинге Заказчика; исходный код — в репозитории Заказчика …, версия от …»
Перечень строк из Спецификации с суммой по каждой	Хорошо: видно, за что платите, и легко сверить с договором	Оставить; если были доработки сверх ТЗ — отдельной строкой со ссылкой на допсоглашение
«Заказчик претензий не имеет»	Нормально, если вы действительно всё проверили. Если замечания остались — фраза работает против вас	Подписывать после проверки. Если оставляете мелочи на гарантию — перечислить их в акте с отдельным сроком
Дата пустая или «___ 20__ г.»	Плохо: от даты акта зависят срок оплаты остатка и срок гарантии	Ставить фактическую дату подписания; если подписываете электронно — дату подписи
«Права на сайт переданы Заказчику»	Опасно: может не совпадать с разделом о правах в договоре — и тогда документы противоречат друг другу	Ссылка на нужные пункты договора о правах, без пересказа своими словами

Как дата акта влияет на оплату и гарантию?

Дата подписания акта запускает два срока: окончательный расчёт и гарантию. Если акт не подписан и отказа нет, ориентиром становится день, когда истекли 5 рабочих дней на приёмку. Поэтому дату нужно ставить фактическую, а не «как удобно бухгалтерии».

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

• Вы проверили сайт и подписали акт в четверг. С четверга идут 3 рабочих дня на оплату остатка и 30 календарных дней гарантии.
• Вы не ответили. Пять рабочих дней истекли в следующий понедельник — работы считаются принятыми, и оба срока считаются от этой даты.
• Вы прислали мотивированный отказ со списком замечаний. Сроки не пошли: после исправлений исполнитель присылает акт снова, и считать будут от новой даты подписания.

Две частые ошибки. Первая — подписать акт задним числом, «чтобы закрыть месяц»: гарантия при этом фактически сокращается. Вторая — подписать раньше, чем проверили, потому что так попросили. Как проверять результат за отведённые дни, мы разобрали в статье как принять сайт у разработчика; здесь не будем повторяться. Что считается ошибкой по гарантии, а что новой задачей, — в статье о гарантии на разработку.

Нужен ли акт по этапу, если оплата 50/50?

Нет. При схеме 50/50 первая половина оплачивается по договору, без акта, а вторая — после одного итогового акта. Акты этапов нужны, когда проект разбит на этапы с отдельной оплатой: тогда каждый этап закрывается своим актом.

Ориентир по длительности даёт прайс. Лендинг — от 24 000 ₽ и 2 дня, корпоративный сайт — от 56 000 ₽ и 3–4 дня: здесь один акт в конце. Веб-приложение — от 160 000 ₽ и от 10 дней, мобильное приложение — от 200 000 ₽ и от 2 недель: в длинном проекте стороны иногда договариваются об этапах, и тогда в спецификации появляется несколько строк со своими сроками и суммами. Как выбрать схему оплаты, разобрано в статье о предоплате и оплате по этапам.

Если акты этапов есть, следите за тремя вещами:

• Номер этапа и строка спецификации. «Принят результат этапа 2 „Личный кабинет клиента“ по строке 2 Спецификации», а не «работы выполнены».
• Промежуточный характер. Полезна фраза о том, что итоговая приёмка результата целиком проводится по итоговому акту. Тогда принятый этап не мешает заметить, что он плохо стыкуется со следующим.
• Что передано по этапу. Если код этапа уже в вашем репозитории — так и записать, со ссылкой на версию.

Что передаётся вместе с актом и как это оформить?

Вместе с актом передаются результат, исходный код, доступы и инструкции. Список удобно оформить отдельным приложением к акту: каждая строка — что передано, куда, на чьё имя и кто проверил. Фраза «доступы переданы» без списка почти ничего не доказывает.

По нашему договору исходный код размещается в репозитории заказчика, указанном в ТЗ, а если репозитория нет — передаётся архивом в объёме, достаточном для сборки, развёртывания и доработки (п. 5.5). В перечень обычно входят:

• репозиторий: адрес, ваша учётная запись с правами владельца, ветка и версия на дату акта;
• домен и хостинг или сервер: на кого оформлены, где лежат доступы;
• админка сайта или приложения: ваша учётная запись администратора;
• аналитика, формы, почта для заявок, платёжный модуль, CRM — что подключено и на чей аккаунт;
• для мобильного приложения — аккаунты разработчика в магазинах приложений, на которых опубликовано приложение;
• инструкция: как менять содержимое, куда приходят заявки, что делать при сбое.

Отдельно о правах. В актах иногда пишут «права на сайт переданы заказчику» — такая фраза может противоречить договору. В типовом договоре Roboweb исключительное право на программный код остаётся у исполнителя, а заказчик с даты полной оплаты получает лицензию на весь срок действия права: исходники в его репозитории, размещение на любом сервере, доработка любыми подрядчиками. Логотип, тексты и элементы фирменного стиля, созданные для заказчика, переходят к нему (пп. 5.1–5.6). Наш акт не пересказывает это своими словами, а ссылается на пункты договора. Подробнее — в статье кому принадлежит код сайта; о готовых библиотеках в коде — в статье об открытых лицензиях MIT и GPL.

Какие документы попросить, кроме акта?

Полный комплект — это договор с ТЗ и спецификацией, допсоглашения на все изменения объёма, акты этапов (если они были), итоговый акт, перечень переданного, инструкция и счета. Этого достаточно, чтобы через год любой подрядчик или проверяющий понял, что заказывали и что получили.

Порядок появления документов и что в каждом проверить:

Документ	Когда появляется	Что проверить
Договор с ТЗ и спецификацией	До старта, до предоплаты	Подписан обеими сторонами; в ТЗ есть раздел «что не входит»; указан репозиторий и аккаунты заказчика
Счёт на предоплату	После подписания договора	Сумма совпадает с процентом из договора, реквизиты исполнителя — с договором
Дополнительное соглашение	Когда меняется объём, цена или срок	Есть до начала работ сверх ТЗ, а не задним числом
Акт этапа (если проект разбит на этапы)	После проверки результата этапа	Указан номер этапа и строка спецификации; сказано, что итоговая приёмка — отдельно
Итоговый акт сдачи-приёмки	После проверки всего результата	Ссылки на ТЗ и спецификацию, сумма, дата, подписи, перечень переданного
Перечень переданных материалов и доступов	Вместе с итоговым актом	Каждая строка проверена вашим входом, а не письмом с паролем
Инструкция для администратора	Вместе с итоговым актом	Понятно, как менять контент и куда приходят заявки
Счёт на окончательный расчёт	После подписания акта	Сумма — остаток по договору плюс подписанные допсоглашения, ничего сверх

Можно ли подписать акт электронно?

Можно. Акт можно оформить на бумаге или как электронный документ с электронной подписью. Квалифицированная подпись равнозначна собственноручной. Простая и неквалифицированная — если это предусмотрено законом или соглашением сторон.

Основания: ст. 6 Федерального закона № 63-ФЗ «Об электронной подписи» и ч. 5 ст. 9 закона о бухучёте. На практике встречаются три варианта:

• Бумага с подписями и печатями — привычно, но медленно: оригиналы ходят почтой, а сроки приёмки идут.
• Скан по почте. Это не электронная подпись в смысле закона: его силу задаёт договор. В нашем договоре есть пункт: документы и переписка по электронной почте сторон имеют юридическую силу (п. 9.4). Для приёмки этого достаточно; оригиналы, если они нужны бухгалтерии, можно обменять позже.
• ЭДО с квалифицированной подписью — быстро и без оригиналов, но обе стороны должны быть подключены к оператору электронного документооборота.

Какой бы способ ни выбрали, дата подписи должна быть видна. В ЭДО она фиксируется автоматически, на скане — написана в документе.

Когда отдельные документы не нужны и какие ошибки встречаются?

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

Частые ошибки в закрывающих документах:

• Акт без ссылки на ТЗ. «Сайт разработан, претензий нет» — и через три месяца невозможно доказать, что интеграция с CRM была в объёме.
• Работы сверх ТЗ без допсоглашения. Их сделали, они есть в итоговой сумме счёта, но ни в договоре, ни в акте не упомянуты. Это спор о деньгах, отложенный на потом.
• Подписант без полномочий. Акт подписал менеджер проекта без доверенности. Для приёмки нужен человек, который вправе подписывать документы компании.
• Доступы «в письме». Пароли переданы, но владельцем аккаунтов остался исполнитель. В перечне должно быть указано, на чьё имя оформлен каждый аккаунт.
• Код без версии. Архив прислали, но непонятно, тот ли это код, что работает на сервере. Ссылка на версию в репозитории снимает вопрос.
• Оплата раньше акта «по-дружески». Если остаток оплачен до подписания, рычагов при приёмке почти не остаётся. Порядок из договора стоит соблюдать.

Что проверить в акте за пять минут перед подписью?

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

1. Номер и дата договора, ссылки на ТЗ и спецификацию совпадают с подписанными.
2. Строки и суммы — как в спецификации плюс подписанные допсоглашения.
3. Дата — фактическая, не пустая и не задним числом.
4. Подписанты — с должностями и расшифровкой подписи; у представителя — доверенность.
5. Есть перечень переданного: репозиторий и версия, домен, хостинг, админка, подключённые сервисы, инструкция — и вы проверили вход в каждый.

Если хотите увидеть, как всё это выглядит в готовом виде, откройте типовые договоры Roboweb: в каждом есть ТЗ, спецификация и акт сдачи-приёмки. Нужен акт под нестандартный проект — с этапами или передачей нескольких систем — подготовим под ваш договор.

Короткие ответы на частые вопросы

Можно ли подписать акт выполненных работ на сайт до полной оплаты?

Да, обычно так и делают: сначала акт, потом окончательный расчёт. В типовом договоре Roboweb вторая половина оплачивается в течение 3 рабочих дней с даты подписания акта.

С какой даты считается гарантия на разработку?

С даты, указанной в договоре. В типовом договоре Roboweb — 30 календарных дней с даты подписания акта или с даты, когда работы считаются принятыми, если за 5 рабочих дней не пришли ни подпись, ни мотивированный отказ.

Есть ли обязательная форма акта на разработку программы?

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

Чем акт этапа отличается от итогового акта?

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

Подойдёт ли скан акта, присланный по почте?

Подойдёт, если договор признаёт документы по электронной почте — в типовом договоре Roboweb такой пункт есть. Для бухгалтерии надёжнее оригиналы или акт, подписанный квалифицированной электронной подписью через ЭДО.

Услуги и кейсы по теме: типовые договоры · заказная разработка · цены и сроки