МЧД после изменения правил: что менять в создании, хранении, отзыве и автоматической проверке доверенностей

Инженерный чек-лист для компаний с ЭДО, отчётностью, закупками и множеством подписантов

С 1 сентября 2027 года вступают в силу поправки в закон № 63-ФЗ «Об электронной подписи», внесённые Федеральным законом от 4 августа 2026 года № 315-ФЗ: единая форма МЧД с портала Госуслуг (формат 003) станет обязательной к приёму, а остальные формы — Банка России, Федеральной нотариальной палаты, операторов государственных информационных систем — станут дополнительными к ней, но не исчезнут [1][2][3][29]. Для бизнеса это не повод переписывать одну форму на другую, а повод, наконец, спроектировать МЧД как управляемую систему: с версионированием форматов, хранением идентификаторов, проверкой полномочий перед каждой операцией и синхронизацией с кадровыми событиями. Ниже — как это сделать на уровне архитектуры, а не разового аудита.

Почему тема выходит за рамки «что такое МЧД»

К 2026 году машиночитаемая доверенность — это не факультативная опция, а обязательный элемент подписания: с 1 сентября 2024 года сотрудники подписывают документы от имени компании только по МЧД, переходный период с личными сертификатами руководителя завершён [7][11]. За это время само определение МЧД несколько раз усложнилось:

• действуют одновременно несколько форматов (003 — единый; 5.03 — специализированный формат ФНС для отчётности; форматы Казначейства, СФР, ЦБ и ФНП — для своих контуров) [21][25];
• форматы 002, 5.01 и 5.02 выведены из обращения для новых доверенностей, но старые экземпляры продолжают действовать до истечения срока [25][21];
• с 1 февраля 2026 года действует приказ Минцифры от 05.11.2025 № 1001, который обязал указывать в доверенности не только идентификатор полномочия из классификатора, но и его наименование, а также срок действия — при этом сделал необязательными паспортные данные представителя [14][12][13];
• с 1 сентября 2027 года единая форма Госуслуг становится обязательной к приёму для всех, кто раньше мог её не принимать, а дополнительные формы должны соответствовать единым требованиям уполномоченного федерального органа [2].

Каждое из этих изменений — не разовая правка одного XML-шаблона, а сигнал, что компании нужна не «доверенность», а система управления доверенностями: с версионированием, реестром статусов и точками проверки перед каждой операцией. Дальше — по элементам этой системы.

1. Поддержка нескольких форматов одновременно

Компании с ЭДО и отчётностью в разные органы физически не могут работать с одним форматом МЧД. Реалистичная картина на 2026–2027 годы:

• 003 (единый/EMCHD) — универсальный формат для B2B- и B2G-взаимодействия, поддерживает передоверие, разработан Минцифры как основной [22][21];
• 5.03 — формат ФНС для налоговой отчётности, утверждён приказом ФНС от 16.10.2024 № ЕД-7-26/858@, действует параллельно с 003 в этом же контуре [25];
• отраслевые и ведомственные форматы — у СФР, Казначейства, у операторов государственных информационных систем — для своих ИС [23][22].

Инженерный вывод: справочник «Форматы доверенностей» в учётной системе должен быть отдельной сущностью, а не константой в коде. У каждой связки «операция → получатель документа» должно быть явное правило, каким форматом эта операция подтверждается — иначе легко попасть в ситуацию, когда бухгалтерия отправляет в ИФНС МЧД формата 003 там, где принимающая система всё ещё требует 5.03, или наоборот.

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

Формат МЧД — это не только номер (002/003/5.03), но и версия XML-схемы внутри формата, а также действующая редакция требований к содержимому (приказ № 1001 добавил обязательные поля, которых не было в МЧД, выпущенных до 1 февраля 2026 года) [12][14]. Отсюда практические правила:

1. Не хардкодить схему в шаблоне. Генератор МЧД должен получать актуальную версию схемы и перечень обязательных полей из внешнего источника (справочника оператора ЭДО, API классификатора Минцифры) [7], а не из зафиксированного при разработке XSD-файла.
2. Проверять дату документа, а не только его валидность по подписи. Доверенность может быть технически корректной, но выпущенной по устаревшим правилам — формально она ещё действует, но принимающая информационная система вправе её не принять [3]. Это отдельная проверка, которую нужно вынести в код, а не полагаться на то, что «раз подписано — значит, правильно».
3. Разделять «формат» и «версия требований». Переход 5.01 → 5.02 → 5.03 менял именно формат (со сменой схемы и реквизитов), а приказ № 1001 менял требования внутри уже существующего формата 003 [25][14]. Система должна уметь отличать одно от другого, иначе миграции превращаются в хаос.

3. Где и как хранить ID МЧД

Юридически значимая копия доверенности лежит не у вас, а в информационной системе хранения — распределённом реестре ФНС (для форматов 003 и 5.03), в СФР, у Казначейства или ЦБ, в зависимости от формата [4][6][24]. Реестр ФНС устроен как распределённая система: узел оператора ЭДО или крупной организации хранит синхронизированную копию, поэтому проверка через сайт ФНС и проверка через оператора ЭДО дают одинаковый результат [8]. Регистрация МЧД в реестре после подписания занимает от нескольких минут до 24 часов [8] — это системная задержка, которую нужно закладывать в бизнес-процесс, а не считать багом интеграции.

Отсюда требования к внутреннему хранению:

• Храните не файл, а идентификатор в реестре плюс метаданные. Минимальный набор: номер (ID) МЧД, ИНН доверителя, ИНН уполномоченного лица, формат, дата выдачи, срок действия, перечень идентификаторов полномочий из классификатора, статус на момент последней проверки и время этой проверки. Сам файл МЧД можно кешировать, но источником истины остаётся реестр, а не локальная копия.
• Не полагайтесь на локальный кеш статуса дольше, чем необходимо. Если МЧД оформлена, скажем, через СБИС, Диадок или Контур.Доверенность, при увольнении сотрудника или изменении полномочий доверенность отзывается именно через сервис создания, а статус в реестре меняется не мгновенно [23][17]. Локальная база, которая считает МЧД действующей просто потому, что «так было при последней синхронизации», — источник риска.
• Свяжите ID МЧД с внутренним ID сотрудника и с ID сертификата (КЭП). В МЧД указывается конкретный сертификат представителя; при смене сертификата (например, после планового перевыпуска КЭП) требуется перевыпуск доверенности [18]. Если в вашей системе связка «сотрудник — сертификат — доверенность» жёстко не зафиксирована, автоматическая проверка при смене одного из элементов работать не будет.

4. Как проверять полномочия непосредственно перед операцией

Ключевая инженерная ошибка — проверять МЧД один раз (например, при найме сотрудника или при первой настройке интеграции) и затем доверять локальному статусу неограниченно долго. Правильная модель — проверка на каждую значимую операцию, а не разово:

• Сервис 1С-ЭДО, например, при подписании документа выполняет комплексную проверку не только самой доверенности, но и применимости конкретной МЧД к конкретному документу и представителю; если проверка не проходит, система блокирует подписание получателем [27].
• Коммерческие API для работы с реестром (МЧД.МИГ24, Контур.Доверенность и аналогичные) поддерживают отдельный запрос проверки по номеру МЧД, ИНН доверителя и ИНН уполномоченного лица — как в синхронном, так и в асинхронном режиме [5][9].
• Проверка должна учитывать не только факт существования МЧД, но и:
• действует ли она на момент операции (не истёк ли срок, не отозвана ли);
• охватывает ли конкретное полномочие операцию (например, подписание документа определённого вида или на определённую сумму — при использовании ограничений в формате 003 стоит отдельно уточнять, поддерживает ли принимающая система такие ограничения, поскольку не все ИС одинаково их обрабатывают) [25];
• соответствует ли сертификат, которым подписан документ, тому, что указан в самой МЧД [18].

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

5. Как узнавать об отзыве МЧД

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

Практические варианты получения информации об отзыве:

1. Опрос реестра перед операцией (см. пункт 4) — самый надёжный вариант, потому что статус запрашивается непосредственно перед действием, а не читается из локального кеша.
2. Push/webhook-уведомления от оператора ЭДО, если ваш оператор их поддерживает — тогда изменение статуса МЧД можно обрабатывать событийно, обновляя локальный кеш статусов почти в реальном времени.
3. Регулярная сверка портфеля активных доверенностей — если событийных уведомлений нет, нужен batch-процесс, который раз в определённый интервал (например, раз в сутки для второстепенных сценариев и перед каждой критичной операцией — синхронно) сверяет локальный список МЧД с реестром.

Важно закладывать в архитектуру саму задержку регистрации отзыва: заявление на отзыв подаётся через сервис создания МЧД или напрямую в ИС хранения, подписывается КЭП заявителя, и до фактической фиксации в реестре может пройти некоторое время [8][17]. Это значит, что «мгновенного» отзыва в инженерном смысле не бывает — систему нужно проектировать так, чтобы минимизировать окно между решением отозвать полномочия и тем, что каждая точка проверки это увидит.

6. Как обрабатывать увольнение сотрудника

Увольнение — самый частый повод досрочного отзыва МЧД на практике [16], и одновременно самый частый источник инцидентов, потому что затрагивает сразу несколько независимых систем: кадровый учёт, реестр доверенностей и сертификаты ЭП. Три события, которые обязаны срабатывать согласованно:

1. Отзыв МЧД в системе, где она была зарегистрирована. Отзыв выполняется через сервис создания (Контур.Доверенность, Астрал, СБИС, 1С-Отчётность и подобные), а не автоматически при увольнении в HR-системе — то есть без явной интеграции этого не произойдёт [15][17][23]. Технически это обычно тот же паттерн: выбрать доверенность из реестра, указать причину отзыва и подтвердить действие своей КЭП [20]. Например, отзыв МЧД, зарегистрированной в СФР, оформляется отдельным уведомлением о прекращении полномочий представителя [15].
2. Прекращение доступа к личному сертификату сотрудника. МЧД без действующего сертификата бесполезна, но верно и обратное: сертификат физлица, не привязанный к организации, может продолжать действовать и после увольнения, если его отдельно не отозвать через Госуслуги или удостоверяющий центр [25]. Именно поэтому одной только МЧД для защиты недостаточно — нужен параллельный процесс с УЦ.
3. Обновление роли в ERP/ЭДО, чтобы уволенный сотрудник не появлялся как активный подписант ни в одном внутреннем справочнике, даже если формально где-то осталась незакрытая МЧД.

Инженерно это означает: увольнение должно быть триггером (event), а не отдельной ручной задачей бухгалтера «не забыть отозвать доверенность». Если кадровая система поддерживает интеграцию (например, через 1С:КЭДО или аналогичный модуль), увольнение сотрудника логично связывать с автоматическим формированием заявления на отзыв МЧД и уведомлением ответственного за реестр доверенностей — с ручным подтверждением подписания, поскольку сам отзыв всё равно требует КЭП уполномоченного лица.

7. Как связывать МЧД с ролью в ERP/ЭДО

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

Практическая схема связывания:

• у каждой роли в ERP («менеджер по закупкам», «главный бухгалтер», «региональный представитель») — фиксированный перечень операций, которые роль вправе подтверждать;
• каждая операция сопоставлена с конкретным идентификатором полномочия из классификатора Минцифры (CODE + наименование, как того требует приказ № 1001) [14][10];
• при назначении сотруднику роли система инициирует (не обязательно автоматически подписывает, но как минимум формирует черновик) выпуск МЧД с нужным набором полномочий;
• при снятии роли — инициирует отзыв;
• при расхождении между тем, что записано в МЧД, и тем, что предусмотрено ролью в ERP (например, роль расширили, а доверенность не переоформили), система должна сигнализировать об этом отдельно, а не молчать до первого отказа контрагента принять документ.

Такая связка снимает типичную проблему, когда несколько МЧД с пересекающимися или противоречащими друг другу полномочиями существуют одновременно, а понять, какая из них действует «по факту», можно только вручную [25].

8. Как не допустить ситуацию «КЭП действует, а полномочия уже прекращены»

Это фундаментальный риск всей конструкции МЧД, и именно ради его снижения весь механизм и вводился: раньше право подписи руководителя фактически передавалось вместе с самим токеном ЭП, и уволенный сотрудник, сохранивший токен, мог продолжать подписывать документы от имени компании [25]. Отзыв МЧД при увольнении решает именно эту проблему: даже если у бывшего сотрудника на руках осталась действующая личная КЭП, отозванная доверенность делает подписание от имени организации невозможным [19]. МЧД разводит два независимых объекта — сертификат представителя и его полномочия, — но именно поэтому оба объекта нужно контролировать отдельно и одновременно.

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

• нельзя считать документ подписанным правомочно только потому, что КЭП валидна — модуль подписания обязан отдельно запросить статус МЧД в реестре;
• нельзя считать МЧД достаточной защитой без параллельного контроля сертификатов — при увольнении нужно закрывать оба контура (см. пункт 6);
• любое расхождение (сертификат действителен, МЧД истекла или отозвана; либо МЧД действует, но сертификат отозван, скомпрометирован или просрочен) должно останавливать операцию автоматически, а не требовать, чтобы кто-то заметил это вручную.

Частые ошибки, которые видно именно на уровне архитектуры

• Однократная проверка вместо проверки на каждую операцию. МЧД проверили при подключении интеграции — и больше не проверяют. Реестр за это время меняется, а система — нет.
• Локальный кеш без TTL и без источника обновления. Если не настроены ни webhook, ни регулярная сверка с реестром, кеш живёт «пока кто-то не заметит проблему».
• Смешение форматов без явного справочника. Компании интегрируются с несколькими получателями (ИФНС, СФР, контрагенты по ЭДО) и незаметно жёстко прописывают конкретный формат МЧД в коде интеграции, что ломается при следующем изменении правил.
• Ручной, а не событийный отзыв при увольнении. Отзыв МЧД остаётся отдельной задачей в чек-листе HR, а не автоматическим следствием события «уволен» в кадровой системе.
• Разрыв между ERP-ролью и содержанием МЧД. Роль в ERP расширили или сузили, а доверенность не переоформили — или наоборот.

Когда достаточно готового сервиса, а когда нужна интеграция

Если у компании один-два подписанта и стандартные сценарии (отчётность, ограниченный набор контрагентов по ЭДО), обычно достаточно личного кабинета оператора ЭДО или удостоверяющего центра — там же можно выпускать, хранить и отзывать МЧД без дополнительной разработки [4][17]. Разработка и интеграция становятся оправданы, когда:

• подписантов много и их состав часто меняется (нужна автоматическая синхронизация с кадровой системой);
• операций много и они происходят в разных системах (ERP, биллинг, закупки, ЭДО) — проверку полномочий нужно выносить в общий сервис, а не дублировать в каждой системе отдельно;
• есть требование проверять полномочия непосредственно перед конкретной транзакцией, а не только при первичном подключении;
• нужно единое хранилище метаданных по МЧД для аудита и разбора инцидентов.

Команда «Пятого фактора» может изучить, как у вас сейчас устроены выпуск, хранение и проверка МЧД, оценить возможные варианты интеграции с оператором ЭДО или реестром ФНС через доступные API и помочь спроектировать и реализовать сервис проверки полномочий, синхронизированный с кадровыми событиями и ролевой моделью в ERP. Если задача решается настройкой уже используемого сервиса без разработки — честно скажем об этом заранее.

Вывод

Изменения по 315-ФЗ, вступающие в силу с 1 сентября 2027 года, не отменяют многоформатность МЧД — они делают единую форму Госуслуг обязательной к приёму, оставляя остальные форматы дополнительными [2][3]. Для бизнеса это подтверждение тренда последних лет: количество форматов и требований к МЧД будет расти и меняться дальше, а значит, устойчивое решение — не подстраиваться под очередную правку вручную, а один раз построить систему, где формат, версия схемы, статус в реестре, привязка к сертификату и роль в ERP — управляемые, проверяемые и синхронизированные друг с другом сущности. Это ровно то, что отличает соответствие требованиям «на бумаге» от системы, которая не создаёт риска в момент, когда КЭП ещё действует, а полномочия — уже нет.

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

Источники

[1] nalog-nalog.ru — МЧД с 1 сентября 2027 года: форма с Госуслуг станет основной — https://nalog-nalog.ru/nalogovye-izmeneniya-2027/mchd-s-1-sentyabrya-2027-goda-forma-s-gosuslug-stanet-osnovnoj/

[2] diadoc.kontur-f.ru — Единый формат МЧД и новые правила ЭП с 2027 года — https://diadoc.kontur-f.ru/edinyj-format-mchd-i-novye-pravila-ep-s-2027-goda/

[3] klerk.ru — МЧД (машиночитаемая доверенность). 1 сентября 2027 года доверенность оформляют по новым правилам — https://www.klerk.ru/user/2669399/704435/

[4] platformaofd.ru — Сервис для выпуска, отзыва и получения сведений о машиночитаемой доверенности — https://platformaofd.ru/services/platforma-mchd/

[5] m4d.mig24.ru — МЧД по API — https://m4d.mig24.ru/api

[6] astral.ru — Реестр МЧД: как устроена система хранения доверенностей — https://astral.ru/aj/elem/reestr-mchd-kak-ustroena-sistema-khraneniya-doverennostey/

[7] m4d-api.ru — МЧД API — реестр полномочий и API классификатора — https://m4d-api.ru/

[8] kontur42.ru — МЧД и реестр доверенностей ФНС — https://kontur42.ru/mchd-creation/tpost/88ddal5tf1-mchd-i-reestr-doverennostei-fns

[9] kontur-spb.ru — API Контур.Доверенность — для работы с МЧД — https://kontur-spb.ru/mchd/api/

[10] pro-goszakaz.ru — Единый классификатор полномочий МЧД ФНС от Минцифры — https://www.pro-goszakaz.ru/article/104598-klassifikator-polnomochiy-dlya-mchd-chto-eto-i-kak-ispolzovat

[11] bpmsoft.ru — МЧД (Машиночитаемая доверенность): что это, как оформить и применять в 2026 году — https://bpmsoft.ru/glossary/mchd-mashinochitaemaya-doverennost-chto-eto-kak-oformit-i-primenyat-v-2026-godu/

[12] its.1c.ru — Изменились единые требования к оформлению МЧД — https://its.1c.ru/db/content/newscomm/src/498321.htm

[13] nalog-nalog.ru — МЧД для ГИС ЭПД: какие полномочия указывать и какую формулировку выбрать — https://nalog-nalog.ru/forum/buhgalterskoe-po/mchd-dlya-gis-epd-kakie-polnomochiya-ukazyvat-i-kakuyu-formulirovku-vybrat/

[14] klerk.ru — Как подобрать полномочия для МЧД — https://www.klerk.ru/blogs/astral/585350/

[15] its.1c.ru — Отзыв МЧД СФР (бывш. ПФР) — https://its.1c.ru/db/content/elreps/src/17_2_3_%D0%BC%D1%87%D0%B4_%D0%BF%D1%84%D1%80_%D0%BE%D1%82%D0%B7%D1%8B%D0%B2.htm

[16] sberbank.ru — МЧД: как сделать, что это и для чего нужна — https://www.sberbank.ru/ru/s_m_business/pro_business/chto-takoe-mchd

[17] astral.ru — Отзыв МЧД: пошаговая инструкция по отмене доверенности — https://astral.ru/aj/elem/kak-otozvat-mchd-poshagovoe-rukovodstvo/

[18] astral.ru — Перевыпуск МЧД: пошаговая инструкция, как перевыпустить МЧД с актуальными полномочиями — https://astral.ru/aj/elem/perevypusk-mchd-rukovodstvo-po-sozdaniyu/

[19] empldocs.ru — МЧД для ЭЦП на сотрудника: как её оформить и получить — https://empldocs.ru/mashinochitaemaya-doverennost/

[20] emchd.ru — Как создать МЧД для ЕИС: полная инструкция, частые ошибки — https://emchd.ru/blog/instrukczii/kak-sozdat-mchd-dlya-eis-polnaya-instrukcziya-chastye-oshibki/

[21] ca.kontur.ru — Форматы МЧД: что это такое и какими они бывают — https://ca.kontur.ru/articles/50924-formaty_mchd_chto_eto_takoe_i_kakimi_oni_byvayut

[22] elma365.com — Виды МЧД: классификация и применение форматов 002, 003, B2B, B2G — https://elma365.com/ru/products/ecm/news/kakimy-byvaut-mchd/

[23] astral.ru — Форматы МЧД: руководство по выбору подходящего типа доверенности — https://astral.ru/aj/elem/formaty-mchd-rukovodstvo-po-vyboru-podkhodyashchego-tipa-doverennosti/

[24] v2b.ru — Форматы МЧД — https://www.v2b.ru/articles/formaty-mchd/

[25] iaassaaspaas.ru — Виды МЧД: отличия по сфере применения, для сотрудников, возможные противоречия — https://iaassaaspaas.ru/po-dlya-biznesa/sed/mchd/vidy-mchd

[26] buhexpert8.ru — Настройка МЧД в сервисе 1С-ЭДО — https://buhexpert8.ru/1s-buhgalteriya/edo/nastrojka-mchd-v-servise-1s-edo.html

[27] 1cbit.ru — Применение и проверка МЧД в 1С-ЭДО — https://www.1cbit.ru/blog/primenenie-i-proverka-mchd-v-1s-edo/

[28] 1cfresh.info — Электронные (МЧД) и бумажные доверенности при обмене через 1С-ЭДО Fresh — https://1cfresh.info/blog/elektronnye-i-bumazhnye-doverennosti-pri-obmene-cherez-1s-edo/

[29] Российская газета — Федеральный закон от 04.08.2026 № 315-ФЗ — https://rg.ru/documents/2026/08/12/fz315-dok.html