Новые требования к учётной системе УЭО: как подготовить ERP к таможенному контролю

Решение ЕЭК № 114 задаёт срок на 2028–2029 годы — но проектировать систему учёта нужно начинать уже сейчас

8 сентября 2026 года Коллегия Евразийской экономической комиссии решением № 114 утвердила Типовые требования к системе учёта товаров [1]. Наличие такой системы уже предусмотрено статьями 433 и 442 ТК ЕАЭС как условие статуса уполномоченного экономического оператора (УЭО). Решение предусматривает применение Типовых требований с 1 января 2028 года и переходный ориентир до 1 января 2029 года для операторов, включённых в реестр до 2028 года, при приведении национального законодательства в соответствие [1]. Эти будущие сроки не отменяют действующие обязанности УЭО: конкретный график доработок следует сверять с законодательством страны регистрации и требованиями таможенного органа.

Материал адресован действующим УЭО, компаниям, которые планируют получить этот статус, и ERP/1С-интеграторам, которые будут переводить требования решения в техническое задание.

Почему рано — не значит неважно

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

По словам министра по таможенному сотрудничеству ЕЭК Сергея Шкляева, единые требования должны гармонизировать национальные законодательства государств-членов и заложить основу для дальнейшего расширения упрощений для операторов[12]. Ожидаемый эффект для добросовестных УЭО — сокращение количества документальных проверок и общего объёма таможенного контроля[13].

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

• вступление решения № 114 в силу — по предусмотренному именно этим решением правилу через 30 календарных дней после официального опубликования [1];
• дату применения Типовых требований — 1 января 2028 года, и именно с этой даты требования становятся действующим условием для системы учёта заявителей на статус УЭО[1].

Иными словами, само решение вскоре станет частью права ЕАЭС, но обязанность соответствовать конкретным пунктам документа наступает позже и поэтапно.

Кому и когда применять требования

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

Заявители на статус УЭО. Наличие системы учёта товаров, отвечающей требованиям законодательства государств-членов о таможенном регулировании, — самостоятельное условие включения в реестр, прямо закреплённое в подпункте 7 пункта 1 статьи 433 ТК ЕАЭС[2]. Решение № 114 наполняет это условие конкретным содержанием. Для компании, которая планирует подавать заявление после начала применения Типовых требований, соответствие системы учёта этим требованиям становится частью общего пакета условий — наравне с финансовой устойчивостью и отсутствием нарушений.

Действующие УЭО. Государствам — членам ЕАЭС решением предписано до 1 января 2028 года привести национальное законодательство о системе учёта в соответствие с Типовыми требованиями, а юридическим лицам, уже включённым в реестр УЭО до этой даты, — дополнительный год, до 1 января 2029 года, на приведение своих систем учёта в соответствие[1]. На практике это означает: если компания получила статус УЭО до наступления 2028 года, у неё есть запас времени на доработку системы длиной примерно в год после того, как требования формально вступят в силу для новых заявителей.

Действующие УЭО и так обязаны соблюдать условия включения в реестр на постоянной основе и обеспечивать таможенным органам доступ к системе учёта товаров, находящихся под таможенным контролем[3]. Новое решение не создаёт эту обязанность заново — оно детализирует, каким технически должен быть учёт, чтобы обязанность считалась исполненной.

Отдельно решение упоминает свидетельства второго и третьего типа — они дают право иметь площадку временного хранения с товарами, входящими в объекты системы учёта по решению № 114; свидетельство первого типа такого требования к площадке не влечёт[4][1]. Это стоит уточнить на этапе анализа применимости: тип свидетельства прямо влияет на то, какой перечень объектов учёта нужно проектировать.

Что должна уметь система учёта: простыми словами

Формально Типовые требования — это перечень пунктов юридического документа. По содержанию — это требования к трём вещам: что именно учитывать, как связывать записи учёта с таможенными документами и как обеспечивать доступ к этим связям.

Объектами системы учёта решение называет три группы товаров: ввезённые и помещённые под таможенные процедуры выпуска для внутреннего потребления, переработки, свободной таможенной зоны и ряда других процедур; вывозимые товары под процедурами экспорта, реэкспорта, временного вывоза и переработки вне таможенной территории; и товары, помещённые на временное хранение на площадке УЭО со свидетельством второго или третьего типа[1].

Ключевое понятие для проектирования системы — «самостоятельный объект системы учёта». Товар становится таким объектом, если он задекларирован отдельно: по разной ДТ, по разному заявлению на выпуск до подачи ДТ, либо заявлен отдельной товарной позицией внутри одного документа[1]. Для товаров на временном хранении признак самостоятельности — иное наименование либо иной документ о размещении на хранение[1]. Это значит, что единицей учёта в системе должна быть не партия «вообще», а конкретная связка «товар — документ, по которому он задекларирован».

Второе базовое понятие — «снятие с учёта». Для ввезённых товаров это передача третьим лицам, использование в производстве, уничтожение, безвозвратная утрата, ввод основных средств в эксплуатацию или передача в розничную/оптовую торговлю[1]. Для вывозимых — фактический вывоз с таможенной территории. Для товаров на временном хранении — выдача с места хранения либо признание таможенным органом факта уничтожения или утраты[1]. Каждое из этих событий должно быть зафиксировано в системе учёта с датой и подтверждающим документом — без этого сопоставление с таможенными сведениями окажется неполным.

Как связать товарную единицу с декларацией и хозяйственными операциями

Требование, вокруг которого строится вся архитектура, сформулировано в пункте 13 решения: система учёта должна фиксировать регистрационный номер декларации на товары (или заявления на выпуск до подачи ДТ), номер товара в этой декларации и уникальный идентификатор товара по выбору организации — номенклатурный, инвентарный, учётный номер или другой признак, обеспечивающий идентификацию и прослеживаемость операций с товаром[1]. Именно этот идентификатор должен связывать первичные учётные документы и регистры бухучёта с конкретной декларацией.

Дальше решение задаёт подробный перечень полей — более 20 показателей на каждый самостоятельный объект учёта: дата принятия к учёту, номер счёта и субсчёта бухучёта, количество и единица измерения, вес нетто и брутто, стоимость и код валюты, остаток на дату, дата и документ снятия с учёта и так далее[1]. Отдельный перечень — для товаров на временном хранении: дата помещения и выдачи, код товара не менее первых четырёх знаков ТН ВЭД, реквизиты подтверждающих документов[1].

Для интегратора задача не сводится к полю номера ГТД. В 1С могут уже существовать справочники и регистры связи декларации с номенклатурой или партией [17]. Достаточность такого механизма зависит от конфигурации, версии и доработок: проверять нужно не название справочника, а сквозную связь «декларация → строка учёта → движение, остаток и корректировки». Только выявленные пробелы становятся основанием для разработки.

Прослеживаемость без ручного соединения выгрузок

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

Практическое следствие для ERP-проекта: если сейчас данные о движении товара разбросаны между несколькими справочниками или базами (склад, производство, розница, обособленные подразделения), проектирование должно устранить необходимость ручного сведения выгрузок при подготовке ответа на запрос таможни. Решение прямо формулирует цель — сопоставление сведений в автоматизированном режиме[1], то есть ручная сверка excel-выгрузок из разных систем не будет считаться исполнением требования, даже если по факту даёт правильный ответ.

Доступ, хранение и защита сведений: что заложить в архитектуру

Здесь решение фиксирует несколько требований, важных для дизайна ИТ-инфраструктуры.

Модель доступа. Удалённый доступ таможенных органов к системе учёта может быть организован двумя способами: прямым доступом к системе с определёнными правами либо через доступ к сведениям, размещённым в иных информационных ресурсах — витринах данных, сервисах облачного хранения[1]. Это подтверждает и практика: на рынке уже существуют коммерческие сервисы передачи данных для УЭО, которые предлагают разные модели — от SaaS с ручной загрузкой до SaaS с автоматической выгрузкой через API и in-house варианта, разворачиваемого на серверах самой компании[18]. Выбор между прямым доступом и витриной данных стоит делать на этапе проектирования, а не постфактум — от него зависит, потребуется ли выделять отдельный контур с ограниченными правами или можно обойтись отчётным слоем поверх основной ERP.

Защита информации. Решение обязывает организацию обеспечивать меры защиты сведений системы учёта: предотвращение несанкционированного доступа, возможность восстановления информации после модификации или уничтожения вследствие несанкционированного доступа, постоянный контроль уровня защищённости[1]. Эти формулировки почти дословно повторяют общие требования к защите информации, установленные статьёй 16 Федерального закона № 149-ФЗ[10], — то есть решение не создаёт отдельного, специфического для таможни контура информационной безопасности, а требует применить к системе учёта уже знакомые ИБ-практики: контроль доступа, резервное копирование, журналирование, регулярный аудит. При организации удалённого доступа компания также вправе проводить идентификацию должностных лиц таможенных органов, которым такой доступ предоставлен[1].

Конфиденциальность встречно. Должностные лица таможенных органов, получившие доступ к сведениям о хозяйственных операциях, не вправе разглашать, использовать в личных целях или передавать третьим лицам информацию, составляющую коммерческую или иную охраняемую тайну, за исключением случаев, установленных правом Союза и международными договорами[1]. Это симметричное обязательство стоит учитывать при подготовке пользовательского соглашения о доступе и регламента взаимодействия с таможней.

Срок хранения. Решение связывает хранение сведений системы учёта со сроком таможенного контроля [1]. Пункт 7 статьи 310 ТК ЕАЭС предусматривает общий трёхлетний срок после соответствующих обстоятельств и возможность его увеличения национальным законодательством до пяти лет; статья 320 отдельно устанавливает сроки хранения документов. Поэтому нельзя автоматически удалять весь архив через три года: сроки следует определять по виду сведений, документу, процедуре и применимому национальному законодательству.

Сверка при частичной реализации, переработке и корректировках

Отдельная практическая сложность — операции, где товар не проходит по системе одной неразрывной цепочкой «поступил → списан».

Смешанный учёт и частичная реализация. Решение прямо допускает ведение учёта товаров одного наименования, которые хранятся, используются или реализуются в смешанном виде, при условии применения правила: товары, помещённые под таможенную процедуру раньше, списываются с учёта первыми[1] — по существу, метод ФИФО применительно к таможенным партиям. Для системы учёта это означает необходимость автоматического списания остатка «сверху вниз» по датам помещения под процедуру, а не по бухгалтерской себестоимости в отрыве от таможенной хронологии партий.

Переработка. В учёте стоит связывать исходную партию с продуктами переработки, отходами и остатками, сохраняя количества, нормы выхода и подтверждающие документы. Дальнейшая таможенная судьба этих объектов определяется применимой процедурой и исключениями ТК ЕАЭС, в том числе для отходов, непригодных для дальнейшего коммерческого использования [19][20]. Универсальное правило «каждый отход обязательно помещается под отдельную процедуру» применять нельзя; связь происхождения объектов в ERP при этом должна сохраняться.

Корректировки. Изменения таможенной стоимости, количества или кода товара после выпуска, а также последующие корректировки декларации должны находить отражение в тех же полях системы учёта, которые формировались на дату первичного принятия товара к учёту (пункты 16–18 Типовых требований прямо перечисляют поля вроде стоимости и кода валюты, заявленных в ДТ)[1]. Практический вывод для ТЗ: система должна поддерживать версионирование значений по объекту учёта, а не только текущее состояние, — иначе сопоставление с таможенными сведениями, которые тоже могут быть скорректированы, начнёт расходиться.

Российская специфика: 289-ФЗ, проверки ФТС и место среди других систем

В России общая обязанность УЭО обеспечивать таможне доступ, в том числе удалённый, к системе учёта товаров закреплена частью 8 статьи 383 Федерального закона от 03.08.2018 № 289-ФЗ «О таможенном регулировании в Российской Федерации»[8]. Отдельная статья того же закона регулирует саму процедуру проверки: наличие системы учёта и порядок ведения учёта проверяются путём сверки данных системы учёта и представляемой таможне отчётности с иными данными, которыми располагает таможенный орган, а также с данными бухгалтерского учёта, первичными документами и регистрами; проверка за один и тот же период проводится один раз[7]. Основные вопросы применения института УЭО в России ФТС традиционно разъясняет в отдельном разделе ответов на часто задаваемые вопросы[6]. Решение № 114 не заменяет эти нормы — оно наполняет техническим содержанием то, что уже проверяется по 289-ФЗ, и именно под него государствам-членам предстоит адаптировать национальное законодательство до 2028 года.

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

• РНПТ (регистрационный номер партии товара) — механизм прослеживаемости отдельных товарных групп на внутреннем рынке в рамках национальной системы прослеживаемости, а не условие включения в реестр УЭО;
• СПОТ — национальная система подтверждения ожидания поставки товаров, оператор которой — ФНС России. Она относится к предварительному оформлению ввоза из других стран ЕАЭС в своём установленном периметре и не заменяет систему учёта товаров УЭО;
• реестр таможенных представителей — отдельный правовой статус со своими условиями включения, не связанный с требованиями к системе учёта товаров конкретного УЭО.

Решение № 114 — самостоятельный набор требований именно к системе учёта товаров организации-УЭО, и с этими тремя системами он не дублируется по предмету регулирования.

Подтверждённых в открытых источниках данных о конкретных поправках в 289-ФЗ или подзаконных актах ФТС России, которые реализуют решение № 114 на национальном уровне, на момент подготовки материала найти не удалось — компаниям стоит отслеживать публикации ФТС и Минфина в этой части отдельно.

Как подготовить ERP: практические этапы

1. Определение применимости. Прежде чем проектировать доработку, нужно зафиксировать: какой тип свидетельства УЭО есть или планируется, какие таможенные процедуры фактически применяет компания (выпуск для внутреннего потребления, переработка, свободная таможенная зона и так далее), есть ли временное хранение на собственной площадке. От ответа зависит, какие из трёх групп объектов учёта, перечисленных в пункте 2 решения, вообще актуальны для конкретной организации[1].

2. Gap-анализ текущей системы учёта. Требования решения удобно разложить построчно — по каждому пункту 13, 16, 17, 18 — и сопоставить с тем, что уже хранит и вычисляет текущая ERP: есть ли уникальный сквозной идентификатор товара, связывается ли он автоматически с номером и строкой декларации, фиксируются ли дата и документ снятия с учёта, поддерживается ли ФИФО-логика по таможенным партиям при смешанном хранении.

3. Матрица соответствия требованиям. Результат gap-анализа оформляется в виде таблицы: пункт решения № 114 → текущее состояние в системе (есть/частично/отсутствует) → требуемая доработка → ответственный модуль ERP. Такая матрица одновременно служит основой для приоритизации задач и для последующей приёмки — по ней легко проверить, закрыт ли каждый пункт требований, а не только общее впечатление о готовности системы.

4. Техническое задание. На основе матрицы формируется ТЗ на доработку учётной системы: перечень новых или изменённых объектов данных (уникальный идентификатор, связи с ДТ и заявлениями), правила автоматического сопоставления с хозяйственными операциями, модель доступа для таможни (прямой доступ или витрина данных), требования к защите информации и журналированию, правила хранения сведений с учётом срока таможенного контроля, а также логика обработки переработки, частичной реализации и корректировок.

5. Программа и методика приёмочных испытаний. Приёмка автоматизированной системы в российской практике традиционно опирается на ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем», который определяет проверку полноты и качества реализации функций, соответствие интерфейсным требованиям, работу средств восстановления после отказов и комплектность эксплуатационной документации[14]. Более новый ГОСТ Р 59792-2021 детализирует состав документов приёмки — программу и методику испытаний, протоколы, акты — и допускает проведение испытаний как на площадке заказчика, так и, по договорённости, на технических средствах разработчика[15]. Применительно к ERP-проекту приёмочное тестирование обычно проводится в форме непрерывной проверки на протяжении внедрения, а для отдельных межсистемных интерфейсов — как самостоятельное интеграционное тестирование с участием ключевых пользователей[16]. Для проверки соответствия решению № 114 в программу испытаний стоит включить контрольный набор данных: несколько «сквозных» товарных позиций, проведённых через полный цикл — от поступления по декларации до списания, включая как минимум один случай переработки и один случай корректировки декларации, — чтобы проверить, что сопоставление данных остаётся корректным на каждом этапе.

Ограничения, ошибки и риски

Наиболее частая ошибка при подготовке к подобным требованиям — воспринимать задачу как «добавить ещё одно поле с номером ГТД», не пересматривая логику списания и не выстраивая сквозной идентификатор через все хозяйственные операции. Формально поле появится, но автоматизированного сопоставления, которого требует решение, не возникнет.

Вторая типичная проблема — недооценка требований к переработке и частичной реализации: если бизнес-процесс компании включает производство из ввезённого сырья, дописывание системы «под декларацию» без учёта норм выхода продукции и статуса отходов/остатков приведёт к разрывам в прослеживаемости именно там, где таможенный контроль наиболее чувствителен.

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

Наконец, стоит помнить, что Типовые требования — акт наднационального уровня, а конкретные технические условия проверки в России будут определяться национальным законодательством о таможенном регулировании, которое ещё предстоит принять или скорректировать. Ориентироваться исключительно на текст решения № 114, не отслеживая последующие акты ФТС и изменения в 289-ФЗ, было бы преждевременно.

Вывод

Решение № 114 задаёт целевую модель учёта товаров УЭО и будущие сроки её применения [1]. Для ERP-проекта важны сквозная связь товара с декларацией и хозяйственными операциями, проверяемые остатки, доступ таможни и правила хранения. Объём доработок определяется gap-анализом: часть требований может уже выполнять действующая система. Переходный период не освобождает от нынешних обязанностей УЭО и не означает, что каждой компании нужна новая ERP.

Источники

[1] Решение Коллегии ЕЭК от 08.09.2026 № 114: официальная карточка и текст.

[2] consultant.ru — ТК ЕАЭС, статья 433. Условия включения в реестр уполномоченных экономических операторов — https://www.consultant.ru/document/cons_doc_LAW_215315/43c3b2c7d7709999185500973887e8af5a41c9c6/

[3] consultant.ru — ТК ЕАЭС, статья 442. Обязанности уполномоченного экономического оператора — https://www.consultant.ru/document/cons_doc_LAW_215315/75505d3143fff3e13dc93c82350f6f12301a57cf/

[4] tks.ru — ТК ЕАЭС, глава 61. Уполномоченный экономический оператор — https://www.tks.ru/codex_eaes/1000000061/

[5] customs.gov.ru — Что такое уполномоченный экономический оператор — https://customs.gov.ru/aeo/chto-takoe-upolnomochennyj-ekonomic

[6] customs.gov.ru — Ответы на наиболее часто задаваемые вопросы по институту УЭО — https://customs.gov.ru/aeo/otvety-na-naibolee-chasto-zadavaemye-voprosy-po-primeneniyu-tamozhennogo-zakonodatel-stva-v-chasti-instituta-upolnomochennyx-ekonomicheskix-operatorov/document/160256

[7] consultant.ru — 289-ФЗ, статья 244. Проведение проверки наличия системы учета товаров — https://www.consultant.ru/document/cons_doc_LAW_304093/4f189110c13155c4deabd8ef463be3082969e12e/

[8] free-ved.com — Уполномоченный экономический оператор (УЭО), со ссылкой на ч. 8 ст. 383 289-ФЗ — https://free-ved.com/upolnomochennyj-ekonomicheskij-operator-ueo/

[9] consultant.ru — ТК ЕАЭС, статья 310. Проведение таможенного контроля — https://www.consultant.ru/document/cons_doc_LAW_215315/817a57502d7f73e798daa585ed3fbff2535fce20/

[10] consultant.ru — 149-ФЗ, статья 16. Защита информации — https://www.consultant.ru/document/cons_doc_LAW_61798/0e9ec16b786dcbdaaa7f44abfc4a15e601d5be22/

[11] ppt.ru — ЕЭК утвердила требования к системам учёта товаров для УЭО — https://ppt.ru/news/tamoj/edinye-trebovaniya-k-uchetu-tovarov-u-ueo

[12] tazabek.kg — ЕЭК утверждает новые требования к системам учёта уполномоченных экономических операторов — https://www.tazabek.kg/news:2530601

[13] terminals.ru — ЕАЭС вводит единые правила учета товаров для уполномоченных экономических операторов — https://www.terminals.ru/news/eaes-vvodit-edinye-pravila-ucheta-tovarov-dlya-upolnomochennyh-ekonomicheskih-operatorov/

[14] rugost.com — ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем — http://www.rugost.com/index.php?catid=22&id=97:34603-92&Itemid=53&option=com_content&view=article

[15] babok-school.ru — Про ПМИ и не только: испытания АС по ГОСТ (ГОСТ Р 59792-2021) — https://babok-school.ru/blog/programma-i-metodika-ispitanyi-as/

[16] corpinfosys.ru — Стратегия тестирования в проектах имплементации ERP-систем — https://corpinfosys.ru/archive/2018/issue-3/141-2018-3-testingstrategy

[17] topkoder.ru — Реестр деклараций на товары (ГТД/ДТ) в 1С — https://topkoder.ru/stati/reestr-elektronnyh-tamozhennyh-deklaracij-na-tovary-gtd-dt-v-1s-naznachenie-nastrojka-i-ispolzovanie/

[18] payhd.ru — Сервис передачи данных для участников УЭО — https://www.payhd.ru/ueo

[19] cyberleninka.ru — Переработка на таможенной территории: отчётность о выверке продуктов переработки, отходов и остатков — https://cyberleninka.ru/article/n/pererabotka-na-tamozhennoy-territorii-tamozhennaya-protsedura-v-pomosch-eksporteram

[20] cyclopedia.ifcg.ru — Таможенный словарь: Переработка на таможенной территории (статус продуктов переработки, отходов и остатков) — https://cyclopedia.ifcg.ru/wiki/Таможенный_словарь:Переработка_на_таможенной_территории