Когда приходят деньги от Ozon продавцу и почему заказы ещё не означают выплату

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

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

Сколько заказ едет и почему это ещё не срок выплаты

В моих данных за 90 дней учтены 20 237 доставленных заказов, и медиана доставки равна 2 дням. Это означает, что середина распределения приходится на этот срок, а не что любой заказ доезжает ровно за столько. Более понятный для планирования ориентир — 80% заказов доезжают за 4 дня и меньше. Значит, даже внутри доставленной части выборки есть заказы с более долгим ожиданием. Я использую эти значения, чтобы понимать задержку между оформлением и доставкой, но не назначаю по ним дату поступления денег.

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

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

Когда Ozon платит селлерам и где проверять график выплат

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

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

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

Как посчитать сумму к получению и не спутать её с прибылью

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

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

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

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

Почему в свежем периоде расходы выглядят быстрее выручки

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

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

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

Что проверить завтра перед закупкой на ожидаемую выплату

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

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

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

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