Целевой кредит для IT-компании: как банки считают ваш продукт, контракты и команду

Целевые кредиты для IT-компаний новые условия

Время на прочтение: 12 минут

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

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

Ниже разберем, как банки принимают решение по IT, что они считают «целевым», где чаще всего ломается заявка и как подготовиться так, чтобы разговор с банком был на одном языке. Если вы хотите посмотреть, как в целом устроено кредитование малого бизнеса на практике, это хорошая отправная точка — дальше будем углубляться именно в IT-специфику.

Что банк на самом деле финансирует, когда вы говорите «целевой кредит»

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

По IT чаще всего нормально проходят такие цели:

Разработка и доработка продукта — когда есть смета по ФОТ, подрядчикам, инфраструктуре, лицензиям, и понятно, что именно меняется в продукте и как это отражается в выручке.
Масштабирование продаж — маркетинг, лидогенерация, выход в новый регион, расходы на партнерскую сеть. Банку важен план по каналам и конверсиям, а не лозунг «усилим маркетинг».
Инфраструктура — серверы, оборудование, дата-центр, рабочие станции, безопасность. Тут проще, потому что появляется «железо», которое можно поставить на баланс.
Контрактное исполнение — когда есть договор, график платежей, бюджет проекта, и деньги нужны, чтобы закрыть кассовый разрыв до оплаты по этапам.

Сложнее проходят цели «на все подряд» или «на пополнение оборотки без объяснений». IT можно профинансировать и как оборотный кредит, но в целевом формате банк хочет видеть конкретику: куда, когда, сколько и за счет чего вернется.

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

У IT одна типовая боль — деньги приходят неровно. В одном месяце закрыли этап и получили 12 млн, в следующем — 3 млн и при этом фонд оплаты труда 6-7 млн. Плюс налоговый календарь, платежи за софт, реклама, подрядчики. На бумаге прибыль может быть, а касса — пустая.

Банк, когда видит неровный денежный поток, пытается ответить на три вопроса:

Какой у вас базовый уровень регулярных поступлений? Подписки, техподдержка, абонентка, SLA — все, что повторяется.
Сколько стоит удержание команды? В IT команда — это «производственный станок». Если вы не выдержите кассовый разрыв и начнете увольнять, проект проседает, банк это понимает.
Что случится, если крупнейший клиент задержит оплату? Это ключевой стресс-тест.

Поэтому задача предпринимателя — не «доказать, что мы крутые», а показать банку управляемость: вы понимаете, где у вас провалы по кассе, и чем закрываете. Здесь хорошо работает простой документ — платежный календарь на 3-6 месяцев с разбивкой поступлений и обязательных расходов. Не идеальный, а честный.

Как мыслит кредитный комитет: какие метрики в IT действительно решают

В IT много нематериального, но кредитный комитет все равно любит опираться на измеримое. Мы видим, что чаще всего в решении «тащат» следующие блоки:

1) Источник возврата и «качество выручки»

Не вся выручка равна. Для банка надежнее:

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

2) Маржинальность и способность обслуживать долг

Банк считает DSCR (простыми словами — хватает ли потока на платежи). И тут начинаются типичные ловушки IT: вы показываете «высокую прибыль», потому что часть расходов не проходит в официальной отчетности, или наоборот — прибыль «убита» из-за особенностей учета, хотя в кассе деньги есть. В обоих случаях кредитный комитет нервничает.

В нашей практике лучше всего работает связка: отчетность + управленка + расшифровки. Банку не нужно 200 страниц. Ему нужно понять, что цифры сходятся и вы не пытаетесь продать «воздух».

3) Риски команды

IT часто держится на 3-5 ключевых людях. Если лидер разработки или архитектор «выйдет из игры», сроки уедут, клиент начнет давить, выручка проседает. Банки это учитывают косвенно: через структуру бизнеса, систему мотивации, оформленность трудовых отношений, наличие дублеров, адекватность фонда оплаты труда к обороту.

4) Доказуемость продукта

Патенты и регистрация прав — хорошо, но для банка важнее коммерческая доказуемость: платящие клиенты, retention, backlog, pipeline, история внедрений. Здесь главное — не уходить в маркетинговые презентации. Лучше коротко: что продаем, кому, за сколько, как повторяем продажи, какой цикл сделки.

Документы, которые помогают IT пройти скоринг без лишнего театра

Большая ошибка — приносить в банк только бухгалтерию и надеяться, что «разберутся». В IT нужно упаковать историю так, чтобы риск-менеджер не додумывал за вас.

Что обычно усиливает заявку:

Реестр профильного ведомства и подтверждение статуса — если он есть, это реально повышает доверие и расширяет варианты программ.
Договоры с заказчиками и приложения: этапы, бюджеты, графики оплат. Если есть крупные контракты — это ваш главный актив для банка.
Сводный реестр проектов: 10-20 строк, клиент, продукт/услуга, срок, выручка, маржа, статус.
Платежный календарь и расчет кассовых разрывов — чтобы показать, зачем кредит именно сейчас.
Управленческий P&L с нормальной расшифровкой ФОТ, подрядчиков, инфраструктуры, маркетинга.
Документы по интеллектуальным правам: договоры с разработчиками, акты передачи прав, регистрация ПО, товарные знаки — чтобы банк не боялся, что «код принадлежит сотруднику».

И отдельный нюанс: если вы работаете с зарубежными заказчиками, банк будет задавать вопросы про валютный риск и «как вы переживете» изменение условий расчетов. Лучше подготовить ответы заранее, чем импровизировать на кредитном комитете.

Типичные ошибки IT-предпринимателей, которые приводят к отказу

Мы видим, что отказ по IT часто случается не потому, что бизнес слабый, а потому что заявка подана «в лоб».

Цель кредита формулируют размыто: «на развитие», «на расширение». Банк не понимает контроль и риски, начинает ужесточать условия или отказывает.
Слишком оптимистичный план: рост выручки в 3 раза без объяснения воронки продаж, команды, бюджета. Кредитный комитет такие истории видит ежедневно.
Один крупный клиент и нет плана диверсификации. Даже если клиент надежный, банк считает концентрацию риском.
Непрозрачная структура расходов: часть ФОТ в одном месте, часть в другом, подрядчики без договоров, платежи «на карту». Внутренние службы банка это не любят.
Интеллектуальные права не оформлены. Для банка это выглядит так: завтра команда разойдется, продукт останется «ничейным».
Путают оборотный кредит и инвестиционный. Инвестиционный требует подтверждения покупки/вложения, оборотный — подтверждения стабильного потока. Если просите инвестиционный, а тратите как оборотный, следующий раунд будет тяжелее.

Ограничения, о которых лучше знать до подачи

Чтобы не было сюрпризов, обозначим реальные ограничения, которые чаще всего всплывают в IT-кейсах:

Срок существования бизнеса: слишком молодой проект без подтвержденных продаж воспринимается как венчур. Классический банк венчур не кредитует, ему нужны признаки устойчивости.
Налоговый режим и отчетность: при упрощенной модели учета банк может попросить дополнительные расшифровки, чтобы понять маржу и поток.
Доля наличных и неформальных выплат: чем больше «серой» зоны, тем меньше кредитный лимит и выше ставка.
Качество дебиторки: если у вас акты подписываются с задержками, а оплаты «когда-нибудь», банк закладывает это как риск.
Залог: без залога можно, но тогда банк сильнее смотрит на контракты, денежный поток и поручительства. Если есть оборудование или недвижимость — решение обычно быстрее и дешевле.

Кейсы из практики: как это выглядит в цифрах

Кейс 1. SaaS для бизнеса: деньги нужны на рост, а выручка «пилой»

Компания с подписной моделью: оборот около 5,8 млн в месяц, но провалы случаются из-за сезонности и крупных доработок. ФОТ команды — 3,6 млн, маркетинг — 900 тыс, прочие расходы — 700 тыс. Собственник хотел 18 млн «на развитие».

Мы переформулировали задачу как финансирование конкретного плана: усиление продаж (маркетинг + расширение отдела) и частично инфраструктура. Подготовили платежный календарь, показали долю повторяющихся платежей (MRR около 3,9 млн) и план по снижению концентрации на одном крупном клиенте (у него было 32% оборота).

Итог: одобрен лимит 15 млн с траншами, срок 24 месяца. Платеж — около 780 тыс в месяц. Ключевым стало то, что банк увидел регулярный поток и управляемые расходы, а не «мечту о росте».

Кейс 2. Контрактная разработка: проект прибыльный, но касса в минусе из-за этапов

Студия разработки в формате ООО. Контракт на 42 млн с оплатой по этапам, но второй этап заказчик подписывал медленно. На проекте сидела команда 11 человек, ежемесячный ФОТ с налогами — 4,9 млн. Просили 10 млн, чтобы не резать команду и не сорвать сроки.

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

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

Кейс 3. Инфраструктура и безопасность: проще, когда появляется «осязаемое»

Компания с продуктом в сфере корпоративной безопасности. Оборот 160-190 млн в год, прибыльность на уровне 18-22% по управленке. Нужны были 30 млн на оборудование, лицензии и модернизацию площадки.

Здесь решило то, что цель была «железная»: счета, спецификации, понятный объект закупки. Плюс показали портфель договоров на сопровождение, который давал стабильные поступления. Итог — 30 млн, срок 36 месяцев, платеж около 1,1 млн в месяц. Кредитный комитет в таких задачах чувствует контроль, поэтому процесс идет заметно спокойнее.

Что будет, если пойти «как есть»: сценарии, о которых редко думают

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

Если подать заявку с размытыми целями — банк может поставить жесткие ковенанты или попросить больше обеспечения. Вы теряете гибкость и потом сами же ругаетесь, что «банк душит».
Если показать слабую структуру прав на продукт — вам не всегда откажут сразу, но почти наверняка попросят дополнительные поручительства и сократят лимит.
Если перебрать с количеством заявок — скоринговые следы и история обращений начинают работать против вас: «почему так активно ищут деньги».
Если взять кредит без расчета нагрузки — самый частый финал: первые 3-4 платежа норм, дальше касса проседает, начинается реструктуризация. Это не «стыдно», но это дорого и на годы ухудшает доступ к финансированию.

Как принимать решение: три рабочих сценария для собственника

Когда мы обсуждаем кредит с IT-собственником, мы обычно раскладываем выбор не по «ставке», а по логике риска.

Сценарий А: у вас есть контракты и понятный кэшфлоу. Тогда задача — правильно упаковать цель и источник возврата. Чаще всего это дает нормальный лимит и адекватные условия.
Сценарий Б: вы растете, но поток неровный. Тогда сначала считаем максимальный комфортный платеж и строим кредит вокруг него: транши, отсрочка, комбинирование с оборотным лимитом, иногда — частичное обеспечение.
Сценарий В: проект молодой и активы нематериальные. Тут важно честно признать: классический банк будет консервативен. Нужно искать формат, где решают контракты, поручители, подтвержденные продажи или смешанные источники финансирования. И да, иногда разумнее сначала «дорастить» финансовый профиль, чем сжечь время и заявки.

Стратегический вывод: как сделать так, чтобы банк поверил в IT

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

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

Для оперативной связи вы можете написать напрямую в Telegram @VkreditOnline.

Если удобнее обсудить задачу в WhatsApp, можно написать в WhatsApp.

АВТОР: Михаил КМС по МСБ