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

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

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

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

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

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

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

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

Сильное ТЗ содержит конкретные модули с описанием логики, пользовательские сценарии, требования к производительности, перечень интеграций с указанием протоколов, макеты экранов или схемы баз данных. Объём в 20-50 страниц для серьёзного проекта - норма, а не избыток.

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

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

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

Именно история коммитов в репозитории (Git, SVN и аналоги) является наиболее объективным доказательством реальности разработки. Она показывает:

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

Многие недооценивают, что распечатка или экспорт истории репозитория может быть представлен в качестве приложения к возражениям на акт проверки. Арбитражные суды принимают такие материалы как письменные доказательства по статье 75 АПК РФ.

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

Сценарий первый: крупная компания заказала разработку внутренней системы документооборота. Подрядчик предоставил доступ к репозиторию с историей за 8 месяцев, более 2 000 коммитов от 6 разработчиков. При проверке инспектор запросил пояснения - заказчик предоставил выгрузку истории и сопоставление задач с коммитами. Претензии были сняты на стадии возражений.

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

Наиболее весомая переписка - деловая электронная почта с корпоративных адресов. Она содержит метаданные (дата, время, IP-адрес сервера), которые сложно фальсифицировать. Переписка в мессенджерах (Telegram, WhatsApp) также принимается судами, но требует нотариального заверения или иного способа фиксации для придания ей доказательственной силы.

Трекеры задач - Jira, YouTrack, Redmine, Asana - фиксируют постановку задач, их выполнение, комментарии и статусы. Экспорт из трекера показывает хронологию работы и соответствие выполненных задач условиям ТЗ. Это особенно ценно, когда подрядчик работал по методологии Agile со спринтами: каждый спринт документирован, результаты приняты заказчиком внутри системы.

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

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

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

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

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

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

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

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

Средний уровень - документы, которые стороны составляют сознательно, но в процессе работы: ТЗ, промежуточные акты, протоколы совещаний, деловая переписка. Они весомы, если датированы корректно и согласуются между собой.

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

Сценарий третий: холдинговая структура заказала разработку у аффилированной IT-компании на УСН. Инспекция усмотрела признаки дробления бизнеса и поставила под сомнение реальность расходов. Заказчик предоставил полный пакет: ТЗ на 40 страниц, историю репозитория, экспорт из Jira, переписку по корпоративной почте, протоколы приёмочного тестирования. Суд первой инстанции поддержал налогоплательщика, указав на достаточность доказательной базы реальности операции.

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

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

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

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

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

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

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

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

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

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

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

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

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