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

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

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

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

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

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

Какие выплаты нужно анализировать

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

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

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

Как считать лимит 30%

Главная формула выглядит просто: сумма выплат иностранным лицам делится на выручку от предоставления права использования конкретного ПО и умножается на 100. Порог - выплаты должны быть менее 30% от такой выручки за истекший календарный год.

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

Например, если выручка по реестровому ПО за год составила 10 млн рублей, а выплаты иностранным разработчикам по этому продукту - 2,5 млн рублей, показатель будет 25%. Формально он ниже 30%. Но даже в такой ситуации нужно хранить договоры, акты, платежные документы, бухгалтерскую справку и сам расчет.

Если при той же выручке выплаты составили 4 млн рублей, показатель уже будет 40%. Это зона риска. В такой ситуации нельзя просто подавать уведомление как есть. Нужно разбирать, какие суммы действительно относятся к зарегистрированному ПО, какие нет, где есть спорные договоры и как компания может подтвердить свою позицию.

Что делать, если выручки нет, а выплаты были

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

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

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

Какие документы собрать

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

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

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

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

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

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

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

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

Есть ситуации, где подача «на автомате» особенно опасна. В них лучше сначала провести внутреннюю проверку, а уже потом направлять уведомление или обновлять сведения.

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

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

Что указывать в уведомлении

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

С 1 марта 2026 года ежегодное уведомление по подпунктам «н» и «у» нужно подавать не позднее 1 июня. Поэтому ждать конца мая рискованно. Если в учете нет раздельной аналитики по каждому продукту, сбор документов может занять не пару часов, а несколько недель.

Хороший стандарт - делать отдельный расчет и отдельный комплект документов по каждому ПО из реестра. Так проще объяснить цифры, если у Минцифры или оператора реестра возникнут вопросы.

Как организовать процесс внутри компании

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

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

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

Вывод

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

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