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. XMP-метадані PDF/A – позначення як PDF/A-3.

Поширений камінь спотикання: невбудовані шрифти

Старіші системи товарного обліку та фактурування часто створюють PDF, які посилаються на системні шрифти на кшталт Arial чи Arial Bold, але не вбудовують їх. Такий файл уже не відповідає PDF/A – і це не можна виправити, лише додавши XML ZUGFeRD та метадані 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.