Рентабельность проекта: почему большая выручка не гарантирует прибыль

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

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

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

Исходный пост в моём Telegram от 9 октября 2026 года. Это пересказ разговора, а не финансовый аудит и не клиентский кейс KorDevTeam. Дальше — практическая схема контроля заказного проекта, а не описание того, как был устроен учёт у Алексея.

Что именно считать рентабельностью проекта

Для управленческого отчёта сначала договоритесь, какой результат вы хотите видеть.

• Результат после прямых затрат: выручка проекта минус расходы, которые можно непосредственно отнести к нему.
• Результат с распределёнными общими расходами: тот же расчёт, дополненный согласованной долей расходов компании.
• Денежный поток: поступившие от клиента деньги минус выплаты. Это отдельный показатель, а не замена прибыли.

В этой статье рентабельность считаем относительно выручки: результат по выбранному составу затрат / выручка × 100%. Название показателя должно показывать, какие расходы включены. Не называйте остаток после оплаты подрядчика «чистой прибылью», если труд команды и остальные расходы ещё не учтены.

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

Начните не с дашборда, а с карточки заказа

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

Зафиксируйте:

1. Договор и согласованный объём: что входит в цену, как принимается результат.
2. Базовый план: выручка, трудозатраты, закупки, подрядчики и известные риски.
3. Факт: выполненная работа и относящиеся к ней затраты с источником каждой суммы.
4. Остаток: сколько ещё потребуется для завершения, включая уже известные переделки.
5. Изменения: кто, когда и почему согласовал дополнительный объём или новую оценку.

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

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

Условный пример: проект ещё не закрыт, а результат уже меняется

Все суммы ниже придуманы для объяснения. Это не показатели KorDevTeam или бизнеса собеседника. Выручка и затраты показаны в одной условной базе; налоговые особенности намеренно не моделируются.

Пусть выручка по заказу — 600 тыс. рублей. В первоначальной оценке прямые затраты составляют 420 тыс. рублей. Плановый результат после них — 180 тыс. рублей, или 30% выручки.

В середине работ уже понесено 300 тыс. рублей прямых затрат. На завершение по обновлённой оценке нужно ещё 180 тыс. рублей. Следовательно:

• прогноз прямых затрат на весь проект: 300 + 180 = 480 тыс. рублей;
• прогноз результата после прямых затрат: 600 − 480 = 120 тыс. рублей;
• прогноз рентабельности по этому показателю: 120 / 600 × 100% = 20%.

Потеря относительно первоначальной оценки — 60 тыс. рублей и 10 процентных пунктов. Но это ещё не итог закрытого проекта и не чистая прибыль.

Если согласованная доля общих расходов составляет ещё 60 тыс. рублей, результат после их распределения — 60 тыс. рублей, или 10% выручки. Оба показателя полезны, если подписаны правильно. Распределённые расходы не обязательно исчезнут при отказе от заказа: нельзя принимать такое решение только по одной итоговой строке.

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

Где искать отклонение

Не начинайте с вывода «сотрудники работают медленно». Разберите разницу по причинам:

• в оценку не вошла обязательная работа;
• клиент согласовал дополнительный объём, но цена не обновилась;
• выросли цены закупок или подрядчика;
• возникли переделки;
• часть часов вообще не относилась к этому заказу;
• прогноз завершения давно не пересматривался.

Труд команды тоже имеет стоимость, но ставка продажи часа клиенту и внутренняя стоимость часа — разные величины. Зафиксируйте состав внутренней ставки и не учитывайте одну зарплату одновременно в часах и в общих расходах.

Связка задач, канбана и тайм-трекинга даёт первичные данные о работе. Для экономики проекта к ним нужно добавить стоимость, договорной объём и прогноз остатка. Сам по себе запущенный таймер прибыль не считает.

Что автоматизировать и как проверить результат

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

До запуска проверьте на одном заказе:

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

Учёт затрат по заказам — не обязательно отдельная разработка. Например, официальная документация 1С описывает аналитику расходов по заказу клиента и расчёт его локального финансового результата. В документации ПланФакта отдельно рассматриваются показатели прибыли и движения денег в карточке проекта. Сначала проверьте возможности используемой системы, затем решайте, чего действительно не хватает.

Поднять цену — не универсальный рецепт

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

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

С чего начать

Возьмите один завершённый и один текущий заказ. Для первого восстановите выручку и затраты из документов и задач. Для второго добавьте честный прогноз до завершения. Отдельно выпишите недостающие данные.

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

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

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