Ozon задерживает выплаты продавцу — как проверить сумму и найти деньги
Разбираю, как отличить задержку выплаты от удержаний, ошибки в реквизитах и расхождения с собственным расчётом. Показываю, где проверить график, как сверить ожидаемое поступление с банковской выпиской и что отправить в поддержку, если денег нет.
Поставщику я уже подтвердил оплату, а потом открыл банковскую выписку и понял, что рассчитывал совсем не на ту сумму. В кабинете Ozon были продажи, рядом отображался баланс, и я мысленно превратил его в деньги, которые вот-вот поступят на счёт. Только у поступления оказался свой расчёт, а у меня — обещание, которое пришлось пересматривать. Сначала хотелось написать в поддержку, что Ozon задерживает выплаты. Но перед обращением пришлось выяснить, действительно ли перевод опоздал или я ждал деньги, которые ещё не должны были перечислить.
После этой истории я перестал считать банковское поступление продолжением цифры продаж на экране. Между продажей товара и переводом продавцу есть начисления, возвраты, услуги площадки, корректировки и условия перечисления денег. Причём сумма и дата — разные вопросы: перевод может прийти по графику, но оказаться меньше моего ожидания. Бывает и обратная ситуация, когда сумма понятна, а движение денег приходится искать между площадкой и банком. Поэтому проверку я начинаю с основания для выплаты, а не с предположения, что деньги пропали.
Где посмотреть выплаты Ozon и дату ближайшего перевода
На вопрос «когда приходят выплаты Ozon Селлер» я не отвечаю датой из памяти или чужого скриншота. Открываю кабинет нужного магазина, перехожу в финансовый раздел и ищу страницу выплат или взаиморасчётов с графиком перечислений. Названия пунктов интерфейса могут меняться, поэтому ориентируюсь на содержание: плановую дату, сумму, статус и историю переводов. Если график не виден, пользуюсь поиском по справке внутри кабинета и сверяю найденное с действующими условиями своего договора. В нескольких магазинах легко посмотреть данные другого юридического лица, поэтому название кабинета и получателя я проверяю сразу.
Вопрос «когда выплаты Ozon Селлер» для меня распадается на дату, указанную площадкой, и фактическое зачисление банком. Я смотрю, что именно означает отображаемая дата: план перечисления, формирование выплаты или уже отправленный платёж. Затем открываю историю операций, чтобы не принять старую выплату за ожидаемую, и сохраняю сведения о нужной записи. Если на период расчётов приходятся праздники, проверяю уведомления Ozon и порядок обработки переводов своим банком, а не прибавляю произвольное количество дней. Подробную проверку перед закупкой я описал в статье о том, как проверить график выплат Ozon и спланировать закупки, а здесь мне нужна зафиксированная точка отсчёта для поиска расхождения.
Юнит-экономика по каждому товару: себестоимость, реальная выплата Ozon, комиссия, реклама и прибыль. Убыточные помечаются сразу — их не приходится высматривать в таблице.
Чтобы понять, как происходят выплаты Ozon Селлер, я смотрю не на оборот, а на движение взаиморасчётов с площадкой. Продажи дают начисления, после чего на доступную к перечислению сумму влияют относящиеся к ней удержания, возвраты и корректировки. Часть операций может относиться к другому расчётному периоду или ещё не входить в ближайшую выплату по условиям кабинета. Поэтому сумма заказов, выручка из отчёта и ожидаемый банковский перевод не обязаны совпадать. Само несовпадение ещё не доказывает задержку, но у каждой разницы должно быть объяснение в операциях или условиях перечисления.
Отдельно я проверяю входящий остаток расчётов, особенно если раньше были расходы, которые не покрылись начислениями. При отрицательном остатке новые начисления могут сначала уменьшать задолженность, а не превращаться целиком в выплату. Какие именно расходы участвуют в таком зачёте, я устанавливаю по детализации, а не по общему названию услуги. Если вижу непонятное списание, ищу его основание, дату и связь с уже учтёнными операциями. Для такой проверки полезен мой разбор задолженности перед Ozon и каждого удержания: отрицательный баланс нужно расшифровать, а не просто принять.
Если сумма выплаты сформирована, но поступления нет, я отдельно проверяю платёжные реквизиты и банковскую сторону. Сверяю получателя, расчётный счёт, БИК и статус счёта, особенно после смены банка или редактирования данных в кабинете. Неверные либо неактуальные реквизиты могут привести к отказу в исполнении или возврату платежа, но конкретный исход подтверждается документами. Праздники тоже рассматриваю как возможную причину изменения обработки, а не как универсальное оправдание любой задержки. Без статуса выплаты, даты отправки и ответа банка у меня нет данных, чтобы уверенно назвать виноватую сторону.
Как заранее посчитать, сколько должно прийти
Для расчёта я выбираю конкретную ожидаемую выплату и границы операций, из которых она складывается. Если взять продажи за календарный период, а удержания — за другой, можно получить аккуратную таблицу с неверным результатом. Мне нужны начальный остаток, начисления, уменьшающие их операции, предыдущие перечисления и суммы, которые пока не входят в текущую выплату. При этом я заранее выясняю, показаны ли начисления до удержаний или уже после них. Иначе один и тот же расход легко вычесть повторно, особенно при переносе данных из разных отчётов.
Сверяю ожидаемую выплату с банковским поступлением
1
Фиксирую начальный остаток
Беру остаток взаиморасчётов на начало выбранного периода вместе с его знаком. Проверяю, какие начисления и удержания уже вошли в него.
2
Добавляю начисления периода
Прибавляю операции, увеличивающие расчётный остаток. Заказы без соответствующего начисления не подставляю вместо денег к выплате.
3
Вычитаю расходы и возвраты
Уменьшаю сумму на относящиеся к периоду удержания и возвраты, учитываю корректировки с их знаком. Если расход уже включён в исходную сумму, повторно его не вычитаю.
4
Учитываю предыдущие перечисления
Вычитаю выплаты, которые уже уменьшили взаиморасчёты в выбранном периоде. Сверяю их с историей переводов, чтобы не ждать перечисленные деньги снова.
5
Выделяю текущую выплату
Исключаю из полученного остатка суммы, которые по действующим условиям ещё не подлежат перечислению в этой выплате. Основание для исключения беру из кабинета или уточняю у поддержки.
6
Сравниваю с выпиской
Сопоставляю ожидаемую сумму с конкретным банковским зачислением либо связанными с ней платежами. Если есть расхождение, ищу операцию или статус, которые его объясняют.
В таблице я показываю именно движение расчётного остатка, а не прибыль магазина. Все суммы условные, и строка удержаний не описывает действующие тарифы Ozon. Начисления в этом примере взяты до перечисленных ниже возвратов и удержаний, поэтому их можно вычесть отдельно. Промежуточный остаток показан для проверки арифметики, его не нужно ещё раз прибавлять к другим строкам. В своих данных я заменяю каждую строку подтверждённой суммой и сохраняю рядом источник, чтобы затем можно было восстановить расчёт.
Пример расчёта выплаты — все числа условные
Операция
Что делаю
Пример
Начальный остаток
Беру со знаком
+1 000 ₽
Начисления до указанных ниже списаний
Прибавляю
+10 000 ₽
Возвраты, ещё не учтённые в начислениях
Вычитаю
−1 000 ₽
Удержания Ozon, условная сумма
Вычитаю
−2 500 ₽
Предыдущие перечисления за выбранный период
Вычитаю
−2 000 ₽
Промежуточный расчётный остаток
Проверяю результат
5 500 ₽
Часть остатка вне текущей выплаты
Исключаю по подтверждённому основанию
−1 500 ₽
Ожидаемая текущая выплата
Сравниваю с кабинетом
4 000 ₽
Поступление по банковской выписке
Сравниваю с ожиданием
4 000 ₽
Пример, числа условные. Удержания не являются тарифами Ozon.
В примере из таблицы банковское поступление совпало с ожиданием, хотя оно заметно меньше начислений. Значит, жалоба на недоплату только на основании продаж была бы необоснованной. Но строка с частью остатка вне текущей выплаты допустима лишь тогда, когда я знаю, почему эти деньги пока не перечисляются. Нельзя записывать туда любую необъяснимую разницу ради красивого совпадения итогов. Себестоимость товара и налоги я также не вычитаю из ожидаемого перевода автоматически: это расходы моего бизнеса, а не подтверждённые удержания площадки из данной выплаты.
Сколько денег стоит товар на складах — отдельно в закупочных ценах и в ценах продажи, с запасом в днях по каждой позиции. Видно, где деньги лежат мёртвым грузом.
Ошибка, из-за которой деньги выглядят потерянными
Самая неприятная ошибка в моём расчёте — повторно вычесть удержания из суммы, которая уже показана после них. Такое случается, если взять готовую сумму к перечислению и затем добавить к таблице расходы из отдельной детализации, не проверив состав исходного показателя. Расчётное ожидание становится заниженным на весь повторно вычтенный расход. Если фактическая выплата тоже окажется меньше положенного по другой причине, такая ошибка способна скрыть недоплату: поступление будет казаться нормальным относительно неверной базы. В противоположной ситуации, когда я считаю выплатой все начисления без удержаний, возникает завышенное ожидание и риск обещать поставщику деньги, которых на счёте не будет.
Не сравнивайте выплату с выручкой без расшифровки перехода между ними. Начисления, расчётный остаток и сумма конкретного перевода могут включать разные операции. Каждое удержание должно попасть в расчёт только один раз. Необъяснимую разницу нельзя списывать на праздники или «особенности Ozon» без проверки.
Чтобы поймать повторный учёт, я рядом с каждой исходной суммой записываю, что в неё уже включено и за какой период она взята. Отчёт о реализации использую для проверки соответствующих начислений, но не назначаю его итог суммой ближайшего банковского перевода. Где искать этот документ и как сопоставлять его с другими данными, я разобрал в статье о проверке закрытого месяца по отчёту о реализации Ozon. Сам я сделал SellOps, потому что не нашёл готового сервиса аналитики, которому доверял бы, и подход к работе с данными описал на странице о том, как устроен сервис. При этом аналитика не заменяет платёжный документ и банковскую выписку: отправку и получение денег я подтверждаю отдельно.
Куда писать, если выплаты нет, и что подготовить
Если указанная для моей выплаты дата прошла, а поступления нет, я открываю обращение в поддержке кабинета продавца по теме финансов или выплат. При выборе категории ориентируюсь на доступные пункты интерфейса, а не ищу название из старой инструкции. В обращении указываю магазин, юридическое лицо, ожидаемую дату, сумму и идентификатор выплаты, если он отображается. Прикладываю сведения из кабинета и банковскую выписку за подходящий период, исключив посторонние данные, которые не нужны для проверки. Вопрос формулирую конкретно: сформирована ли выплата, отправлена ли она в банк и что мешает перечислению, если отправки ещё не было.
Когда кабинет показывает отправку, я прошу у поддержки платёжное поручение или доступные реквизиты платежа для банковского поиска. С этими данными обращаюсь в свой банк и прошу проверить поступление, возможный отказ или возврат отправителю. Одновременно сверяю реквизиты из платёжного документа с действующим счётом, а не только с тем, что сейчас записано в кабинете. Статус в интерфейсе полезен для поиска, но сам по себе не подтверждает зачисление на мой счёт. Если банк сообщает о возврате, передаю это подтверждение Ozon и уточняю порядок исправления причины и повторного перечисления.
При неполной выплате я отправляю другой набор вопросов: из каких операций собрана сумма и почему мой расчёт отличается. К обращению добавляю сверку начального остатка, начислений, удержаний и уже проведённых перечислений, выделяя только необъяснимую часть. Если сомнение связано с конкретной услугой или корректировкой, прошу основание именно этой операции. Это полезнее сообщения «деньги пришли не все», потому что поддержке не приходится угадывать, с какой цифрой я сравниваю поступление. Ответ проверяю по документам: общее объяснение про взаиморасчёты ещё не означает, что спорная сумма действительно учтена верно.
Я сохраняю номер обращения, документы и ответы в одной истории, чтобы при продолжении проверки не собирать всё заново. Если поддержка отвечает общими словами, повторно прикладываю сверку и прошу ответить на оставшийся конкретный вопрос. При подтверждённом нарушении условий перечисления и отсутствии решения проверяю в договоре порядок направления официальной претензии. Сроки ответа и дальнейшие действия беру из применимых условий и при необходимости обсуждаю с юристом, а не переношу из чужого случая. До выяснения причины не закладываю спорную выплату в обязательный платёж поставщику как уже доступные деньги.
Завтра я бы начал с ближайшего платежа поставщику и той выплаты Ozon, за счёт которой собираюсь его провести. Открыл бы нужный кабинет, сохранил график и составил сверку от начального остатка до ожидаемого поступления. Затем проверил бы реквизиты и банковскую выписку, отдельно обозначив подтверждённые удержания и суммы без объяснения. Если расхождение осталось, отправил бы обращение с расчётом и вопросом о конкретной выплате, а не обо всём балансе магазина. После такой проверки становится понятно, что делать дальше: исправлять собственное ожидание, искать платёж в банке или добиваться объяснения и перечисления денег от Ozon.
Разбор для продавцов Ozon
Как передавать коды маркировки
Разбор8 ноября 2026 г.
Как передавать коды маркировки в Ozon на FBS и что делать с УПД
Разбираю путь кода от получения товара до сборки заказа FBS, передачи сведений в Ozon и проверки возврата. Объясняю, почему УПД не заменяет код в отправлении, где искать причину ошибки и что меняется при работе по FBO.