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