Закон о платформенной экономике 2026: что меняется для бизнеса и 1С

Маркетплейс для бизнеса давно перестал быть просто дополнительным каналом продаж.

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

С 1 октября 2026 года эта модель получает отдельную законодательную рамку.

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

Что такое платформенная экономика

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

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

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

Когда закон вступает в силу

Федеральный закон №289-ФЗ от 31 июля 2025 года вступает в силу 1 октября 2026 года.

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

Кого касается закон

В первую очередь регулирование затрагивает несколько групп участников платформенной экономики.

Какие отношения регулируются

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

В частности, правила касаются:

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

Для бизнеса это означает появление большого количества новых контролируемых событий.

Что меняется в договорах с маркетплейсами

Договор между оператором платформы и партнёром должен содержать более детализированные условия взаимодействия.

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

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

Изменение условий договора: что важно бизнесу

Оператор платформы не сможет просто изменить существенные условия взаимодействия без предварительного уведомления.

В предусмотренных законом случаях уведомление об изменении условий должно направляться не менее чем за 45 календарных дней.

Для иных изменений установлен более короткий срок — не менее 15 календарных дней.

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

Изменение условий платформы
         ↓
    Уведомление
         ↓
   Integration API
         ↓
  ┌──────┴──────┐
  ↓             ↓
 CRM            ERP
  ↓             ↓


Ответственный   Финансы
↓             ↓
Решение       Пересчёт
↓
Изменение
бизнес-процесса

Что меняется для продавцов маркетплейсов

Продавцу становится недостаточно просто загрузить товар, установить цену и ждать заказов.

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

Причём часть этой информации уже существует в корпоративной системе продавца.

Например:

Проверка продавца: что меняется технически

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

Для российской компании маркетплейс должен проверить, в частности, сведения о полном и сокращённом наименовании, адресе, ИНН, ОГРН и КПП.

Для разных категорий партнёров используются соответствующие наборы сведений и способы проверки.

Часть проверки может выполняться через ЕСИА или другие предусмотренные системы идентификации и аутентификации.

Для IT это означает, что процесс регистрации партнёра превращается в формализованный цифровой workflow.

Регистрация продавца
    ↓


Сбор данных
↓
Проверка реквизитов
↓
Проверка через внешние системы
↓
┌───────────────┐
│   Результат   │
└───────────────┘
↓       ↓
Успех     Отказ
↓       ↓
Договор   Причина
↓
Marketplace

Проверка карточек товаров

Одно из важных изменений — формализация проверки информации, которую продавец размещает на платформе.

Это особенно важно для компаний с большим ассортиментом, где карточки товаров формируются не вручную, а загружаются из 1С, PIM, ERP или собственной системы.

В такой архитектуре карточка становится результатом интеграционного процесса.

1С / ERP


↓
Товар
↓
PIM / Product Service
↓
Validation
↓
Marketplace API
↓
Карточка товара
↓
Проверка
↓
Результат
↓
1С / ERP

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

Маркировка и документы становятся частью карточки

Новый режим работы платформ повышает значение качества исходных данных.

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

Поэтому данные о товаре постепенно превращаются из простого набора маркетинговых характеристик в структурированный корпоративный объект.

Скидки: почему это становится IT-задачей

Закон отдельно регулирует применение скидок и ситуации, когда расходы на предоставление скидки могут затрагивать продавца.

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

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

Цена продавца
 ↓


Скидка
↓
Цена покупателя
↓
Комиссия платформы
↓
Логистика
↓
Возврат
↓
Фактическая выплата
↓
ERP / Управленческий учёт

Почему старой интеграции с маркетплейсом может быть недостаточно

Типичная интеграция продавца сегодня выглядит примерно так:

1С


│
├── Ozon API
│
└── Wildberries API

Для небольшого продавца этого может быть достаточно.

Но с ростом бизнеса появляются новые процессы:

• несколько юридических лиц;
• несколько складов;
• разные цены;
• разные схемы логистики;
• маркировка;
• ЭДО;
• возвраты;
• акции и скидки;
• управленческий учёт;
• несколько маркетплейсов.

После этого точечные интеграции начинают превращаться в отдельную распределённую систему.

Архитектура интеграции маркетплейсов с 1С

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

                         1С / ERP
                         │
                         ↓
              ┌────────────────────┐
              │  Integration Bus   │
              └────────────────────┘
                │        │        │
                ↓        ↓        ↓
              Ozon       WB      Другие
                │        │        │
                └────────┼────────┘
                         ↓
                      Клиенты


Дополнительные контуры:
↑             ↑             ↑
ЭДО         Честный знак    CRM
↑             ↑             ↑
└──────── Integration ──────┘

В такой архитектуре маркетплейсы становятся внешними системами, а внутренняя бизнес-логика остаётся внутри корпоративного контура.

Зачем нужна интеграционная шина

Основная проблема большого количества интеграций — не количество API само по себе.

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

Если соединять каждую систему напрямую:

          1С
    ↙ ↓ ↘
  Ozon WB CRM
   ↘  ↓  ↙
   ЭДО / ERP
      ↓
   Склад

количество связей быстро растёт.

Если вынести интеграцию в отдельный слой:

                 1С / ERP
                 │
                 ↓
          Integration Bus
         ↙      ↓       ↘
      Ozon      WB       ЭДО
        │        │        │
        ↓        ↓        ↓
      CRM      WMS    Честный знак

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

Такой подход особенно полезен, когда компания одновременно работает с несколькими маркетплейсами, ЭДО, государственными системами и собственной ERP.

Как новый закон влияет на 1С

Сам закон не требует переписывать 1С.

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

В 1С может потребоваться дополнительно контролировать:

API маркетплейса как источник бизнес-событий

В зрелой архитектуре API маркетплейса нельзя рассматривать только как способ загрузки заказов.

Это поток событий.

Marketplace
 │
 ├── NewOrder
 ├── OrderPaid
 ├── OrderShipped
 ├── OrderDelivered
 ├── ReturnCreated
 ├── PriceChanged
 ├── StockChanged
 ├── CardRejected
 └── ContractChanged
          │
          ↓
   Integration Layer
          │
    ┌─────┼─────┐
    ↓     ↓     ↓
   1С    ERP   CRM

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

Идемпотентность: как не задвоить заказ

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

Например, сервис получил заказ, записал его в базу, но ответ маркетплейсу не дошёл. Внешняя система повторяет запрос.

Если не предусмотрена идемпотентность, в 1С может появиться второй заказ.

Поэтому необходимо хранить внешний идентификатор операции:

Marketplace Order ID
    ↓


Internal Order ID
↓
1С Document ID
↓
Processing Status

При повторном событии интеграционный сервис проверяет, существует ли уже соответствующая операция.

Retry и очередь сообщений

Маркетплейсы, ЭДО и государственные системы могут быть временно недоступны.

Если интеграция построена на синхронном HTTP-запросе, ошибка внешней системы может остановить внутренний бизнес-процесс.

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

1С


↓
Message
↓
Queue
↓
Worker
↓
Marketplace API
↓
Success

или

Marketplace API
↓
Timeout
↓
Retry
↓
Retry
↓
Dead Letter Queue
↓
Manual Review

Такой механизм особенно важен при массовой загрузке товаров, остатков, цен и заказов.

Что делать с блокировкой карточки или личного кабинета

Новый порядок предусматривает отдельные правила рассмотрения жалоб партнёров и владельцев ПВЗ.

Оператор должен обеспечить возможность досудебного рассмотрения соответствующих обращений.

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

Marketplace
 ↓


Restriction / Block
↓
Webhook / API / Notification
↓
Integration Layer
↓
CRM / ERP
↓
Ответственный
↓
Разбор причины
↓
Жалоба / Исправление
↓
Восстановление работы

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

Возвраты становятся отдельным бизнес-процессом

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

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

Для IT это означает, что возврат нельзя рассматривать исключительно как изменение статуса заказа.

Возврат должен пройти через весь корпоративный контур:

Marketplace
 ↓


Return Request
↓
CRM
↓
ERP / 1С
↓
WMS
↓
Фактический возврат
↓
Финансовая корректировка
↓
ЭДО
↓
Управленческая аналитика

Как подготовить IT-инфраструктуру к 1 октября

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

Какой минимальный контур нужен продавцу

Для небольшого продавца сложная ESB-архитектура может быть избыточной.

Минимальный контур может выглядеть так:

1С


│
↓
Marketplace Connector
│
├── Ozon
├── Wildberries
└── Другие площадки

Здесь важно хотя бы обеспечить:

• синхронизацию товаров;
• синхронизацию остатков;
• синхронизацию цен;
• загрузку заказов;
• обработку возвратов;
• обработку ошибок;
• логирование операций.

Какой контур нужен крупному продавцу

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

                         1С / ERP
                         │
                         ↓
                 Integration Bus
                         │
      ┌──────────────────┼──────────────────┐
      ↓                  ↓                  ↓
   Ozon API          WB API           Other APIs
      │                  │                  │
      └──────────────────┼──────────────────┘
                         ↓
                Order Management
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
         WMS            CRM            ЭДО
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                   Analytics / BI

В такой архитектуре изменение API одного маркетплейса не должно ломать остальные бизнес-процессы.

Мониторинг: что должен видеть IT-директор

После роста количества интеграций недостаточно просто иметь кнопку «Синхронизировать».

Почему закон о платформенной экономике — это ещё и закон об API

На уровне бизнеса новый закон регулирует отношения между платформой и её партнёрами.

На уровне IT эти отношения реализуются через данные, API, личные кабинеты, уведомления, документы и автоматизированные процессы.

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

Что делать бизнесу до 1 октября 2026 года

Типичные ошибки бизнеса

Ошибка №1. Рассматривать закон только как юридическую задачу

Если изменение условий работы с маркетплейсом не попадает в IT-систему, финансовый и операционный контур компании продолжает работать по старым правилам.

Ошибка №2. Хранить данные только на маркетплейсе

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

Ошибка №3. Интегрировать каждый маркетплейс напрямую с 1С

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

Ошибка №4. Не учитывать изменения цен и скидок

Если фактическая цена продажи отличается от цены в ERP, компания должна иметь возможность восстановить, почему произошло изменение.

Ошибка №5. Не автоматизировать возвраты

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

Как построить архитектуру на несколько лет вперёд

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

                    Корпоративный контур

          ┌─────────────────────┐
          │       1С / ERP      │
          └──────────┬──────────┘
                     │
                     ↓
          ┌─────────────────────┐
          │  Integration Bus    │
          └──────────┬──────────┘
                     │
      ┌──────────────┼──────────────┐
      ↓              ↓              ↓
   Marketplace      ЭДО          Гос. системы
      │              │              │
  ┌───┴───┐          │              │
  ↓       ↓          ↓              ↓
 Ozon     WB      Документы       API

                     │
                     ↓
                   AI / MCP
                     │
                     ↓
               Аналитика / BI

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

Именно этот подход становится особенно актуальным, когда к маркетплейсам добавляются ЭДО, маркировка, цифровой рубль, CRM, WMS и AI-сервисы.

Итог

С 1 октября 2026 года в России начинает действовать закон о платформенной экономике.

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

Для IT-службы изменения выглядят ещё шире. Маркетплейс становится полноценной внешней системой, с которой необходимо синхронизировать данные, бизнес-события и документы.

Если компания продаёт через одну площадку и имеет простую инфраструктуру, достаточно качественного коннектора с 1С или ERP.

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

В зрелой архитектуре маркетплейсы становятся только одним из подключаемых каналов: рядом находятся 1С, ERP, CRM, ЭДО, Честный знак, государственные системы и AI. Поэтому вопрос стоит не только в том, как интегрировать Ozon или Wildberries с 1С, а в том, как построить единый слой интеграций, который будет масштабироваться вместе с бизнесом.