Подтверждение реальности IT-разработки - это задача доказать, что программный продукт действительно создавался, а не был оформлен на бумаге ради налоговой экономии. В 2026 году ФНС последовательно атакует расходы на разработку ПО, квалифицируя их как фиктивные операции по статье 54.1 НК РФ. Компании, которые не выстроили доказательную базу заблаговременно, обнаруживают это только на стадии выездной проверки - когда исправить ситуацию уже крайне сложно.
Ниже - анализ того, какие доказательства работают, какие не работают и как суды оценивают каждый элемент доказательной базы.
Налоговые органы применяют к IT-контрактам ту же аналитическую рамку, что и к любым другим услугам: если результат нематериален, его легко имитировать. Разработка программного обеспечения особенно уязвима, потому что:
Инспекция, как правило, строит претензию по двум направлениям. Первое - отрицание самого факта разработки: исполнитель не имел ресурсов, не нанимал разработчиков, не арендовал серверы. Второе - признание разработки реальной, но отрицание её связи с конкретным контрагентом: работу выполнил кто-то другой, а деньги ушли в схему. Оба направления требуют разных доказательных стратегий.
Статья 54.1 НК РФ устанавливает два условия для признания расходов: операция должна быть реальной и исполненной именно тем лицом, которое указано в договоре. Нарушение любого из условий влечёт отказ в расходах и вычетах по НДС.
Техническое задание - это документ, фиксирующий требования к разрабатываемому продукту до начала работ. Суды в 2026 году оценивают ТЗ не как самостоятельное доказательство, а как отправную точку для проверки соответствия между заявленным и полученным результатом.
Рабочее ТЗ содержит конкретные функциональные требования, описание пользовательских сценариев, технические ограничения и критерии приёмки. Документ, в котором написано «разработка корпоративной системы управления», без детализации модулей, интерфейсов и логики - не ТЗ в доказательном смысле. Инспекция и суд воспримут его как шаблон, скопированный ради оформления сделки.
Распространённая ошибка - подписывать ТЗ той же датой, что и договор, без каких-либо следов согласования. На практике ТЗ проходит несколько итераций: правки, комментарии, версионирование. Если в материалах дела есть только финальная версия без истории изменений, это вызывает обоснованные сомнения.
Что усиливает доказательную силу ТЗ:
Чтобы получить чек-лист требований к ТЗ для налоговых целей, направьте запрос на info@bizdroblenie.ru.
Исходный код - это совокупность файлов, содержащих инструкции для компьютера, написанные на языке программирования. В налоговых спорах код выступает прямым доказательством того, что разработка велась. Однако суды сами код не читают - они оценивают его через экспертизу и косвенные признаки.
Ключевой инструмент - судебная техническая экспертиза. Эксперт устанавливает: когда создавались файлы, кем вносились изменения, соответствует ли объём кода заявленной стоимости работ, есть ли признаки того, что код скопирован из открытых источников или написан одним человеком за короткий срок. Метаданные файлов, история коммитов в системах контроля версий (Git, SVN), записи в трекерах задач - всё это становится предметом экспертного анализа.
Неочевидный риск состоит в том, что код, хранящийся только на локальных машинах заказчика без истории коммитов, практически невозможно датировать независимо. Инспекция вправе поставить под сомнение дату создания любого файла, если нет внешних временных меток - например, из облачного репозитория или системы непрерывной интеграции.
Практический сценарий первый: заказчик - крупная торговая компания, расходы на разработку CRM-системы составили десятки миллионов рублей. Инспекция запросила исходный код. Компания передала архив без истории изменений. Эксперт установил, что все файлы созданы в течение двух дней - незадолго до проверки. Суд поддержал доначисление.
Практический сценарий второй: заказчик - производственное предприятие, расходы на разработку системы учёта - несколько миллионов рублей. Код хранился в облачном репозитории с историей коммитов за полтора года. Эксперт подтвердил постепенное наращивание функциональности. Суд признал расходы реальными, несмотря на аффилированность исполнителя.
Что критично для доказательной силы кода:
Переписка между заказчиком и исполнителем - один из наиболее убедительных косвенных доказательств реальности разработки. Она показывает живой процесс: обсуждение требований, выявление ошибок, согласование изменений, приёмку отдельных модулей.
Суды в 2026 году принимают в качестве доказательств переписку по корпоративной электронной почте, мессенджерам (при наличии нотариально заверенного протокола осмотра или распечаток, заверенных стороной), системам управления проектами (Jira, Confluence, YouTrack). Принципиально важно, чтобы переписка велась между конкретными людьми с идентифицируемыми должностями, а не между обезличенными адресами.
Многие недооценивают риск того, что переписка в мессенджерах без надлежащего оформления не будет принята судом. Скриншоты, сделанные самой стороной без нотариального удостоверения, суды нередко отклоняют как ненадёжные - их легко подделать. Нотариальный протокол осмотра переписки в мессенджере - стандартный способ придать ей доказательную силу.
Распространённая ошибка - переписка, в которой заказчик и исполнитель общаются исключительно формально и только по вопросам оплаты. Реальная разработка порождает содержательные технические обсуждения: «кнопка не работает в Safari», «нужно добавить фильтр по дате», «сервер упал при нагрузке». Отсутствие такого контента - сигнал для инспекции.
Чтобы получить чек-лист по оформлению переписки для налоговых целей, направьте запрос на info@bizdroblenie.ru.
Акт приёмки-передачи итогового результата - необходимый, но недостаточный документ. Суды последовательно указывают: один финальный акт без документации промежуточных этапов не подтверждает реальность длительной разработки.
Документация процесса включает протоколы совещаний, промежуточные акты по спринтам или этапам, отчёты о тестировании, баг-репорты, записи в системе управления задачами. Каждый из этих документов сам по себе слаб, но в совокупности они создают картину живого проекта.
Практический сценарий третий: малый бизнес, расходы на разработку мобильного приложения - около миллиона рублей. Исполнитель - ИП на УСН. Инспекция поставила под сомнение реальность, указав на отсутствие у ИП наёмных сотрудников. Заказчик представил переписку в Telegram (нотариально заверенную), историю коммитов в GitHub, баг-репорты из Jira и протоколы приёмочного тестирования. Суд признал расходы реальными, указав, что один разработчик вправе выполнить работу самостоятельно при наличии доказательств процесса.
Этот сценарий показывает: отсутствие штата у исполнителя само по себе не опровергает реальность, если процесс задокументирован. Статья 54.1 НК РФ не требует, чтобы исполнитель был крупной компанией.
Аффилированность заказчика и исполнителя - отдельный фактор риска, который усиливает скептицизм инспекции. Однако сама по себе аффилированность не запрещена: статья 105.1 НК РФ регулирует взаимозависимость в контексте ценообразования, но не делает сделку автоматически фиктивной.
Позиция Верховного Суда РФ, сформированная в последние годы, состоит в следующем: взаимозависимость - это основание для углублённой проверки условий сделки, но не для автоматического отказа в расходах. Инспекция обязана доказать, что именно взаимозависимость повлекла получение необоснованной налоговой выгоды.
На практике важно учитывать: при аффилированности инспекция запрашивает дополнительные доказательства рыночности цены. Если стоимость разработки существенно превышает рыночный уровень - это самостоятельное основание для претензий по статье 40 НК РФ или в рамках трансфертного ценообразования. Независимая оценка стоимости разработки, проведённая до заключения договора, снижает этот риск.
Неочевидный риск при аффилированности - перекрёстное использование разработчиков. Если сотрудники исполнителя одновременно числятся в штате заказчика или работают на его территории, инспекция квалифицирует это как признак отсутствия самостоятельного исполнителя. Разграничение рабочих мест, оборудования и доступов - не формальность, а элемент доказательной базы.
Налоговая реконструкция - это механизм, при котором суд или инспекция признают часть расходов реальными, даже если операция в целом вызывает сомнения. Применительно к IT-разработке реконструкция актуальна, когда продукт существует, но его стоимость завышена или исполнитель частично не соответствует заявленному.
Верховный Суд РФ последовательно поддерживает подход: если налогоплательщик понёс реальные расходы, пусть и через ненадлежащего контрагента, полное снятие расходов несправедливо. Инспекция обязана определить реальный размер налоговых обязательств с учётом фактически понесённых затрат.
Для применения реконструкции налогоплательщик должен раскрыть реального исполнителя и представить доказательства его затрат. Это непростое решение: раскрытие реального исполнителя может создать новые риски. Стратегический выбор между полной защитой первоначальной позиции и переходом к реконструкции требует оценки конкретных обстоятельств дела.
Расходы на сопровождение налогового спора по IT-контрактам зависят от стадии: возражения на акт проверки, апелляционная жалоба в УФНС и арбитражный суд - каждая стадия требует отдельной подготовки. Юридическое сопровождение начинается от десятков тысяч рублей на ранних стадиях и существенно возрастает при переходе в суд.
Чтобы получить чек-лист по подготовке к налоговой реконструкции в IT-спорах, направьте запрос на info@bizdroblenie.ru.
Какой минимальный набор документов подтверждает реальность IT-разработки при налоговой проверке?
Минимально необходимый набор включает договор с детализированным предметом, ТЗ с историей согласования, историю коммитов в репозитории, промежуточные акты или отчёты по этапам и финальный акт приёмки. Переписка между конкретными специалистами усиливает позицию. Ни один документ в отдельности не является достаточным - суды оценивают совокупность. Отсутствие репозитория с историей изменений при значительной стоимости разработки - существенный пробел, который сложно закрыть постфактум.
Каковы финансовые последствия, если инспекция признает расходы на IT-разработку фиктивными?
Последствия включают доначисление налога на прибыль по ставке 25% от суммы снятых расходов, отказ в вычете НДС по счетам-фактурам исполнителя, штраф 20% от недоимки при отсутствии умысла или 40% при его доказанности по статье 122 НК РФ, а также пени за весь период. При суммах недоимки свыше 18,75 млн рублей за три финансовых года возникают риски по статье 199 УК РФ. Совокупная нагрузка может превысить первоначальную сумму расходов.
Когда стоит переходить к стратегии налоговой реконструкции вместо полной защиты первоначальной позиции?
Реконструкция целесообразна, когда продукт реально существует и используется, но доказательная база по конкретному контрагенту слабая - например, исполнитель ликвидирован или не отвечает на запросы. Полная защита первоначальной позиции оправдана при наличии сильной документации: репозиторий, переписка, промежуточные акты. Смешанная стратегия - защита основной позиции с параллельной подготовкой к реконструкции - снижает риск полного проигрыша. Выбор зависит от конкретных обстоятельств и должен приниматься с участием юриста до подачи возражений на акт проверки.
Доказательная база по IT-разработке строится не в момент проверки, а в ходе самого проекта. Репозиторий с историей коммитов, содержательная переписка специалистов, версионированное ТЗ и промежуточные акты - это рабочие инструменты разработки, которые одновременно являются налоговыми доказательствами. Компании, которые выстраивают документацию проекта по профессиональным стандартам, получают защиту автоматически. Те, кто ограничивается финальным актом, принимают на себя риск полного снятия расходов.
Команда bizdroblenie.ru сопровождает бизнес в спорах и проектах, связанных с защитой расходов на IT-разработку и оспариванием доначислений по договорам с технологическими подрядчиками. Мы можем помочь с оценкой текущей доказательной базы, подготовкой возражений на акт проверки и выработкой стратегии защиты в арбитражном суде. Чтобы получить консультацию, напишите на info@bizdroblenie.ru.