Техническая компания в цепочке поставщиков: где скрыты риски

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

Почему риск обнаруживают после сдачи проекта

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

Цена ошибки — не только задержка платежа. Это повторная разработка за свой счёт, спор о правах, претензия заказчика, доначисления и расходы на юристов. Чем больше звеньев в цепочке, тем сложнее быстро восстановить, кто отвечал за конкретный этап.

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

Пять зон риска для технического поставщика

1. Субподрядчик существует только в договоре

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

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

2. Документы есть, а результата не видно

Акт с общей формулировкой «услуги оказаны полностью» плохо помогает, если позднее стороны спорят о составе работ. Для разработки и внедрения полезно фиксировать этапы, версии, тесты, настройки, инструкции и критерии приёмки. Не каждый проект требует всех этих артефактов, но документы должны позволять связать оплату с конкретным результатом.

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

3. Не определены права на код и другие материалы

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

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

4. Доступ к данным и системам не контролируют

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

Ведите список учётных записей и ответственных. Не передавайте общие пароли в переписке и не оставляйте активные доступы бывшим сотрудникам или субподрядчикам. По завершении работ запросите подтверждение возврата или удаления данных, если это предусмотрено договором и применимыми требованиями.

5. Налоговая картина не совпадает с реальностью

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

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

Что проверить и когда

1. До подписания договора. Проверьте реквизиты контрагента, полномочия подписанта, предмет договора, цену, порядок оплаты, право на субподряд и условия передачи результата. Для налоговых вопросов сверяйте актуальные разъяснения и требования на nalog.gov.ru.
2. До передачи доступа или данных. Назначьте ответственных, определите минимально необходимый доступ, согласуйте режим обработки информации и порядок его отзыва. Если требуется согласие заказчика на субподряд или доступ третьих лиц, получите его заранее.
3. На каждом этапе работ. Сохраняйте задания, промежуточные результаты, отчёты, переписку и подтверждения передачи материалов. Привязывайте акт к этапу и результату, а не только к календарному месяцу.
4. До оплаты и закрытия этапа. Сверьте акт, счёт и фактический результат; проверьте, что подписант уполномочен, а документы соответствуют договору. Срок оплаты и приёмки смотрите в договоре — общего срока для всех проектов нет.
5. До сдачи налоговой отчётности. Передайте бухгалтеру полный комплект документов и объясните, кто выполнял работу. Сроки и состав отчётности зависят от налогового режима и статуса компании; проверьте календарь ФНС и личный кабинет, а не ориентируйтесь на прошлогодний график.

Типичные ошибки и возможные последствия

• Подписывать акт без проверки. Если заказчик обнаружит дефект позднее, придётся разбирать договор, переписку и доказательства приёмки. Последствия зависят от условий договора и обстоятельств спора.
• Не оформлять работу субподрядчика. Это может нарушить условия основного договора и затруднить подтверждение состава работ. Проверьте, требуется ли согласие заказчика и какие документы должны быть у вас.
• Считать, что права на код переходят автоматически. Условия передачи зависят от договора и вида результата. Если стороны не разделили новый код и ранее созданные компоненты, спор может остановить внедрение или ограничить дальнейшее использование.
• Пропустить срок налоговой отчётности. За несвоевременную подачу декларации предусмотрен штраф по статье 119 НК РФ: 5% не уплаченной в срок суммы налога за каждый полный или неполный месяц просрочки, но не более 30% этой суммы и не менее 1 000 рублей. Применимость и расчёт зависят от конкретной декларации и обстоятельств; сверяйте актуальную редакцию нормы.
• Оставить доступы после завершения договора. Это повышает риск утечки и претензий со стороны заказчика. Отзовите доступы по согласованному процессу и сохраните подтверждение.

Как снизить риск без лишней бюрократии

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

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