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

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

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

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

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

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

Работающее ТЗ содержит:

• функциональные требования с детализацией до уровня модулей и экранов - не «система аналитики», а «модуль отчётности с фильтрацией по 12 параметрам и экспортом в Excel»
• нефункциональные требования: производительность, нагрузка, совместимость с конкретными версиями ПО
• этапы разработки с промежуточными результатами и датами сдачи каждого этапа
• критерии приёмки: как именно заказчик проверяет, что этап выполнен

Неочевидный риск состоит в том, что ТЗ, написанное задним числом, легко распознаётся по метаданным файла. Инспекторы запрашивают свойства документа Word или PDF - дата создания и дата последнего изменения должны соответствовать логике проекта. Если ТЗ датировано январём, а метаданные показывают август - это прямой аргумент против реальности сделки.

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

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

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

Дополнительные доказательства из технической инфраструктуры:

• логи деплоя: записи о развёртывании кода на серверах заказчика с временными метками
• тикеты в системах управления задачами (Jira, YouTrack, Trello) - они показывают, как задачи ставились, обсуждались и закрывались
• документация: README, API-спецификации, схемы баз данных, написанные в процессе разработки
• результаты тестирования: отчёты о баг-репортах и их устранении

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

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

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

Какие каналы переписки работают как доказательство:

• корпоративная электронная почта с сохранёнными архивами - предпочтительный вариант, поскольку метаданные писем сложно подделать
• мессенджеры с экспортом истории: Telegram, Slack, Teams - суды принимают скриншоты и экспортированные логи при условии, что они заверены надлежащим образом
• протоколы встреч и демонстраций - особенно ценны, если подписаны обеими сторонами

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

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

Сценарий первый: малый бизнес, расходы до 5 млн рублей. Компания на общей системе налогообложения заказала разработку CRM-системы у ИП. Акт подписан, оплата прошла. При камеральной проверке инспектор запросил ТЗ и переписку. ТЗ оказалось на полторы страницы, переписки нет - общались устно. Инспектор вынес решение об отказе в расходах и вычете НДС. Доначисление составило около 1,5 млн рублей с учётом штрафа 20% по статье 122 НК РФ. Возражения не принесли результата, поскольку доказательная база отсутствовала. Суд поддержал налоговый орган.

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

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

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

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

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

Доказательная база формируется в процессе проекта, а не после получения требования от инспектора. Ретроспективное восстановление документов - это риск уголовной ответственности по статье 303 УК РФ за фальсификацию доказательств и дополнительный аргумент против налогоплательщика.

Практические шаги, которые защищают позицию:

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

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

Цена бездействия конкретна: при доначислении налога на прибыль по ставке 25% и НДС 20% с расходов на разработку в 20 млн рублей совокупная налоговая нагрузка с учётом штрафа 20% и пеней может превысить 12 млн рублей. Это не считая расходов на судебное сопровождение и временных затрат менеджмента.

Достаточно ли подписанного акта и счёта-фактуры для подтверждения IT-расходов?

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

Какие последствия грозят, если налоговый орган признает IT-расходы нереальными?

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

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

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

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

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

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