Документы для продажи IT-компании: что готовить заранее: практика

Антон пришёл с папкой. Буквально — с бумажной папкой, в которой лежали распечатки: устав, несколько договоров с клиентами, выписка из ЕГРЮЛ. «Покупатель просит документы, — сказал он. — Я собрал, что нашёл».

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

Этот кейс — о том, что покупатель IT-компании проверяет на самом деле. И о том, почему документы для продажи IT-компании нужно начинать готовить не тогда, когда появился покупатель, а значительно раньше.

Антон строил IT-сервис больше восьми лет. Автоматизация бизнес-процессов для среднего бизнеса — ниша узкая, конкурентная, но прибыльная. Оборот подбирался к двумстам миллионам. Несколько десятков сотрудников, устойчивая клиентская база, несколько крупных контрактов с понятными компаниями.

Покупатель появился через знакомых — стратег из смежной отрасли, который хотел добавить IT-компетенции к своему основному бизнесу. Переговоры шли неплохо. Стороны примерно сошлись по цене. И тут покупатель сказал стандартную фразу: «Нам нужно провести due diligence. Пришлите документы».

Антон собрал то, что счёл очевидным. Устав. Выписку. Несколько клиентских договоров. Финансовую отчётность за последние два года. Всё это лежало в папке — аккуратно, с разделителями.

Когда я увидел этот список, первым моим вопросом было: «А где IP-документация?» Антон посмотрел на меня с искренним непониманием. «Какая IP-документация? Это же наш продукт, мы его написали сами».

Именно здесь начинается история о том, что «написали сами» и «юридически принадлежит компании» — это два разных утверждения. И покупатель это знает.

Что именно было в той папке — и чего в ней не было — стало понятно только после первого запроса от юристов покупателя.

Стандартный запрос на due diligence в IT-сделке — это не список документов. Это структурированный вопросник на несколько десятков пунктов, разбитый по блокам. Юристы покупателя прислали его через неделю после первого разговора.

Я покажу логику, не сам список — он у каждого покупателя свой, но структура везде похожа.

Первый слой — юридический. Корпоративная история: кто владел компанией, когда, как менялась структура. Все сделки с долями за последние несколько лет. Судебные споры — завершённые и текущие. Обременения. Поручительства. Это то, что большинство фаундеров более-менее готовы предоставить.

Второй слой — интеллектуальная собственность. Вот здесь начинается настоящая проверка для IT. Кому принадлежит код? Если разработчики работали как самозанятые или ИП — есть ли договоры с явной передачей исключительных прав? Если работали по трудовым договорам — есть ли в этих договорах корректные формулировки о служебных произведениях? Зарегистрированы ли товарные знаки? Есть ли лицензионные соглашения на используемые библиотеки и компоненты с открытым исходным кодом — и совместимы ли их лицензии с коммерческим использованием?

Третий слой — операционный и коммерческий. Клиентские договоры: есть ли в них ограничения на уступку прав при смене собственника? Ключевые сотрудники: есть ли с ними NDA, non-compete, соглашения об удержании? Подрядчики: кто из них критичен для работы продукта и на каких условиях работает?

Антон был готов к первому слою. Ко второму — частично. К третьему — почти нет.

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

Следующие несколько недель мы занимались тем, что я называю «документальной археологией». Это неприятная работа — особенно когда понимаешь, что часть артефактов безвозвратно утеряна.

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

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

Проблема вторая: трудовые договоры. Часть сотрудников была принята на работу по шаблонным договорам, в которых формулировки о служебных произведениях либо отсутствовали, либо были некорректными. Это решаемо — дополнительные соглашения к трудовым договорам, — но требует времени и аккуратности. Сотрудники задают вопросы. Некоторые нервничают. Нужно объяснять, не раскрывая факт переговоров о продаже.

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

Решение нашли через структуру сделки: покупатель приобретал долю в компании, а не активы. Юридически компания оставалась той же — менялся только собственник. Большинство оговорок об уступке прав в таком случае не срабатывают. Но это потребовало дополнительного юридического анализа каждого контракта.

Ключевая развилка — IP третьего разработчика. Это едва не остановило сделку. Покупатель хотел либо полного урегулирования, либо существенного снижения цены. Мы предложили третий вариант: escrow-удержание части суммы на срок, достаточный для попытки урегулирования, плюс страховое покрытие IP-риска. Покупатель согласился — но это добавило к сделке три недели и дополнительные расходы.

Одна незакрытая проблема с правами на код едва не остановила сделку. В итоге она изменила её структуру.

Сделка закрылась. Цена — в пределах того, на что Антон рассчитывал изначально. Это хороший исход, и я не хочу его обесценивать.

Но структура оказалась другой. Часть суммы была выплачена сразу. Часть — в формате earnout: привязана к финансовым показателям компании в течение двух лет после закрытия. Это произошло не потому, что покупатель хотел снизить цену. Это произошло потому, что несколько рисков остались незакрытыми — и покупатель справедливо захотел разделить их с продавцом.

Earnout — не катастрофа. Антон получил деньги и продолжает участвовать в операционном управлении на переходный период. Но это не то, что он планировал. Он планировал чистый выход.

Что изменилось бы при подготовке за год до сделки? Почти всё. IP-документация могла быть приведена в порядок без спешки. Трудовые договоры — переоформлены планово, без тревоги сотрудников. Клиентские контракты — пересмотрены при очередном продлении. Разработчик-ИП — найден и урегулирован без давления дедлайна.

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

Earnout мог быть не нужен. Но для этого нужно было начать готовиться раньше.

Антон — четвёртый IT-фаундер за последние полтора года, с которым я работал над подготовкой к сделке. У всех четырёх была одна и та же структурная проблема: документальная история компании не велась как актив. Она велась как административная нагрузка — или не велась вовсе.

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

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

Три категории документов, которые стоит начинать вести с первого дня:

IP-документация. Каждый раз, когда кто-то создаёт что-то для компании — сотрудник, подрядчик, фрилансер, — должен быть документ, фиксирующий передачу прав. Не «написали сами», а «написали, и вот договор, подтверждающий, что права принадлежат юридическому лицу».

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

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

Для сравнения — другой фаундер, с которым я работал примерно в то же время. Он пришёл не с папкой, а с ссылкой на data room: структурированное облачное хранилище, разбитое по разделам, с актуальными версиями всех ключевых документов. Он готовил его два года — не к конкретной сделке, а «на всякий случай». Сделка с его компанией закрылась за шесть недель. Due diligence занял меньше трёх.

Документы — это не для продажи. Это для управления. Продажа — просто момент, когда это становится видно.

Это единичный случай или типичная ситуация для IT-компаний?

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

А если покупатель — финансовый инвестор, а не стратег? Требования другие?

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

Что делать, если я вижу у себя похожие проблемы прямо сейчас?

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

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

Документы для продажи IT-компании — это не отдельная задача, которую решают перед сделкой. Это отражение того, как компания управлялась всё это время.

Если этот кейс читается как твоя история — не обязательно один в один, достаточно структурного сходства — приходи на разбор. Работаю с фаундерами IT-компаний от 80 миллионов выручки, которые думают о выходе сейчас или в горизонте двух лет. Беру до трёх новых запросов в месяц.

Напиши на hi@vvetrov.com: кто ты, что за компания, на каком этапе.

Подробнее о том, как устроен процесс подготовки к сделке — в полном гайде по продаже бизнеса. О переговорной стороне той же темы — в материале «Переговоры о продаже IT-компании: этапы и ошибки». Если твой бизнес не IT, но вопрос документов стоит так же остро — смотри кейс по B2B-услугам.

P.S. Если ты сейчас думаешь «у меня ещё есть время» — именно это и говорил Антон, когда пришёл с папкой.

Апрель 2026. Автор — Виталий Ветров, практикующий юрист и эксперт по корпоративным сделкам.