Компании чаще всего подключают сервисы точечно, по мере появления новых требований регулятора. Результат предсказуем: через два-три цикла внедрений IT-ландшафт превращается в набор разрозненных лоскутных интеграций, каждая из которых требует отдельной поддержки, отдельной команды и отдельного бюджета. Ниже разберем пять конкретных архитектурных ошибок, которые приводят к этому результату, и покажем, как их избежать.
Ошибка 1. Каждый сервис интегрируют отдельно
Типичный пример: в 2022 году компания интегрировала посредством API сервис ЭДО для обмена счетами-фактурами. В 2024 году понадобилась работа с МЧД в связи с принятием закона № 536-ФЗ от 19.12.2022, установившего обязательность машиночитаемых доверенностей для сотрудников, подписывающих документы от имени организации. В 2025 г. добавились электронные транспортные накладные в рамках подготовки к обязательному переходу на ЭПД с 1 сентября 2026 года. Каждый раз выбирался отдельный вендор и писалась новая интеграция с учетной системой.
Таким образом, каждый процесс превратился в подключение отдельного API. Интеграция нового сервиса требует повторения одних и тех же инфраструктурных шагов:
настройка авторизации и управления доступом;
реализация логики подписания;
обработка ошибок и ретраев;
логирование и мониторинг;
маппинг сущностей между системами;
поддержка регуляторных форматов.
При этом растет стоимость внедрения и поддержки. Каждая дополнительная интеграция увеличивает нагрузку на команду: растет количество точек отказа, логов, сценариев обработки ошибок и требований к поддержке. При этом каждое изменение регуляторных требований (например, новый формат XML, обновленный классификатор полномочий МЧД) затрагивает только одну из интеграций, и изменения необходимо вносить в каждую интеграцию отдельно.
Ошибка 2. Нет единого центра управления электронной подписью
Электронная подпись используется практически во всех юридически значимых процессах: подписание первичных документов, отправка отчетности, работа с МЧД, подписание ЭПД. Согласно ст. 10 закона № 63-ФЗ, участники электронного взаимодействия обеспечивают конфиденциальность ключей электронных подписей. На практике это означает, что компании необходимо контролировать весь жизненный цикл сертификатов.
Если подпись распределена по разным подсистемам, возникает несколько проблем одновременно.
Ключи и сертификаты находятся в разных системах и хранилищах. Часть в модуле ЭДО, часть в системе отчетности, часть на токенах у самих сотрудников. Когда сотрудник увольняется, отозвать все его подписи за один шаг невозможно: нужно пройти по каждой системе отдельно.
Аудит операций подписания фрагментирован. Журнал подписания в системе ЭДО не связан с журналом в модуле кадрового документооборота. При налоговой проверке или судебном споре собрать полную картину подписания конкретного документа становится отдельной задачей.
Контроль юридической значимости ослабевает. Разные подсистемы могут использовать разные типы подписей (КЭП, НЭП, ПЭП), и без единого реестра сложно гарантировать, что конкретный документ подписан подписью нужного уровня. Напомним: согласно ч. 1 ст. 6 63-ФЗ, информация в электронной форме, подписанная квалифицированной электронной подписью, признается равнозначной бумажному документу с собственноручной подписью. Использование НЭП или ПЭП вместо КЭП в случаях, где закон требует квалифицированную подпись, делает документ юридически ничтожным.
Ошибка 3. Подпись встроена в интерфейс, а не в инфраструктуру
Разработчики часто реализуют подписание на уровне пользовательского интерфейса: кнопка «Подписать» в веб-приложении вызывает плагин криптопровайдера, пользователь выбирает сертификат, документ подписывается. Для единичного сценария это работает. Проблемы начинаются, когда подписание нужно встроить в несколько процессов.
Повторное использование невозможно. Логика подписания «зашита» в конкретный экран конкретного приложения. Чтобы добавить подписание в другой процесс (например, в мобильное приложение водителя для подписания путевого листа), код приходится писать заново.
Автоматизация заблокирована. Массовое подписание документов (сотни накладных в конце месяца, пакетная отправка отчетности) требует серверного подписания без участия пользователя. Если подпись реализована только через UI-плагин, автоматизировать процесс не получится без переписывания архитектуры.
Зависимость от конкретного криптопровайдера. UI-решения, как правило, жестко привязаны к одному средству криптографической защиты информации. Переход на другие СКЗИ или поддержка нескольких средств одновременно требует значительных доработок. При этом требования к средствам электронной подписи определяются ФСБ (приказ ФСБ № 796 от 27.12.2011), и их обновление может потребовать замены криптопровайдера.
Пример: логистическая компания реализовала подписание транспортных накладных через веб-интерфейс диспетчера с использованием УКЭП. Когда потребовалось дать водителям возможность подписывать ЭПД (титулы Т2 и Т4 ЭТрН) в мобильном приложении на маршруте с помощью ПЭП (простой электронной подписи — допустимый тип для водителей), выяснилось, что вся логика подписания привязана к десктопному браузеру и плагину криптопровайдера. Пришлось разрабатывать отдельный сервис подписания с нуля, потратив три месяца и бюджет, сопоставимый с первоначальной интеграцией.
Ошибка 4. Нет контроля регуляторных форматов на уровне инфраструктуры
Юридически значимые документы в России должны соответствовать строго определенным форматам. ФНС утверждает XML-форматы счетов-фактур, УПД, актов, накладных. Минтранс и ФНС совместно регулируют форматы электронных перевозочных документов. Минцифры ведет Классификатор полномочий для МЧД. Эти форматы обновляются регулярно.
Получается, что при обновлении форматов (что происходит регулярно, в среднем несколько раз в год) нужно отслеживать изменения в каждой интеграции, где эти форматы используются. Если хотя бы в одной из них обновление пропущено или выполнено с ошибкой, документ будет отклонен контрагентом или контролирующим органом.
Дополнительный риск связан с форматно-логическим контролем. ФНС применяет ФЛК при приеме отчетности и документов: если XML не проходит проверку, документ возвращается с ошибкой. Централизованный контроль форматов позволяет прогонять документы через ФЛК до отправки, что снижает процент отказов.
Ошибка 5. Архитектура не рассчитана на масштабирование
Первый процесс компания, как правило, закрывает без серьезных архитектурных проблем. Сложности начинаются при переходе ко второму-третьему процессу, особенно если они затрагивают разные подразделения и разные контуры (внутренний документооборот, обмен с контрагентами, взаимодействие с государственными системами).
Признаки того, что архитектура уперлась в потолок:
Добавление нового процесса занимает столько же времени, сколько первый. Нет переиспользуемых компонентов: каждая новая интеграция проектируется с нуля.
IT-команда тратит больше времени на поддержку существующих интеграций, чем на разработку новых. Обновление одного компонента (например, версии СКЗИ) требует тестирования всех интеграций, где он используется.
Невозможно быстро реагировать на регуляторные изменения. Когда государство вводит новый обязательный процесс (например, ЭПД с 1 сентября 2026 года), компания не может развернуть интеграцию за разумный срок, потому что архитектура не предусматривает стандартизованного способа подключения новых сервисов.
Комплексное решение: платформенный подход
Компании, для которых юридически значимые процессы стали частью ежедневных операций, приходят к одному и тому же выводу: нужен выделенный инфраструктурный слой, который берет на себя всю сложность работы с подписями, форматами, доверенностями и взаимодействием с государственными системами.
Что дает выделенный инфраструктурный слой?
Единая точка интеграции. Вместо пяти отдельных подключений к разным сервисам и вендорам, IT-система взаимодействует с единым интеграционным слоем. Каждый следующий юридически значимый процесс подключается быстрее предыдущего, потому что базовые механизмы (авторизация, подписание, валидация форматов, логирование, маршрутизация) уже реализованы.
Повторное использование инфраструктуры. Каждый новый сценарий строится поверх уже реализованных механизмов и не требует разработки с нуля. Команда не повторяет настройку авторизации и подписания для каждого нового сервиса.
Централизованное управление подписями. Выпуск, продление, отзыв сертификатов, журнал операций подписания управляются централизованно. Аудит существенно упрощается.
Контроль регуляторных форматов. Обновления форматов ФНС, изменения в классификаторе полномочий МЧД, новые требования к ЭПД обрабатываются провайдером решения. Бизнес-приложение получает уже валидированные данные.
Масштабирование без роста сложности. Добавление нового сценария интеграции к уже настроенному ранее (например, подключение к ГИС ЭПД или интеграция с Единым налоговым счетом) не требует построения интеграции с нуля. Используются уже реализованные механизмы и инфраструктурные компоненты. Это напрямую влияет на time-to-market: запуск новых юридически значимых процессов занимает недели, а не месяцы, поскольку не требует отдельного проекта интеграции.
Такую архитектуру реализует, в частности, Астрал.Платформа. Здесь через единый API пользователям доступно сразу несколько инструментов:
сервисы для работы с электронными подписями;
работа с машиночитаемыми доверенностями (формирование, регистрация в реестре ФНС, проверка полномочий);
юридически значимый ЭДО с поддержкой роуминга;
электронные перевозочные документы;
передача отчетности и работа с ЕНС.
Сервисы комбинируются: например, в одном сценарии пользователь выпускает подпись, формирует МЧД и отправляет документ в контролирующий орган без выхода из корпоративной системы.
Для разработчиков предусмотрена песочница с тестовыми сертификатами, что позволяет отлаживать сценарии без юридических последствий. Подключение к API бесплатное, оплата идет за транзакции: выпущенные подписи, отправленные документы.
Критерий | Точечные интеграции | Платформенный подход |
Подключение нового процесса | Отдельный проект, как правило, 2–4 месяца (экспертная оценка) | Дополнительный набор методов API, как правило, 1-2 месяца (по данным вендора) |
Обновление регуляторного формата | Правки и контроль в каждой интеграции | Обновление на стороне платформы |
Управление подписями | Распределено по системам | Централизованное управление |
Аудит операций | Сбор данных из нескольких источников | Единый журнал |
Стоимость поддержки при 5+ процессах | Растет нелинейно | Фиксированная стоимость сопровождения одного API |
Повторное использование логики | Не всегда возможно | Реализовано на уровне платформы |
Ключевое отличие платформенного подхода — не просто объединение сервисов, а стандартизация API:
единая модель данных;
единая структура ошибок;
единый механизм авторизации;
единые правила работы с методами (пагинация, фильтрация, версии).
Это позволяет разработчикам не изучать каждый сервис отдельно и снижает порог входа при масштабировании интеграции.
Кастомизированное решение для бизнеса — Астрал.Платформа
Удобная интеграция по единому коннектору API
Оставьте заявку и мы свяжемся с вами
Выводы и практические рекомендации
Точечная интеграция юридически значимых сервисов работает, пока такой сервис один. При переходе к двум и более процессам архитектурные ошибки начинают конвертироваться в прямые затраты: рост стоимости поддержки, увеличение времени выхода на рынок, риск отклонения документов из-за рассинхронизации форматов.
В большинстве случаев все эти ошибки вызваны одной причиной — отсутствием выделенного инфраструктурного слоя для работы с подписями, доверенностями, форматами и государственными системами. Платформенный подход (через единый API) решает сразу несколько проблем, потому что переносит сложность из бизнес-приложений в специализированный сервис.
Практические шаги для бизнеса:
Проведите инвентаризацию текущих интеграций с юридически значимыми сервисами. Зафиксируйте, сколько отдельных подключений существует, кто их поддерживает и сколько времени занимает обновление формата.
Оцените ближайшие регуляторные изменения. Обязательный ЭПД с сентября 2026 года, обновления форматов ФНС, расширение классификатора полномочий МЧД, развитие мобильных подписей: каждое из этих изменений потребует доработки. Если текущая архитектура не позволяет подключить новый процесс за месяц, это сигнал к пересмотру подхода.
Рассмотрите переход на единый интеграционный слой. Астрал.Платформа позволяет вынести юридически значимые процессы в инфраструктурный слой, сохранив контроль над бизнес-логикой в корпоративной системе. Бесплатная песочница дает возможность протестировать сценарии до принятия решения о миграции.
Реклама: ООО «АСТРАЛ-СОФТ», ИНН: 4027145240, erid: 2W5zFHaevHP
Начать дискуссию