Компания получила IT-льготы. Почему это еще не значит, что она сможет их сохранить

2026-07-22 21:54:41 Время чтения 12 мин 15

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

На практике именно после этого начинается наиболее важная часть работы.

Компании необходимо не только формально соответствовать условиям получения льгот, но и быть готовой в любой момент подтвердить:

  1. чем она занимается в действительности;
  2. из каких операций складывается профильная выручка;
  3. кому принадлежат права на программное обеспечение;
  4. что именно компания продает клиентам;
  5. соответствуют ли договоры, первичные документы и фактические процессы заявленной IT-модели.

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

Поэтому главный вопрос для бизнеса сегодня звучит не так:

«Получили ли мы IT-аккредитацию?»

А так:

«Сможем ли мы доказать право на льготы, если документы и фактическую деятельность начнут проверять?»

Аккредитация сама по себе не подтверждает каждую льготную операцию

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

Но этого недостаточно, если:

  1. в льготную выручку включаются операции, которые сложно отнести к IT-деятельности;
  2. договоры не отражают реальную модель работы;
  3. права на ПО оформлены не полностью;
  4. разные услуги объединены в один общий предмет договора;
  5. первичные документы не позволяют понять, за что именно заплатил клиент;
  6. фактические процессы расходятся с тем, что компания заявляет в документах.

Аккредитация подтверждает статус организации. Но право на конкретные налоговые преимущества связано еще и с тем, насколько компания выполняет установленные законодательством условия и может это документально доказать.

Что обычно становится предметом проверки

1. Из чего складывается выручка компании

Один из ключевых вопросов — какие поступления компания относит к профильным.

На практике IT-бизнес редко продает только один продукт. В структуре выручки одновременно могут находиться:

  1. лицензии на программное обеспечение;
  2. предоставление удаленного доступа;
  3. разработка и доработка продукта;
  4. техническая поддержка;
  5. внедрение;
  6. интеграция;
  7. обучение пользователей;
  8. аналитические и консультационные услуги;
  9. маркетинг;
  10. обслуживание оборудования;
  11. предоставление специалистов в команду заказчика.

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

Для каждой модели необходимо отдельно понимать:

  1. что именно получает клиент;
  2. какой результат передает компания;
  3. какие права предоставляются;
  4. является ли услуга самостоятельной;
  5. как она описана в договоре и закрывающих документах;
  6. соответствует ли содержание операции критериям профильной деятельности.

Название платежа или договора само по себе не определяет его юридическую и налоговую природу.

2. Что компания фактически продает клиенту

В договоре может быть написано «предоставление права использования программного обеспечения», но фактически основным результатом для клиента окажутся:

  1. консультации;
  2. ручная обработка данных;
  3. работа выделенной команды;
  4. маркетинговое сопровождение;
  5. ведение проектов;
  6. эксплуатация инфраструктуры.

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

Обе ситуации создают риск.

Налоговый анализ начинается не с названия договора, а с ответа на вопрос:

Какой экономический и технологический результат получает клиент?

После этого уже проверяется, совпадает ли реальная модель с:

  1. предметом договора;
  2. порядком расчета цены;
  3. актами;
  4. техническими заданиями;
  5. счетами;
  6. перепиской;
  7. описанием продукта;
  8. маркетинговыми материалами.

3. Кому принадлежат права на программное обеспечение

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

Типичные проблемы:

  1. код создавали сотрудники, но служебные произведения оформлялись формально;
  2. часть продукта разработали подрядчики без корректного отчуждения прав;
  3. нет подтверждений передачи исходного кода и результатов работ;
  4. права принадлежат одному юридическому лицу группы, а продукт продает другое;
  5. в продукте используются сторонние компоненты, лицензии на которые не проанализированы;
  6. права на старые версии программы невозможно подтвердить;
  7. товарный знак, интерфейс, документация и база данных принадлежат разным лицам.

Для бизнеса это не только риск спора об интеллектуальной собственности.

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

4. Совпадает ли продукт в документах и в реальности

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

Например:

  1. появились новые модули;
  2. изменился правообладатель;
  3. продукт стал частью более крупной платформы;
  4. компания продает не саму программу, а комплекс услуг вокруг нее;
  5. в договоры включены функции, которые не отражены в реестровом описании;
  6. изменились наименование, архитектура или способы предоставления доступа.

Само включение программы в реестр — значимый актив, но оно не заменяет регулярную проверку соответствия продукта, договоров и фактических процессов.

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

5. Как устроена группа компаний

В технологическом бизнесе нередко используется несколько юридических лиц:

  1. одно владеет программным обеспечением;
  2. другое заключает договоры с клиентами;
  3. третье нанимает разработчиков;
  4. четвертое занимается маркетингом;
  5. отдельная компания получает платежи или работает с иностранными заказчиками.

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

Необходимо понимать:

  1. на каком основании одно лицо использует ПО другого;
  2. кто несет расходы на разработку;
  3. кто заказывает доработки;
  4. как распределяются доходы;
  5. за что выплачивается вознаграждение внутри группы;
  6. кто предоставляет клиенту конечный результат;
  7. где фактически находятся сотрудники и ключевые компетенции.

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

6. Как оформлены первичные документы

Даже сильная договорная конструкция не поможет, если закрывающие документы состоят из одной строки:

«Услуги оказаны в полном объеме».

Из акта или отчета должно быть понятно:

  1. какие работы выполнены;
  2. к какому продукту они относятся;
  3. какой результат передан;
  4. за какой период;
  5. по какому заданию;
  6. какие права получил заказчик;
  7. как рассчитано вознаграждение.

Особенно опасны ситуации, когда в одном акте объединены:

  1. лицензия;
  2. разработка;
  3. сопровождение;
  4. консультации;
  5. обучение;
  6. маркетинг;
  7. предоставление сотрудников.

В таком случае компания сама лишает себя возможности уверенно показать, какая часть платежа относится к конкретному виду деятельности.

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

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

Но бухгалтер видит операцию через:

  1. счет;
  2. назначение платежа;
  3. договор;
  4. акт;
  5. статью учета.

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

Поэтому проверка права на IT-льготы не может быть задачей только бухгалтерии.

В ней должны участвовать:

  1. финансовая служба;
  2. налоговые консультанты;
  3. юристы;
  4. продуктовая команда;
  5. руководители продаж;
  6. сотрудники, отвечающие за интеллектуальную собственность.

Необходимо сопоставить четыре уровня:

  1. Продукт — что компания реально создает и продает.
  2. Договоры — как оформлены отношения с клиентами и партнерами.
  3. Первичные документы — что именно закрывается и оплачивается.
  4. Налоговый учет — как операции попадают в расчет льготной выручки.

Если эти уровни не совпадают, риск возникает даже у компании с сильным продуктом и действующей аккредитацией.

Семь признаков, что IT-компании нужен аудит

Проверку стоит проводить, если:

1. Компания быстро выросла

Договоры и процессы создавались на разных этапах, разными людьми и под разные модели продаж.

2. Появилось несколько продуктов

Выручка смешивается, а права и документы по каждому продукту оформлены неодинаково.

3. Есть значительная доля услуг

Не всегда понятно, являются ли они частью работы с программой или самостоятельной деятельностью.

4. В группе несколько юридических лиц

Права, сотрудники, продажи и расходы распределены между разными компаниями.

5. Продукт включен в реестр ПО

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

6. Договоры давно не пересматривались

Хотя фактическая работа с клиентами уже устроена иначе.

7. Документы начинают собирать только после требования

В этот момент времени на исправление модели уже нет — остается объяснять те документы и процессы, которые существовали в проверяемом периоде.

Что должно входить в аудит IT-деятельности

Качественный аудит — это не только проверка одного расчета.

Обычно необходимо проанализировать:

  1. статус аккредитации;
  2. соответствие компании установленным требованиям;
  3. структуру выручки;
  4. ключевые договоры с клиентами;
  5. лицензионную модель;
  6. договоры разработки и сопровождения;
  7. права на программное обеспечение;
  8. документы по сотрудникам и подрядчикам;
  9. сведения о продукте в реестре российского ПО;
  10. отношения внутри группы компаний;
  11. акты, отчеты и технические задания;
  12. маркетинговые материалы и описание продукта;
  13. логику налогового и бухгалтерского учета.

Результатом должна стать не общая фраза «риски есть», а конкретная карта:

  1. какие операции безопасны;
  2. какие требуют дополнительного обоснования;
  3. где нужно изменить договоры;
  4. какие документы необходимо восстановить;
  5. что исправить в процессах;
  6. как распределить ответственность между юристами, финансами и продуктовой командой;
  7. какие доказательства следует собирать регулярно.

Проверять нужно до запроса ФНС

После получения требования компания уже работает с прошлым.

Она не может задним числом изменить:

  1. предмет подписанного договора;
  2. содержание переписки;
  3. порядок взаимодействия с клиентом;
  4. фактическую роль программы;
  5. движение денег;
  6. объем оказанных услуг;
  7. структуру группы.

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

Поэтому задача предварительного аудита — не найти формальные ошибки ради отчета.

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

Главный вывод

Право на IT-льготы существует не внутри свидетельства об аккредитации и не в одной бухгалтерской таблице.

Оно подтверждается всей системой работы компании:

  1. продуктом;
  2. договорами;
  3. правами на ПО;
  4. структурой выручки;
  5. первичными документами;
  6. фактическими процессами.

Компания может действительно быть IT-бизнесом, но потерять возможность уверенно защищать льготы из-за слабого оформления.

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

"Зарцын и партнеры"  проводит аудит IT-деятельности и права компании на применение налоговых льгот.

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

Оставить заявку на аудит можно по ссылке - написать.