Как инвестору провести due diligence в M&A‑сделках
Согласно исследованию Aspring Capital за последние два года сектор IT и программного обеспечения (ПО) — один из лидеров по количеству сделок слияния и поглощения на российском рынке. Значительный рост спроса на активы технологических компаний наблюдается с осени 2023 года, поэтому инвесторам важно уметь правильно оценивать ключевой IT–актив компании, — программное обеспечение.
В своей статье рассмотрю юридические аспекты оценки программного обеспечения в контексте M&A‑сделок, подскажу, как правильно провести due diligence ПО до совершения сделки, и отмечу, на что еще важно обратить внимание.
Зачем в M&A‑сделках проводить due diligence
В этой статье я рассматриваю due diligence как юридическую проверку программного обеспечения перед приобретением этого актива или бизнеса, где софт — ключевой актив. Результат due diligence — отчет с описанием рисков и способов митигации таких рисков.
При анализе программного обеспечения наряду с экономическим потенциалом важно оценивать юридические риски. Если этого не сделать, инвестиции могут в лучшем случае оказаться «токсичными» — нужно будет проводить разные затратные юридические ритуалы, чтобы привести их в порядок. Например, доплачивать авторам ПО за уступку прав, если договоры изначально были оформлены неправильно, или налоги за некорректный учет нематериальных активов. В худшем случае купленный актив может и вовсе оказаться не вашим из‑за недостающих правоустанавливающих документов, например, если внештатные разработчики формально остались правообладателями компонентов ПО.
Почему мыслить стандартно = потерять деньги
Когда люди сталкиваются со словами, связанными с правообладанием, то часто предполагают, что это исключительно юридическая область. Однако, когда дело доходит до проверки прав на программное обеспечение, ситуация не так проста.
Проверка всех исторических рисков выходит за рамки возможностей юристов, а чтобы юридическое заключение в области ПО обладало ценностью, нужны специальные технические знания, понимание архитектуры продукта. И инвестору, и юристу до сделки важно задать правильные вопросы таргету. Например, какие боли — специфические юридические риски — могут быть у этого продукта?
- Составное ПО с чужими компонентами: продукт может включать open‑source библиотеки с ограничительными/вирусными лицензиями, что создает риск принудительного раскрытия исходного кода всего продукта.
- «Невидимые» соавторы: в разработке участвовали стажеры, консультанты или сотрудники других компаний, права которых не были оформлены.
- Код, написанный до трудоустройства: разработчик использовал наработки из предыдущих проектов или личные разработки, права на которые не перешли к компании.
- Форк чужого продукта: продукт создан на основе существующего ПО, но права на базовую часть не принадлежат компании.
- Разработка по договору услуг: права на код остались у исполнителя, поскольку договор был оформлен как оказание услуг, а не создание РИДа.
Также в IT‑отрасли присутствует терминологический барьер: нет единых стандартов для описания сущностей. Так, технические специалисты даже одной компании при предоставлении юристам информации могут одинаковую сущность называть разными словами: эпик, сторя и прочее.
Представить такую утопию, где юристы смогут проанализировать все документы, — невозможно, поэтому все стороны сделки должны стремиться проводить встречи для уточнения деталей. Так, юристы должны объяснить инвестору, кто автор софта, а команда таргета — предоставить точные сведения об архитектуре ПO: его внутреннем устройстве, количестве подсистем, самостоятельных компонентов и их взаимосвязях.
Именно поэтому традиционный подход к due diligence ПО оказывается неэффективным: для проверки такого актива нужна междисциплинарная команда — юристы, работающие в связке с техническими специалистами. Речь не идет о том, что юрист должен стать программистом, или наоборот. Важно обеспечить эффективное взаимодействие между специалистами разных профилей.
Вот как это работает на практике:
- Технический специалист анализирует архитектуру ПО, выявляет использованные библиотеки и компоненты, изучает историю разработки в системах версионирования.
- Юрист на основе технической информации формулирует правовые вопросы, анализирует документооборот и оценивает юридические риски.
- Уже совместно эксперты определяют критические точки для углубленной проверки и разрабатывают план митигации рисков.
Такой подход более эффективен, чем попытки юриста самостоятельно разобраться в технических тонкостях или технического специалиста — в правовых нюансах.
Рассылка: как вести бизнес в России
Пять полезных писем пришлем сразу после подписки. В них — бизнес‑идеи, готовые промпты для нейросетей, советы, как выбрать налоговый режим и получать пассивный доход
С чего начинать проверку прав на ПO
Бизнес должен принять риск, что в силу специфики такого объекта, как ПО, на 100% выявить все риски и установить точную картину не получится никогда. Но точная картина и не нужна, важна разумная степень достоверности. А к ней приблизиться вполне реально, если забыть о стандартном юридическом подходе к due diligence.
Любая проверка прав на ПО должна начинаться с установления следующих фактических обстоятельств:
- Сколько в ПО самостоятельных компонентов и как они связаны?
- Кто их авторы?
- В какие периоды времени созданы компоненты софта?
Это те обстоятельства, которые юристы сами установить не могут, но и полагаться только на ответы компании тоже нельзя. Поэтому юристы должны приложить максимум усилий и помочь компании — владельцу ПО собрать нужную информацию.
Чек‑лист для инвестора: какую информацию нужно запросить у таргета
Я подготовила подробный чек‑лист, который поможет выяснить всю необходимую информацию. Вот что нужно запросить:
- Подробное описание архитектуры ПО, в том числе схемы с указанием структурных элементов, из которых состоит софт, их названий.
- Краткое описание функционала каждого из таких элементов — для определения, является ли ПО составным.
- Период разработки MVP. Часто ПО начинало разрабатываться в один период, а отношения с автором оформляли позднее — эта информация поможет обнаружить такие казусы и исправить ситуацию.
- Процесс разработки ПО: как и где происходит постановка задачи, хранение кода; если это электронная среда разработки, отражен ли этот факт в локальных актах.
- Структуру команды разработки и процесс взаимодействия внутри нее, чтобы верифицировать круг авторов и правообладателей.
- Перечень лиц, которым когда‑либо был предоставлен доступ к среде разработки с указанием: ФИО, включая внештатных разработчиков; должности по штатному расписанию; роли в разработке; даты приема на работу для штатных работников, заключения ГПД или начала работы без договора для внештатных работников; даты увольнения или прекращения гражданско‑правового договора; информацию о количестве коммитов в репозитории в процентном и абсолютном выражении.
- Описание конкретного вклада в разработку ПО каждого из лиц, кто участвовал в его создании, в том числе лиц, не имевших доступа в информационные системы.
- На проверку цепочки переходов исключительного права на ПО от авторов софта до текущего предполагаемого правообладателя, оценку правомерности.
- На анализ правоотношений при создании обновлений и новых версий, правомерность выполнения доработок и модификаций программного продукта.
- На оценку правомерности владения экземплярами ПО.
- На анализ наличия у приобретаемой компании правовых оснований для распоряжения исключительными правами на ПО.
- На наличие side–ground IP — ПO, создание которого не было предметом договора. Например, такая ситуация может возникнуть в рамках техподдержки софта, когда оказание услуг на самом деле включает разработку ПО.
Налоговый контекст
Порой бизнес оценивает риски, о которых пишут консультанты в отчетах, как теоретические. Но это не так. Если не понимать исторические риски, то это чревато запретом на использование ПО, де‑факто — его утратой. Как итог — продукт или его критические компоненты будет невозможно коммерциализировать, а от авторов можно получить денежные претензии. Проверка прав также влияет на финансовую модель и налоговое риски.
Текст договоров в отношении распоряжения правами на ПО часто включают положения, характерные для заказной разработки. В них стороны названы как «исполнитель» и «заказчик», присутствуют упоминания «выполнения работ по разработке ПО», встречаются требования к ПО и элементы технического задания. ФНС может переквалифицировать такие договоры в сервисную разработку с доначислением НДС.
Данные учета придется корректировать, если в процессе due diligence права на ПО будут не подтверждены. Поставленные в компании на учет такие нематериальные активы следует оценивать в контексте налоговых и бухгалтерских последствий.
Правообладание ПО и состав его компонентов напрямую влияет на возможность применения налоговых льгот в контексте санкций и положений налогового IT- маневра. Например, использование запрещенных компонентов не позволит применять нулевую ставку по НДС при лицензировании ПО, ведь такой софт Минцифры не зарегистрирует в Едином реестре российских программ для электронных вычислительных машин и баз данных.
Заключение
- Для инвестирования в IT‑бизнес важно тщательно разобраться не только в его коммерческой привлекательности, но и оценить юридические риски, чтобы не получить на выходе «кота в мешке». Для этого обязательно нужно провести due diligence.
- Традиционная проверка силами только юристов не подходит для программного обеспечения. Здесь нужна междисциплинарная команда из юристов и технических специалистов, понимающих терминологию и процесс разработки.
- Начинать необходимо с установления фактических обстоятельств с помощью технических экспертов. А после — пройтись по детальному чек‑листу запросов к таргету.
- Неподтвержденные права делают ПО бесполезным активом, блокируют коммерциализацию и создают условия для предъявления претензий. Некорректные договоры разработки могут быть переквалифицированы ФНС в услуги с доначислением НДС, а использование запрещенных компонентов лишает права на налоговые льготы.
