PDF/A-3B и ZUGFeRD: действительно ли мой PDF электронного счёта соответствует стандарту? (veraPDF)

ZUGFeRD – это гибридный счёт: читаемый человеком PDF плюс машиночитаемая XML внутри. При этом PDF-часть должна быть особым архивным вариантом – PDF/A-3. Именно здесь возникает большинство недоразумений.

> Краткий ответ: Чтобы PDF действительно был PDF/A-3(-B), в нём, среди прочего, должны быть встроены все шрифты, присутствовать OutputIntent/ICC-цветовой профиль и подходящие PDF/A-метаданные. Валидатор вроде veraPDF проверяет это, но ничего не исправляет. Если исходный PDF не соответствует (например, не встроены шрифты), помогает только настоящая конвертация – или вы используете чистую XRechnung.

Что требует PDF/A-3

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

1. Все шрифты встроены – файл должен сам содержать данные шрифтов и не может полагаться на то, что у читателя установлен, например, Arial.
2. OutputIntent / ICC-цветовой профиль – файл должен определять, как воспроизводятся цвета.
3. PDF/A-XMP-метаданные – обозначение как PDF/A-3.

Частый камень преткновения: не встроенные шрифты

Более старые системы товарного учёта и фактурирования часто создают PDF, которые ссылаются на системные шрифты вроде Arial или Arial Bold, но не встраивают их. Такой файл уже не соответствует PDF/A – и это не исправить тем, что просто добавить ZUGFeRD-XML и PDF/A-метаданные.

Валидация – это не конвертация

Важный момент: veraPDF только валидирует, но не конвертирует. Валидатор сообщает «не соответствует», но не превращает несоответствующий файл в соответствующий. Чтобы действительно создать PDF/A-3, нужен настоящий шаг конвертации, который встраивает шрифты и добавляет цветовой профиль (например, с помощью Ghostscript или эталонной библиотеки ZUGFeRD Mustangproject).

Что всегда верно: XML

Независимо от PDF-контейнера, решающей, юридически значимой частью является структурированная XML. У TaxLayer она полностью валидируется по стандарту проверки KoSIT и EN 16931 (0 ошибок). Сами данные счёта тем самым корректны и соответствуют стандарту – вопрос PDF/A касается только внешней оболочки.

Как надёжно достичь цели

• Вариант A – экспорт PDF/A из системы: Если ваша система товарного учёта может выводить счёт как PDF/A (со встроенными шрифтами), созданный из него файл ZUGFeRD соответствует стандарту.
• Вариант B – использовать чистую XRechnung: При XRechnung (чистая XML) PDF-контейнер полностью отпадает; вопрос соответствия PDF/A не возникает.

Итог

PDF/A-3 – это больше, чем ярлык: он требует встроенных шрифтов, цветового профиля и правильных метаданных. Кто работает со старой системой, лучше всего экспортирует напрямую PDF/A – или делает ставку на XRechnung, где PDF-контейнер не играет роли.

---

XML электронного счёта у TaxLayer всегда валидирована по EN 16931 и KoSIT. Вопросы о соответствии PDF/A? Пишите на info@landauer.de.