Аккредитация есть. Компания действительно занимается разработкой программного обеспечения. Продукт существует, клиенты платят, разработчики работают.
Кажется, что с применением IT-льгот все должно быть в порядке.
На практике этого недостаточно.
Во время аудитов IT-компаний мы регулярно сталкиваемся с ситуацией, когда бизнес фактически ведет IT-деятельность, но документы, структура договоров, сайт или оформление разработки этого не подтверждают. А иногда — прямо противоречат реальной бизнес-модели.
Именно такие кейсы мы разбирали на вебинаре «Налоговые льготы IT-компаний: кейсы и споры с ФНС» (видео в конце статьи).
Главный вывод из практики простой: налоговый орган не обязан восстанавливать за компанию реальную картину ее деятельности.
Если из договора следует оказание консультационных услуг, инспектор не обязан выяснять, что фактически это было внедрение и сопровождение ПО. Если в документах компания владеет одной версией продукта, а продает уже совершенно другую, никто не обязан самостоятельно восстанавливать всю историю разработки.
Поэтому перед применением льгот важно проверять не отдельный договор или формальное наличие аккредитации, а всю модель целиком.
Одна из базовых ошибок — считать, что статус аккредитованной IT-компании автоматически означает возможность применять налоговые преференции.
Это не так.
Для применения налоговых IT-льгот необходимо дополнительно соблюдать требования к квалифицированному доходу. В частности, на вебинаре мы разбирали требование о 70% профильной выручки.
И здесь возникает следующий вопрос: а точно ли те доходы, которые компания считает IT-доходами, действительно являются квалифицированными?
Именно на этом уровне часто начинаются основные проблемы.
Компания смотрит на себя как на IT-бизнес в целом. Налоговое законодательство смотрит на конкретный вид деятельности, конкретный продукт, конкретную услугу и то, как все это оформлено.
Это не всегда одно и то же.
Один из показательных кейсов из нашей практики.
Компания действительно занималась IT-деятельностью. Ее услуги потенциально могли относиться к квалифицированным.
Но мы открыли договоры и увидели достаточно широкие формулировки — в том числе «консультационные услуги».
При этом по факту речь шла о сопровождении программного продукта, его внедрении, установке и других работах, которые могли относиться к IT-деятельности.
Для бизнеса разница кажется формальной:
Мы же понимаем, что именно делали.
Для налоговой ситуация может выглядеть иначе:
В договоре написано «консультационные услуги». Почему мы должны считать, что оказывалось что-то другое?
После этого компании уже самой придется доказывать фактический характер оказанных услуг: поднимать переписку, технические задания, отчеты, результаты работ и другие подтверждения.
И далеко не всегда необходимые доказательства вообще сохранились.
Поэтому название договора не делает доход IT-доходом. Важно содержание обязательств, фактическая деятельность и подтверждающие ее документы.
Еще одна очень распространенная конструкция:
компания оказывает несколько услуг в рамках одного договора.
Например:
— разработку ПО;
— дополнительные консультационные или иные услуги.
Сам по себе смешанный договор не проблема. Делить все на десять самостоятельных договоров тоже необязательно.
Проблема появляется, когда весь пакет продается, например, за 1 млн рублей, но стоимость отдельных услуг нигде не определена.
Возникает простой вопрос:
какая часть этого миллиона — квалифицированный IT-доход, а какая нет?
Компания может внутренне считать, что 800 тыс. рублей относятся к разработке, а 200 тыс. — к другим услугам.
Но сможет ли она доказать именно такое распределение?
Гораздо безопаснее заранее разделить стоимость услуг — в самом договоре, спецификациях или иных документах.
Тот же принцип работает и при применении льгот по НДС. В расшифровке вебинара мы разбирали распространенную конструкцию, когда доступ к ПО объединяется с установкой, адаптацией, поддержкой и сопровождением, а налоговый режим автоматически распространяется на весь комплекс. Именно здесь возникает риск доначислений.
Отдельная зона риска — понятие собственного ПО.
Представим типичную ситуацию.
Компания заказала разработку программного продукта у внешнего подрядчика. Получила результат, оформила исключительные права и начала продавать доступ к продукту.
С точки зрения интеллектуальной собственности компания действительно может быть правообладателем.
Но для целей применения IT-льгот вопрос может оказаться сложнее: значение имеет в том числе то, кто разрабатывал, дорабатывал, адаптировал и модифицировал ПО.
Поэтому одна лишь цепочка передачи исключительных прав не всегда закрывает налоговый риск.
Чем больше компания самостоятельно развивает продукт, тем важнее уметь это подтвердить:
— техническими заданиями;
— задачами на разработку;
— релизами;
— документами о доработках;
— изменениями функционала;
— репозиториями и версиями кода;
— документами сотрудников и подрядчиков;
— передачей результатов интеллектуальной деятельности.
Особенно опасна ситуация, когда продукт годами развивается, но юридически продолжает существовать в своей первоначальной версии.
Такой кейс мы тоже видели на практике.
Программный продукт начинался с небольшого набора функций, затем постепенно развивался и в итоге превратился в серьезную систему.
Но история развития продукта документально почти не фиксировалась.
В результате фактически компания продавала сложное решение, а по имеющимся документам ей принадлежал практически «калькулятор».
Проблема здесь не только в интеллектуальной собственности.
Если компания заявляет, что получает доход от собственного программного продукта, она должна быть способна показать, какой именно продукт является ее собственным и как он появился.
В одном из рассмотренных кейсов вопрос возник уже в ходе налоговой проверки. Проверяющие посмотрели в том числе штатное расписание и документы сотрудников и не увидели людей, которые могли бы заниматься разработкой. Не было и достаточной документальной фиксации доработок.
Фактические изменения кода существовали, и это позволило компании усилить свою позицию и снизить сумму доначислений. Но собирать такую доказательственную базу уже после начала проверки гораздо сложнее.
Правильнее заранее выстроить понятный трек:
была версия продукта → появилась задача → произведена разработка или модификация → результат принят → права оформлены → возникла новая версия.
Особенно часто эта проблема возникает в группах компаний.
Бизнес принимает вполне логичное управленческое решение: создать отдельную IT-компанию группы и централизовать в ней всю технологическую функцию.
И туда постепенно переезжает все, что сотрудники привыкли называть IT:
— разработка;
— поддержка ПО;
— администрирование;
— настройка оборудования;
— Wi-Fi;
— доступы;
— пароли;
— принтеры;
— помощь пользователям и многое другое.
С точки зрения бизнеса это единая IT-функция.
С точки зрения правил квалификации доходов — нет.
Не каждая услуга, оказываемая IT-подразделением или IT-компанией, автоматически превращается в квалифицированный IT-доход.
Из-за этого компания может неожиданно обнаружить, что доля доходов, которую она считала профильной, уже приближается к критической границе.
Особенно важно проверять внутригрупповые договоры: какой конкретно предмет в них указан, в отношении какого ПО выполняются работы и кто разработал этот программный продукт.
В 2026 году эта тема стала особенно актуальной.
После изменения порядка совмещения льгот часть компаний стала сравнивать две модели — оставаться участником «Сколково» или переходить на IT-льготы.
И здесь есть важная ловушка.
Просто отказаться от применения льгот «Сколково» недостаточно, если компания сохраняет статус участника проекта.
На вебинаре мы разбирали случаи, когда сам статус участника становился препятствием для применения IT-льгот. Поэтому переход необходимо планировать не только экономически, но и юридически: определить момент утраты статуса и момент, с которого может применяться соответствующая льгота.
Отдельный вопрос — налог на прибыль при переходе.
Позиция, которую мы видим в разъяснениях финансовых органов и на практике, требует особенно внимательно анализировать возможность применения льготы в год выхода из «Сколково». Неправильно выбранный момент перехода способен сам стать причиной требований и доначислений.
Поэтому решение «нам IT-льготы теперь выгоднее» должно начинаться не с отказа от текущей модели, а с расчета:
— сколько компания экономит;
— какие условия должна выполнить;
— когда может перейти;
— какие налоговые последствия возникают в переходном периоде;
— какие документы потребуется изменить.
Мы бы рекомендовали не ограничиваться вопросом: «Есть ли у нас аккредитация и 70% выручки?»
Проверка должна идти минимум по восьми направлениям.
1. Фактическая деятельность
Что компания реально делает для каждого типа клиентов и из чего фактически получает деньги?
2. Структура выручки
Какие виды доходов относятся к квалифицированным, а какие нет? Есть ли запас относительно необходимой доли?
3. Договоры и акты
Совпадает ли написанное в договорах с реальными услугами? Не используются ли слишком широкие понятия вроде «консультационных», «информационных» или «сервисных» услуг?
4. Разделение стоимости
Если в одном договоре есть IT- и не-IT-составляющая, можно ли определить стоимость каждой из них?
5. Программный продукт
Соответствует ли продукт тому, что описано в документации и реестрах? Зафиксирована ли история его развития?
6. Права и разработка
Понятно ли, кто создавал продукт и его отдельные версии? Есть ли документы о разработке, доработках, адаптации и передаче прав?
7. Сайт
Совпадает ли публичное описание деятельности компании с тем, что она заявляет для целей аккредитации и применения льгот?
Сайт — один из самых простых источников информации о компании. Если уже на нем видны противоречия, проверяющему может не понадобиться глубокий анализ внутренних процессов.
8. Специальные режимы
Если компания использует «Сколково», реестр российского ПО или другие специальные режимы и статусы, нужно отдельно проверить условия каждого из них и их совместимость.
При аудите IT-деятельности мы обычно смотрим сразу на четыре уровня:
что компания реально делает → что умеет продукт → что написано в документах → за что именно платит клиент.
В идеальной модели все четыре элемента совпадают.
Если фактическая деятельность одна, в договоре написано другое, в реестре зарегистрирована третья версия продукта, а акт сформулирован четвертым способом — возникает зона риска.
Именно поэтому исправить только договор или только сайт обычно недостаточно.
Налоговая модель IT-компании сегодня — это уже не вопрос наличия нескольких формальных документов. Это связанная система из продукта, договоров, интеллектуальной собственности, процессов разработки, выручки и корпоративной структуры.
И чем раньше компания сама сможет «распутать этот клубок», тем меньше вероятность, что за нее это будет делать налоговый орган — уже в рамках проверки.