Выплаты иностранным разработчикам и реестр ПО: как проверить риск превышения 30%
Что нужно проверить до подачи уведомления в Минцифры
Проблема начинается не тогда, когда компания заплатила иностранному разработчику.
Проблема начинается тогда, когда эти выплаты никто заранее не связал с конкретным программным продуктом из реестра, не отделил от общей выручки компании и не посчитал процент по правилам Минцифры.
На бумаге все выглядит просто: есть выручка по ПО, есть выплаты иностранным лицам, нужно проверить лимит 30%.
На практике именно здесь компании чаще всего ошибаются. Берут не ту выручку. Считают не те договоры. Не видят иностранный контроль у российского подрядчика. Или считают, что договор “на техподдержку” точно не относится к разработке, хотя в актах прямо написано: доработка функционала, адаптация, модификация кода.
Итог неприятный: формально компания подает уведомление, но по сути приносит в Минцифры не доказательства соответствия, а набор цифр без понятной логики.
Разберем, что именно нужно проверить.
Какие выплаты попадают в расчет
Проверять нужно не все расходы компании, а только выплаты, связанные с конкретным ПО из реестра.
В зону риска попадают выплаты в пользу:
- иностранных юридических лиц;
- иностранных физических лиц;
- иностранных ИП и самозанятых за рубежом;
- российских компаний, которые контролируются иностранными лицами;
- агентов и представителей иностранных лиц;
- российских организаций, которые действуют в интересах таких агентов или представителей.
Важно: смотрим не только на название договора, а на фактический смысл работ.
Если иностранный подрядчик:
- писал код;
- дорабатывал функционал;
- создавал отдельный модуль;
- адаптировал продукт под клиента;
- менял архитектуру;
- исправлял ошибки в логике работы ПО;
- передавал права на компонент;
- выполнял работы, которые развивают зарегистрированное ПО
Такие выплаты нужно включать в первичный анализ.
Даже если договор называется “техническая поддержка” или “консультационные услуги”.
Главный вопрос не в названии договора. Главный вопрос: помогали ли эти работы создавать, развивать, адаптировать или модифицировать именно то ПО, которое включено в реестр.
Что обычно не включается в расчет
Не нужно автоматически тащить в расчет все расходы компании.
Как правило, не учитываются:
- расходы по другим программным продуктам;
- маркетинг и реклама;
- бухгалтерские услуги;
- юридическое сопровождение;
- общехозяйственные расходы;
- зарплата российских сотрудников;
- выплаты российским подрядчикам без иностранного контроля;
- выплаты российским подрядчикам без иностранного контроля; • расходы, которые не относятся к зарегистрированному ПО.
Но есть нюанс.
Если юридический договор по названию “не про разработку”, а по актам видно, что подрядчик дорабатывал код, адаптировал продукт или создавал модуль, такие суммы лучше проверить отдельно.
Именно такие “пограничные” договоры чаще всего становятся проблемой при проверке.
Главная формула проверки
Нужно посчитать, какой процент выплаты иностранным лицам составляют от выручки по конкретному ПО.
Формула простая:
Сумма выплат иностранным лицам / выручка от предоставления права использования ПО × 100
Порог: выплаты должны быть менее 30% от выручки за истекший календарный год.
Ключевое слово здесь - конкретному ПО.
Нельзя брать всю выручку компании, если в реестре находится только один продукт.
Например, у компании общая выручка 100 млн рублей. Но по зарегистрированному ПО она получила только 12 млн рублей. Для расчета берется не 100 млн, а именно 12 млн.
Иначе расчет будет красивым, но неправильным.
Пример безопасной ситуации
Компания за 2025 год получила по зарегистрированному ПО 10 000 000 рублей выручки.
И заплатила иностранным разработчикам за доработку продукта 2 500 000 рублей.
Считаем:
2 500 000 / 10 000 000 × 100 = 25%
Показатель ниже 30%.
Формально лимит соблюден.
Но даже в такой ситуации нужно подготовить документы: договоры, акты, платежки, бухгалтерскую справку и расчет. Потому что Минцифры интересует не только итоговая цифра, но и то, как компания к ней пришла.
Пример рискованной ситуации
Выручка по ПО за 2025 год: 10 000 000 рублей.
Выплаты иностранным разработчикам: 4 000 000 рублей.
Считаем:
4 000 000 / 10 000 000 × 100 = 40%
Показатель выше 30%.
Это уже риск несоответствия требованиям реестра.
В такой ситуации нельзя просто “подать как есть”. Нужно разбирать структуру выплат: какие работы действительно относились к зарегистрированному ПО, какие нет, какие суммы подтверждены документами, где есть спорные договоры, а где нужна отдельная правовая позиция.
Самая опасная ситуация: выручка ноль, выплаты есть
Отдельный красный флаг - когда по ПО за год нет выручки, но выплаты иностранным разработчикам были.
Например:
- продукт еще дорабатывался;
- коммерческие продажи не начались;
- доступ к ПО не предоставлялся;
- лицензий не было но иностранным разработчикам компания платила.
В такой ситуации обычный расчет невозможен: делить на ноль нельзя.
А требование “менее 30% от выручки” фактически становится проблемным, потому что выручки нет, а выплаты есть.
Здесь нужен не просто расчет, а отдельное пояснение и правовая позиция. И готовить ее лучше заранее, до подачи уведомления.
Какие документы нужно собрать
Минимальный комплект для внутренней проверки
- карточка ПО из реестра;
- номер реестровой записи;
- данные о правообладателе;
- оборотно-сальдовая ведомость по выручке от этого ПО;
- бухгалтерская справка по выручке за год;
- реестр договоров с разработчиками и подрядчиками;
- договоры с иностранными разработчиками;
- акты выполненных работ;
- счета и инвойсы;
- платежные поручения;
- справка бухгалтерии о сумме выплат;
- расчет процента;
- пояснительное письмо для подачи в реестр;
- документы по структуре владения подрядчика, если есть риск иностранного контроля.
Главная задача - показать связку:
конкретное ПО → конкретная выручка → конкретные выплаты → понятный расчет → подтверждающие документы.
Если этой цепочки нет, цифры выглядят слабо.
Как проверить подрядчиков
- Это иностранное юридическое лицо?
Если да, выплаты включаются в анализ.
- Это иностранное физическое лицо, ИП или самозанятый за рубежом?
Если да, выплаты также проверяются.
- Это российская компания, но у нее есть иностранный контроль?
Если да, выплаты могут попасть в зону риска.
- Подрядчик действует как агент или представитель иностранного лица?
Если да, выплаты нужно анализировать отдельно.
- Работы относились именно к зарегистрированному ПО?
Если да, суммы считаются по этому ПО, а не “по компании в целом”.
- Сумму можно подтвердить документами?
Если нет, нужно готовить бухгалтерскую справку и пояснение.
На практике проблемы часто возникают не с очевидными иностранными компаниями, а с российскими подрядчиками, у которых в структуре владения есть иностранное лицо. Такие связи лучше выявить до подачи уведомления, а не после запроса Минцифры.
Красные флаги перед подачей уведомления
Проверку нужно усилить, если:
- выплаты иностранным лицам есть, а выручка по ПО небольшая;
- выплаты приближаются к 30%;
- выплаты уже превышают 30%;
- выручка по ПО равна нулю;
- нет раздельного учета по конкретному продукту;
- один договор закрывает сразу несколько программных продуктов;
- подрядчик российский, но структура владения непрозрачная;
- договор называется “консультации”, а в актах есть разработка;
- документы на иностранном языке без перевода;
- суммы в актах, платежках и бухгалтерской справке не совпадают;
- платежи шли физическим лицам за рубежом;
- невозможно быстро объяснить, почему выплата относится или не относится к конкретному ПО.
Если хотя бы один пункт совпал, лучше не подавать уведомление “на автомате”. Сначала нужно привести расчет и документы в порядок.
Что указывать в уведомлении
В уведомлении по подпункту «у» обычно нужно отразить:
- сумму выплат за истекший календарный год;
- выручку по зарегистрированному ПО за тот же год;
- процент выплат от выручки;
- документы, которые подтверждают расчет.
С 1 марта 2026 года ежегодное уведомление по подпунктам «н» и «у» подается не позднее 1 июня.
Поэтому ждать конца мая опасно. Если в учете нет раздельной аналитики по конкретному ПО, сбор документов может занять не пару часов, а несколько недель.
Рабочий алгоритм для компании
Чтобы не собирать документы в пожарном режиме, действуйте по шагам.
- Возьмите список всех программных продуктов компании в реестре Минцифры.
- По каждому ПО отдельно определите выручку за календарный год.
- Поднимите все договоры с разработчиками и подрядчиками за этот же период.
- Отделите выплаты иностранным лицам и подрядчикам с возможным иностранным контролем.
- Проверьте, какие работы относились именно к зарегистрированному ПО.
- Сложите выплаты по каждому ПО отдельно.
- Рассчитайте процент по формуле.
- Проверьте, не достигает ли показатель 30%.
- Подготовьте бухгалтерскую справку и подтверждающие документы.
- Сформируйте пояснение для подачи в реестр.
- Подайте уведомление через личный кабинет.
- Подпишите уведомление УКЭП.
- Сохраните подтверждение подачи и весь комплект документов.
Хороший стандарт - делать отдельный расчет и отдельный комплект документов по каждому ПО из реестра. Так проще защищать позицию, если у Минцифры появятся вопросы.
Что мы рекомендуем сделать до подачи
Не ограничивайтесь фразой “у нас все в пределах лимита”.
Проверьте это документально.
Нужно убедиться, что:
- выплаты посчитаны корректно;
- они относятся именно к конкретному ПО;
- выручка взята не по всей компании, а по зарегистрированному продукту;
- процент рассчитан правильно;
- показатель не достигает 30%;
- каждая сумма подтверждается договором, актом, платежкой или бухгалтерской справкой;
- по спорным подрядчикам есть понятное объяснение.
Именно это отличает безопасную подачу от формальной.
Нужна проверка перед уведомлением?
Мы в «Антиштраф» помогаем IT-компаниям проверить выплаты иностранным разработчикам, рассчитать процент по каждому ПО из реестра и подготовить комплект документов для подачи в Минцифры.
Разбираем не только цифры, но и смысл договоров: где обычная поддержка, где доработка кода, где адаптация, а где уже риск для реестра.
Если у вас были выплаты иностранным разработчикам или подрядчикам со сложной структурой владения, лучше проверить их до подачи уведомления.
Так вы подаете не просто сумму, а доказательную позицию. А это совсем другой уровень защиты.
