Выплату Ozon я не использую как готовую сумму для расчёта УСН, хотя именно её проще всего взять из банковской выписки. Деньги уже на счёте, назначение платежа знакомое, а удержания площадки остались где-то в отчётах. Если считать налог от этого поступления, комиссия и другие удержанные расходы незаметно исчезнут из налоговой базы. На УСН «Доходы» такое вычитание обычно неправомерно. В моих магазинах я поэтому разделяю деньги, которые перечислил маркетплейс, доход для налога и прибыль после расходов.
Вопрос «с какой суммы платить налог на маркетплейсе» я сначала перевожу в вопрос о конкретной операции: сколько дохода получил продавец и что из него площадка удержала. Банковская выписка показывает движение денег между Ozon и продавцом, а не всю историю расчёта с покупателем. Между продажей и выплатой могут оказаться комиссия, услуги, возвраты, взаимозачёты и корректировки. Если смотреть только на итог перевода, эти разные по смыслу операции сливаются в одну сумму. Дальше я разбираю именно УСН с объектом «Доходы»: для другого объекта налогообложения порядок учёта расходов будет отличаться.
С какой суммы платить налог — с продажи или с выплаты Ozon
При обычной продаже через маркетплейс в доход продавца входит выручка от реализации до удержания вознаграждения площадки. Ozon может оставить свою комиссию из денег покупателя и перечислить остаток, но от этого доход продавца не превращается в остаток. Удержанная комиссия означает, что часть выручки пошла на оплату услуг посредника. Для УСН «Доходы» такой расход не уменьшает налоговую базу. Поэтому отправной точкой я беру документы о продажах и расчётах, а банковскую выплату использую для проверки того, как площадка рассчиталась со мной.
Здесь легко спутать налог на Ozon для продавцов с налогом на заработанную прибыль. После закупки товара, комиссии, логистики и рекламы у меня действительно остаётся меньше денег, чем заплатили за проданный товар. Но объект «Доходы» не предполагает, что я вычту эти затраты перед применением ставки. Даже убыточная продажа может сформировать доход, учитываемый при УСН. Если продавец также обязан исчислять НДС, предъявленный покупателю НДС требует отдельного учёта и не должен автоматически попадать в доход для УСН. Поэтому фраза «налог со всей суммы покупателя» полезна как ориентир, но без проверки состава суммы бывает слишком грубой.
Цена на карточке тоже не заменяет сумму дохода по документам. Скидка продавца, скидка за счёт площадки, бонусы и компенсационные начисления могут по-разному отражаться в расчётах, поэтому я не восстанавливаю налоговую базу по витринной цене. Сначала нужно увидеть, какая сумма признана выручкой продавца и какие начисления идут отдельно. Затем проверить, не посчитано ли одно и то же поступление повторно под другим названием. Без конкретного отчёта и условий программы я не могу уверенно сказать, как учитывать любую строку со словом «бонус»: здесь решает содержание операции.
Какие документы нужны, чтобы доход не потерялся между отчётами
Я начинаю с отчётных документов Ozon, в которых раскрываются продажи, возвраты, начисления и удержания, а затем сопоставляю их с банковской выпиской. Названия разделов кабинета и состав выгрузок могут меняться, поэтому ориентироваться только на знакомую кнопку ненадёжно. Мне нужны сумма операции, её основание, дата и связь с продажей либо услугой. Когда в документе виден лишь итог взаиморасчётов, для налогового расчёта этого недостаточно. Нужно раскрыть составляющие, иначе комиссия будет выглядеть просто как недополученная выручка, хотя экономически и для учёта это разные вещи.
Отдельно я проверяю дату признания дохода, потому что дата продажи, оплата покупателя и выплата продавцу могут не совпадать. При посреднической схеме для УСН ориентиром служит получение оплаты посредником за продавца, а не последующий перевод продавцу на расчётный счёт. Применительно к своим операциям нужно проверить договорную схему и документы, подтверждающие получение оплаты. Просто разнести все поступления по датам банковской выписки недостаточно: часть дохода может оказаться в другом отчётном периоде. Особенно внимательно я смотрю операции на границе периодов и не подменяю дату получения денег датой формирования отчёта.
Главная ловушка — считать налог с выплаты Ozon, в которой уже вычтены комиссия и услуги площадки. На УСН «Доходы» эти удержания обычно не уменьшают доход от продажи. При этом нельзя механически прибавить к выплате все списания: сначала нужно отделить расходы от возвратов и других корректировок. Надёжная база расчёта — подтверждённые доходы и допустимые уменьшения дохода, а не итоговая сумма перевода.
С возвратами я поступаю иначе, чем с комиссией: это не просто ещё одно удержание в пользу площадки. Если ранее учтённая оплата возвращена покупателю, такое событие может уменьшать доход для УСН в периоде возврата. Для этого нужна связь с исходной оплатой и подтверждение возврата денег, а не только смена статуса заказа. Отмена до получения оплаты сама по себе не создаёт доход, который затем нужно вычитать. Я также проверяю, не учтён ли возврат уже внутри показателя отчёта, иначе при дополнительном вычитании база окажется занижена.
Как считать УСН на маркетплейсах по шагам
Для повторяемого расчёта я собираю таблицу, где доходы отделены от расходов площадки и от движения денег по банку. В ней должны быть видны основания включения суммы в расчёт, а не только итог по магазину. Рядом я держу сведения о применяемой ставке и праве на уменьшение налога, проверенные для своего бизнеса и соответствующего периода. Ставку нельзя выбирать по чужому скриншоту: она может зависеть от условий, которые у другого продавца отличаются. Сам расчёт я веду нарастающим итогом с начала года, чтобы затем корректно определить авансовый платёж или доплату.
- Собрать доход от продаж. Взять подтверждённые суммы, относящиеся к нужному периоду по правилам признания дохода, до удержания комиссии и услуг Ozon. Не заменять их стоимостью созданных заказов или суммой банковских поступлений.
- Проверить состав начислений. Добавить другие поступления, которые действительно являются облагаемым доходом, если они ещё не вошли в выручку. Отдельно проверить скидки, компенсации и НДС, когда он применим, чтобы избежать пропусков и повторного учёта.
- Учесть возвраты и исправления. Вычесть документально подтверждённые суммы, которые уменьшают доход в рассматриваемом периоде. Не вычитать возврат повторно, если исходный показатель уже приведён за его вычетом.
- Оставить расходы за пределами налоговой базы. Не вычитать себестоимость товара, комиссию, логистику, хранение и рекламу только потому, что они уменьшили выплату. Эти суммы нужны для прибыли и сверки расчётов, но не для такого уменьшения дохода при выбранном объекте УСН.
- Рассчитать налог с полученной базы. Применить действующую для продавца ставку, затем учесть разрешённое уменьшение налога, в том числе на страховые взносы при соблюдении соответствующих условий. Право, период и ограничения такого уменьшения проверить отдельно.
- Определить сумму к уплате. Из рассчитанной нарастающим итогом обязанности вычесть ранее исчисленные авансовые платежи по правилам УСН. После этого отдельно сверить расчёт с состоянием единого налогового счёта и уже перечисленными деньгами.
В короткой записи налоговая база получается так: учитываемая выручка до удержаний плюс другие облагаемые доходы минус подтверждённые суммы, уменьшающие доход. Комиссии площадки в этой формуле среди вычитаемых расходов нет. Затем база умножается на применимую ставку, и только после этого проверяется допустимое уменьшение самого налога. Уменьшение дохода и уменьшение налога — разные действия, их нельзя смешивать в одной строке. Если из выручки сначала вычесть страховые взносы, а потом применить ставку, это уже будет другой расчёт, не тот, который нужен для УСН «Доходы».
Для проверки механики удобно мысленно оставить обычную оплаченную продажу без возврата и дополнительных начислений. Покупатель оплатил товар, площадка удержала вознаграждение, а остаток отправила продавцу. В доход для УСН попадает выручка до этого удержания, хотя на банковском счёте виден меньший приход. Если покупателю затем вернули оплату, появляется отдельное основание для корректировки дохода, которое нужно подтвердить и отнести к своему периоду. Я намеренно не подставляю условные ставки и тарифы: здесь нужно понять последовательность, а не запомнить чужую сумму.
Ошибка с налогом от выплаты и сколько денег она скрывает
Самая неприятная ошибка выглядит аккуратно: продавец выгружает банковские поступления от Ozon и умножает их на ставку УСН. Таблица сходится с выпиской, арифметических ошибок нет, но исходная база выбрана неверно. Если единственное отличие выплаты от выручки состоит в удержанных услугах площадки, недостающий расчётный налог равен сумме ошибочно исключённых удержаний, умноженной на применимую ставку. Итоговая недоплата зависит также от разрешённых уменьшений налога и предыдущих расчётов. Поэтому без документов я не назову сумму потери, но механизм понятен: расходы незаконно уменьшают доход, а налог получается ниже положенного.
Обратная попытка исправиться тоже бывает ошибочной: взять выплату и прибавить к ней вообще все отрицательные строки отчёта. Среди них могут быть возвраты покупателям, исправления прошлых начислений и операции, относящиеся к другому периоду. Их нельзя без разбора считать расходами, которые требуется вернуть в базу. Есть и риск повторно учесть выручку, если одновременно сложить доход по отчёту и соответствующее банковское поступление. В таком случае продавец уже завышает налог, потому что одна продажа попадает в расчёт повторно под видом разных источников денег.
Если раньше налог считался от выплат, я бы не ограничивался сменой формулы для будущих продаж. Сначала нужно восстановить расчёт за затронутые периоды и сравнить правильные суммы с тем, что уже было исчислено и отражено в отчётности. Затем вместе с бухгалтером определить порядок исправления, необходимость уточнённой декларации и дополнительных платежей. Недоплата может повлечь пени, а вопрос штрафа зависит от обстоятельств и порядка исправления ошибки. Прибавлять всю найденную разницу к текущему доходу без разбора периодов нельзя: так ошибка в датах останется внутри учёта.
Что я проверяю перед следующим расчётом налога
Когда меня спрашивают про налоги на Ozon для продавцов, я предлагаю сначала сверить несколько разных итогов, а не искать универсальный процент от выплаты. Доход для УСН должен объясняться документами о получении дохода и его корректировках. Выплата должна объясняться взаиморасчётами с площадкой, включая удержания и остатки задолженности. Прибыль должна учитывать расходы бизнеса, даже если они не уменьшают налоговую базу на выбранном объекте. Эти результаты не обязаны совпадать, зато переход между ними должен быть понятен по строкам.
Когда магазинов несколько, к этой проверке добавляется вопрос, на кого именно оформлены продажи. Магазин в аналитике и налогоплательщик — не одно и то же: если магазины принадлежат одному налогоплательщику, считать УСН изолированно по каждому и забывать остальные доходы нельзя. Именно потребность видеть происхождение показателей подтолкнула меня сделать SellOps, потому что готового сервиса, которому я доверял бы, я не нашёл. На странице о том, как устроен SellOps, можно посмотреть подход к работе с аналитикой. Но сервисная таблица не заменяет первичные документы и проверку налоговых правил для конкретной операции.
Завтра я бы начал с уже закрытого отчётного периода и положил рядом документы Ozon, банковскую выписку и свой расчёт УСН. Затем выписал бы выручку до удержаний, подтверждённые возвраты, другие доходы и расходы площадки в отдельные колонки, сохранив ссылки на исходные документы. После проверки дат осталось бы пересчитать базу и сравнить её с той, которую использовали для налога раньше. Любую разницу я бы объяснил конкретными операциями, а спорные строки передал бухгалтеру вместе с документами, не просто с итоговой суммой. Так станет видно, где деньги действительно не являются доходом, а где доход лишь потратили до того, как он дошёл до расчётного счёта.
Хотите увидеть эти цифры по своим товарам?
Попробовать SellOps бесплатно