Сверка отчётов Wildberries и Ozon с 1С и МоимСкладом

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

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

Какие отчёты и документы сравнивать?

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

Для Wildberries актуальный источник построчных данных — детализации к отчётам реализации: список отчётов за период и детализация по ID отчёта или за период, с данными с 1 января 2025 года по списку и с 29 января 2024 года по детализации за период. Старый метод отчёта о продажах по реализации помечен как устаревший и удаляется, поэтому сверка, построенная на нём, перестанет работать (WB API, раздел «Документы и бухгалтерия», проверено 31 октября 2026). Если ваша таблица или интеграция тянет данные старым методом, это первое, что нужно исправить.

Для Ozon отчёт о реализации формируется за календарный месяц не позднее 5-го числа следующего; если выплаты за месяц были две, площадка готовит два отчёта — за первую половину и за весь месяц (справка Ozon «Взаиморасчёты», проверено 31 октября 2026). В API это метод отчёта о реализации второй версии, выпущенный в мае 2024 года именно для того, чтобы данные совпадали с личным кабинетом (Ozon for dev, 2 мая 2024).

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

Почему продажа, начисление и выплата различаются?

Три суммы за один и тот же месяц — продано, начислено, выплачено — почти никогда не совпадают, и это не ошибка. У них разные моменты признания, разный состав и разные периоды.

Продажа признаётся площадкой в момент выкупа покупателем, а не в момент заказа или отгрузки. Заказ, оформленный 30-го числа и выкупленный 3-го, в учёте компании может стоять отгрузкой прошлого месяца, а в отчёте площадки — продажей следующего. Возврат, принятый площадкой, уменьшает продажи того периода, в котором принят, а не того, в котором была продажа.

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

Выплата — начисление за расчётный период минус переходящие остатки и корректировки. У Ozon по стандартному графику деньги приходят два раза в месяц: операции до 15-го числа — в первый платёж, с 16-го по конец месяца — во второй, причём второй платёж привязан к согласованию отчётных документов (справка Ozon «Взаиморасчёты»). У Wildberries еженедельные отчёты и своё расписание выплат, при этом в списке отчётов есть поле суммы банковского платежа рядом с суммой к перечислению — именно их и нужно сравнивать (WB API, список отчётов реализации).

Из этого следует правило: сверять нужно не «месяц с месяцем», а три пары по отдельности.

Тот, кто сравнивает итог продаж за месяц в 1С с суммой выплаты на счёт, получает расхождение всегда — и не узнаёт из него ничего.

Как нормализовать периоды и идентификаторы?

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

Периоды. У Wildberries отчётный период — неделя, у Ozon — половина месяца или месяц, у учёта — месяц. Нормализация означает, что каждая строка получает единую дату события — дату продажи или возврата, — а отчётный период становится атрибутом, а не основой группировки. Сверка идёт по датам событий, а границы периодов учитываются как переходящие строки: продажа в последний день месяца, попавшая в отчёт следующего, не расхождение, а переход.

Идентификаторы. У каждой стороны свой набор:

Для Wildberries ключом сопоставления операций служит srid: он присутствует в детализациях к отчётам реализации, в статистике заказов и продаж и в отчёте об эквайринге, и площадка прямо рекомендует его для определения заказа (WB API, отчёты). Если заказы с площадки попадают в учёт с сохранением srid, сверка продаж становится точным соединением по ключу. Если нет — сопоставлять приходится по товару, дате и сумме, и часть строк останется неоднозначной.

Для Ozon ситуация сложнее: в отчёте о реализации позиции и номера заказов — разные сущности, и площадка в своём сообществе подтверждает, что прямой связи нет; сопоставлять можно по артикулу или SKU и цене с данными методов отправлений (Ozon for dev, обсуждение поля «Реализовано на сумму»). Поэтому для Ozon сверка продаж идёт в два шага: отправления из учёта сопоставляются с транзакциями по номеру отправления, а транзакции — с отчётом о реализации по товару, дате и сумме.

Товары. Один и тот же товар должен иметь одну строку соответствия: внутренний код учёта ↔ артикул продавца на каждой площадке ↔ баркод ↔ SKU площадки. Без таблицы соответствий сверка остановится на первом же товаре, который на площадке называется иначе, чем в учёте. Как устроен обмен с учётной системой, из которого берутся отгрузки и в который возвращаются отчёты комиссионера, описано на страницах интеграция с 1С и интеграция с МоимСкладом; для сверки важно, что из обмена должны приходить идентификаторы площадки, а не только названия.

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

Как сопоставлять возвраты и корректировки?

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

Возвраты. У Wildberries возврат — отдельная строка с типом документа «Возврат» и тем же srid, что у исходной продажи, поэтому пару можно найти по ключу. Логистика возврата — отдельная строка операции. Ozon включает возвраты в отчёт о реализации того месяца, в котором они приняты, и в начисления с датой операции. В учёте возврат — документ возврата от покупателя или сторно отгрузки. Правило сопоставления: возврат привязывается к исходной продаже независимо от периода, и только после этого сравниваются итоги; незакрытая пара «продажа без возврата в учёте при возврате в отчёте» — расхождение, которое нужно разобрать.

Невыкупы и отмены. Товар, который покупатель не забрал, в отчёте о реализации площадки продажей не является, но логистика по нему начислена. В учёте такой заказ может висеть отгрузкой. Строка логистики без продажи — не ошибка площадки, а признак того, что в учёте отгрузку нужно отменить или оформить возврат.

Корректировки площадки. Пересчёт логистики, доплаты, компенсации, сторно комиссии приходят отдельными строками с собственным типом операции. У Ozon корректировки оформляются УКД к акту и отдельно видны в документах (seller-edu Ozon, FAQ по документам). Корректировки не сопоставляются с отгрузками — они сопоставляются с исходной строкой, которую корректируют, и в реестре идут отдельной категорией.

Удержания без привязки к заказу. Хранение, платная приёмка, штрафы за занижение габаритов, удержания за подмены и самовыкупы в отчёте Wildberries стоят строками с типом начисления и датой, но часто без конкретного заказа. Их основание — отдельные отчёты об удержаниях: по габаритам отчёт содержит заявленные и измеренные размеры с фотографиями, по подменам — старый и новый артикул с фото, по самовыкупам — сумму за неделю при удержании 30% от стоимости товаров (WB API, отчёты об удержаниях). Сверка здесь означает не поиск пары в учёте, а проверку: есть ли в детализации удержаний запись на эту сумму и дату, и согласны ли вы с её основанием.

Таблица типов строк и правил сопоставления:

Что проверяется обычной арифметикой?

Большая часть сверки — не задача для нейросети. Это соединение таблиц по ключу, сравнение сумм с допуском и проверка контрольных равенств. Делать это должна детерминированная программа, которая даёт одинаковый результат при одинаковых входных данных и не «додумывает».

Контрольные равенства, которые проверяются кодом без участия человека:

1. Сумма строк детализации по полю «к перечислению» равна итогу в списке отчётов за тот же ID отчёта. У Wildberries список отчётов содержит агрегаты — сумма продаж, к перечислению, логистика, хранение, приёмка, удержания, штрафы, доплаты, — и они должны сходиться с построчной детализацией (WB API, список отчётов реализации).
2. Для каждой строки продажи: цена со скидкой минус комиссия минус прочие удержания строки равна сумме к перечислению по строке, с учётом знаков.
3. Процент комиссии по строке соответствует категории товара и действующему тарифу на дату продажи; отклонения — список на проверку.
4. Эквайринг по строке равен заявленному проценту от суммы, и совпадает с отчётом об издержках на приём платежей.
5. Каждая строка продажи и возврата нашла ровно одну пару в учёте; строки без пары и пары без строки — в реестр.
6. Каждая строка удержания имеет запись в детализации удержаний на ту же сумму и дату.
7. Сумма банковского платежа по отчёту равна поступлению в выписке; разница — переходящие операции или удержание в счёт долга, и она должна объясняться.
8. Итог отчёта комиссионера в учёте за период равен сумме к перечислению по отчётам площадки за тот же набор отчётов.

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

Для масштаба: по исследованию Data Insight и Точка Банка 2025 года, селлеры универсальных маркетплейсов в среднем используют один инструмент аналитики, и самый популярный — Excel, 35% (Data Insight, «Исследование селлеров универсальных маркетплейсов 2025»). Таблица хорошо справляется с равенствами 1 и 8 и плохо — с 5 и 6, где нужны соединения по ключам на тысячах строк и история по периодам. Именно там начинается смысл автоматизации — и это всё ещё арифметика, а не ИИ.

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

Где полезен ИИ?

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

Задачи, которые имеет смысл отдавать модели:

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

Чего модели делать нельзя: пересчитывать суммы, принимать решение о согласии с удержанием, отправлять обращение без подтверждения, изменять документы в учёте. Арифметика — код; решения и внешние действия — человек. Такое разделение Like Sites закладывает в агента сверки как принцип: детерминированная часть считает и сопоставляет, модель объясняет и готовит черновики, человек утверждает, а каждое действие записывается в журнал (страница «ИИ-агенты для бизнеса», условия на 31 октября 2026 года).

Схема разделения задач:

Если исполнитель предлагает «ИИ, который сверит отчёты», спросите, какая часть работы делается моделью, а какая кодом. Правильный ответ: модель не касается цифр.

Как составить реестр расхождений?

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

Минимальный набор полей:

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

Три правила ведения:

1. Одна строка — одно расхождение. Если по заказу разошлись и сумма продажи, и логистика — это две строки с разными типами и равенствами.
2. Категория причины назначается после разбора, а не при обнаружении. До разбора у строки статус «открыто» и предварительная категория от классификатора.
3. Закрытие — только с результатом в деньгах. «Разобрались» — не закрытие; «признано удержание 450 ₽, основание — отчёт по габаритам от такого-то числа» — закрытие.

Отчёт по реестру за месяц даёт четыре цифры, которые нужны собственнику: сумма открытых расхождений, сумма в обращениях, сумма возвращённого, сумма признанного. Динамика этих цифр по месяцам показывает, улучшается ли учёт и меняется ли поведение площадки, — и это те данные, которых у компании без реестра просто нет.

Почему расхождение ещё не означает потерю?

Соблазн после первой полной сверки — сложить все расхождения и назвать сумму «потерями на площадке». Это неверно, и обращение в поддержку с такой суммой закончится ничем. Расхождение — это строка, которая не прошла проверку, и у неё есть несколько возможных объяснений, большинство из которых — не потеря.

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

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

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

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

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

Как готовить материалы для проверки и обращения?

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

Состав пакета для одной категории расхождений:

1. Перечень операций: идентификатор заказа или отправления, артикул, дата, тип строки, сумма по отчёту площадки, ожидаемая сумма и разница — таблицей.
2. Выдержки из отчётов площадки: ID отчёта, период, строки с полями как есть, без пересчёта.
3. Основание расчёта ожидаемой суммы: тариф категории на дату, условия договора, расчёт по строке.
4. Для удержаний — результат проверки детализации: запись найдена или не найдена; если найдена — почему вы с ней не согласны, с фотографиями и замерами, если спор о габаритах или подмене.
5. Для расхождений по возвратам — статус возврата по отчёту о возвратах площадки и документ в учёте.
6. Формулировка запроса: что просите — пересчёт, сторно, разъяснение основания.

Для Wildberries выдержки по удержаниям готовятся из соответствующих отчётов: по габаритам — с заявленными и измеренными размерами, по подменам — со старым и новым артикулом, по маркировке — с фотографиями; отчёт о возвратах даёт статус, причину и даты по каждому возврату (WB API, отчёты об удержаниях и возвратах). Для Ozon основания расходов — акт выполненных работ и УКД, а построчные начисления — отчёт «Начисления» и список транзакций за период не более месяца в одном запросе (справка Ozon «Отчёты»).

Здесь уместна работа модели: собрать из строк реестра одной категории таблицу, выдержки и черновик текста. Но отправляет обращение человек, после проверки идентификаторов и сумм. И каждое обращение фиксируется в реестре: номер, дата, статус, ответ площадки, результат в деньгах. Без этого через два месяца невозможно понять, по каким строкам ответ получен, а по каким нужно напомнить.

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

Когда автоматическая сверка не нужна?

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

• Объём мал. Десятки заказов в месяц сверяются вручную за час, и все строки видны глазами. Построчная автоматизация начинает окупать себя, когда таблица перестаёт помещаться в голову: сотни и тысячи строк в месяц, несколько площадок, несколько складов.
• Одна площадка и одна схема. При продажах только по FBO на одной площадке состав строк стабилен, и готового отчёта комиссионера в учётной системе с типовой загрузкой часто достаточно.
• Учёт не ведётся построчно. Если отгрузки не заводятся по заказам, а продажи площадки вносятся одной суммой в месяц, сверять построчно нечего — сначала учёт по заказам, потом сверка.
• Нет таблицы соответствий товаров. Без неё любая сверка остановится на первом товаре; её создание — отдельная задача, часто решаемая вместе с интеграцией учёта и площадок.
• Нет ответственного за разбор. Сверка находит расхождения, но решения и обращения — работа человека. Если некому разбирать реестр, автоматизация произведёт список, который никто не прочитает.
• Готовый сервис закрывает задачу. Для типовой сверки продаж с учётом существуют модули учётных систем и подписочные сервисы; заказная разработка нужна, когда вам требуются свои правила сопоставления, несколько систем, детерминированные равенства по удержаниям и реестр с историей.

Признак обратный — сверка нужна даже при небольшом объёме, если цена ошибки высока: дорогие товары, большие удержания по габаритам или подменам, частые возвраты. Там одна найденная строка может стоить больше месяца сопровождения.

Как принять пилот?

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

Что подготовить к пилоту:

• Детализации отчётов о реализации обеих площадок за три–шесть закрытых месяцев — через API или выгрузкой из кабинета.
• Отчёты об удержаниях и возвратах за те же периоды.
• Отчёты о реализации Ozon за месяц и акты, УПД, УКД.
• Выгрузку отгрузок, возвратов и отчётов комиссионера из 1С или МоегоСклада за те же периоды с идентификаторами площадок, если они сохраняются.
• Банковскую выписку по поступлениям от площадок.
• Таблицу соответствий товаров или согласие её построить на первом этапе.
• Результаты вашей ручной сверки за эти периоды, если она делалась, — для сравнения.

Данные передаются после договора и в рамках согласованных доступов; для первичной оценки достаточно описания объёма, площадок и учётной системы.

Метрики приёмки:

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

Как устроен пилот процессного агента в целом — режим черновиков, роли доступа, условия остановки, передача кода и документации — разобрано в статье как внедрить ИИ-агента в бизнес: пилот, тесты, безопасность. Полная стоимость агента сверки — разработка, поддержка, инфраструктура, время на разбор реестра — и то, как сопоставить её с найденными расхождениями и часами бухгалтера, разобраны в статье сколько стоит ИИ-агент для бизнеса и когда он окупается. На условиях Like Sites сверка отчётов маркетплейсов с 1С или МоимСкладом — один из восьми процессов каталога со стартовой ценой 250 000 ₽, поддержкой 35 000 ₽ в месяц и инфраструктурой 5 000–15 000 ₽ в месяц по факту; оплата 50% на старте и 50% после приёмки по метрикам, первая неделя — только черновики, код и документация передаются клиенту (страница «ИИ-агенты для бизнеса», условия на 31 октября 2026 года). Это условия одного исполнителя на дату проверки, а не рыночная цена.

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