Как проверить акт сверки с Ozon и найти причину расхождения

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

Когда я открываю в Ozon Seller акт сверки, мне нужен ответ на конкретный вопрос: из каких операций получилась задолженность на конец периода. Цифры в кабинете помогают ориентироваться, но сами по себе не объясняют движение от начального остатка к конечному. Для этого я сопоставляю акт с документами о продажах, удержаниях, корректировках и перечислениях. Затем отдельно проверяю фактическое поступление денег по банковской выписке. Такой порядок позволяет сначала найти участок расхождения и только потом разбирать относящиеся к нему строки.

Зачем нужна сверка Ozon, если суммы видны в кабинете

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

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

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

Какие отчёты о взаиморасчётах Ozon сопоставлять

Для проверки я собираю акт за нужный период, предыдущий проверенный акт, отчёт о реализации и доступную детализацию начислений, удержаний и выплат. Отдельно беру документы по услугам и корректировкам, если их суммы участвуют во взаиморасчётах. Банковскую выписку держу рядом, но не использую вместо отчёта о продажах. У каждого источника своя задача: один объясняет реализацию, другой удержание, третий перечисление денег. Состав документов зависит от операций продавца, поэтому отсутствие знакомого названия файла само по себе ещё не означает, что какой-то суммы не хватает.

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

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

Как сверить отчёт Ozon от начального остатка до конечного

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

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

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

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

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

Какие расхождения объяснимы и где продавец теряет деньги

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

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

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

Что проверить за пятнадцать минут и что сделать завтра

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

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

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

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