Отчет о реализации - единственный документ WB, по которому можно доказать цифру деньгами, а не поверить кабинету на слово. Формируется еженедельно, приходит в понедельник за прошедшую неделю, и хвост месяца виден уже через один-три дня. К перечислению считается как строки Продажа минус Возврат плюс добровольная компенсация при возврате и коррекция продаж - остальные операции отчета вычитаются позже и в эту сумму не входят. Три частые ошибки: фильтровать месяц по периоду отчета вместо даты продажи, ловить возвраты поиском по подстроке и суммировать колонку вознаграждения целиком. И главное: умножать заказы-нетто на процент выкупа нельзя - это двойной счет, который занижает план на 9-14 процентов.
У селлера на Wildberries есть ровно один документ, которым можно что-то доказать: еженедельный отчет о реализации. Все остальное - витрины, сводки и графики кабинета - удобно для наблюдения, но в спорной ситуации не стоит ничего. Отчет о реализации построчный, в нем видно каждую операцию, и именно по нему считается сумма, которую площадка переводит на счет.
Разбираю его как документ проверки: что внутри, чем к перечислению отличается от выручки и от заказов, где прячутся удержания и в каком порядке искать причину расхождения.
Что это за документ и когда он появляется
Кабинет продавца, финансовые отчеты, отчеты реализации. Выгружается в xlsx, тянется через API. Формируется еженедельно: в понедельник закрывается прошедшая неделя.
Из этого следует практический вывод, который многие упускают. Месяц закрывается деньгами через один-три дня после его окончания, а не через две недели: хвост месяца попадает в первый же понедельничный отчет. До этого момента сверять план надо по заказам, они видны в кабинете в тот же день. Именно поэтому план разумно строить в заказах, а деньги делать производной от них.
Две технические детали, на которых спотыкаются при первом разборе:
- На одну неделю приходится два блока строк. Основной отчет и отдельно продажи юридическим лицам. Если взять только первый, часть денег потеряется.
- Дат в отчете несколько. Дата продажи, дата операции, период отчета. Для расчета за календарный месяц нужна именно дата продажи: недельные отчеты пересекают границы месяцев, и фильтрация по периоду отчета дает смещение.
Три разные цифры, которые постоянно путают
Заказы. Намерение купить. Считаются в тот же день, отменяются в течение недель, деньгами не являются вообще.
Выкупы. Факт получения товара покупателем. Это уже проданный товар, но еще не ваши деньги: из суммы предстоит вычесть долю площадки.
К перечислению. Деньги, которые площадка готова перевести на счет за реализованный товар. Комиссия уже вычтена, а логистика, хранение, штрафы и реклама - еще нет.
И ни одна из трех не является чистой прибылью. Между к перечислению и прибылью стоят удержания площадки, реклама, эквайринг, налог и ваша себестоимость - о них подробно в отдельном разборе про чистую прибыль на Wildberries.
Из чего складывается сумма к перечислению
В отчете есть колонка “К перечислению Продавцу за реализованный Товар”. В API это отдельное поле, и складывать надо не всю колонку подряд, а по типам операций:
К перечислению = Продажа минус Возврат плюс Добровольная компенсация при возврате плюс Коррекция продаж
Все прочие операции отчета - логистика, хранение, приемка, удержания, штрафы, обработка товара, возмещение издержек - в эту сумму не входят. Они вычитаются на следующем шаге, когда считается итог к оплате.
Три ловушки, каждая из которых дает расхождение в десятки тысяч рублей.
Возвраты нельзя ловить поиском по куску слова. Под фильтр по строке “озврат” попадает и добровольная компенсация при возврате, которая должна прибавляться, а не вычитаться. Итог разъедется ровно на удвоенную сумму компенсаций, и найти это потом тяжело.
Колонку вознаграждения нельзя суммировать целиком. Поле с вознаграждением встречается и в строках продажи - там это часть комиссии, а не возмещение вам. Считать надо по типу операции. На реальном месячном объеме разница между “сумма по колонке” и “сумма по нужным операциям” была в двести раз.
Строки без привязки к артикулу. Часть операций, особенно по хранению, не привязана к конкретной карточке. Если собирать P&L суммированием по артикулам, эти строки просто исчезнут. Правильный порядок: расходные статьи брать суммой по всему построчному листу, а к перечислению - выборкой по типу операции.
Какие удержания в отчете прячутся
Формально они не спрятаны, но лежат отдельными строками среди тысяч других, и без группировки их не видно.
- Логистика. Доставка до покупателя и обратный путь по каждому невыкупу.
- Хранение. Зависит от оборачиваемости: чем дольше товар лежит, тем дороже каждая единица.
- Приемка и обработка товара. Разово при поставке, ставка зависит от склада и загрузки.
- Штрафы и удержания. Маркировка, упаковка, нарушение поставки. Идут пунктиром, поэтому масштаб становится виден только в сумме за месяц.
- Возмещение издержек. Разбирать построчно, что именно возмещается.
Отдельно то, чего в отчете нет вообще: реклама (она проходит отдельным документом и отдельными удержаниями), эквайринг, налог и себестоимость.
И одна строка, которую регулярно принимают за расход: погашение заемных средств площадки. Это возврат тела кредита. Он уменьшает сумму, которая придет на счет, но не уменьшает прибыль. В P&L его место - справочная строка, а не расход. Если поставить погашение в расходы, вы дважды заплатите за одни и те же деньги: один раз при закупке товара, второй раз при возврате займа.
Как сверить отчет со своими цифрами
Порядок проверки, который мы применяем к любому периоду.
Шаг 1. Три независимых прохода. Считаем итог тремя способами: по каждому недельному отчету отдельно, по месяцам с фильтром по дате продажи и прямой формулой по типам операций на всем массиве. Три числа обязаны совпасть. Если совпали два из трех - ошибка в третьем способе, и ее видно сразу.
Шаг 2. Сверка с банком. Сумма поступлений на счет за период должна сходиться с итогом к оплате из отчетов с поправкой на разрыв в датах и на погашение займа. Это финальная проверка: банк не ошибается.
Шаг 3. Список номеров отчетов. В любой расчет, который уходит клиенту или партнеру, кладем перечень всех недельных отчетов, которые в него вошли, с номерами и периодами. Человек открывает отчет по номеру и сверяет одну строку один в один. Расчет, который нельзя проверить руками, считается непроверенным.
Шаг 4. Ролл-форвард. Остаток на начало периода плюс начисления минус удержания минус выплаты равно остатку на конец. Сходится в ноль - расчет корректный, не сходится - ищем недостающий тип операции.
Почему нельзя умножать заказы на процент выкупа
Самая распространенная ошибка в планировании, и она системная.
Логика выглядит убедительно: заказали на миллион, выкупают 80 процентов, значит денег будет на 800 тысяч. Проблема в том, что процент выкупа из воронки кабинета считается от общего числа заказов и уже включает в себя отмены и отказы при получении. А заказы из выгрузки обычно берут очищенными от отмен. В итоге одни и те же потери вычитаются дважды.
Мы проверяли это на полных когортах со сцеплением заказа и строки реализации по общему идентификатору: до выкупа доходит практически весь очищенный от отмен поток, по разным предметам от 99,7 до 100 процентов. То есть заказ-нетто по деньгам тождествен выкупу, и умножать его на процент выкупа не на что. Ошибка занижала план на 9-14 процентов по разным предметам - при обороте в несколько миллионов в месяц это сотни тысяч рублей мнимого недобора.
Как переводить заказы в деньги правильно:
К перечислению = заказы-нетто х средняя цена заказа х коэффициент предмета
Коэффициент - это отношение фактически перечисленного к цене заказа, он вбирает в себя комиссию, скидки площадки и мелкие корректировки. Считать его надо по когортам, сцепляя заказ и строку реализации по общему идентификатору: так не нужно предполагать средний срок доставки. Дальше модель валидируется на трех месяцах подряд против факта. Нормальное расхождение - до 5 процентов, больше - в модели что-то не учтено.
Что делать при расхождении
Порядок, который экономит часы. Проверять сверху вниз, не перескакивая.
- Даты. Фильтр по дате продажи, а не по периоду отчета. Это причина примерно половины расхождений.
- Полнота выгрузки. Все ли недельные отчеты на месте, оба ли блока строк за каждую неделю, нет ли дублей после повторной догрузки.
- Свежесть данных. Не верить дате локальной выгрузки. Прежде чем заявить “данных еще нет”, надо дернуть источник заново: отчет мог появиться в кабинете еще позавчера, а копия просто не обновлялась.
- Типы операций. Все ли четыре нужные операции вошли в к перечислению и не попал ли туда лишний тип.
- Хвосты прошлых периодов. Возврат по продаже позапрошлого месяца попадает в текущий отчет. Это не ошибка, это природа документа, но в помесячной раскладке это надо видеть.
Если после пяти шагов расхождение осталось и оно больше процента, дальше идет обращение в поддержку площадки - с номером отчета, строкой и своим расчетом. Формулировка “у меня не сходится” не работает, работает “в отчете номер такой-то строка такая-то, ожидаю такую сумму по такой формуле”.
Коротко о главном
Отчет о реализации - это документ проверки, а не справка. Он построчный, в нем видно каждую операцию, и любую цифру из него можно доказать.
К перечислению - это продажи минус возвраты плюс компенсации и коррекции. Это не выручка и не прибыль: удержания, реклама, налог и себестоимость стоят после. Месяц режется по дате продажи, а не по периоду отчета. Погашение займа - не расход.
И главное правило планирования: заказы-нетто на процент выкупа не умножаются. Переводить заказы в деньги нужно через коэффициент, посчитанный по когортам и проверенный на трех месяцах факта.
Хочешь увидеть свои цифры так, как их видим мы?
Сделаем мини-отчет на твоих реальных данных за 1-2 рабочих дня. Три находки, конкретные суммы, разбивка по каждой строке в выгрузке. Бесплатно, без обязательств.
Открыть бот @aximaa_bot