PDF/A — архивная версия PDF: обещание, что документ в 2050 году отобразится так же, как в 2026. Есть четыре основных профиля (PDF/A-1, 2, 3, 4) и уровни соответствия внутри них. PDF/A-3 — профиль, который фактически держит на себе европейские электронные счета, и единственный широко используемый PDF/A-профиль, разрешающий произвольные вложения внутри архивной оболочки.
Если вы работаете с invoices, регуляторными отчетами или любым процессом “PDF + structured data”, вы встретите PDF/A-3. Ниже — практическое объяснение: что это, чем отличается от соседних профилей и как убедиться, что файл действительно соответствует требованиям.
Семейство PDF/A в одном обзоре
| Профиль | ISO part | Год | Главная особенность |
|---|---|---|---|
| PDF/A-1 | 19005-1 | 2005 | Первый архивный профиль. Без transparency, без JavaScript, шрифты встроены. |
| PDF/A-2 | 19005-2 | 2011 | Добавляет JPEG2000, transparency и layers. Лучше для печатной точности. |
| PDF/A-3 | 19005-3 | 2012 | Добавляет embedded file attachments. Оболочка для Factur-X / ZUGFeRD. |
| PDF/A-4 | 19005-4 | 2020 | Современная ревизия; более чистая модель соответствия, без разделения b и a. |
Уровни:
- b (basic): визуальная точность сохранена, но семантическая структура не гарантируется.
- a (accessible): структурные теги и Unicode mapping, чтобы screen readers извлекали текст в правильном порядке.
- u (Unicode): Unicode mapping без полной структуры.
- e / f (только PDF/A-4): инженерный 3D-контент и полноценные формы.
“PDF/A-3b” означает: архивный профиль 3, где разрешены вложения, и basic-уровень без обязательного accessibility tagging. Это самый частый вариант для счетов.
В чем особенность PDF/A-3
PDF/A-1 и PDF/A-2 запрещают произвольные embedded files. Логика архивирования простая: PDF должен быть самодостаточным; если внутри лежит data.xlsx, вложение может “состариться” отдельно от PDF и сломать архивную гарантию.
PDF/A-3 ослабляет правило при строгом условии: каждый embedded file должен иметь атрибут AFRelationship, объясняющий связь файла с видимым содержимым PDF. Допустимые значения: Source, Data, Alternative, Supplement, Unspecified. Сам PDF также должен перечислить вложение в массиве /AF и выдать XMP metadata по attached file.
Иными словами: PDF/A-3 разрешает прикладывать файлы, но требует точно указать, что это такое и как это связано с тем, что видит человек. Поэтому PDF/A-3 стал транспортом e-invoicing: читаемый счет находится в PDF, машиночитаемый EN 16931 CII XML — во вложении, а AFRelationship="Alternative" заявляет, что это две формы одного счета.
Где PDF/A-3 живет в production
- Factur-X (Франция, поэтапная обязательность B2B с 2026): PDF/A-3 + CII XML, с XMP namespace
urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#. - ZUGFeRD 2.x (Германия, обязательный прием с 2025): PDF/A-3 + CII XML, с XMP namespace
urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#. - Архивирование инженерных CAD: PDF/A-3 с приложенным native CAD file. PDF — rendering, CAD — source.
- Регуляторные подачи: PDF/A-3 с XML payloads, например FDA submissions или ESEF financial reports для компаний из ЕС.
Во всех этих сценариях wrapper — не просто контейнер. Это контракт: PDF и вложенный файл представляют один документ, и оба должны пройти проверку.
Как проверить соответствие PDF/A-3
Официальный checker — veraPDF (verapdf.org), поддерживаемый PDF Association. Он реализует правила ISO 19005-3; если veraPDF говорит “Pass — PDF/A-3b”, это самый сильный сигнал от одного движка.
Но single-engine “Pass” не является audit-grade стандартом (Why two PDF/A validators are better than one объясняет почему). Надежный паттерн — запускать два независимых движка и считать файл compliant только если оба прошли.
Для e-invoice нужна еще одна проверка: Mustang (mustangproject.org), фактический стандартный checker для Factur-X / ZUGFeRD. Он проверяет embedded CII XML по EN 16931 Schematron. Соответствия PDF/A-3 недостаточно; attached XML тоже должен быть валидным EN 16931, иначе AP system получателя отклонит счет.
Обычно команды ставят Java, настраивают veraPDF CLI, устанавливают Mustang и пишут shell script для объединения отчетов. Это работает, но создает лишнее трение.
validator запускает все три проверки в браузере:
- veraPDF: official reference, PDF/A-3 conformance.
- gPdf Rust+WASM edge engine: независимая реализация, second opinion.
- Mustang: EN 16931 CII XML Schematron для embedded e-invoice payloads.
Перетащите файл: три движка работают параллельно, отчеты появляются рядом. JSON можно скачать как QA evidence. Без login и quota.
Что смотреть в отчете
Ошибки обычно группируются так:
- Нет metadata embedded file: отсутствует массив
/AF, либо вложение не указано в нем. - AFRelationship отсутствует или неверен: для e-invoice нужен
Alternative; многие PDF libraries по умолчанию ставятSourceилиData. - XMP namespace отсутствует или неверен: у Factur-X и ZUGFeRD конкретные URI; ошибка в один символ приводит к fail.
- Шрифты не subsetted или не embedded: PDF/A требует, чтобы все использованные glyphs были встроены вместе со шрифтом.
- Нет output intent: PDF/A требует цветовое намерение (sRGB или другой ICC profile), даже если документ черно-белый.
- Document metadata неполная: в information dictionary должны быть
/Title,/Producer,/CreationDate.
Отчет обычно указывает конкретный раздел спецификации. Исправляйте источник; если генерируете через gPdf, API делает это автоматически, а validator остается публичным подтверждением.
TL;DR
PDF/A-3 = PDF/A-2 + возможность легально встраивать произвольные файлы. Эта возможность делает европейский e-invoicing практичным: визуальный invoice + структурированный EN 16931 CII XML в одной архивной оболочке. Должны пройти и PDF/A-3 wrapper, и attached XML.
Генерируйте через POST /api/v1/e-invoice/render. Проверяйте в validator. Три движка (veraPDF + gPdf edge + Mustang), один upload, бесплатно.