Калькулятор юнит-экономики Ozon которому можно доверять

За 90 дней в моих магазинах выручка составила 39 895 094 ₽, а после учтённых расходов из каждых 100 ₽ осталось 11,1 ₽. Когда смотришь только на оборот, такой остаток легко переоценить. Особенно если калькулятор уже вычел закупку и комиссию, показал положительное число и на этом закончил работу. Между этим числом и деньгами, которые действительно можно считать заработанными, стоят доставка, реклама, налог и другие удержания. Поэтому я проверяю калькулятор не по аккуратности таблицы, а по тому, какие расходы он оставляет за её пределами.

У меня несколько магазинов на Ozon, и мне нужен расчёт, который можно проверить по исходным операциям. Из этой задачи вырос SellOps: я сделал сервис сам, потому что не нашёл готового решения, которому мог бы доверить такую проверку. Но наличие сервиса само по себе ничего не доказывает. Если исходные данные неполные, автоматизация просто быстрее покажет неверный остаток. Ниже я покажу, что должен считать калькулятор юнит-экономики Ozon, как проверить товарную строку и какое число использовать для закупки, а какое — для оценки уже состоявшихся продаж.

Что именно должен показывать калькулятор прибыли Ozon

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

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

В моих данных из каждых 100 ₽ выручки комиссия Ozon забрала 40,2 ₽, логистика и прочие сборы — 10,4 ₽, реклама — 13,3 ₽, себестоимость товара — 21,6 ₽, налог — 3,5 ₽. Осталось 11,1 ₽. Это фактическая структура расходов моих магазинов за указанный период, а не тарифная сетка Ozon и не готовые коэффициенты для чужого товара. Значения округлены независимо, поэтому при сложении видимых чисел возможна небольшая разница. Отдельной разбивки эквайринга и обратной логистики в переданных данных нет, поэтому приписывать им долю или добавлять их поверх уже учтённых сборов я не буду.

Какие входные данные нужны до первого вычитания

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

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

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

Отдельный набор входных данных — расходы на рекламу, правило их распределения, налоговый режим, налоговая база и применимые к продавцу особенности учёта. Если возникает НДС, его отражение тоже должно соответствовать принятому порядку учёта, иначе доход и затраты окажутся несопоставимыми. Для невыкупов нужны частота таких событий и стоимость связанных с ними операций, а для общих расходов — сумма и способ распределения. В самостоятельной таблице я оставляю рядом источник каждого значения и признак «план» или «факт». Как организовать такие поля, я описал в статье про таблицу расчёта прибыли на Ozon без потерянных расходов.

В каком порядке я считаю остаток с товара

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

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

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

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

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

Как забытые расходы меняют результат одного товара

Для проверки беру одну товарную строку и обозначаю её остаток после закупки, комиссии, прямой доставки и рекламы буквой R. Это ещё неполный результат: эквайринг, обратная логистика невыкупов и налог в него намеренно не включены. Числовой карточки конкретного товара у меня в исходных данных нет, поэтому я не стану превращать общую структуру магазинов в якобы реальный пример артикула. Вместо этого расчёт можно повторить на своей строке без выдуманных ставок. Обозначу относимый эквайринг буквой E, нагрузку обратной логистики — B, а налог на выбранную единицу расчёта — T.

После добавления эквайринга остаток становится R − E, после обратной логистики невыкупов — R − E − B, после налога — R − E − B − T. Значит, первоначальный калькулятор завысил доступный остаток ровно на E + B + T. Если эта сумма больше R, товар из прибыльного на экране превращается в убыточный по учтённым затратам. В моих агрегированных данных налог составляет 3,5 ₽ на каждые 100 ₽ выручки, поэтому его пропуск сам по себе заметно искажает оценку остатка. Но подставлять это значение в конкретный артикул нельзя без проверки его налоговой базы и способа распределения.

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

Почему план и факт расходятся и какое число брать в работу

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

Для решения о новой поставке рабочее число — обновлённый план, построенный на действующих условиях и проверенном опыте прошлых продаж. Для ответа на вопрос, сколько товар уже принёс, нужен сверенный факт с понятной датой среза и отмеченными незавершёнными операциями. Ozon Seller калькулятор я рассматриваю как источник плановой оценки только в пределах тех расходов, которые он действительно учитывает: конкретный состав нужно проверять в используемом инструменте. Бесплатный калькулятор юнит-экономики тоже может подойти, если формулы открыты, а недостающие строки можно добавить. В описании того, как устроен SellOps, можно посмотреть устройство сервиса, но проверку полноты затрат я не отменяю ни для своего инструмента, ни для чужого.

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