Неправильный XML-файл СЭДО: почему фонд не принимает ответ

Неправильный XML-файл в СЭДО — это формулировка, за которой стоят три разных отказа, и лечатся они по-разному. Первый: файл не прошёл форматный контроль, и в протоколе видно «Ошибка формата сообщения» с расшифровкой валидатора SAXParseException и префиксом cvc-. Второй: файл собран по схеме правильно, но значения не сошлись с базой фонда, и тогда в протоколе стоит код вида ERR_PR_1029 или ERR_PR_1104. Третий: до разбора XML дело вообще не дошло, потому что сообщение не расшифровали или не проверили подпись, и в тексте стоят E_SEDO_1010, E_SEDO_1020 либо HTTP-код. Различает их префикс в тексте протокола, а не длинное число рядом со словом «ошибка»: девятизначное число почти всегда оказывается номером проактивного процесса, а не кодом.

Разберём, где в протоколе логического контроля искать причину, как читать префиксы E_SEDO_, ERR_PR_ и отрицательные коды шлюза отчётности и почему кода 1000014 не существует, а 109 — это тип сообщения, а не ошибка. Отдельно покажем самую частую причину осени 2026 года: после перехода на ГИС ЕЦП 19-21 сентября старые типы сообщений шлюз не принимает, и протокол говорит об этом прямым текстом. Сроки ответа, размеры штрафов по статье 15.2 255-ФЗ, сценарная таблица по способу обмена и разбор ситуаций, когда переделывать файл не нужно вовсе, — во второй половине статьи.

Три причины, которые прячутся за формулировкой «неправильный XML»

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

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

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

Как читать протокол логического контроля и что означает длинное число

Протокол приходит отдельным входящим сообщением, а не строкой в журнале ошибок. В 1С:ЗУП 3.1 он лежит в регистре «Входящие сообщения СЭДО СФР», а сами документы раскладываются по разделу Кадры — Пособия: входящие запросы, ответы на запросы СФР, исходящие сообщения о страховых случаях, извещения. Попасть в регистр можно через строку навигации по ссылке e1cib/list/РегистрСведений.ВходящиеСообщенияСЭДОФСС, открыв её командой «Сервис и настройки — Перейти по ссылке». В половине инструкций в интернете эта ссылка напечатана без точки после «РегистрСведений» и просто не открывается.

Ошибки внутри протокола записаны однообразно: «Ошибки (1): ERR_PR_1076: Проактивный процесс 213969809 был закрыт ранее по причине…». Здесь есть код, есть текст и есть девятизначное число. Искать надо по коду, а не по числу: число идентифицирует процесс.

Отсюда главный источник путаницы в теме. Пользователь видит длинную цифру рядом со словом «ошибка» и ищет по ней расшифровку, которой не существует. Семизначных кодов ошибок в системах СФР нет вообще: коды шлюза СЭДО состоят из префикса E_SEDO_ и четырёх цифр, коды проактивного процесса — из ERR_PR_ и четырёх цифр, коды доверенностей — из ERR_ и четырёх цифр, коды базы данных сервиса ЭЛН — из ORA-200 и двух цифр. Поэтому кода 1000014 не существует ни в одном справочнике фонда, а 109 — это номер типа сообщения «Информация о жизненных событиях», которым работодатель сам инициирует проактивный процесс, а не код отказа.

Последняя строка снимает отдельный класс ложных диагнозов. Коды вида -503 «XML-файл расчёта не прошел форматный контроль» и -19 «Расчет не зашифрован или не подписан» выдаёт шлюз приёма отчётности, через который уходят 4-ФСС и реестры прямых выплат. Если вы получили такой код, ответ на проактивный запрос тут ни при чём, и искать причину надо в отчётности.

Факт: распечатанный электронный документ остаётся копией электронного документа, а не оригиналом. Чтобы распечатка протокола что-то значила при споре, её заверяют: оператором электронного документооборота, удостоверяющим центром, нотариусом либо самой организацией с отметкой о верности копии.

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

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

Файл не прошёл форматный контроль: что именно ломает схему

Форматный контроль означает, что фонд открыл сообщение и сверил его с XSD-схемой. Отказ приходит с заголовком «Ошибка формата сообщения», а дальше идёт текст парсера. Читается он буквально. Префикс cvc-pattern-valid означает, что значение не подошло под шаблон поля: например, в поле, которое ждёт другой формат, попал идентификатор вида 8c647a7b-ec40-48b3-81ce-68420be3ec69. Префикс cvc-maxInclusive-valid означает, что значение больше максимума, заданного схемой. В реальном протоколе это выглядело так: «Value ’12’ is not facet-valid with respect to maxInclusive ‘11.0’ for type ‘countMount’» — в поле количества месяцев стажа поставили 12, притом что схема допускает максимум 11, потому что 12 месяцев — это уже год.

Остальные префиксы валидатора XML Schema читаются так же: cvc-minInclusive-valid — значение ниже минимума, cvc-enumeration-valid — значение вне перечня допустимых, cvc-complex-type — нарушенная структура элемента, cvc-type — несовпадение с объявленным типом. В протоколах СЭДО реально встречались первые два, остальные держите как общее правило валидатора, а не как готовые формулировки фонда.

Отдельно стоят два официальных текста. «Ошибка формата сообщения. Unknown format message» означает, что сообщение не соответствует спецификации целиком, и официальное решение здесь одно: обновить программу до последней версии и повторить отправку. Формулировка «Invalid element … ROW — SERV1_DT1» означает, что поле исключено в новой версии спецификации, и обновлять надо и программу, и базу. Оба случая разобраны в базе знаний СФР по техническим вопросам вместе с требованиями к пространствам имён и формату адреса.

Что фонд требует от XML официально: формат XML-документа; обработку по наименованию атрибута, а не по привязке к пространству имён, поскольку префиксы ns4 и ns5 различаются только префиксом; передачу обоих регистрационных номеров, которые фонд указал в запросе; шифрование на сертификате СФР. Отдельного требования к кодировке файла ни одна открытая страница фонда не устанавливает, поэтому советы «пересохраните файл в UTF-8» проверить не на чем, и как причину отказа эту версию рассматривать не стоит. Актуальные XSD-схемы и спецификации лежат в техническом разделе СЭДО: архив схем датирован 12.05.2026, спецификация типов документов — версия 2.15 от той же даты, спецификация самого сервиса СЭДО — версия 2.3_ЕЦП от 09.12.2025.

Здесь же снимается частое недоразумение про «спецификацию 3.0». С 21.09.2026 запросы приходят в формате спецификации 3.0 с новым полем в служебных данных, но 3.0 — это поколение модуля ВНиМ и ССВ, у которого Том 1 имеет версию 3.2, а Том 2 — версию 3.1. Спецификация сервиса СЭДО при этом осталась версией 2.3. Искать несуществующую «спецификацию СЭДО 3.0» бесполезно.

Файл собран правильно, а значения недопустимы

Эта группа отказов приходит кодами ERR_PR_ в протоколе типа 105 (с 21.09.2026 — 10510) или 112 (11210). Схема выдержана, парсер претензий не имеет, но данные не сошлись с тем, что фонд знает о работнике и о вас.

• ERR_PR_1029 «Значение поля недопустимо для редактирования». Изменены защищённые поля: метод назначения пособия, реквизиты документов о рождении, причина нетрудоспособности. Ответ переформировывают, не трогая эти поля.
• ERR_PR_1104 «Страхователь не найден в списке страхователей застрахованного лица в СФР». Чаще всего не принят подраздел 1.1 ЕФС-1 о приёме работника, ошибка в СНИЛС, неверный регистрационный номер либо при переводе между юрлицами не оформлено увольнение по прежнему месту. Повторную отправку делают через 1-2 рабочих дня после принятия подраздела 1.1.
• ERR_PR_1203 «Сумма заработка не соответствует данным персонального учета». Позиция фонда прямая: работодатель не меняет сумму заработка в проактивном запросе. При наличии подтверждающих документов корректируют стаж, а не заработок.
• ERR_PR_1200 «При указании договора ГПХ необходимо указать дату начала договора». Заполняется дата начала договора.
• ERR_PR_1047 «Процесс закрыт. Пособие … не было оплачено. Перерасчет не представляется возможным». Ответ на старый запрос уже не примут, нужно новое сообщение о страховом случае типа 10910 и ответ на новый запрос.
• ERR_PR_1076 в варианте про просрочку: «Проактивный процесс … был закрыт ранее по причине: Страхователь не направил ответ на запрос недостающих сведений в течении одного календарного месяца с даты направления запроса недостающих сведений». Процедура та же: новое сообщение типа 10910, затем ответ на пришедший запрос.

Совместительство и замена лет расчётного периода идут по своим правилам: при работе по совместительству ответ направляют без корректировки сумм среднего заработка, метод назначения фонд определяет сам; при замене лет годы меняют прямо в ответе на проактивный запрос и потом отвечают на новый запрос с учётом замены.

Когда переделывать файл не нужно вовсе

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

• ERR_PR_1114 «Проактивный процесс закрыт. В системе был найден завершенный процесс по другому страхователю» — действий не требуется.
• ERR_PR_1116 — процесс закрыт, потому что у другого страхователя обнаружен договор ГПХ. Назначение возможно только у одного страхователя, действий не требуется.
• ERR_PR_1076 в варианте «выплата пособия подтверждена другим страхователем» — действий не требуется. Это тот же код, что и при просрочке, но другая причина, и отличаются они текстом, а не номером.
• WARN_PR_1003 — процесс закрыт, потому что другой страхователь изменил расчётные годы или признак договора. Нужно дождаться нового запроса с изменёнными данными.
• E_SEDO_3110 «Абонент уже подписан» и E_SEDO_3120 «Абонент уже откреплён» — повторная подписка или отписка, действий не требуется.
• Входящее сообщение типа 107 (10710) — не отказ, а уведомление о том, что ответ по этому работнику отправил другой работодатель.

Отдельно про сообщение типа 124 (12410). Это не ошибка файла, а уведомление о том, что ответ на запрос в срок не поступил. Оно означает, что процесс ещё жив и ответ ждут, и разбирать его надо не как отказ, а как напоминание: найти по идентификатору исходный запрос, сформировать и отправить ответ.

Старые типы сообщений после перехода на ГИС ЕЦП

С 19 сентября 2026 года 10:00 по московскому времени фонд прекратил приём и отправку типов 100, 101, 105, 107, 109, 112, 124, 320, 321 и 322. В тот же день включилась отправка типов 10010 и 32210, а 21 сентября 10:00 по московскому времени — приём и отправка остальных новых типов. Открытые процессы работодателям надо было закрыть до 18 сентября включительно.

Если учётная программа продолжает слать старые типы, отказ приходит с прямым текстом: «Не удалось определить маршрут для сообщения 101. Проверьте указанный тип сообщения или обратитесь к администратору. Типы сообщений № 109, 101, 320 больше не поддерживаются. Для корректной работы используйте новые типы: № 10910, 10110, 32010». К структуре XML это отношения не имеет: файл собран так, как умеет ваш релиз, а маршрут для его типа на стороне фонда больше не существует. Второй характерный симптом той же причины — ERR_PR_1000 «Не найден процесс» с девятизначным номером: процесс не нашёлся в новой платформе.

Для 1С:ЗУП 3.1 рабочий минимум на осень 2026 года — релиз 3.1.38.92 и выше: перевод пособий по временной нетрудоспособности и в связи с материнством на ЕЦП выполнен начиная с него, дата перехода на новые типы заложена в программу как 21.09.2026. Обновления мало: документы «Ответ на запрос СФР для расчета пособия», проведённые до 21 сентября, нужно перепровести перед отправкой в новом формате, а исходящие сообщения о страховом случае, на которые не пришло подтверждение приёма, отправить повторно.

В практике Добыто с конца сентября первое, что мы смотрим в обращениях по отказам СЭДО, — номер релиза, а не содержимое файла: на этом закрывается основная часть вопросов, пришедших после 21 сентября.

Отдельная ловушка релиза 3.1.38.92 в версии КОРП: при ручной загрузке XML-файла входящего запроса форма обращается к методу, которого в конфигурации больше нет, и выдаёт «Ошибка загрузки файла… Метод объекта не обнаружен (ЗагрузитьСообщение100)… Вероятно, файл не соответствует спецификации ответа веб-сервиса ФСС». Формулировка про несоответствие спецификации вводит в заблуждение: с самим файлом здесь всё в порядке, дефект на стороне конфигурации. Это единичный случай в КОРП-версии, а не типовая ошибка.

Пожалуйста, подпишитесь на нас в мессенджерах

Канал для кадровиков и HR: изменения в законах, практика проверок, шаблоны документов, инструменты подбора и оценки.

Канал в MAX Канал в Telegram

Справочники и формы для разбора отказов СЭДО

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

Когда дело не в XML, а в подписи, шифровании или транспорте

Сообщение СЭДО шифруется на сертификате фонда и подписывается усиленной квалифицированной подписью страхователя. Если этот слой не отработал, фонд до содержимого файла не добирается, и текст отказа говорит про криптографию, а не про данные: «Произошла ошибка при выполнении криптооперации над запросом к серверу СЭДО», E_SEDO_1010 «Ошибка при попытке расшифровать сообщение», E_SEDO_1020 «Ошибка проверки ЭЦП», E_SEDO_1080 «Ошибка подписи исходящего сообщения». Встречается и развёрнутая формулировка «Сообщение не соответствует формату XML Encryption» с указанием на отсутствующий элемент EncryptedData: сообщение не зашифровано или зашифровано неверно.

Слово XML в последнем тексте сбивает с толку сильнее всего. Речь там не про структуру данных ответа, а про конверт, в который эти данные упакованы, и правится он настройками шифрования и сертификатами, а не полями документа.

Календарь ближайших недель для этого слоя плотный. С 1 сентября 2026 года фонд не принимает отчётность, подписанную сертификатами без трёх параметров в поле «Использование ключа»: keyAgreement (согласование ключей), dataEncipherment (шифрование данных) и keyEncipherment (шифрование ключа). Сертификаты, полученные в УЦ ФНС после 28 августа 2025 года, требованию соответствуют. Проверяется это за минуту: открыть файл сертификата, вкладка «Состав», строка «Использование ключа».

Вторая дата ещё ближе. Сертификат шифрования фонда для 4-ФСС и ПВСО действует по 01.10.2026 14:32:53, сертификат для ЭЛН, ПОВЭД, ССВ и СЭДО — по 03.10.2026 10:19:55. Сертификатов 2026 года на странице фонда на 23 сентября нет. Прогнозировать, продлит фонд действующие или выложит новые, смысла не имеет, а вот заложить в календарь проверку настроек на эти даты стоит: в прошлую смену сертификатов массово ловили именно ошибку криптооперации над запросом к серверу СЭДО.

Мария Ж, специалист по цифровой подписи и КЭДО: «Усиленная подпись получается двойным криптографическим преобразованием: сначала от документа считается хэш, потом этот хэш подписывается ключом. Проверяющая сторона считает хэш заново и сравнивает: если два значения совпали, в документ после подписания ничего не вносили. Отказ со словом «подпись» почти никогда не лечится правкой полей: проверяйте сертификат и криптопровайдер.»

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

Что проверить до того, как переделывать файл

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

1. Релиз учётной программы. Для 1С:ЗУП 3.1 — не ниже 3.1.38.92. Ниже этого релиза программа шлёт типы, которых шлюз уже не знает, и никакая правка полей не поможет.
2. Префикс в тексте отказа. E_SEDO_ или HTTP-код — транспорт и криптография, ERR_PR_ — данные, SAXParseException — схема.
3. Сроки действия сертификатов. В форме настроек обмена с СФР видны периоды действия обоих сертификатов шифрования и сертификата страхователя. Критические даты — 01.10.2026 и 03.10.2026.
4. Регистрационный номер. Сверяют с уведомлением фонда и актуальной выпиской ЕГРЮЛ и проверяют, что указан номер по ОСС, а не по ПФР. Единый номер СФР — 10 цифр, номер ПФР — 12 цифр в формате ХХХ-ХХХ-ХХХХХХ, и старые номера ПФР не отменены.
5. Номер процесса в ответе. При повторном запросе по тому же работнику программа может подставить первичный входящий запрос с первичным номером процесса, а тот уже закрыт. В ответе должен стоять запрос с наибольшим номером процесса.
6. Одновременность. Если те же тексты в тот же час ловят многие, причина не у вас. Плановые работы фонд объявляет в техническом разделе СЭДО.

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

Как разобрать отказ фонда по XML-файлу: пошаговая инструкция

1. Шаг 1. Откройте сам протокол, а не строку журнала: в 1С:ЗУП это регистр «Входящие сообщения СЭДО СФР» и документы раздела Кадры — Пособия. Строка «Ошибка обработки сообщения» в списке — ещё не текст отказа.
2. Шаг 2. Выпишите из текста префикс и четыре цифры за ним. Длинные числа и идентификаторы пропускайте: они адресуют процесс и сообщение, а не причину.
3. Шаг 3. Определите слой по таблице выше и закройте сначала его. Один и тот же файл не может одновременно не доехать и не пройти логический контроль.
4. Шаг 4. Если слой — форматный контроль, прочитайте хвост текста после cvc-: валидатор прямо называет поле, значение и нарушенное ограничение. Правьте это значение, а не файл целиком.
5. Шаг 5. Если слой — логический контроль, сверьте данные ответа с персучётом: СНИЛС посимвольно, принятие подраздела 1.1 ЕФС-1, регистрационный номер. Сумму заработка в проактивном запросе не меняйте.
6. Шаг 6. Перед повторной отправкой проверьте, не ушло ли сообщение само из очереди фоновой загрузки. Ручная переотправка поверх успешной даёт дубль, и фонд отвечает на него отдельной ошибкой.
7. Шаг 7. Сохраните протокол, скриншот текста и запись журнала регистрации. Если отказ окажется следствием сбоя, это ваша доказательственная база, и собирать её задним числом тяжело.

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

Важный нюанс из практики: фоновая загрузка вытягивает содержимое только тех сообщений, по которым запрос уже был подписан вручную. Список идентификаторов обновляется каждые 30 минут и без сертификата, а само содержимое — раз в 1 час 55 минут днём или раз в 40 минут ночью. Пока никто ни разу не нажал получение сообщений вручную, регламентное задание видит только идентификаторы, и вся категория обращений «настроили, а ничего не грузится» растёт отсюда.

Сколько стоит ошибка в ответе фонду

Цена отказа складывается не из переделки файла, а из пропущенного срока. Ответить на запрос недостающих сведений нужно за 3 рабочих дня, по единовременному пособию при рождении ребёнка — за 2 рабочих дня, подтвердить получение извещения — за 3 рабочих дня и ответить по существу — за 5 рабочих дней. Информацию о районном коэффициенте фонд ждёт не позднее 2 рабочих дней. Пособие выплачивается в течение 10 рабочих дней с даты поступления всех необходимых сведений.

Нарушение срока представления сведений — это 5 000 рублей по части 3 статьи 15.2 255-ФЗ. Непредставление документов по запросу — 200 рублей за каждый документ по части 1. Недостоверные сведения, из-за которых фонд понёс излишние расходы, — 20 процентов от суммы излишних расходов, но не более 5 000 и не менее 1 000 рублей по части 2. На должностное лицо отдельно накладывается административный штраф 300-500 рублей по части 4 статьи 15.33 КоАП. Формулировки «5 процентов за отказ» в статье 15.2 нет: 5 процентов относятся к другой норме и к другой отчётности.

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

Кто виноват в сбое, суды разбирают по стороне отказа, и результат отличается принципиально. Когда сведения направлены в срок, а фонд не принял их из-за ошибки в сертификате шифрования на своей стороне, штраф отменяют: так решил Арбитражный суд Московского округа постановлением от 22.02.2024 по делу № А40-175408/2023. Когда сбой произошёл в системе самого страхователя, штраф оставляют в силе, что подтвердил Арбитражный суд Северо-Западного округа постановлением от 18.03.2024 № Ф07-1747/2024. Промежуточный вариант тоже есть: Арбитражный суд Западно-Сибирского округа постановлением от 30.01.2025 № Ф04-5727/24 признал техсбой у страхователя смягчающим обстоятельством и снизил штраф с 300 000 до 20 000 рублей. Доказательствами суды принимают уведомления операторов электронного документооборота, скриншоты ошибок, письма о технических неполадках и логи обмена.

Мария Ж, судебный эксперт в сфере корпоративного и трудового права: «Переход на электронные документы не означает, что бумага не понадобится никогда. Суд вправе истребовать подлинник, если только он способен подтвердить обстоятельство дела, а при сомнениях в подлинности назначается экспертиза документа, его реквизитов или подписи. Посмотрите, какие документы у вас существуют только в электронном виде, и заранее решите, чем вы подтвердите их подлинность.»

Отдельный срок отсчитывается не так, как кажется. Суды исходят из того, что три рабочих дня считаются не с момента поступления электронного запроса, а со дня, когда работодатель получил недостающие сведения от работника: без реквизитов счёта форма просто не отправляется. Эту логику подтвердил Арбитражный суд Северо-Кавказского округа постановлением от 03.04.2026.

Стоимость электронного документооборота с сотрудниками: тарифы Добыто на 2026 год

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

Итоговая сумма считается от численности и выбранного набора видов подписи, а на тарифе «Бизнес» действует минимальная оплата за 50 сотрудников независимо от фактического количества. Актуальный состав и условия каждого пакета опубликованы на странице тарифов Добыто.КЭДО.

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

Выводы

За фразой про неправильный XML стоят четыре разных рубежа отказа, и каждый лечится своим инструментом: транспорт — сетью и адресом сервиса, криптография — сертификатами, форматный контроль — релизом и конкретным значением поля, логический контроль — данными ответа. Определяется рубеж по префиксу в тексте протокола, а длинные числа рядом со словом «ошибка» адресуют процесс или сообщение и расшифровки не имеют. Осенью 2026 года первая гипотеза почти всегда одна: программа ниже нужного релиза продолжает слать типы сообщений, которые шлюз перестал принимать 19 сентября. И отдельно стоит помнить, что часть отказов означает корректно закрытый процесс у другого страхователя, где любая переделка файла — лишняя работа.

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

Частые вопросы

Можно ли отредактировать XML-файл вручную и отправить его повторно?

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

Фонд прислал протокол с ошибкой, но пособие работнику уже выплачено. Что делать?

Сначала посмотрите код. Если это ERR_PR_1114, ERR_PR_1116 или вариант ERR_PR_1076 про подтверждение выплаты другим страхователем, процесс закрыт корректно и действий не требуется: пособие назначено по другому месту работы. Если код другой, а выплата уже прошла, проверьте номер процесса в ответе: программа могла подставить первичный входящий запрос вместо последнего, и тогда ответ уходит в уже закрытый процесс.

Почему один и тот же код ERR_PR_1076 приходит с разными текстами?

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

Нужна ли машиночитаемая доверенность, если ответы подписывает бухгалтер?

Если обмен подписывается сертификатом, выданным на организацию и на лицо, действующее без доверенности, доверенность не нужна. Если подписывает сотрудник своим сертификатом физического лица, полномочия подтверждаются МЧД, и её номер указывается в настройках обмена. Ошибки этого слоя приходят отдельными кодами: ERR_4030 «Указанная доверенность не найдена», ERR_4080 при несовпадении данных сертификата и уполномоченного, ERR_4200 при расхождении полей родительской и дочерней доверенности. Регистрируется МЧД на стороне фонда автоматически за несколько секунд.

Что означает отказ E_SEDO_1026 с регистрационным номером в тексте?

Текст звучит как «Регистрационный номер страхователя не найден в справочнике организаций», и причин несколько: указан номер по ПФР вместо номера по обязательному социальному страхованию, страхователь снят с учёта, запрос подписан не подписью страхователя, у индивидуального предпринимателя в сертификате нет ОГРНИП либо не указан номер доверенности. Чаще всего номер в карточке организации расходится с актуальной выпиской ЕГРЮЛ. Проверять надо оба номера: по ОСС и единый десятизначный номер СФР, действующий с 01.11.2024.

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

Официальных причин три: расхождение фамилии, имени и отчества в разных системах, некорректные записи о кадровых мероприятиях и неподтверждённое трудоустройство в персонифицированном учёте. Расхождение анкетных данных исправляется формой АДВ-2 или дубликатом листка нетрудоспособности с корректными данными, некорректное кадровое мероприятие отменяется и подаётся заново. Если запрос фонд не направлял, процесс инициируют сами исходящим сообщением о страховом случае в течение 3 дней с даты закрытия листка; ответ на него приходит в течение суток.

Как отличить массовый сбой на стороне фонда от проблемы у себя?

Признаков четыре. В тексте стоит HTTP-код 500, 502, 503 или 504 без упоминания сертификата — это отказ сервера, а не данных. Формулировка «Не удалось обратиться к серверу» означает, что соединение не установилось и файл шлюз не видел. Те же тексты в тот же час ловят многие страхователи. И на технической странице СЭДО опубликовано объявление о работах с датами. Обмен при перегрузке рекомендуют запускать до 8:00 или после 18:00 по московскому времени.