Кейс: - Подтверждение реальности IT-разработки: код, ТЗ, переписка - практический разбор

Расходы на IT-разработку - одна из наиболее уязвимых статей при выездной налоговой проверке. ФНС квалифицирует их как фиктивные, если не видит доказательств реального исполнения договора. Код, техническое задание и переписка - три ключевых элемента доказательной базы, и каждый из них требует отдельного подхода.

Этот материал - практический разбор того, как выглядит защита расходов на IT-разработку изнутри: что проверяет инспекция, какие документы работают в суде, а какие создают дополнительные риски.

Налоговые органы относят IT-разработку к категории услуг с высоким риском фиктивности. Причина - нематериальный результат и сложность его верификации. Инспектор не может потрогать программный код так же, как товар на складе. Это создаёт пространство для злоупотреблений - и ФНС это знает.

Статья 54.1 НК РФ устанавливает два условия для признания расходов обоснованными: сделка реально исполнена, и исполнена именно тем лицом, которое указано в договоре. Оба условия должны выполняться одновременно. Если инспекция докажет, что разработку фактически никто не вёл или вёл не тот подрядчик, расходы снимаются, а налог на прибыль доначисляется по ставке 25%.

На практике важно учитывать, что претензии возникают не только к откровенно фиктивным схемам. Добросовестные компании, которые реально заказывали разработку, теряют расходы из-за слабой документации. Инспекция не обязана доказывать умысел - достаточно показать, что документы не подтверждают факт исполнения.

Типичный сценарий: компания заключила договор с IT-подрядчиком, оплатила работы, получила акт. Через два года - выездная проверка. Инспектор запрашивает ТЗ, переписку, исходный код. Оказывается, ТЗ составлено задним числом, переписка не сохранилась, а код хранится только у подрядчика, который к тому моменту ликвидирован.

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

Распространённая ошибка - составлять ТЗ как формальное приложение к договору без реального содержания. Инспекция и суд оценивают несколько параметров:

• Конкретность требований - ТЗ должно описывать функциональность, а не просто называть тип продукта («разработка CRM-системы» без детализации - слабый документ).
• Соответствие квалификации заказчика - если ТЗ написано на уровне, недоступном для сотрудников компании-заказчика, это вызывает вопросы об авторстве.
• Дата создания - метаданные файла, история версий в системе контроля версий, дата первого письма с прикреплённым ТЗ.
• Итерационность - реальные проекты проходят несколько редакций ТЗ. Единственная версия без правок подозрительна.

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

Чтобы получить чек-лист по подготовке ТЗ для налоговой защиты, направьте запрос на info@bizdroblenie.ru.

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

Проблема в том, что большинство компаний не имеют доступа к коду после завершения проекта. Договор предусматривал передачу прав, но не передачу репозитория. В момент проверки предъявить нечего.

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

Что работает в суде:

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

Многие недооценивают значение истории коммитов. Если подрядчик работал в частном репозитории и не передал его заказчику, восстановить доказательную базу после ликвидации подрядчика практически невозможно.

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

Инспекция запрашивает переписку в рамках статьи 93 НК РФ. Отсутствие переписки трактуется как косвенное доказательство нереальности операции - особенно если речь идёт о многомесячном проекте стоимостью в несколько миллионов рублей.

Три сценария с разными последствиями:

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

Второй сценарий - переписка велась в мессенджерах (Telegram, WhatsApp). Суды принимают такую переписку, но с оговорками. Необходимо нотариальное заверение скриншотов или протокол осмотра доказательств. Переписка в личных аккаунтах сотрудников, а не в корпоративных - дополнительный риск.

Третий сценарий - переписка не сохранилась или велась устно. Это наиболее уязвимая позиция. Компания вынуждена опираться на косвенные доказательства: показания сотрудников, внутренние документы, результат работы. Суды оценивают такую совокупность критически.

Чтобы получить чек-лист по сохранению и систематизации переписки для налоговой защиты, направьте запрос на info@bizdroblenie.ru.

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

Типичные ошибки в договорах на IT-разработку:

• Предмет договора описан слишком широко - «разработка программного обеспечения» без указания функциональности, платформы, языка разработки.
• Цена не обоснована - нет расчёта трудозатрат, нет сравнения с рыночными ставками. Инспекция привлекает эксперта, который оценивает стоимость работ по рыночным ценам.
• Акт не содержит описания результата - «работы выполнены в полном объёме» без перечня конкретных функций или модулей.
• Подписант акта не имел полномочий принимать технический результат - директор подписал акт, не привлекая технических специалистов.

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

На практике важно учитывать, что акт должен быть подписан лицом, которое реально принимало работу и может пояснить её содержание на допросе. Инспекция вызывает сотрудников на допрос в рамках статьи 90 НК РФ. Если технический директор не знает, что именно разрабатывал подрядчик, - это серьёзный риск.

Допрос - это процессуальное действие, в ходе которого инспектор получает показания свидетеля об обстоятельствах сделки. Показания фиксируются в протоколе и используются как доказательство в суде.

Многие компании недооценивают этот риск. Документы в порядке, код передан, переписка сохранена - но сотрудники на допросе дают противоречивые показания. Этого достаточно, чтобы инспекция включила операцию в акт проверки.

Типичные противоречия, которые выявляет инспекция:

• Руководитель не знает имён разработчиков подрядчика и не может описать процесс взаимодействия.
• Технический специалист заказчика утверждает, что разработку вели собственными силами, а не привлекали подрядчика.
• Менеджер проекта не помнит, когда и как принимал промежуточные результаты.

Подготовка сотрудников к допросу - не инструктаж по даче ложных показаний. Это восстановление реальной картины событий: кто с кем общался, как проходила приёмка, где хранятся документы. Сотрудник должен знать, что он вправе воспользоваться статьёй 51 Конституции РФ и не давать показания против себя.

Сценарий первый. Небольшая торговая компания заказала разработку внутренней системы учёта за 3,5 млн рублей. Подрядчик - небольшая IT-компания на УСН. Договор, акт, счёт-фактура - всё в наличии. При проверке выяснилось: ТЗ отсутствует, переписка не сохранилась, система работает, но доступ к коду только у подрядчика. Инспекция сняла расходы полностью. Компания оспорила решение в суде, представив показания сотрудников и скриншоты работающей системы. Суд частично восстановил расходы, снизив доначисление, но не отменив его полностью.

Сценарий второй. Производственное предприятие заказало разработку модуля интеграции с ERP-системой за 8 млн рублей. Проект длился 14 месяцев. Сохранены: ТЗ с историей версий, переписка в корпоративной почте, репозиторий с историей коммитов, акты по этапам. На допросе технический директор детально описал процесс взаимодействия. Инспекция включила операцию в акт, но суд полностью поддержал компанию: доказательная база признана достаточной.

Сценарий третий. Группа компаний использовала внутреннюю IT-компанию на УСН для разработки продуктов, которые затем лицензировались основной компании на ОСНО. Инспекция квалифицировала схему как дробление бизнеса с целью налоговой экономии. Здесь реальность разработки была доказана, но возник вопрос о деловой цели структуры. Налоговая реконструкция позволила снизить доначисление, но не исключить его полностью.

Какой документ является наиболее критичным при оспаривании расходов на IT-разработку?

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

Каковы финансовые последствия снятия расходов на IT-разработку?

При снятии расходов инспекция доначисляет налог на прибыль по ставке 25% от суммы снятых расходов. Дополнительно начисляются пени за каждый день просрочки. Штраф по статье 122 НК РФ составляет 20% от недоимки при отсутствии умысла и 40% при доказанном умысле. Для проекта стоимостью 10 млн рублей совокупные доначисления с учётом пеней и штрафа могут составить от 3 до 5 млн рублей в зависимости от периода и квалификации нарушения. Расходы на юридическое сопровождение спора начинаются от десятков тысяч рублей на стадии возражений и существенно возрастают при переходе в арбитражный суд.

Стоит ли оспаривать доначисления или лучше согласиться и заплатить?

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

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

Чтобы получить чек-лист по подготовке доказательной базы для защиты IT-расходов при налоговой проверке, направьте запрос на info@bizdroblenie.ru.

Команда bizdroblenie.ru сопровождает бизнес в спорах и проектах, связанных с защитой расходов на IT-разработку и оспариванием доначислений по налогу на прибыль. Мы можем помочь оценить текущую доказательную базу, подготовить возражения на акт проверки и выстроить стратегию защиты в суде. Чтобы получить консультацию, напишите на info@bizdroblenie.ru.