Блог

PDF/A-3: что это такое и как проверить реальное соответствие файла

PDF/A-3 — распространенный профиль PDF/A, который легально допускает вложения и лежит в основе Factur-X / ZUGFeRD e-invoicing. Отличия, проверки и двойная валидация.

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-119005-12005Первый архивный профиль. Без transparency, без JavaScript, шрифты встроены.
PDF/A-219005-22011Добавляет JPEG2000, transparency и layers. Лучше для печатной точности.
PDF/A-319005-32012Добавляет embedded file attachments. Оболочка для Factur-X / ZUGFeRD.
PDF/A-419005-42020Современная ревизия; более чистая модель соответствия, без разделения 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 запускает все три проверки в браузере:

  1. veraPDF: official reference, PDF/A-3 conformance.
  2. gPdf Rust+WASM edge engine: независимая реализация, second opinion.
  3. 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, бесплатно.