ФНС проверяет реальность ИТ-разработок

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

Я – Антон Фокин, CEO Qtim, считаю, что это уже не теоретический сюжет, а практическая проблема для бизнеса, которую мы можем решить. У компании может быть сайт, личный кабинет, оплата и продажи, но при проверке выясняется, что ключевая логика находится вне ее контура, права на код оформлены не до конца, а архитектура не описана. В такой ситуации вопрос уже не в маркетинге, а в том, как доказать, что продукт действительно свой и избежать штрафов.

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

Почему этот вопрос встал именно сейчас и кто попадает в риск

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

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

Хорошая новость в том, что месяц — достаточный срок, чтобы собрать ясную картину и навести порядок.

Провести аудит текущего решения

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

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

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

Зафиксировать, что именно является собственным продуктом

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

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

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

Проверить права на код и архитектуру
 

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

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

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

Выделить, какие модули нужно разработать или переработать

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

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

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

Что в итоге можно успеть за 30 дней

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

За 30 дней у бизнеса должен появиться набор материалов для предметного разговора о продукте. После этого его можно объяснить без общих слов: какую задачу он решает, как устроен и в чем его собственная ценность.

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

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