Валидация XRechnung: KoSIT-валидатор, ошибки Schematron и что они означают

KoSIT-валидатор — это эталонное программное обеспечение, с помощью которого вы можете проверить, действительно ли XRechnung соответствует стандарту, прежде чем она попадёт к получателю или будет отклонена государственным заказчиком. Он сочетает проверку по XML-схеме с правилами Schematron из спецификации XRechnung и сообщает как о структурных ошибках, так и о содержательных нарушениях логики счёта. Тем, кто формирует XRechnung из собственной системы выставления счетов или из автоматизированного workflow, следует твёрдо запланировать эту проверку перед отправкой, а не только тогда, когда счёт возвращается обратно. Актуально на: август 2026 г.

Что именно проверяет KoSIT-валидатор?

KoSIT-Validator проходит, согласно собственной документации, несколько этапов: он распознаёт имеющийся формат XML, проверяет файл по XML-схеме и правилам Schematron, формирует на основе этого индивидуальный отчёт и вычисляет статус приёма. Сами правила проверки валидатор при этом не поставляет, их предоставляет отдельная конфигурация — так называемый файл сценария. Для XRechnung эту роль берёт на себя XRechnung-Validator-Konfiguration, которая объединяет правила Schematron из EN16931 и немецкого CIUS-расширения XRechnung, а также соответствующие XML-схемы для счетов UBL и UN/CEFACT. Без этой конфигурации валидатор вообще ничего не проверяет — он намеренно спроектирован как универсальный инструмент.

Как запустить проверку через командную строку?

Вы запускаете валидатор как Java-программу и передаёте ему конфигурацию сценария, а также файл для проверки. На практике это означает:

• Вызов: java -jar validator-Version-standalone.jar -s Szenario-Konfigurationsdatei -r Repository-Pfad Dateiname, опционально с дополнительными параметрами.
• Справка: Параметр --help показывает все доступные опции прямо в терминале.
• Альтернативы: Валидатор также можно встроить в собственное программное обеспечение как Java-библиотеку или запускать в режиме демона с HTTP-интерфейсом — через параметр -D.

Для автоматизированного workflow особенно интересен режим демона, поскольку в этом случае проверку можно встроить в конвейер через HTTP-запрос, вместо того чтобы каждый раз запускать новый процесс.

В чём разница между ошибками схемы и ошибками Schematron?

Ошибка схемы означает, что XML-файл не соответствует предписанной структуре — например, полностью отсутствует обязательное поле или элемент находится не на своём месте. Как правило, это серьёзные технические ошибки, которые необходимо устранить до какой-либо содержательной проверки. Ошибка Schematron, напротив, означает, что файл структурно корректен, но нарушает содержательное правило спецификации XRechnung — например, сумма не сходится или налоговая ставка не соответствует выбранной категории. Оба типа ошибок попадают в один и тот же XML-отчёт и вместе формируют итоговый статус приёма, который валидатор выдаёт в конце.

Как автоматизировать проверку перед отправкой?

Наиболее надёжна проверка, которая выполняется автоматически ещё до того, как счёт вообще покинет компанию. В workflow на базе n8n это можно реализовать так, что сгенерированный XML XRechnung отправляется по HTTP-запросу на работающий экземпляр валидатора в режиме демона, а возвращённый отчёт анализируется ещё до начала самого шага отправки. Если проверка не проходит, workflow прерывается и сообщает об ошибке в бухгалтерию, вместо того чтобы отправить недействительный счёт. Именно такие предварительные шаги проверки и утверждения относятся к автоматизациям, которые мы в NordFlux настраиваем для клиентов с собственным выставлением счетов.

Часто задаваемые вопросы о валидации XRechnung

Достаточно ли проверки с помощью KoSIT-валидатора в качестве единственного контроля перед отправкой?

Для технического и содержательного соответствия EN16931 и XRechnung-CIUS — да, ведь именно для этого создан валидатор. Однако он не проверяет, корректны ли по содержанию указанные бизнес-данные, такие как банковские реквизиты или описание услуги, — это остаётся вашей ответственностью.

Нужна ли мне отдельная конфигурация для каждого вида счёта?

Да, конфигурация сценария привязана к конкретному формату. Для XRechnung используется XRechnung-Validator-Konfiguration, а для других вариантов EN16931, таких как ZUGFeRD, существуют соответствующие другие файлы конфигурации с собственными правилами Schematron.

Можно ли использовать валидатор без знаний Java?

Базовых знаний командной строки достаточно для простого запуска проверки отдельных файлов, среда разработки Java для этого не нужна. Для интеграции в автоматизированный workflow, например через режим демона, полезно техническое понимание HTTP-запросов.

Что происходит при изменении правил Schematron?

Правила Schematron для XRechnung следуют семантическому версионированию: основные версии вносят несовместимые изменения правил, дополнительные версии расширяют допустимое содержимое, например новыми списками кодов, а патч-версии устраняют обратно совместимые ошибки. Стоит держать под контролем используемую версию конфигурации и повторно тестировать существующие workflow валидации при смене основной версии.