Как автоматизировать сверку отчётов WB/Ozon с 1С: комиссии, логистика и выплаты

Коротко

• Сверка отчётов маркетплейсов с 1С автоматизируется на 90–95%: загрузка отчётов по API, сопоставление строк с документами учёта, расчёт ожидаемой суммы и сравнение с фактической выплатой.
• Оставшиеся 5–10% — это исключения: неопознанные удержания, штрафы, спорные возвраты, потери на складе. Их разбирает человек, но уже по короткому списку, а не по всей выгрузке.
• Основные точки расхождений: комиссия по факту не совпадает с тарифом в карточке, логистика считается по фактическому объёму, возвраты приходят в другом периоде, а из выплаты вычитается всё сразу — реклама, хранение, платная приёмка, штрафы.
• Реальная экономия: 20–40 часов в месяц у бухгалтера или финансиста плюс найденные потери. На объёме 10–30 млн выручки в месяц регулярно находится 100–400 тысяч, которые раньше просто списывали в «прочее».
• Внедрение на связке WB + Ozon + 1С занимает 3–6 недель. Начинать имеет смысл с одной площадки и одного отчёта — о реализации.

Почему ручная сверка не работает

Отчёт комиссионера — не просто «сколько продали». Это документ, где на одну продажу приходится несколько строк удержаний, а деньги за неё приходят не в том же периоде.

Возьмём одну футболку за 1 490 ₽. В отчёте она может встретиться так:

• продажа — 1 490 ₽;
• комиссия площадки — минус 348 ₽ (не 20%, потому что скидка постоянного покупателя учитывается иначе, чем вы ожидали);
• логистика — минус 76 ₽;
• через две недели возврат — минус 1 490 ₽;
• обратная логистика — минус 50 ₽;
• ещё через неделю та же единица снова продана — плюс 1 490 ₽ и всё по новой.

Теперь умножьте это на 3 000 SKU и 4 отчёта в месяц. Человек не сверяет это построчно — он сверяет итоги. А расхождение в 30 копеек на строке при 40 000 строк даёт 12 тысяч, которых никто не найдёт.

Вторая причина — разная логика площадок. У WB отчёт о реализации приходит еженедельно, и в нём смешаны продажи, возвраты, логистика, хранение и штрафы. У Ozon отдельно отчёт о реализации, отдельно транзакции, отдельно начисления за услуги. Свести их в одну модель в голове невозможно, а в Excel можно, но только один раз и не повторяемо.

Третья — 1С про это ничего не знает, пока ей не расскажут. В «Управлении торговлей» и «Комплексной автоматизации» есть механизм отчётов комиссионера, но данные туда всё равно должны попасть. Обычно попадают через ручную загрузку файла, а значит — с ошибками сопоставления номенклатуры, с задвоениями и с пропущенными периодами.

Где именно возникают расхождения

Прежде чем строить автоматизацию, полезно понимать, что именно ищем. Иначе получится красивый отчёт, который никто не читает.

Комиссия

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

Что проверяем: для каждой строки продажи считаем ожидаемую комиссию по тарифу, действовавшему на дату продажи, и сравниваем с фактической. Отклонение больше 1% или больше 50 ₽ — в исключения.

Логистика

Самая частая дыра. Логистика на WB считается по объёму (литрам), и если габариты в карточке заполнены неверно, вы платите за 12 литров вместо 5. Ошибка в одной карточке при 500 продажах в месяц — это 20–30 тысяч.

Плюс обратная логистика по возвратам и логистика по невыкупам, которые в отчёте отражаются отдельно и легко теряются при ручном подсчёте.

Что проверяем: сопоставляем фактическую сумму логистики с расчётной по габаритам из вашей карточки. Расхождение по конкретному SKU — сигнал, что габариты в карточке не соответствуют реальным.

Хранение и платная приёмка

Начисляются не за конкретную продажу, а за период и за склад. Их надо распределять по товарам, иначе юнит-экономика врёт. Ручной расчёт даёт погрешность, автоматика — распределение по объёму и остаткам.

Возвраты

Продажа и возврат живут в разных периодах. В марте вы отгрузили и получили деньги, в апреле товар вернулся и деньги вычли. Если сверять отчёты по одному, картина не сходится ни в одном месяце.

Что проверяем: цепочку по каждой единице. Продажа — возврат — повторная продажа. Возврат без соответствующей продажи в предыдущих периодах — исключение.

Штрафы и удержания

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

Выплата

Финальная проверка. Сумма, пришедшая на расчётный счёт, должна равняться: продажи − комиссия − логистика − хранение − реклама − штрафы + возвраты комиссии по отменённым заказам. Если не сходится — ищем, что не разложили.

Как выглядит рабочая схема

Опишу процесс так, как он собирается на практике, без привязки к конкретному стеку.

Шаг 1. Забор данных. Раз в сутки, по расписанию, сервис ходит в API WB (Statistics API — реализация, продажи, поставки; отдельно — детализация по услугам) и Ozon (Seller API — отчёт о реализации, транзакции, начисления). Данные складываются в промежуточную базу как есть, без обработки. Это важно: если завтра площадка изменит формат, у вас останется сырой слой, на который можно перепарсить.

Шаг 2. Нормализация. Разные названия одних и тех же сущностей приводятся к единой модели: sku_seller, sku_platform, дата операции, тип операции, сумма, период отчёта. Строится справочник соответствий артикулов — свой артикул ↔ артикул WB ↔ артикул Ozon ↔ номенклатура в 1С. Этот справочник придётся один раз собрать вручную и потом поддерживать: без него автоматизация просто не поедет.

Шаг 3. Расчёт ожидаемых величин. Для каждой продажи считается, сколько *должно было* быть удержано: комиссия по тарифу на дату, логистика по габаритам, скидки и акции. Получается «наша версия отчёта».

Шаг 4. Сопоставление. Наша версия сравнивается с версией площадки построчно. Строки, которые сошлись, помечаются как подтверждённые и идут дальше без участия человека. Остальные попадают в очередь исключений с указанием суммы и причины отклонения.

Шаг 5. Загрузка в 1С. Подтверждённые данные создают документы: отчёт комиссионера, реализация, поступление услуг по видам (комиссия, логистика, хранение, реклама), корректировки по возвратам. Загрузка идёт через HTTP-сервис 1С или обмен файлами по расписанию — зависит от вашей конфигурации и от того, где 1С живёт (на своём сервере или в облаке).

Шаг 6. Отчёт человеку. Утром в Telegram приходит сводка: загружено столько-то строк, сумма расхождений такая-то, требуют внимания N позиций. Ссылка на список исключений с расшифровкой по каждой.

Шаг 7. Разбор исключений. Здесь работает человек. Смотрит список, помечает: «это акция, всё верно», «это ошибка габаритов — надо править карточку», «это штраф, идём оспаривать». Решения сохраняются как правила, и в следующий раз похожие строки система классифицирует сама.

Именно седьмой шаг делает систему живой. Через два-три месяца работы очередь исключений сокращается вдвое, потому что типовые ситуации уже размечены. Здесь же уместен AI-агент: он читает расшифровку удержания, находит похожие разобранные случаи и предлагает классификацию — но применяет её только после подтверждения человеком.

Сколько это экономит

Считаем на конкретном профиле: селлер, 15 млн выручки в месяц, две площадки, около 1 500 активных SKU.

Было. Бухгалтер тратит на сверку 4 отчётов WB и 2 комплектов отчётов Ozon примерно 6–8 часов в неделю. Плюс финансист раз в месяц пересобирает юнит-экономику — ещё 6–8 часов. Итого 30–40 часов в месяц. Расхождения при этом не разбираются, а списываются: «где-то потеряли, поехали дальше».

Стало. Загрузка и сверка идут ночью. Человек тратит 1–1,5 часа в неделю на разбор исключений. Итого 5–7 часов в месяц. Освобождается 25–33 часа.

Но основные деньги не в часах. Они в найденном:

• неверные габариты по 8 SKU — переплата логистики около 60 тыс. ₽ за квартал, правится за час работы контент-менеджера;
• невозвращённая комиссия по отменённым заказам — обычно 15–40 тыс. ₽ в месяц, которые площадка возвращает по обращению, но только если вы её попросите;
• потери на складе, которые компенсируются при обращении в срок — здесь важна скорость обнаружения, через два месяца доказать что-либо сложно;
• корректная юнит-экономика: видно, какие SKU убыточны после всех удержаний. Обычно 10–20% ассортимента продаётся в минус, и без нормальной сверки это не видно.

По опыту, на таком объёме за первые три месяца находится 150–400 тыс. ₽. Дальше сумма падает — потому что источники ошибок устраняются. Это и есть правильный результат.

Стоимость внедрения на связке WB + Ozon + 1С — обычно в диапазоне 250–600 тыс. ₽ в зависимости от состояния учёта и конфигурации 1С. Окупаемость 3–8 месяцев. Если у вас оборот меньше 5 млн в месяц — вероятно, рано: дешевле навести порядок в таблицах и вернуться к автоматизации на следующем уровне оборота. Подробнее о том, как понять, что процесс пора автоматизировать.

Что может пойти не так

Честный список рисков — он же список того, что надо заранее обсудить с подрядчиком.

Изменения в API площадок. WB и Ozon регулярно меняют форматы и лимиты. Система должна переживать это без остановки: сырой слой данных, версионирование парсеров, алерт при изменении структуры ответа. Без этого через полгода всё сломается молча, и вы узнаете об этом в отчётный период.

Кривой справочник номенклатуры. Если в 1С один и тот же товар заведён трижды, автоматизация это унаследует и умножит. Сопоставление артикулов — самая скучная и самая важная часть проекта. Закладывайте на неё время.

Автоматическое создание документов в 1С. Это операция, которая меняет учётные данные. Никогда не запускайте её без «сухого» режима на первые 4–6 недель: система формирует документы, но не проводит их, бухгалтер проверяет и проводит сам. Только после того, как несколько периодов сошлись, можно включать автопроведение — и то с ограничением по сумме.

Права доступа. API-ключи маркетплейсов дают доступ к финансовым данным и часто к управлению ценами. Ключи — только на чтение, где это возможно; хранение — в защищённом хранилище, не в коде и не в переписке; отдельный ключ на каждую интеграцию, чтобы можно было отозвать один, не ломая остальное. Доступ к базе 1С — под отдельной учётной записью с минимальными правами.

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

Соблазн отдать всё AI. Классификация удержаний, поиск похожих случаев, черновик обращения в поддержку площадки — да. Решение «принять расхождение на 80 тысяч» — нет. Провести документ в учёте — нет. Правило простое: модель предлагает, человек утверждает, действие логируется с указанием, кто утвердил.

С чего начать

Не надо строить всё сразу. Рабочая последовательность:

Неделя 1–2. Аудит. Выгрузите последние 3 месяца отчётов. Посчитайте в Excel, насколько сходятся выплаты с расчётной суммой. Если расхождение меньше 0,5% — возможно, у вас всё неплохо и автоматизация даст только экономию времени. Если 2–5% — там лежат деньги.

Неделя 2–3. Справочник. Соберите таблицу соответствий: свой артикул, артикул WB, артикул Ozon, код номенклатуры 1С, габариты, себестоимость. Это фундамент. Делается один раз, дальше поддерживается.

Неделя 3–5. Одна площадка, один отчёт. Автоматизируйте загрузку и сверку отчёта о реализации WB. Не трогайте Ozon, рекламу, хранение. Добейтесь, чтобы недельный отчёт сходился с точностью до рубля и вы понимали каждую строку расхождений.

Неделя 5–8. Расширение. Добавляйте Ozon, потом услуги (реклама, хранение, приёмка), потом выгрузку в 1С. На каждом шаге — сухой режим и проверка человеком.

Дальше. Правила классификации исключений, автоматические обращения в поддержку площадок по типовым потерям, дашборд юнит-экономики по SKU с учётом всех удержаний.

Если внутри команды нет разработчика, который возьмёт это на себя, — не начинайте с самого сложного контура. Начните с шага «аудит» силами финансиста и Excel. Результат этого шага уже покажет, стоит ли вкладываться дальше.

FAQ

Можно ли обойтись типовыми механизмами 1С без разработки? Частично. В «Управлении торговлей» 11 и «Комплексной автоматизации» есть загрузка отчётов комиссионера и обмен с маркетплейсами. Этого хватает, если у вас одна площадка, простой ассортимент и вы готовы мириться с ручным разбором. Как только появляются две площадки, услуги, реклама и логика проверки расхождений — типовой функционал упирается в потолок, и нужен промежуточный слой между API и 1С.

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

Что делать с расхождениями, которые нашлись за прошлые периоды? Смотрите на сроки. У площадок есть регламент подачи обращений — обычно от 30 до 90 дней в зависимости от типа претензии. Что попало в срок — оспаривайте, начиная с самых крупных сумм. Что не попало — используйте как данные: правьте габариты, категории, условия участия в акциях. Массово оспаривать всё подряд смысла нет, поддержка площадки просто утонет в обращениях, а вы — в переписке.

Нужен ли для этого AI или достаточно обычных скриптов? Основная часть — обычная детерминированная логика: забор данных, сопоставление, арифметика. AI здесь не нужен и даже вреден, потому что в финансовых расчётах нужна воспроизводимость. Языковая модель полезна на одном участке: классификация непонятных удержаний по текстовому описанию и подготовка черновиков обращений в поддержку. Это 5% объёма работы, но самая нудная её часть.

Сколько строк выдерживает такая система? На типовом стеке (Python + PostgreSQL + очередь задач) 200–500 тысяч строк в месяц обрабатываются за минуты. Узкое место обычно не в объёме данных, а в лимитах API площадок: приходится растягивать выгрузку и корректно обрабатывать ошибки 429. Поэтому загрузка ставится на ночь, а не запускается по кнопке.

Что если 1С стоит в облаке и туда нет прямого доступа? Работает через файловый обмен или через опубликованный HTTP-сервис. У большинства облачных провайдеров 1С есть возможность публикации веб-сервисов на тарифе выше базового. Если совсем нет — остаётся обмен через папку синхронизации: медленнее и требует аккуратности с блокировками, но рабочий вариант.

Как понять, что подрядчик делает нормально, а не «нарисовал дашборд»? Три проверки. Первая: попросите показать, что происходит при изменении формата ответа API — должен быть алерт, а не тихая потеря данных. Вторая: попросите откатить одну конкретную загрузку — если это делается руками по строкам, архитектура плохая. Третья: возьмите одну случайную строку в 1С и попросите проследить её до исходной строки в отчёте площадки. Если прослеживается за минуту — всё в порядке.