gPdf render/edge
Блог

PDF/A-3: що це таке і як перевірити реальну відповідність файлу

PDF/A-3 — поширений профіль PDF/A, який легально дозволяє вкладення і є основою Factur-X / ZUGFeRD e-invoicing. Відмінності, перевірки та подвійна валідація.

by Інженерна команда gPdf
#pdf-a#compliance#archival#e-invoice

PDF/A — архівний різновид PDF: обіцянка, що документ у 2050 році відобразиться так само, як у 2026. Є чотири основні профілі (PDF/A-1, 2, 3, 4), кожен із власними рівнями conformance. PDF/A-3 — це профіль, на якому фактично тримається європейський e-invoicing, і єдиний широко вживаний PDF/A-профіль, що дозволяє довільні вкладення всередині archival wrapper.

Якщо ви працюєте з invoices, regulatory filings або будь-яким workflow “PDF + structured data”, PDF/A-3 з’явиться у вимогах. Нижче — практичне пояснення: що це, чим відрізняється і як перевірити справжню відповідність.

Сімейство PDF/A коротко

ProfileISO partYearВизначальна риса
PDF/A-119005-12005Перший архівний профіль. Без transparency, без JavaScript, fonts embedded.
PDF/A-219005-22011Додає JPEG2000, transparency та layer support. Краща print fidelity.
PDF/A-319005-32012Додає embedded file attachments. Wrapper для Factur-X / ZUGFeRD.
PDF/A-419005-42020Сучасна ревізія; чистіша conformance model, без поділу b vs a.

Рівні:

  • b (basic): збережена візуальна точність, без гарантій семантичної структури.
  • a (accessible): structure tagging та Unicode mapping для screen readers.
  • u (Unicode): Unicode mapping без повної структури.
  • e / f (лише PDF/A-4): engineering 3D content та full forms.

“PDF/A-3b” означає: архівний profile 3, де дозволені attachments, і basic level без обов’язкового accessibility tagging. Це найпоширеніший варіант для рахунків.

Чим особливий PDF/A-3

PDF/A-1 і PDF/A-2 забороняють довільні embedded files. Логіка архівування проста: PDF має бути self-contained; вкладений data.xlsx може зіпсуватися окремо від PDF і зламати архівну гарантію.

PDF/A-3 послаблює це правило за суворої умови: кожен embedded file має оголосити AFRelationship, тобто зв’язок із видимим PDF content. Допустимі значення: Source, Data, Alternative, Supplement, Unspecified. PDF також має перелічити вкладення в array /AF і видати XMP metadata для attached file.

Інакше кажучи: PDF/A-3 дозволяє вкладати файли, але вимагає точно сказати, що це і як воно пов’язане з тим, що бачить людина. Саме це стало основою e-invoicing: human-readable invoice лежить у PDF, machine-readable EN 16931 CII XML — у attachment, а AFRelationship="Alternative" оголошує їх альтернативними представленнями одного invoice.

Де 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#.
  • Engineering CAD archival: PDF/A-3 з вкладеним native CAD file. PDF — rendering, CAD — source.
  • Regulatory submissions: PDF/A-3 з XML payloads, наприклад FDA submissions або ESEF financial reports для емітентів ЄС.

У цих випадках wrapper — не просто container. Це contract: PDF і attached file представляють один document, і обидва мають validate.

Як перевірити PDF/A-3 compliance

Офіційний conformance checker — veraPDF (verapdf.org), підтримується PDF Association. Він реалізує ISO 19005-3 rule set; якщо veraPDF каже “Pass — PDF/A-3b”, це найсильніший сигнал від одного engine.

Але single-engine “Pass” не є audit-grade standard (Why two PDF/A validators are better than one пояснює чому). Надійний pattern — запускати два independent engines і вважати файл compliant лише якщо обидва pass.

Для e-invoice потрібен ще Mustang (mustangproject.org), de-facto checker для Factur-X / ZUGFeRD. Він перевіряє embedded CII XML за EN 16931 Schematron. PDF/A-3 conformance недостатньо; attached XML теж має бути valid EN 16931, інакше AP system отримувача відхилить invoice.

Багато команд встановлюють Java, налаштовують veraPDF CLI, встановлюють Mustang і пишуть shell script для об’єднання виходів. Це працює, але створює friction.

validator запускає всі три в browser:

  1. veraPDF: official reference, PDF/A-3 conformance.
  2. gPdf Rust+WASM edge engine: independent re-implementation, second opinion.
  3. Mustang: EN 16931 CII XML Schematron для embedded e-invoice payloads.

Drop file, три engines працюють parallel, reports повертаються side-by-side. JSON можна завантажити як QA evidence. Без login і quota.

Що дивитися в report

Failures зазвичай групуються так:

  • Embedded file metadata missing: немає array /AF, або embedded file не listed у ньому.
  • AFRelationship missing or wrong: для e-invoice має бути Alternative; багато PDF libraries default ставлять Source або Data.
  • XMP namespace missing or wrong: Factur-X і ZUGFeRD мають конкретні namespace URI; помилка в один символ дає fail.
  • Fonts not subsetted or not embedded: PDF/A вимагає, щоб усі використані glyphs були embedded разом із font.
  • Output intent missing: PDF/A потребує colour intent (sRGB або інший ICC profile), навіть якщо документ чорно-білий.
  • Document metadata incomplete: в information dictionary мають бути /Title, /Producer, /CreationDate.

Report зазвичай показує конкретний spec section. Виправляйте в source; якщо generate через gPdf, API робить це автоматично, а validator стає public receipt.

TL;DR

PDF/A-3 = PDF/A-2 + можливість легально embed arbitrary files. Саме це робить EU e-invoicing практичним: human-readable invoice + structured EN 16931 CII XML в одному archival wrapper. Мають пройти і PDF/A-3 wrapper, і attached XML.

Генеруйте через POST /api/v1/e-invoice/render. Перевіряйте в validator. Три engines (veraPDF + gPdf edge + Mustang), один upload, безкоштовно.