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

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

Теперь в моих магазинах закрытие месяца начинается с отчёта о реализации, но не заканчивается им. Я использую его как документальную основу для суммы реализованных товаров, а затем связываю её с остальными начислениями, удержаниями и выплатами. Это отличается от привычки смотреть на крупную цифру продаж в кабинете и прикидывать, сколько должно остаться. Ниже я объясню, какие суммы сопоставляю и в каком порядке проверяю расхождения. Конкретные названия колонок могут меняться, поэтому я буду опираться на содержание строк, а не на расположение кнопок.

Что искать в отчёте, прежде чем смотреть итог

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

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

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

Почему личный кабинет показывает другую сумму

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

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

У банковской выписки своё ограничение: она показывает движение денег, а не состав реализованных товаров. В перечислении могут оказаться расчёты по операциям разных периодов, тогда как часть суммы за закрываемый месяц ещё остаётся к выплате. Именно поэтому я беру отчёт о реализации за основу сверки месяца: он задаёт документально отражённый состав реализации за период. Но один этот документ не обязан объяснять все услуги, корректировки и движения взаиморасчётов. Месяц сходится по связке документов, а не благодаря попытке приравнять итог отчёта к поступлению в банк.

Как я считаю сумму от реализации до прибыли

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

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

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

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

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

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

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

Ошибка, из-за которой расходы появляются повторно

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

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

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

Что проверить завтра при закрытии месяца

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

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

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