Как читать P&L для расчета юнит-экономики продукта
В отчёте P&L компания прибыльна, но это ещё не ответ на вопрос, сколько приносит один заказ или окупается ли привлечение нового клиента. Отчёт объединяет продажи, разные виды затрат и результаты периода. Для юнит-экономики нужно раскрыть состав строк, выбрать единицу анализа и связать суммы с правильным количеством юнитов.
Разберём условный продукт с 1 000 выполненных заказов за месяц. Все суммы и распределения ниже — авторский учебный пример, уже приведённый к одной базе без НДС. Он показывает перенос данных, а не рекомендуемую систему бухгалтерского или налогового учёта.
Сначала прочитайте лестницу прибыли
В учебном материале SEC отчёт о прибылях и убытках описан как результат за период: выручка, расходы и прибыль либо убыток. COGS отражает затраты на произведённые или перепроданные товары и услуги; далее в отчёте появляются операционные расходы. Это полезная отправная карта, но не готовое разделение всех затрат на переменные и постоянные.
Валовая прибыль — не синоним маржинального дохода в управленческой модели. OpenStax определяет contribution margin как выручку за вычетом переменных затрат. Поэтому для ответа «что изменится при дополнительном заказе» классификация по поведению расходов важнее привычного названия строки.
| Строка P&L | Что нужно раскрыть для юнита |
|---|---|
| Выручка | Продукт, период признания, возвраты и количество выполненных заказов |
| COGS | Какие затраты следуют за объёмом, а какие связаны с поддержанием мощности |
| Продажи и маркетинг | Привлечение новых клиентов, удержание, общая работа бренда и оплата команды |
| Административные расходы | Постоянная база и возможные расходы, изменяющиеся с объёмом |
| Проценты и налог на прибыль | Отдельный слой модели, если задача требует результата после финансирования и налогов |
Последние строки не нужно просто объявлять «неважными». Они не входят в выбранный здесь первый расчёт операционного вклада заказа, но остаются существенными для итоговой прибыли компании. Сначала зафиксируйте, на каком уровне вы принимаете решение.
Определите знаменатель до деления
Юнитом может быть заказ, проданная единица, активная подписка или новый платящий клиент. В нашем первом расчёте юнит — выполненный заказ. Мы не делим расходы месяца на заявки, отменённые корзины и покупателей за всю историю.
Для нескольких продуктов выделите выручку и прямые расходы каждого направления. Если в одной строке лежат доставка двух продуктов и зарплата общего координатора, сделайте расшифровку. Среднее по компании может скрыть продукт, который требует гораздо больше обслуживания.
OpenStax подчёркивает зависимость поведения затрат от объёма и рассматриваемого диапазона деятельности. В учебной модели оклад действующей команды считается постоянным в пределах выбранного объёма. Если рост потребует новую смену, эту ступень затрат нужно добавить отдельным сценарием, а не бесконечно считать команду бесплатной.
Пример: мост от P&L к одному заказу
| Показатель месяца | Сумма, руб. | Роль в примере |
|---|---|---|
| Выручка от 1 000 заказов | 3 000 000 | База расчёта |
| COGS | 1 200 000 | По условиям примера полностью переменные затраты |
| Переменная доставка и обслуживание | 200 000 | Следуют за выполненными заказами |
| Привлечение новых клиентов | 300 000 | Отдельно раскрытая часть маркетинга |
| Постоянная команда, офис и разработка | 700 000 | База месяца в выбранном диапазоне объёма |
Валовая прибыль при данном составе COGS равна 3 000 000 − 1 200 000 = 1 800 000 рублей. Но доставка и переменное обслуживание лежат ниже COGS, поэтому вклад до привлечения составляет 1 600 000, или 1 600 рублей на выполненный заказ.
Если для сверки результата периода распределить 300 000 рублей привлечения на все 1 000 заказов, получится ещё 300 рублей на заказ. После этого распределения остаются 1 300 рублей на заказ, или 1 300 000 за месяц. За вычетом постоянных 700 000 операционный результат нашего упрощённого P&L — 600 000 рублей.
Проверка обратным сложением: 1 200 000 + 200 000 + 300 000 + 700 000 + 600 000 = 3 000 000. Если модель не сходится с выбранным периметром отчёта, ищите пропуск или двойной учёт, а не корректируйте итог вручную.
CAC нельзя получить делением на все заказы
Stripe описывает CAC как расходы на привлечение, отнесённые к новым платящим клиентам, с согласованным периодом и составом затрат. В расчёт могут входить не только рекламные кабинеты, но и работа продаж, контент, комиссии и инструменты привлечения. Расходы на поддержку продукта не следует автоматически называть привлечением.
Предположим, все 300 000 рублей в строке примера относятся к привлечению 150 новых платящих клиентов. CAC = 300 000 / 150 = 2 000 рублей на клиента. Ранее рассчитанные 300 рублей на заказ — распределение маркетинга по объёму месяца, а не CAC.
Если первая покупка нового клиента такая же, как средний заказ, её вклад до привлечения — 1 600 рублей. При CAC 2 000 первая покупка не покрывает привлечение: разница составляет 400 рублей. Но из одного месячного P&L нельзя узнать, окупится ли клиент следующими покупками. Нужны данные о повторных заказах, удержании и затратах соответствующей когорты.
Для длинного цикла продаж отдельно согласуйте временной лаг: расходы текущего месяца могли привести к клиентам следующего. Не смешивайте зрелую клиентскую базу со свежей когортой только ради красивого среднего.
Сохраните связь с учётом, но не копируйте его строки вслепую
В управленческой расшифровке полезны четыре поля для каждой суммы: источник в P&L, продукт, характер затрат и правило отнесения. Например, часть зарплаты общего отдела можно распределять по выбранному драйверу для оценки полной рентабельности, но такое распределение не делает её переменной себестоимостью дополнительного заказа.
НДС проверяйте на уровне исходных данных. Если выручка уже выгружена без налога, нельзя вычесть его второй раз. Если в выгрузке расходов и платежей другая база, сначала согласуйте с бухгалтерией, какие суммы признаются расходом в применимом учёте и какие относятся к налоговым расчётам. Не подставляйте одну универсальную ставку к любому бизнесу.
Денежная оплата тоже не равна расходу периода автоматически. Покупка запаса, выплата аванса и признание себестоимости могут относиться к разным моментам. Для сверки P&L используйте соответствующие расходы и выручку периода; кассовую потребность анализируйте отдельно.
Три проверки перед решением о росте
Первая — каждый рубль учтён один раз. Если комиссия уже в COGS, не добавляйте её повторно из отчёта продаж; если зарплата привлечения включена в 300 000, она не должна ещё раз попасть в постоянные 700 000.
Вторая — единицы названы явно. «1 300 на заказ после распределения маркетинга», «2 000 CAC на нового клиента» и «600 000 операционной прибыли месяца» описывают разные показатели. Подмена их одним словом «маржа» разрушает смысл модели.
Третья — решение соответствует данным. Положительный результат месяца не доказывает окупаемость новой когорты, а отрицательная полная прибыль продукта не доказывает, что каждый дополнительный заказ убыточен. Разворачивайте P&L до нужного уровня и проверяйте конкретный сценарий объёма, привлечения и мощности.
