Как я пересобрал P&L, которому нельзя было доверять

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

Выручка могла попадать в отчёт в момент поступления денег. Упаковка и сырьё — в месяц оплаты. Запасы и задолженности между периодами толком не учитывались. Поэтому из P&L нельзя было понять, почему именно так изменился остаток денег на счетах.

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

В конце февраля 2022 года отчётность перешла ко мне вместе с ответственностью за коммерческую часть бизнеса. Я сразу увидел главный риск: на этих цифрах нельзя основывать решения. Сначала нужно было восстановить логику учёта.

Первая итерация: полная себестоимость каждого продукта

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

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

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

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

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

Вторая итерация: отделить себестоимость продукта от общих расходов

Разобраться с оплатой труда мне помогла «Цель» Голдратта. Книга подсказала другой вопрос: важно не то, связан ли расход с производством, а то, вырастет ли он, если мы сделаем ещё одну коробку.

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

На той же логике строилось понятие throughput из книги. Для себя я перевёл его так: сколько каждый канал оставляет бизнесу после собственных затрат.

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

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

┌────────────────────────────────────────────────┐
│               ДЛЯ КАЖДОГО КАНАЛА               │
│                                                │
│                    Выручка                     │
│             − привлечение заказов              │
│                   − комиссии                   │
│                   − доставка                   │
│                − себестоимость                 │
│                 = вклад канала                 │
└────────────────────────────────────────────────┘
                        │
                складываем каналы
                        │
                        ▼
┌────────────────────────────────────────────────┐
│              ОБЩИЙ ВКЛАД КАНАЛОВ               │
└────────────────────────────────────────────────┘
                        │
                − общие расходы
                − налоги
                        │
                        ▼
┌────────────────────────────────────────────────┐
│          УПРАВЛЕНЧЕСКИЙ РЕЗУЛЬТАТ              │
└────────────────────────────────────────────────┘

ДЛЯ КАЖДОГО КАНАЛА
Выручка
− привлечение заказов
− комиссии
− доставка
− себестоимость
= вклад канала
          ↓
  СЛОЖИТЬ КАНАЛЫ
          ↓
  ОБЩИЙ ВКЛАД КАНАЛОВ
− общие расходы
− налоги
          ↓
УПРАВЛЕНЧЕСКИЙ РЕЗУЛЬТАТ

Это был управленческий контур P&L и cash flow. Налоги учитывались отдельной строкой, капитальные вложения — в движении денег. Балансовый учёт и амортизация оставались за границами этого контура. Поэтому итогом модели был управленческий результат, а не бухгалтерская чистая прибыль.

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

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

Почему цифры всё равно не сходились

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

Один заказ на маркетплейсе превращался в несколько финансовых операций. Выручка возникала только после получения товара покупателем. Отдельно проходили комиссия, прямая и обратная логистика, хранение, эквайринг, реклама, компенсации, возвраты и утилизация. Часть расходов существовала на уровне заказа, часть — SKU или рекламной кампании, а часть относилась ко всему магазину.

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

Поэтому я развернул расчёт в обратную сторону — от отдельного заказа.

Bottom-up: расчёт от каждого заказа

Я собрал в n8n процессы, которые получали данные площадок через API или разбирали выгруженные CSV- и Excel-отчёты. Все источники приводились к одному формату.

Одному заказу могло соответствовать несколько финансовых строк. Я объединял их и получал экономику отдельного заказа:

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

Если рекламный расход был доступен только по SKU, я распределял его между проданными единицами этого SKU. Некоторые расходы относились ко всему магазину, а не к конкретному заказу: например, плата за дополнительные сервисы маркетплейса. Их я оставлял общей строкой месяца.

Если покупатель не забирал заказ, выручки и комиссии не было. Но модель учитывала возникшие расходы: логистику в обе стороны, хранение и утилизацию.

Себестоимость зависела от периода производства. Для исторических данных я использовал принцип FIFO: первыми считал проданными товары из более ранних партий. При небольших партиях и ограниченном сроке годности это соответствовало обычному движению нашего склада.

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

Top-down: проверка от движения денег

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

Это были два расчёта с разной точкой входа:

BOTTOM-UP                               TOP-DOWN
операции площадок                       деньги на счетах
        ↓                                      ↓
заказы и товары                         изменение за период
        ↓                                      ↓
выручка и прямые затраты                запасы, долги и другие движения
        ↓                                      ↓
экономика каналов                       экономика компании
        └─────────────── сверка ───────────────┘

BOTTOM-UP
операции площадок
 ↓
заказы и товары
 ↓
выручка и прямые затраты
 ↓
экономика каналов
        ┐
        ├─ сверка
        ┘
TOP-DOWN
деньги на счетах
 ↓
изменение за период
 ↓
запасы, долги и движения
 ↓
экономика компании

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

Какие решения изменила новая картина

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

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

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

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

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

Что я считаю результатом

Результатом был не дашборд и не ещё одна сложная таблица.

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

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

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

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

Моя роль

В этом проекте я:

• принял на себя управленческую отчётность и разобрал исходные ошибки учёта;
• несколько раз пересобрал модель и связал P&L с движением денег, запасами и задолженностями;
• отделил себестоимость продукта от общих расходов;
• нашёл, почему агрегированные отчёты площадок искажали картину;
• собрал в n8n загрузку и нормализацию API- и файловых данных;
• спроектировал расчёт на уровне заказов и правила распределения расходов;
• построил отдельную сверку от фактического движения денег;
• использовал модель для решений о ценах, каналах и формате доставки;
• готовил отчётность и пояснения напрямую для инвестора.