Финансовая аналитика для маркетплейсов помогает понять, сколько денег остаётся продавцу

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

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

Что аналитика продаж Ozon не расскажет о деньгах

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

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

Какие пять цифр я проверяю каждую неделю

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

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

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

Как связать расчёт с отчётом о реализации

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

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

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

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

Ошибка, из-за которой закупка выглядит убытком

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

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

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

Как превратить проверку в рабочую привычку

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

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

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