Совет директоров начался с хорошей новости. SaaS-компания из Кишинёва показала 126 платящих клиентов, €34 800 MRR, рост выручки на 41% за год и очередь из новых интеграций. Основатель открыл красивый дашборд и сказал: «Мы наконец-то нашли product-market fit».

Финансовый менеджер переключил слайд. На счёте оставалось денег примерно на одиннадцать недель. Два крупнейших клиента должны были продлеваться только через три месяца. Почти половина годовых подписок уже была потрачена на payroll и облако. Несколько клиентов пользовались «безлимитным» тарифом намного активнее остальных, а стоимость инфраструктуры по ним никто не считал.

SaaS умирает не только потому, что у него мало клиентов. Иногда он умирает потому, что слишком рано поверил собственному дашборду.

Дело SaaS-126: цифры выглядели лучше, чем бизнес

Показатель на презентации	Что обнаружилось при проверке
126 платящих клиентов	19 клиентов были на временных скидках, а 11 — в просроченной оплате
€34 800 MRR	В расчёт включались годовые договоры, бесплатные месяцы и ожидаемые доплаты
€417 600 ARR	Часть контрактов могла быть прекращена раньше, а часть суммы уже была получена и потрачена
4,1% churn	Отток считался по количеству клиентов, но не по потерянной выручке
78% gross margin	В cloud cost не входили support, мониторинг, резервные копии и сторонние API
Рост команды	Каждый новый сотрудник увеличивал минимальную налоговую нагрузку MITP
Крупный enterprise-клиент	На него приходилось 27% MRR и большая часть индивидуальной разработки

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

Комната №1. MRR не равен деньгам на счёте

MRR — полезная управленческая метрика, которая приводит разные подписки к месячному эквиваленту. Но она не показывает, когда деньги поступили, сколько клиент реально заплатил и какую часть суммы компания ещё обязана «отработать» в будущем.

Четыре разных слоя подписочной выручки

Слой	Что показывает
Contracted revenue	Что стороны согласовали в договоре
Billing	Что уже выставлено клиенту
Cash collected	Что фактически поступило
Revenue for the period	Какая часть услуги относится к конкретному месяцу

В месячном отчёте разделяйте

• MRR начала месяца;
• новый MRR;
• expansion MRR;
• contraction MRR;
• churned MRR;
• выставленные счета;
• полученные деньги;
• неоказанную часть предоплаченных услуг;
• просроченную дебиторскую задолженность;
• возвраты и credit notes;
• комиссии платёжных провайдеров;
• денежный runway.

Комната №2. ARR может содержать будущее, которого ещё нет

ARR часто получают умножением текущего MRR на двенадцать. Это удобно для сравнения динамики, но опасно для планирования, если текущий месяц был необычным.

Перед использованием ARR проверьте

• является ли подписка действительно повторяющейся;
• закончился ли период скидки;
• есть ли бесплатные месяцы;
• автоматически ли продлевается договор;
• может ли клиент прекратить его раньше;
• есть ли usage-based часть;
• включены ли one-time setup fees;
• не включены ли услуги внедрения;
• не зависит ли доход от одного крупного заказчика;
• подтверждён ли план клиента после текущего срока.

Комната №3. «Безлимитный» тариф оказался самым дорогим продуктом

Команда продавала три пакета: Start, Growth и Unlimited. Самый дорогой тариф выглядел наиболее прибыльным. Но несколько клиентов загрузили миллионы файлов, активно использовали AI-функции и ежедневно создавали отчёты. Их инфраструктура росла быстрее платы.

Unit economics нужно считать по тарифу и клиенту

Прямой компонент	Что учитывать
Compute	CPU, serverless-вызовы, контейнеры и фоновые задачи
Storage	Основные данные, логи, резервные копии и архив
Traffic	Исходящий трафик, CDN и передача между регионами
Сторонние API	AI, SMS, e-mail, карты, переводы и проверка данных
Support	Тикеты, onboarding, customer success и технические встречи
Payments	Комиссии, конвертация, chargeback и возвраты
Security	Мониторинг, сканирование, аудит и управление секретами
Operations	Резервирование, incident response и ручные операции

Для каждого клиента полезно видеть

• тариф;
• месячную плату;
• фактическое использование;
• cloud cost;
• стоимость сторонних API;
• часы поддержки;
• скидку;
• валовую маржу;
• кастомные обязательства;
• дату следующего пересмотра цены.

Комната №4. Enterprise-клиент купил продукт, а получил внутренний отдел разработки

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

В договоре и CRM разделяйте

• стандартный продукт;
• настройку без изменения кода;
• onboarding;
• миграцию данных;
• индивидуальную интеграцию;
• кастомную разработку;
• приоритетную поддержку;
• консультационные часы;
• разовые отчёты;
• будущую roadmap-функцию.

Запрос клиента должен пройти четыре вопроса

1. Эта функция нужна рынку или только одному клиенту?
2. Она входит в подписку, оплачивается отдельно или меняет тариф?
3. Кто владеет результатом и может ли продукт использовать его для других клиентов?
4. Кто будет поддерживать функцию после запуска?

Крупная сделка может увеличить MRR и одновременно ухудшить продукт, маржу и концентрацию риска.

Комната №5. Churn считался одним числом

Потерять пять небольших клиентов и одного крупного — не одно и то же. Поэтому logo churn нужно отделять от revenue churn, а добровольный уход — от технической неоплаты.

Тип оттока	Что он рассказывает
Logo churn	Сколько клиентов ушло
Gross revenue churn	Какой процент повторяющейся выручки потерян
Net revenue retention	Компенсируют ли расширения потери и сокращения
Involuntary churn	Сколько клиентов потеряно из-за неуспешной оплаты
Early churn	Сколько клиентов ушло в первые месяцы
Cohort retention	Как ведут себя клиенты, пришедшие в один период или канал

Exit reason должен быть конкретным

• не увидел ценность;
• не завершил onboarding;
• дорого;
• не хватило функции;
• перешёл к конкуренту;
• закрыл бизнес;
• плохая поддержка;
• ошибка или нестабильность;
• проблема оплаты;
• сезонная пауза;
• требования безопасности или compliance;
• неясная причина.

Комната №6. Неуспешные платежи выглядели как проблема банка

Подписочная компания теряет клиентов не только потому, что они решили уйти. Карта истекла, лимит закончился, банк отклонил операцию, invoice попал не тому сотруднику или клиент сменил юридическое лицо.

Dunning-процесс должен включать

• предупреждение до списания;
• несколько безопасных повторных попыток;
• понятное уведомление;
• ссылку для обновления оплаты;
• альтернативный банковский платёж;
• контакт финансового лица клиента;
• grace period;
• ограничение функций вместо немедленного удаления;
• порядок восстановления;
• закрывающие документы;
• список клиентов с риском involuntary churn.

Комната №7. Продление начиналось за два дня до окончания договора

Для B2B SaaS renewal — отдельный коммерческий процесс. Клиенту могут понадобиться бюджет, security review, procurement, DPA, внутреннее согласование и новый purchase order.

Календарь продлений

Срок до окончания	Действие
120–90 дней	Проверка использования, ценности, задолженности и будущих требований
90–60 дней	Коммерческое предложение и обсуждение тарифа
60–30 дней	Юридические, security- и procurement-процедуры
30–10 дней	Подпись, invoice или purchase order
После продления	Обновление MRR, обязательств, SLA и контактов

Комната №8. Договор обещал uptime, но не объяснял, что происходит при сбое

SLA — не маркетинговая цифра. Он связывает архитектуру, поддержку, мониторинг и финансовые последствия.

В SaaS-договоре определите

• период измерения доступности;
• что считается downtime;
• плановое обслуживание;
• исключения;
• метод измерения;
• уровни критичности инцидентов;
• срок первого ответа;
• срок обновлений статуса;
• service credits;
• максимальную ответственность;
• резервное копирование;
• восстановление;
• экспорт данных при прекращении;
• срок удаления данных.

Комната №9. Исходный код был у компании — права на него не всегда

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

IP-аудит SaaS должен проверить

• код основателей до создания компании;
• трудовые договоры разработчиков;
• договоры с фрилансерами;
• договоры с outsourcing-командами;
• передачу имущественных прав;
• право изменять и коммерциализировать результат;
• документацию и дизайн;
• домены и торговые марки;
• доступ к репозиториям;
• open-source зависимости;
• лицензии библиотек;
• модели AI и условия поставщиков;
• право на данные для обучения или аналитики.

Комната №10. Open source был бесплатным только в бюджете

Open-source библиотеки позволяют быстро создавать продукт, но каждая зависимость имеет условия лицензии, требования к уведомлениям и собственный security lifecycle.

Software Bill of Materials полезно связывает

• название компонента;
• версию;
• лицензию;
• источник;
• автора или поставщика;
• обязательные notices;
• известные уязвимости;
• дату последнего обновления;
• ответственного владельца;
• используемые модули;
• план замены неподдерживаемого компонента.

Комната №11. Данные клиентов стали частью продукта, но не частью управления

С 23 августа 2026 года в Молдове начинает применяться Закон №195/2024 о защите персональных данных. Он усиливает требования к законности и прозрачности обработки, ответственности операторов, безопасности, правам людей, оценке воздействия и уведомлению об инцидентах.

Для SaaS это требует карты данных

Область	Что нужно знать
Регистрация	Какие поля обязательны и зачем
Продуктовые события	Какие действия пользователя логируются
Support	Какие данные видят сотрудники и подрядчики
Analytics	Какие идентификаторы передаются внешним системам
AI-функции	Какие данные уходят поставщику модели
Backups	Где хранятся и как удаляются
Subprocessors	Какие компании обрабатывают данные
Exit	Как клиент экспортирует и удаляет информацию

До вступления новых правил стоит проверить

• privacy notice;
• договоры обработки данных;
• реестр процессов;
• правовые основания;
• минимизацию данных;
• роли и доступы;
• сроки хранения;
• трансграничную передачу;
• subprocessor list;
• процедуру запросов пользователей;
• оценку воздействия для рискованных процессов;
• incident response;
• удаление из активных систем и резервных копий;
• доказательство выполнения требований.

Комната №12. Cloud invoice вырос, но никто не знал почему

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

FinOps-отчёт должен разделять

• production;
• staging и development;
• клиентов или tenants;
• вычисления;
• хранение;
• резервные копии;
• трафик;
• логи;
• managed databases;
• сторонние API;
• неиспользуемые ресурсы;
• скидки и обязательства поставщику;
• аномалии;
• unit cost на активного клиента.

Комната №13. MITP упростил налоги, но не unit economics

Для резидентов Moldova IT Park единый налог рассчитывается как 7% месячного дохода от продаж, но не ниже минимальной суммы, рассчитанной по числу сотрудников. MITP указывает для 2026 года прогнозную среднюю зарплату 17 400 леев и минимальный расчёт 30% этой суммы на сотрудника. Налог декларируется и оплачивается ежемесячно.

При этом VAT, удержания и платежи по отдельным операциям не становятся автоматически частью единого налога. Поэтому SaaS-компания должна отдельно анализировать зарубежные cloud-, software-, marketing- и профессиональные услуги, а также собственные продажи в разных юрисдикциях.

Для финансовой модели MITP важно видеть

• месячный доход от продаж;
• количество сотрудников, влияющих на минимум;
• сравнение 7% и минимальной суммы;
• резидентскую плату;
• VAT-позицию;
• удержания по отдельным выплатам;
• расходы на подрядчиков;
• валютные операции;
• annual verification;
• документы по соответствию деятельности режиму.

Комната №14. Подрядчик дешевле сотрудника — пока отношения не стали трудовыми

С 1 января 2026 года действует режим независимого предпринимателя для предусмотренных видов деятельности: при безналичных расчётах он упрощает регистрацию и налоговую администрацию. Официальный гид MDED указывает единый налог 15% до годового дохода 1,2 млн леев и 35% для превышения.

Для software-компании это новый вариант сотрудничества с отдельными специалистами, но не автоматическая замена трудовых отношений.

Перед подключением специалиста проверьте

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

Комната №15. Revenue вырос, а продуктовая разработка исчезла в общей сумме payroll

Разработка SaaS создаёт новые функции, поддерживает старые, исправляет ошибки, выполняет миграции и обслуживает клиентов. Если всё время команды находится в одной строке «зарплаты IT», директор не понимает, сколько стоит развитие продукта и сколько — поддержание текущей системы.

Управленческий учёт времени можно разделить

• новый продукт;
• новая функция;
• customer-specific development;
• исправление дефектов;
• технический долг;
• security;
• support escalation;
• инфраструктура;
• внутренние инструменты;
• research и эксперименты;
• простой и обучение.

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

Комната №16. Runway считался по среднему burn, хотя впереди были годовые платежи

Средний месячный burn скрывает даты крупных обязательств: annual cloud commitment, лицензии, бонусы, налоги, аудит, страхование и возвраты.

13-недельный cash forecast должен показывать

• начальный остаток;
• плановые оплаты клиентов по неделям;
• вероятность просрочки;
• payroll;
• налоги;
• cloud и SaaS-поставщиков;
• подрядчиков;
• маркетинг;
• annual renewals;
• возвраты;
• капитальные покупки;
• минимальный безопасный остаток;
• сценарий потери крупного клиента.

Панель директора SaaS: не 60 графиков, а 16 решений

Показатель	Какой вопрос он решает
MRR bridge	Откуда пришёл рост или падение
Cash collected	Сколько денег реально поступило
Deferred service obligation	Сколько будущей услуги уже оплачено
Gross revenue churn	Какая выручка потеряна
NRR	Растёт ли существующая база
CAC	Сколько стоит новый клиент
CAC payback	Когда возвращаются затраты привлечения
Gross margin	Сколько остаётся после прямой стоимости сервиса
Cloud cost per tenant	Какие клиенты и функции потребляют инфраструктуру
Support cost	Какие тарифы требуют ручной работы
Customer concentration	Что произойдёт при потере крупного клиента
Renewal pipeline	Какие договоры нужно защищать заранее
Failed payment exposure	Какая выручка рискует исчезнуть технически
Product development mix	На что уходит инженерная команда
13-week cash	Хватит ли денег выполнить обязательства
Runway under stress	Сколько времени остаётся при плохом сценарии

90-дневный план спасения SaaS-126

Первые 30 дней: сделать цифры правдивыми

• пересобрать MRR bridge;
• отделить cash от выручки периода;
• проверить годовые предоплаты;
• сверить подписки, invoices и банк;
• найти неуспешные платежи;
• посчитать cloud cost по крупным клиентам;
• составить renewal-календарь;
• построить 13-недельный cash forecast;
• проверить концентрацию клиентов.

Дни 31–60: починить коммерческую модель

• ввести fair-use limits;
• отделить кастомную разработку;
• пересмотреть убыточные тарифы;
• запустить dunning;
• формализовать скидки;
• пересмотреть enterprise SLA;
• ввести платный onboarding там, где он требует проекта;
• согласовать индексацию и usage-based компоненты.

Дни 61–90: укрепить фундамент

• провести IP-аудит;
• проверить open-source лицензии;
• обновить договоры сотрудников и подрядчиков;
• подготовить процессы к Закону №195/2024;
• инвентаризировать subprocessors;
• проверить backup и incident response;
• ввести FinOps-отчёт;
• связать roadmap с затратами;
• утвердить ежемесячную панель директора.

Как iCont помогает разработчикам ПО и SaaS-компаниям

• сверять подписки, invoices, платёжные системы и банк;
• разделять MRR, фактические поступления и обязательства по предоплатам;
• вести выручку по продуктам, тарифам, странам и валютам;
• контролировать зарубежные cloud- и software-услуги;
• считать payroll, подрядчиков и налоговую нагрузку MITP;
• видеть cloud cost и прямую стоимость сервиса;
• считать прибыльность enterprise-клиентов;
• контролировать дебиторку, возвраты и failed payments;
• готовить 13-недельный cash forecast;
• формировать ежемесячную панель SaaS-метрик и финансовых рисков.

Официальные источники

• Moldova IT Park: расчёт и отчётность по единому налогу 7%
• Moldova IT Park: FAQ, состав единого налога и исключения
• Закон №230/2022 об авторском праве: компьютерные программы и права
• CNPDCP: Закон №195/2024 и новые требования к данным
• MDED: режим независимого предпринимателя с 2026 года
• Государственная налоговая служба: налоговая база и электронные сервисы
• SFS: руководство по API-интеграции e-Factura

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