01 С этой ситуацией обращаются

  • 01 Wildberries или Ozon начислили штраф или удержание за габариты либо вес товара
  • 02 стоимость логистики или хранения оказалась выше ожидаемой
  • 03 после контрольного замера изменились параметры товара
  • 04 возникло расхождение между данными карточки и фактическими параметрами на складе
  • 05 начисление связано с поставкой, приёмкой, упаковкой или хранением
  • 06 продавец не понимает, из какого именно события сформировалась итоговая сумма
  • 07 финансовый отчёт показывает корректировку, но её расчёт или основание неочевидны
  • 08 спорное начисление относится к FBO, FBS, realFBS или другой схеме работы площадки

Первый вопрос Бюро — какие конкретные параметры товара, складские события и действовавшие правила сформировали спорное начисление.

02 Что именно могла зафиксировать площадка или склад

В спорном начислении значение могут иметь:

  • 01 заявленные габариты и вес товара
  • 02 результаты контрольного замера
  • 03 дата и место замера
  • 04 схема работы продавца — FBO, FBS, realFBS или иная
  • 05 событие приёмки или отгрузки
  • 06 данные упаковки и маркировки
  • 07 срок и условия хранения
  • 08 маршрут логистики
  • 09 категория товара
  • 10 применённый тариф
  • 11 дата вступления тарифа или правила в силу
  • 12 отражение начисления в финансовом отчёте

Финансовое начисление нужно связывать не с общей формулировкой «логистика» или «габариты», а с конкретным измерением, событием, тарифом и датой его применения.

03 Где чаще всего возникает расхождение

Спор может возникнуть, когда:

  • 01 параметры товара в карточке отличаются от данных контрольного замера
  • 02 замер проведён позже поставки, а начисление применено к более раннему периоду
  • 03 продавец не видит исходные данные измерения
  • 04 тариф изменился после создания поставки или заказа
  • 05 одна и та же операция отражена в разных разделах отчётности по-разному
  • 06 логистическое событие зафиксировано платформой иначе, чем его видит продавец
  • 07 штраф или корректировка сформированы автоматически, но из кабинета неясно, на каком именно событии основан расчёт
  • 08 данные склада, карточки товара и финансового отчёта не складываются в одну непротиворечивую цепочку

Ключевой вопрос — можно ли по доступным данным восстановить непрерывную цепочку от фактического параметра товара или складского события до конкретного финансового начисления.

04 Что важно разделить при проверке

При разборе нельзя смешивать несколько разных уровней:

  • 01 Исходные параметры товара. Что продавец указал в карточке: габариты, вес, категория, упаковка
  • 02 Фактическое складское событие. Что произошло при приёмке, замере, хранении, перемещении или отгрузке
  • 03 Правило или тариф платформы. Какая редакция условий действовала на соответствующую дату
  • 04 Финансовое последствие. Как именно событие отразилось в отчёте: логистика, хранение, штраф, корректировка или иное удержание

Только после сопоставления этих четырёх уровней можно понять, соответствует ли начисление фактическим данным и действовавшим условиям Wildberries или Ozon.

05 Wildberries: что проверяем отдельно

Для Wildberries важно сопоставить не только итоговое удержание, но и всю цепочку, которая к нему привела:

  • 01 какие габариты и вес были указаны продавцом
  • 02 когда и где проводился контрольный замер
  • 03 какие значения зафиксировал склад
  • 04 была ли доступна детализация результата замера
  • 05 какая редакция тарифов и правил действовала на эту дату
  • 06 к каким заказам или поставкам применилось начисление
  • 07 как оно отразилось в финансовом отчёте
  • 08 были ли последующие корректировки
  • 09 обращался ли продавец в поддержку и какой ответ получил
  • 10 совпадают ли данные карточки, склада и финансовой отчётности между собой

Для Wildberries ключевой вопрос — можно ли проследить непрерывную связь от конкретного замера или складского события до конкретного начисления в отчёте продавца.

06 Ozon: что проверяем отдельно

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

  • 01 схема работы — FBO, FBS, realFBS или иная
  • 02 дата заказа, поставки или отгрузки
  • 03 заявленные габариты и вес товара
  • 04 фактические параметры, зафиксированные при приёмке или обработке
  • 05 маршрут и этап логистики
  • 06 стоимость обработки, доставки и хранения
  • 07 действовавший на эту дату тариф
  • 08 дата вступления тарифа в силу
  • 09 отражение операции в отчёте продавца
  • 10 последующие корректировки или перерасчёты
  • 11 переписка с поддержкой по спорному начислению

Для Ozon ключевой вопрос — соответствует ли конкретное начисление фактически зафиксированному событию, применённой схеме работы и тарифу, который действовал на эту дату.

Не нашли свою ситуацию или нужен разбор по конкретным документам?

Обсудить ситуацию

07 Какие данные и документы нужны для проверки

Для первичного разбора обычно достаточно собрать:

  • 01 карточку товара с указанными габаритами и весом
  • 02 сведения о спорной поставке, заказе или отгрузке
  • 03 результаты контрольного замера, когда они доступны продавцу
  • 04 финансовый отчёт с конкретным начислением
  • 05 детализацию логистики, хранения или штрафа
  • 06 уведомления платформы
  • 07 действовавшую на нужную дату редакцию тарифа или правил
  • 08 переписку с поддержкой
  • 09 документы о фактических параметрах товара
  • 10 сведения о последующих корректировках или перерасчётах

Главное — собрать не весь кабинет целиком, а документы и данные, которые связывают конкретный товар, конкретное событие и конкретное начисление.

08 Что проверяет Бюро

Бюро сопоставляет фактические параметры товара, складские события, правила платформы и финансовое начисление в одной проверяемой цепочке. В рамках проверки можно:

  • 01 восстановить хронологию поставки, приёмки, замера, хранения и начисления
  • 02 сопоставить данные карточки товара с данными склада
  • 03 проверить, какая редакция правил и тарифов действовала на нужную дату
  • 04 установить, к какому именно событию относится спорное удержание
  • 05 сравнить расчёт платформы с финансовым отчётом продавца
  • 06 выявить расхождения между исходными параметрами товара и данными, использованными площадкой
  • 07 определить, были ли последующие перерасчёты или корректировки
  • 08 отделить фактическое складское событие от автоматического расчёта или вывода системы
  • 09 определить, каких данных не хватает для окончательной проверки

Задача Бюро — восстановить проверяемую связь: товар → параметр или складское событие → действующее правило → расчёт → конкретное финансовое последствие.

09 Где заканчивается факт и начинается расчёт платформы

При проверке важно разделять:

  • 01 фактические параметры товара
  • 02 событие, которое действительно произошло на складе или в логистической цепочке
  • 03 правило, по которому платформа квалифицировала это событие
  • 04 формулу или тариф, применённые к событию
  • 05 итоговое начисление в отчёте продавца

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

Проверка начинается с факта и заканчивается финансовым результатом: параметр → событие → правило → тариф → начисление.

10 Что нельзя утверждать без подтверждения

До проверки конкретных данных нельзя заранее утверждать, что:

  • 01 площадка неправильно измерила товар
  • 02 склад зафиксировал ошибочные параметры
  • 03 применён не тот тариф
  • 04 начисление произведено задним числом
  • 05 логистический сбой произошёл по вине маркетплейса
  • 06 штраф или удержание автоматически являются неправомерными
  • 07 продавец корректно указал все исходные параметры
  • 08 перерасчёт обязательно должен быть произведён
  • 09 обращение в поддержку гарантированно приведёт к отмене начисления

Вывод формируется только после сопоставления исходных параметров товара, фактического события, действовавших правил, тарифа и финансового отражения операции.

11 Что может быть результатом проверки

Результатом проверки становится не общий вывод о том, что маркетплейс “прав” или “ошибся”, а восстановленная цепочка конкретного начисления — от параметров товара и складского события до применённого тарифа и суммы в отчёте. По итогам могут быть сформированы:

  • 01 хронология спорной поставки, замера или логистического события
  • 02 сопоставление параметров товара с данными склада и карточки
  • 03 проверка действовавшей редакции тарифа или правила
  • 04 расчётная цепочка спорного удержания
  • 05 перечень расхождений между данными продавца и платформы
  • 06 фиксация последующих корректировок или перерасчётов
  • 07 перечень недостающих данных
  • 08 структурированная позиция для обращения в поддержку или претензионной работы
  • 09 техническая часть материалов для профильного юриста
  • 10 вывод о том, какие обстоятельства подтверждаются документально, а какие остаются неустановленными

Контур М4 используется как дополнительный слой проверки цифрового и расчётного основания и не заменяет экспертизу, судебную оценку, юридическое представительство или полномочия самой платформы.