В ЕГРЮЛ теперь два вида ОКВЭД. Что это меняет в карточке контрагента, CRM и 1С

Заявительный и отчётный коды больше не одно и то же поле — и это ломает привычную логику интеграций

С сентября 2025 года в выписках ЕГРЮЛ и ЕГРИП отражаются коды ОКВЭД заявительного типа — те, что компания или ИП указали сами. С 2026 года по мере поступления данных от Росстата в реестрах и выписках начинают появляться коды отчётного типа — их определяет Росстат на основании статистической отчётности, с указанием процентных долей по видам деятельности [1]. Один и тот же код может смениться: если Росстат прислал отчётный основной код, он становится основным в реестре, а прежний заявительный основной код автоматически превращается в дополнительный заявительный [1][5]. Хранить это как одно поле «ОКВЭД» в CRM или 1С больше нельзя — нужно фиксировать тип, источник, дату получения и историю изменений, иначе карточка контрагента будет врать о том, откуда взялся код и что он означает.

В чём проблема и кому полезна статья

До сентября 2025 года в выписке ЕГРЮЛ был один основной код ОКВЭД и список дополнительных — все они указывались бизнесом самостоятельно при регистрации или изменении сведений. Разработчики CRM, 1С-интеграций и сервисов проверки контрагентов привыкли к простой модели: одно поле для основного кода, список — для дополнительных, обновление раз в какое-то время через выписку или API.

Реформа, запущенная Федеральным законом от 28.12.2024 № 529-ФЗ, вводит второй источник данных о видах деятельности — Росстат — и второй тип записи в реестре [2]. Для карточки контрагента это не косметическое изменение: сама семантика поля «основной ОКВЭД» становится неоднозначной, если не указано, о каком типе кода идёт речь.

Статья адресована тем, кто:

• ведёт карточку контрагента в CRM и синхронизирует её с ЕГРЮЛ/ЕГРИП или сервисами проверки (DaData, Контур.Фокус, СБИС и аналоги);
• дорабатывает 1С или интеграционный слой, который принимает данные о видах деятельности;
• отвечает за сегментацию клиентов по отрасли и заполнение анкет контрагента для договоров;
• проверяет контрагентов перед сделкой и должен понимать, на что вообще смотрит.

Заявительный и отчётный ОКВЭД: в чём разница

Официальная страница ФНС описывает два типа сведений в ЕГРЮЛ и ЕГРИП [1]:

Заявительный код — компания или ИП определяют и вносят его сами, на основании документов, поданных при регистрации или последующем изменении сведений. Поменять заявительный код можно в любой момент, подав заявление в регистрирующий орган [1].

Отчётный код — его определяет Росстат по итогам статистической отчётности, с указанием процентной доли по каждому виду деятельности. ФНС вносит эти сведения в ЕГРЮЛ/ЕГРИП в течение трёх рабочих дней с момента поступления данных от Росстата [1]. Изменить отчётный код напрямую нельзя — только через подачу уточнённой статистической отчётности в Росстат [1][7].

Важный нюанс, о который спотыкаются почти все интеграции: основной код в реестре может быть только один — либо заявительного, либо отчётного типа, а не оба одновременно [1]. Как только по конкретному ЮЛ или ИП в реестр поступает отчётный основной код, прежний заявительный основной код не исчезает — он автоматически переводится в статус дополнительного заявительного кода [1][5][6]. То есть после реформы «основной ОКВЭД» компании, которая заявляла один вид деятельности, а фактически зарабатывает на другом, в выписке поменяется — и это ожидаемое поведение системы, а не ошибка реестра.

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

Как работает переход на новый порядок

Процесс идёт поэтапно, и это стоит закладывать в интеграцию как факт, а не как временное неудобство:

• С сентября 2025 года — в выписках отражаются коды заявительного типа (по сути, старая модель, просто переименованная).
• С 2026 года — начинают появляться отчётные коды у тех, кто уже ежегодно отчитывается перед Росстатом (формы № 1-предприятие, № 1-ТОРГ, № 1-ИП, № П-4 и аналогичные) [1][3].
• С 2027 года — отчётные коды получают остальные юридические лица, ранее не отчитывавшиеся перед Росстатом ежегодно [1].
• С 2028 года — то же самое для индивидуальных предпринимателей [1].

Практический вывод: отсутствие отчётного кода в карточке контрагента сейчас — это норма, а не признак проблемы или недостоверности данных [4]. CRM не должна помечать такие карточки как «неполные» до наступления соответствующего этапа для этой категории субъектов.

Есть и обратный процесс — актуализация уже присвоенного отчётного кода. Хозяйствующий субъект, у которого в реестре уже есть отчётный код, обязан повторно направить статистические данные, если основной код или доли по нему изменились более чем на 20 процентных пунктов, либо если с последней подачи данных прошло пять лет [1].

Несовпадение кодов — это не автоматический сигнал о нарушении

Соблазн для любой системы проверки контрагентов — завести правило «заявительный ОКВЭД не совпадает с отчётным → красный флаг». Это упрощение, которое может привести к ложным срабатываниям.

Причины расхождения бывают разными:

1. Компания действительно диверсифицировала бизнес. Отчётный код строится на реальной структуре доходов за прошедший год, а заявительный мог не обновляться годами [5]. Несовпадение здесь — не нарушение, а как раз то, для чего реформа и задумана: показать фактическую деятельность.
2. Техническая ошибка Росстата или в самой статформе. За корректность отчётных сведений отвечает Росстат, и организация вправе добиваться исправления через территориальный орган статистики, если данные внесены неверно [7].
3. Ошибка в исходной статотчётности компании. Тогда исправление идёт через подачу уточнённых данных в Росстат, а не через ФНС [7].
4. Переходный период. У части контрагентов отчётного кода ещё просто нет — сравнивать «текущий заявительный» не с чем.

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

Границы открытых данных: процентные доли не входят в общедоступный справочник

Это критично для любого, кто планирует делать сегментацию клиентов «по вкладу вида деятельности в выручку» на основе открытых данных.

Коды ОКВЭД — заявительные и отчётные, без процентных долей — доступны любому заинтересованному лицу через сервисы ФНС «Предоставление сведений из ЕГРЮЛ/ЕГРИП» и «Прозрачный бизнес», а также через коммерческие сервисы проверки контрагентов вроде DaData или Контур.Фокуса, которые агрегируют эти открытые данные [1][8][9][10][12].

А вот сведения о процентных долях видов деятельности в открытый доступ не выкладываются [1]. Получить выписку с процентными долями может только:

• сама организация или ИП — в отношении себя, через личный кабинет и сервис «Государственная онлайн-регистрация бизнеса» [1];
• органы государственной власти, суды, Банк России, государственные внебюджетные фонды — через систему межведомственного электронного взаимодействия [1].

Значит, любая интеграция, которая планирует автоматически подтягивать «долю дохода по виду деятельности» контрагента через открытое API или платный сервис проверки, столкнётся с тем, что этих данных там просто нет и не будет — это не ограничение конкретного провайдера данных, а норма закона [1]. Если бизнес-процессу компании нужны именно доли (например, для сложной сегментации по профилю клиента), единственный законный источник — сам контрагент, добровольно предоставивший собственную выписку.

Что это меняет в карточке контрагента и CRM

Не перезаписывайте одно поле «ОКВЭД»

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

Разумная модель данных предполагает хранение по каждому виду деятельности:

• тип кода — заявительный или отчётный;
• признак основной/дополнительный;
• сам код и его расшифровка по ОК 029-2014 (КДЕС Ред. 2) — классификатор не менялся, поменялся только порядок отражения кодов в реестре [3];
• процентная доля, если она известна (только по данным самого контрагента, полученным напрямую, а не из открытого источника);
• источник сведений — ЕГРЮЛ/ЕГРИП напрямую, сервис проверки контрагентов, ручной ввод менеджером, анкета от контрагента;
• дата получения конкретного значения;
• история изменений — что было раньше, когда и почему заменилось.

Разведите поле «основной ОКВЭД по реестру» и поле «фактический профиль клиента для отдела продаж»

Отделу продаж и закупок обычно нужен не юридически точный тип кода, а понятный ответ на вопрос «чем занимается эта компания». Дублирование сущностей помогает не путать регуляторное поле (что видно в выписке ЕГРЮЛ, с указанием типа) с рабочим полем сегментации (отраслевой тег, который менеджер может скорректировать вручную, если формальный код не отражает реальность бизнеса клиента).

Пересмотрите логику анкет и форм для договоров

Если в анкете контрагента или преддоговорной проверке есть поле «основной вид деятельности (ОКВЭД)», стоит уточнить формулировку и логику заполнения:

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

Проверьте правила сегментации клиентов

Если в CRM есть автоматическая сегментация по отрасли на основе ОКВЭД (например, для маршрутизации лида, применения отраслевых скидок или юридических шаблонов договора), после появления отчётных кодов у части контрагентов сегмент может измениться без вмешательства менеджера — просто потому, что реестр сменил источник основного кода. Стоит заранее решить: сегментация обновляется автоматически при смене основного кода в реестре, или требует подтверждения ответственного сотрудника — особенно если от сегмента зависят коммерческие условия.

Как эти данные использовать при проверке контрагента

При комплаенс-проверке перед сделкой ОКВЭД обычно смотрят как один из косвенных признаков благонадёжности — совпадает ли заявленный вид деятельности с предметом договора. С учётом двух типов кодов логика проверки становится немного тоньше:

• Смотрите оба типа кода, если они есть, а не только «текущий основной» — расхождение между ними само по себе не аргумент против контрагента, но контекст для более внимательного изучения предмета сделки.
• Не путайте отсутствие отчётного кода с фиктивностью компании — для большей части ИП и части юрлиц он появится только к 2027–2028 году [1].
• Не пытайтесь получить процентные доли контрагента через сторонние сервисы — легально это невозможно, такие данные предоставляются только самому субъекту и госорганам [1].
• Официальную выписку с юридической силой можно получить через сервисы ФНС «Предоставление сведений из ЕГРЮЛ/ЕГРИП» и «Прозрачный бизнес» — они, в отличие от скриншотов из коммерческих сервисов, подписаны усиленной квалифицированной электронной подписью и принимаются как подтверждение должной осмотрительности [12].

Техническое задание: корректная модель ОКВЭД в интеграции и карточке компании

Ниже — минимальный набор требований, которые стоит закрепить в ТЗ на доработку CRM, 1С-интеграции или сервиса проверки контрагентов при переходе на два типа кодов.

1. Модель данных

Вместо одного поля «Основной ОКВЭД» — сущность «Вид деятельности контрагента» (справочник/подтаблица, связанная с карточкой компании), с обязательными атрибутами:

Атрибут Назначение Обязательность тип_кода заявительный / отчётный обязательно признак_основной основной / дополнительный вид деятельности обязательно код_ОКВЭД значение по ОК 029-2014 (КДЕС Ред. 2) [4] обязательно процентная_доля заполняется только если получена напрямую от контрагента; из открытых источников не подтягивается [1] опционально источник ЕГРЮЛ/ЕГРИП напрямую, сервис проверки контрагентов (с указанием какого), ручной ввод, анкета контрагента обязательно дата_получения дата, на которую значение актуально обязательно предыдущее_значение / история ссылка на предыдущую запись при замене — без физического удаления старых данных обязательно Правило: никакая синхронизация не должна перезаписывать значение поля без записи в историю и без указания источника и даты. Замена заявительного основного кода на отчётный — это создание новой версии записи, а не редактирование старой.

2. Бизнес-правила обработки расхождений

• Расхождение между текущим заявительным и отчётным кодом фиксируется как факт, а не как ошибка или нарушение [1][5].
• Автоматическая пометка контрагента как «рискованного» только на основании расхождения кодов — запрещена; допустимо ставить пометку «требует ручной проверки».
• Отсутствие отчётного кода не помечается как «данные не заполнены» до наступления соответствующего этапа перехода для категории субъекта (2026 / 2027 / 2028) [1][3].
• При появлении нового отчётного кода ответственный сотрудник получает уведомление, если от вида деятельности контрагента зависят коммерческие условия или сегмент.

3. Требования к отображению в интерфейсе

• В карточке контрагента оба типа кода (если оба присутствуют) показываются отдельно, с явной подписью типа и датой получения — не единым значением.
• Отдельно от регуляторного поля ведётся рабочее поле «отраслевой сегмент», которое менеджер может скорректировать вручную независимо от кода в реестре.
• В интерфейсе не используются формулировки «нарушение», «недостоверные данные» применительно к расхождению кодов без дополнительной проверки.

4. Требования к анкетам и формам для договоров

• Поле «основной вид деятельности» в анкете, заполняемой самим контрагентом, трактуется как заявительный код.
• Поле, автоматически подтягиваемое из выписки, обязательно сопровождается пометкой типа кода и датой выписки.
• Форма анкеты не запрашивает процентные доли по видам деятельности как обязательные — контрагент вправе, но не обязан их предоставлять, и это не общедоступные данные [1].

5. Источники данных и синхронизация

• Источник — открытые сервисы ФНС («Предоставление сведений из ЕГРЮЛ/ЕГРИП», «Прозрачный бизнес» [12]) либо коммерческий сервис проверки контрагентов (DaData, Контур.Фокус и аналоги [8][9][10]) — выбирается исходя из требуемой периодичности обновления и SLA.
• При любом источнике интеграция обязана сохранять метаданные о моменте получения каждого конкретного значения, а не только последнее состояние.
• Получение процентных долей через открытые каналы не проектируется — по закону это невозможно ни для одного внешнего провайдера [1].

Ограничения и что не стоит путать

Эта статья — про модель данных для карточки контрагента и проверку контрагента, а не про расчёт тарифа страховых взносов на травматизм. Хотя оба процесса опираются на один и тот же реестр и один и тот же закон № 529-ФЗ, с 2026 года Социальный фонд определяет тариф взносов на травматизм по основному коду ОКВЭД (заявительному или отчётному — тому, что зафиксирован в реестре на 15 апреля текущего года), и ежегодное подтверждение вида деятельности для этой цели в общем случае отменено [11]. Это отдельная тема с собственной логикой и сроками, которая заслуживает отдельного разбора.

Вывод

Реформа кодов ОКВЭД меняет не классификатор, а модель данных, которую все привыкли считать простой: «один код — одно поле». Теперь основной код в реестре — это результат выбора между двумя источниками правды, заявительным и отчётным, а расхождение между ними — рабочая ситуация, а не сигнал тревоги. Для CRM, 1С-интеграций и служб проверки контрагентов это повод пересмотреть структуру хранения видов деятельности: явно фиксировать тип кода, источник, дату получения и историю, не путать регуляторное поле с рабочей сегментацией клиентов и не рассчитывать на доступ к процентным долям через открытые каналы — этих данных там не будет по закону.

Источники

[1] nalog.gov.ru — Новое о кодах ОКВЭД в ЕГРЮЛ и ЕГРИП — https://www.nalog.gov.ru/okved/

[2] pravo.gov.ru — Федеральный закон от 28.12.2024 № 529-ФЗ — http://publication.pravo.gov.ru/document/0001202412280030

[3] 26-2.ru — В ЕГРЮЛ и ЕГРИП добавили коды ОКВЭД отчетного типа — https://www.26-2.ru/news/367203-v-egryul-i-egrip-dobavili-kody-okved-otchetnogo-tipa

[4] 1c-prime.ru — Коды ОКВЭД отчетного типа в ЕГРЮЛ и ЕГРИП: изменения 2026 — https://1c-prime.ru/articles/rekomendatsii-novye-stati-2025/kody-okved-otchetnogo-tipa-v-egryul-i-egrip-izmeneniya-2026-polza-dlya-biznesa-i-kak-proverit/

[5] gazeta-unp.ru — Новые правила ОКВЭД: главным стал отчетный код, а не заявительный — https://www.gazeta-unp.ru/news/45797-novye-pravila-okved-glavnym-stal-otchetnyy-kod-a-ne-zayavitelnyy

[6] klerk.ru — Из-за недостоверного кода ОКВЭД могут отказать в господдержке – налоговая — https://www.klerk.ru/buh/news/704231/

[7] ascon-spb.ru — Неприятные последствия ОКВЭД-реформы: что можно исправить и как это сделать — https://www.ascon-spb.ru/navigator/stati/nepriyatnie_posledstviya_okved-reformi__chto_mozhno_ispravit_i_kak_eto_sdelat/

[8] dadata.ru — ОКВЭД: что это, как выбрать для бизнеса или узнать по ИНН контрагента — https://dadata.ru/blog/basics/okved/

[9] dadata.ru — Проверка контрагентов — https://dadata.ru/product/party-inspection/

[10] focus.kontur.ru — Проверка контрагентов API — https://focus.kontur.ru/site/api

[11] nalog-nalog.ru — Тариф страховых взносов на травматизм в 2026 году: как определить по ОКВЭД и проверить в СФР — https://nalog-nalog.ru/strahovye_vznosy/fss/kak-uznat-tarif-strahovyh-vznosov-na-travmatizm-v-2026-godu/

[12] support-nalog.ru — Проверить контрагента по ИНН бесплатно — онлайн-сервис «Прозрачный бизнес» от ФНС — https://support-nalog.ru/proverit-kontragenta-po-inn-besplatno-onlain-servis-prozrachnyi-biznes-ot-fns