Закон о платформенной экономике с 1 октября 2026 года: что изменить продавцу и оператору цифровой платформы

С 1 октября 2026 года в России начнут действовать Федеральные законы от 31 июля 2025 года № 289-ФЗ и № 290-ФЗ. Они вводят единые правила работы посреднических цифровых платформ: маркетплейсов, сервисов заказа услуг, доставки и других площадок, которые сводят партнеров с пользователями и помогают заключать сделки.

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

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

Новый режим не сводится к отдельным требованиям для крупнейших маркетплейсов. Он устанавливает базовую архитектуру отношений внутри платформенной экономики:

• определяет участников и посредническую цифровую платформу;
• вводит реестр посреднических цифровых платформ;
• устанавливает требования к договорам оператора с партнерами;
• регулирует проверку сведений о партнерах и предложениях;
• ограничивает одностороннее изменение условий и применение скидок за счет продавца;
• закрепляет порядок ограничения доступа, рассмотрения жалоб и восстановления карточек;
• уточняет правила возврата товаров через инфраструктуру платформы;
• предусматривает информационное взаимодействие операторов с государственными системами.

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

Ключевые правила распределены между законами и постановлениями Правительства РФ.

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

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

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

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

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

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

На 27 июля 2026 года окончательный состав реестра еще не утвержден. В опубликованный предварительный перечень из 12 сервисов вошли Avito, Delivery Club, Joom, Lamoda, Ozon, Wildberries, «Купер», «Магнит Маркет», «Яндекс Go», «Яндекс Еда», «Яндекс Маркет» и «Яндекс Путешествия». Это кандидаты на включение, а не готовый государственный реестр.

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

До допуска на платформу партнер должен предоставить сведения, позволяющие подтвердить его статус. Продавцу следует проверить:

• наименование или Ф.И.О., ИНН, ОГРН либо ОГРНИП;
• адрес и контактные данные;
• банковские реквизиты;
• статус самозанятого, если он используется;
• лицензии, разрешения и сведения о включении в специальные реестры;
• полномочия сотрудников, управляющих личным кабинетом.

Расхождения между ЕГРЮЛ или ЕГРИП, договором, карточкой продавца и платежными реквизитами могут задержать повторную проверку или ограничить доступ к размещению предложений.

Карточка должна содержать обязательные сведения о продавце и предложении. Состав информации зависит от категории товара и применимых технических регламентов. До запуска новых правил полезно разделить ассортимент на группы:

1. товары с обязательной сертификацией или декларированием;
2. маркируемые товары;
3. лицензируемые виды деятельности;
4. товары и услуги с возрастными или иными ограничениями;
5. обычный ассортимент без специальных разрешительных требований.

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

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

Платформа не должна уменьшать цену за счет партнера без его согласия. Продавцу нужно выяснить:

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

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

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

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

Для плановых изменений условий закон предусматривает заблаговременное уведомление; для отдельных изменений применяются увеличенные сроки. Внутренний календарь продавца должен учитывать как минимум контрольные точки за 45 и 15 дней до вступления новой редакции в силу. Полученные уведомления стоит сохранять вместе с соответствующей редакцией договора.

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

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

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

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

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

• адреса и способы приема;
• фиксацию состояния товара;
• передачу заявления и доказательств;
• движение денег;
• сроки ответа;
• судьбу товара после приемки пунктом выдачи.

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

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

Если группа использует несколько приложений или юридических лиц, анализ необходимо проводить по всей цепочке, а не по одному домену или владельцу товарного знака.

До допуска партнера оператору нужен воспроизводимый процесс проверки сведений. Он должен включать:

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

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

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

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

Площадке потребуется проверять обязательные сведения в карточках и реагировать на недостоверные данные. Для этого нужны:

• правила по категориям;
• интеграция с реестрами и системами маркировки, где она требуется;
• статусы «черновик», «на проверке», «опубликовано», «ограничено»;
• журнал изменения данных;
• уведомление партнера о выявленном нарушении;
• механизм исправления и повторной публикации.

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

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

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

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

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

Решение алгоритма должно быть проверяемым человеком. В уведомлении полезно указывать нарушенное правило, фактическое основание, объем ограничения, срок и способ обжалования.

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

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

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

Основные обязанности уже установлены законами № 289-ФЗ и № 290-ФЗ и вступают в силу 1 октября 2026 года. Отдельный законопроект № 959258-8 вводит административную ответственность за нарушения в сфере платформенной экономики.

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

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

• ☐ Сведения в кабинете совпадают с государственными реестрами и банковскими данными.
• ☐ Для регулируемых товарных категорий собраны действующие документы.
• ☐ Документы связаны с конкретными карточками и SKU.
• ☐ Удалены запрещенные и неподтвержденные предложения.
• ☐ Понятно, какие скидки финансирует продавец и как фиксируется согласие.
• ☐ Сохранены договор, тарифы и правила площадки в действующей редакции.
• ☐ Настроена ежемесячная сверка расчетов и выгрузка отчетов.
• ☐ Есть ответственный и шаблон для обжалования блокировки.
• ☐ Описан процесс возврата через платформу или пункт выдачи.
• ☐ Назначен сотрудник, отслеживающий изменения до 1 октября 2026 года.

• ☐ Выполнена правовая квалификация сервиса и проверены критерии реестра.
• ☐ Описаны все участники, договоры, пользовательские и денежные потоки.
• ☐ Онбординг включает требуемую проверку партнера и журнал результата.
• ☐ Карточки проверяются по категориям и имеют маршрут исправления.
• ☐ Условия договора, тарифы и уведомления синхронизированы с интерфейсом.
• ☐ История редакций и согласий хранится в установленный срок.
• ☐ Источник каждой скидки фиксируется технически.
• ☐ Основные параметры ранжирования объяснены партнерам.
• ☐ Для блокировок определены основания, доказательства, уведомления и исключения.
• ☐ Жалобы регистрируются, маршрутизируются и рассматриваются в срок.
• ☐ Возвраты связаны с расчетами и логистикой.
• ☐ Подготовлено взаимодействие с ФНС и резервный порядок при сбое интеграции.

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

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