Как в SellerHub нашли расхождения выручки на больших каталогах
В SellerHub сверка выручки с маркетплейсами начала ломаться на крупных продавцах: комиссии, штрафы и логистика считались по-разному, а отчёты требовали batch-обработки.
10 000+ SKU на одной площадке — это тот объём, на котором финансовая сверка SellerHub начала вести себя иначе, чем на тестовых каталогах.
Задача звучала спокойно: сравнить ожидаемую выручку продавца с фактической выручкой на маркетплейсе и показать расхождения. В реальности между этими двумя числами лежали комиссии, штрафы, логистика и правила каждой площадки. Одно и то же событие в заказе могло попадать в отчёт разными строками, с разными датами и детализацией.
Пока продавец небольшой, это ещё можно разобрать глазами. На крупном каталоге отчёт превращается в пачку связанных начислений и удержаний, где ошибка в одной категории выглядит как «не сходится выручка».
Как заметили проблему
Первые расхождения выглядели как ошибка формулы. Ожидаемая сумма в SellerHub отличалась от фактической суммы в отчёте маркетплейса. Причём отличие не было стабильным: на одних наборах данных всё сходилось, на других появлялись хвосты по комиссиям, штрафам или логистике.
Мы начали с очевидного: проверили, как считаем выручку, какие удержания вычитаем, какие начисления добавляем. Отдельно смотрели комиссии, отдельно логистику, отдельно штрафы. Это была та часть расследования, где легко зависнуть: у каждой площадки своя модель расчётов, и хочется привести всё к одной красивой схеме.
Живая деталь: спорили не о том, где поставить ещё один if, а о том, считать ли расхождение ошибкой или нормальным следствием детализации отчёта. Для продавца ответ простой: если в ожидаемой и фактической выручке разные суммы, ему нужен понятный отчёт, а не объяснение про особенности площадки.
Где копали не туда
Сначала мы смотрели на математику. Казалось, что проблема в правилах: не тот процент комиссии, не туда отнесли логистику, неправильно обработали штраф.
Но часть расхождений не объяснялась формулами. Одни и те же правила на малом объёме работали, а на больших продавцах начинались пропуски и неполная картина. Это был важный сигнал: если бизнес-логика одинаковая, а результат зависит от размера каталога, надо смотреть не только на расчёт, но и на то, как мы забираем данные.
У крупных продавцов на каждой площадке может быть 10 000+ SKU. Сверка по такому объёму упирается в внешние интеграции: отчёты нужно получать порциями, корректно проходить страницы, не терять строки между запросами и не пытаться обработать всё одним массивом.
Что оказалось причиной
Причина была не в одном универсальном баге. Проблема складывалась из двух слоёв.
Первый слой — разные правила маркетплейсов. Комиссии, штрафы и логистика не являются одинаковыми сущностями для всех площадок. Где-то они приходят отдельными строками, где-то влияют на итоговую сумму уже в отчёте площадки. Поэтому сверка не могла быть одним сравнением «ожидали X, получили Y» без расшифровки.
Второй слой — объём. Для продавцов с большим каталогом критичными стали batch-обработка и пагинация. Если интеграция забирает не весь отчёт или пытается переварить большой набор за один проход, итоговая сверка становится недостоверной. Снаружи это выглядит как финансовое расхождение, хотя часть причины лежит в доставке данных до расчёта.
Мы разделили эти вещи. Расхождение по правилам площадки — это одно. Неполная выборка из-за пагинации или слишком крупной обработки — другое. В отчёте для продавца они не должны смешиваться.
Что поменяли в сверке
Сверку перестроили вокруг автоматического выявления несоответствий и отчёта, который показывает продавцу, где именно ожидаемая выручка расходится с фактической.
Для больших продавцов сделали акцент на обработке объёма:
- данные забираются постранично, чтобы не зависеть от размера отчёта;
- расчёт идёт batch-ами, а не одним большим проходом;
- комиссии, штрафы и логистика учитываются как отдельные категории расхождений;
- итоговый отчёт формируется после того, как интеграция собрала все нужные части данных.
Это не отменило различия между маркетплейсами. Их всё равно приходится учитывать отдельно. Зато стало проще отделять финансовую логику от транспортной проблемы: если не сошлась выручка, мы видим, это комиссия, штраф, логистика или неполный набор данных из внешней интеграции.
Следующий шаг для таких задач всегда один и тот же: не верить одной итоговой сумме. Сначала проверить, что все страницы отчёта приехали, batch-и обработались, а уже потом спорить с формулами.