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

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

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

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

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

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

Налоговый орган при проверке IT-расходов анализирует несколько уровней доказательств.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для налоговых целей рекомендуется сохранять: экспорт истории репозитория с подписями коммитов, документацию к коду (README, комментарии, архитектурные схемы), результаты code review, если они проводились, и акты передачи исходного кода с описанием состава передаваемых материалов.

Сценарий первый: крупная производственная компания заказала разработку системы учёта у небольшого IT-подрядчика. При проверке инспекция усомнилась в реальности сделки, поскольку у подрядчика было только два сотрудника. Заказчик предоставил историю репозитория с 847 коммитами от шести разработчиков подрядчика за восемь месяцев, переписку в корпоративном мессенджере и акты промежуточной приёмки по спринтам. Инспекция сняла претензии.

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

Для налоговых целей ценна переписка в корпоративной электронной почте, мессенджерах (при условии, что она сохранена и атрибутирована конкретным сотрудникам), системах управления задачами (Jira, YouTrack, Trello и аналогах), а также протоколы совещаний и созвонов.

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

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

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

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

Акт должен описывать конкретный результат: что именно разработано, в каком объёме, какие функции реализованы. Формулировка «оказаны услуги по разработке ПО на сумму X рублей» не даёт никакой содержательной информации и не выдерживает проверки.

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

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

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

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

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

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

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

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

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

Условия применения реконструкции: налогоплательщик должен раскрыть реального исполнителя и представить доказательства фактически понесённых затрат. Это сложнее, чем изначально правильно оформить документы, но лучше, чем полная потеря расходов.

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

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

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

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

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

Стоит ли заключать договор с физическим лицом-разработчиком или лучше работать через юридическое лицо?

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

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

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