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

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

Этот материал отвечает на практические вопросы: что именно проверяет инспектор, какие документы работают в суде, а какие создают иллюзию защиты.

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

Первое - наличие квалифицированного персонала у подрядчика. Инспектор запрашивает штатное расписание, трудовые договоры, сведения о численности. Если у подрядчика один директор и нет разработчиков в штате, расходы будут оспорены вне зависимости от качества первичных документов.

Второе - соответствие объёма работ и стоимости. ФНС сравнивает цену договора с рыночными ставками и анализирует, сколько человеко-часов потребовалось бы для выполнения заявленного объёма. Если по ТЗ предусмотрена разработка ERP-системы за два месяца силами трёх человек, а стоимость договора составляет десятки миллионов рублей, это вызывает вопросы.

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

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

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

ТЗ, которое работает в суде, содержит несколько обязательных элементов. Функциональные требования должны быть описаны конкретно: не «разработка модуля отчётности», а перечень отчётных форм, форматы выгрузки, источники данных. Нефункциональные требования - производительность, нагрузка, совместимость с операционными системами. Критерии приёмки - конкретные тесты или сценарии, по результатам которых заказчик подписывает акт.

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

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

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

Исходный код - это наиболее весомое техническое доказательство реальности разработки. Он содержит встроенные метаданные: даты коммитов, имена авторов, историю изменений. Эти данные крайне сложно сфальсифицировать ретроспективно без следов.

Репозиторий в системе контроля версий - Git, SVN или аналогичной - фиксирует каждое изменение кода с временной меткой. История коммитов показывает, как проект развивался во времени: появлялись новые функции, исправлялись ошибки, рефакторился код. Если история коммитов охватывает весь период действия договора и корреспондирует с этапами оплаты, это сильный аргумент в пользу реальности работ.

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

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

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

Деловая переписка - электронная почта, мессенджеры, системы управления проектами - подтверждает, что стороны взаимодействовали в ходе исполнения договора. Для налогового спора важно не просто наличие переписки, а её содержание и хронология.

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

Хронология переписки должна совпадать с этапами договора. Если договор предусматривает три этапа с промежуточными актами, переписка должна охватывать каждый этап. Разрывы в коммуникации на несколько месяцев при активном проекте выглядят подозрительно.

На практике важно учитывать, что переписка в мессенджерах - Telegram, WhatsApp - имеет меньшую доказательную силу, чем корпоративная электронная почта, поскольку её сложнее верифицировать. Если основная коммуникация велась в мессенджерах, рекомендуется дублировать ключевые решения письмами на корпоративные адреса или фиксировать их в протоколах рабочих встреч.

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

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

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

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

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

Три практических сценария показывают, как работает эта логика. В первом сценарии заказчик - крупная торговая компания с оборотом свыше 500 млн рублей - заказал разработку системы управления складом. Договор на несколько десятков миллионов рублей, подрядчик на УСН. ФНС оспорила расходы, но заказчик представил полный пакет: ТЗ с версионностью, историю репозитория за 14 месяцев, переписку в корпоративной почте, протоколы тестирования и акт ввода в эксплуатацию. Суд поддержал заказчика.

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

В третьем сценарии IT-компания заказала у аффилированного подрядчика разработку внутренней CRM. Документация была полной, но налоговый орган установил аффилированность и транзитное движение денег. Суд оценил совокупность признаков и признал схему направленной на получение необоснованной налоговой выгоды. Полная документация не компенсировала отсутствие деловой цели.

Системный подход к документированию IT-проектов снижает налоговый риск принципиально, а не косметически. Он предполагает несколько последовательных шагов.

До заключения договора - проверка подрядчика: штатная численность, квалификация разработчиков, портфолио реализованных проектов, деловая репутация. Результаты проверки фиксируются в досье контрагента. Это подтверждает должную осмотрительность по статье 54.1 НК РФ.

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

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

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

Возражения на акт выездной налоговой проверки подаются в течение одного месяца с момента его получения. Апелляционная жалоба в УФНС - также в течение одного месяца после вынесения решения. Обращение в арбитражный суд возможно в течение трёх месяцев после решения УФНС. Каждый из этих сроков критичен: пропуск без уважительных причин закрывает соответствующую стадию защиты.

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

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

Что происходит, если ФНС снимает IT-расходы: каков масштаб потерь?

Налоговый орган доначисляет налог на прибыль по ставке 25% от суммы снятых расходов и отказывает в вычете НДС. Дополнительно начисляются пени за каждый день просрочки и штраф - 20% от недоимки при отсутствии умысла или 40% при его доказанности по статье 122 НК РФ. При крупном размере недоимки - свыше 18 750 000 рублей за три финансовых года - возникают уголовные риски по статье 199 УК РФ с максимальным наказанием до пяти лет лишения свободы. Совокупные потери существенно превышают сумму спорных расходов.

Когда лучше привлечь налогового юриста - на стадии проверки или заранее?

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

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

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

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