Начисления и компенсации Ozon продавцу и как учесть их в прибыли
Разбираю, как выяснить причину компенсации, корректировки или списания и связать её с конкретным товаром или операцией. Показываю порядок расчёта результата месяца и объясняю, что проверять, если выплата за потерянный товар не покрывает его себестоимость.
Когда в отчёте появляется компенсация за потерянный товар, я не спешу прибавлять её к прибыли магазина. Деньги начислили, но товар тоже чего-то стоил, а его стоимость могла остаться в учёте среди складских запасов. Если посмотреть только на поступление, получится приятный результат, которого в действительности нет. Меня здесь интересует связка: какой товар выбыл, сколько он мне стоил и какую часть потери возместили. Без неё строка с положительной суммой говорит слишком мало.
С корректировками бывает ещё запутаннее: сумма появилась в текущем отчёте, а относится к операции прошлого периода. Я могу принять её за дополнительный заработок этого месяца или, наоборот, решить, что внезапно выросли расходы на продажи. В обоих случаях управленческое решение будет опираться на неверную причину. Поэтому начисления Ozon продавцу я разбираю отдельно от вопроса, сколько денег пришло на расчётный счёт. В этой статье покажу свой порядок проверки: от непонятной строки до её места в расчёте прибыли, включая ситуацию, когда компенсация не закрывает себестоимость.
Что скрывается за начислениями помимо продаж
Для меня слово «начисления» само по себе ещё не объясняет экономический смысл суммы. В расчётах с площадкой могут отражаться продажи, возмещения, пересчёты ранее учтённых операций и удержания, причём смотреть нужно на содержание конкретной строки. Положительная сумма не обязательно означает новую продажу, а отрицательная не всегда является новой услугой. Например, исправление прежнего расчёта может уменьшить ранее начисленный доход или вернуть часть ранее удержанного расхода. Точные названия операций я беру из отчёта и его расшифровки, а не пытаюсь угадать по знакомому слову.
Компенсацию за утраченный товар я рассматриваю как возмещение конкретной потери, а не как выручку от покупателя. Но даже слово «компенсация» требует проверки основания: нельзя автоматически считать любую такую строку выплатой за потерю на складе. Корректировка показывает, что прежний расчёт изменили; дальше надо выяснить, что именно пересчитано и в какую сторону. Доначисление тоже не раскрывает причину без документа или привязки к исходной операции. Я сначала устанавливаю содержание события и только потом решаю, куда относить его в управленческом учёте.
Отдельно я различаю списание денег и списание товара: это разные события, хотя в разговоре их часто называют одинаково. Денежное удержание меняет расчёты с площадкой, а выбытие товара требует разобраться с его стоимостью в запасах. Они могут относиться к одному случаю, но одно не заменяет другое. Также начисленная сумма не обязана совпадать с отдельным банковским поступлением: выплата может учитывать другие операции и взаиморасчёты. Эту разницу я подробнее разбираю в статье о том, когда приходят деньги от Ozon и почему заказы ещё не означают выплату.
Как понять, за что пришла или ушла сумма
Я начинаю с исходной строки и сохраняю её описание, сумму, дату отражения и доступные идентификаторы. Рядом записываю магазин, отчёт и период, чтобы потом не искать похожую операцию в другом кабинете. Если есть ссылка на заказ, отправление, товар, акт или обращение, использую её для дальнейшей проверки. Не предполагаю, что все эти поля обязательно будут в любой выгрузке: состав данных зависит от документа. Когда основания в строке нет, я ищу детализацию и связанные документы, а не присваиваю расходу удобную категорию по одному названию.
Следующий вопрос — какую исходную операцию изменяет эта сумма. Для корректировки я ищу первоначальное начисление, сравниваю основание и выясняю, передо мной разница к старой сумме или её отмена с новым начислением. Это принципиальное различие: прибавить новый полный расчёт к старому означает задвоить результат. Знак тоже проверяю по смыслу отчёта и влиянию строки на итог, потому что обозначение удержания и способ его показа могут различаться. Если связь не находится, оставляю операцию неразобранной и фиксирую, каких именно данных не хватает для проверки.
Запрос «корректировки Ozon отчёт» обычно возникает именно в этот момент: итог изменился, а причина из сводной суммы не видна. Я собираю простой реестр, где рядом стоят исходная операция, её изменение, документ-основание и результат проверки. После этого сопоставляю реестр с детализацией начислений и итогами соответствующих документов, не пытаясь получить всю картину из одного отчёта о реализации. Порядок проверки самого отчёта описан у меня отдельно — как читать отчёт о реализации и сверять закрытый месяц. Если расшифровки всё равно нет, в поддержку уходит вопрос о конкретной строке с идентификатором и суммой, а не общее сообщение о неправильном балансе.
Компенсация не означает, что потеря закрыта полностью. Сначала сопоставьте её со стоимостью именно выбывшего товара и проверьте, не была ли эта стоимость уже признана расходом. Начисленное возмещение нельзя автоматически считать прибылью или повторно прибавлять при поступлении денег в банк. Пока основание суммы не подтверждено, я держу её отдельно от расшифрованных операций.
Как я считаю результат месяца с компенсациями и списаниями
Сначала я задаю границы расчёта: конкретный магазин и месяц, по которому собираю управленческий результат. Беру доход от состоявшихся продаж с учётом относящихся к нему возвратов и подтверждённых изменений, а не сумму заказов или выплат из банка. Затем вычитаю себестоимость проданных товаров, учитывая восстановление стоимости возвращённых товаров там, где оно действительно произошло. После этого вычитаю связанные с продажами расходы площадки и остальные расходы бизнеса, которые входят в мой расчёт. Если отчёт уже показывает сумму за вычетом какого-то удержания, повторно этот расход не вычитаю: сначала восстанавливаю понятную структуру расчёта.
Дальше отдельно разбираю утраты и другие выбытия, которые не являются продажей покупателю. Для потерянного товара устанавливаю количество и себестоимость по своему учёту, а не подставляю цену с карточки. В моём управленческом расчёте это стоимость приобретения и те затраты на доведение товара до места продажи, которые включены в стоимость запасов по принятому мной подходу. Если в учёте доступны партии, проверяю, какая стоимость относится к выбывшему товару; если используется средняя себестоимость, не меняю метод только ради этого случая. Полученную стоимость вычитаю как потерю лишь в той части, которая ещё не была учтена в расходах.
Затем прибавляю подтверждённую компенсацию, связанную с этим выбытием, и получаю результат самого случая: возмещение минус себестоимость утраты минус отдельные связанные расходы, если они были. Расходы, которые уже попали в общий расчёт месяца, здесь повторно не вычитаю. Если компенсация меньше себестоимости, разница остаётся убытком, даже когда сама строка начисления положительная. Ожидаемое дополнительное возмещение я показываю отдельно от уже подтверждённого, иначе спор с площадкой незаметно превратится в нарисованный доход. При последующем подтверждении доплаты обновляю расчёт и сохраняю связь с первоначальным случаем.
После этого разношу оставшиеся корректировки по их содержанию: изменение дохода исправляет доход, пересчёт услуги исправляет соответствующий расход. Для операций прошлых периодов храню и дату отражения, и период, к которому относится причина изменения. В анализе магазина я отдельно показываю влияние таких исправлений, чтобы не приписывать текущим продажам чужой результат; порядок официального бухгалтерского и налогового учёта согласовываю с бухгалтером. В конце сверяю учтённые операции с документами и расчётами с площадкой, а банковские поступления использую для контроля погашения задолженности. Они не становятся дополнительным доходом поверх уже учтённых начислений.
Юнит-экономика по каждому товару: себестоимость, реальная выплата Ozon, комиссия, реклама и прибыль. Убыточные помечаются сразу — их не приходится высматривать в таблице.
Ошибка, из-за которой компенсация превращается в мнимую прибыль
Самая неприятная ошибка в таком расчёте — учесть компенсацию и оставить потерянный товар в остатках по полной стоимости. Получается, что магазин одновременно владеет товаром и получил деньги за его отсутствие. Если стоимость утраты ещё нигде не попала в расходы, прибыль завышена на эту стоимость. Это не безобидное расхождение между таблицами: на основании такого результата можно вывести деньги из бизнеса, хотя часть капитала уже потеряна. При следующей закупке обнаружится нехватка средств, которую легко ошибочно объяснить слабым денежным потоком от обычных продаж.
Обратная ошибка возникает, когда стоимость товара уже списали, а при разборе компенсации вычитают её ещё раз. Тогда прибыль оказывается занижена на повторно учтённую стоимость. В магазине может выглядеть убыточным товар, который на самом деле пострадал только от ошибки учёта, и решение остановить закупки будет преждевременным. Поэтому я проверяю не только наличие строки себестоимости, но и событие, по которому она попала в расходы. Для каждого случая мне нужна прослеживаемая связь между выбытием, признанной потерей, компенсацией и возможным последующим исправлением.
С корректировкой услуги логика похожая: если площадка вернула часть прежнего удержания, это уменьшение расхода, а не новая продажа товара. Общая прибыль при разовом прибавлении может даже получиться верной, но выручка и доля расходов будут искажены. Потом я сравню магазины или периоды и начну искать причину изменения там, где её нет. Именно из-за таких вопросов я сделал SellOps: готового сервиса, чьим расчётам мог бы доверять, я для себя не нашёл. То, как устроен SellOps, я описываю через логику работы с данными, но отсутствие основания у конкретной операции никакая автоматизация не исправит.
Что делать, если Ozon потерял товар, а компенсация меньше себестоимости
Когда Ozon потерял товар, компенсация продавцу и себестоимость этого товара отвечают на разные вопросы. Себестоимость показывает мои затраты, а основание и порядок возмещения нужно устанавливать по применимым условиям и документам конкретного случая. Сам по себе убыток ещё не доказывает, что площадка рассчитала сумму неправильно или обязана доплатить разницу. Я не привожу формулу Ozon по памяти: она может зависеть от обстоятельств, а актуальные условия необходимо проверять. Сначала сопоставляю товар и количество, подтверждённый факт утраты, назначенную сумму и объяснение её расчёта.
Если объяснение не сходится с документами, я собираю обращение с конкретным расхождением и требованием проверить расчёт. Прикладываю доступные подтверждения передачи и утраты товара, идентификаторы операций, документы о стоимости и собственный расчёт разницы, поясняя назначение каждого вложения. Прошу указать применённое основание, исходные данные и причину, по которой получилась именно такая компенсация, а при ошибке — пересчитать её. Сроки и способ подачи требования проверяю в актуальных условиях для этого случая, не откладывая вопрос до удобного момента. Документы о закупке полезны для обоснования моей позиции, но я не обещаю себе, что одна накладная автоматически обеспечит возмещение всей себестоимости.
Завтра я бы начал не с пересчёта всего магазина, а с выгрузки непродажных начислений за закрываемый месяц. Напротив каждой строки поставил бы основание, связанную операцию, период события, влияние на прибыль и статус проверки, а компенсации отдельно сопоставил бы с учтёнными потерями. По неясным строкам подготовил бы точечные обращения и обозначил, какие суммы пока мешают считать результат окончательным. Если расчёт компенсации подтверждён и оснований для пересмотра нет, оставил бы непокрытую часть в убытке и использовал её при оценке риска следующих поставок. Месяц для меня закрыт не тогда, когда в таблице получилась приятная сумма, а когда я могу объяснить, почему каждая существенная корректировка её изменила.