Как посчитать прибыль на Озон за месяц и не перепутать её с выплатой

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

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

Почему заказ, доставка, начисление и выплата не помещаются в одну дату

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

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

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

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

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

Я не подставляю эти соотношения в новый месяц вместо расчёта. Состав продаж, расходы на продвижение и стоимость проданного товара могут отличаться, поэтому одинаковая выручка не гарантирует одинакового остатка. Комиссия 40,2 ₽ из каждых 100 ₽ здесь означает долю в конкретных данных, а не опубликованный тариф Ozon для всех товаров. Аналогично налог 3,5 ₽ — это часть выручки в расчёте, а не рекомендация применять такую налоговую ставку. Остаток 11,0 ₽ относится к перечисленным статьям: если у продавца есть дополнительные расходы бизнеса, их тоже нужно проверить перед распределением прибыли.

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

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

Как правильно посчитать прибыль на Озон после выхода отчёта

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

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

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

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

Почему прибыль по приходу денег на счёт получается неправильной

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

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

В деньгах эта ошибка оборачивается вполне конкретным риском: можно вывести сумму, которая нужна для пополнения проданного запаса, оплаты налога или других обязательств. В моём срезе от каждых 100 ₽ выручки после перечисленных расходов остаётся 11,0 ₽, поэтому путать проходящие суммы с заработком особенно опасно. Но переносить этот остаток на банковскую выплату и считать её прибыльную часть тем же способом тоже нельзя. Я проверяю выплаты отдельной сверкой: что площадка должна была на начало периода, какие начисления и удержания появились, сколько перечислено и что осталось к расчёту. Это проверка взаиморасчётов, а не замена расчёта прибыли.

Что я предлагаю сделать завтра с расчётом за месяц

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

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

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