PDF/A to archiwalna odmiana PDF: obietnica, że dokument w 2050 roku wyrenderuje się tak samo jak w 2026. Główne profile to PDF/A-1, 2, 3 i 4, każdy z własnymi poziomami conformance. PDF/A-3 jest profilem, który praktycznie umożliwia europejskie e-faktury, i jedynym szeroko używanym profilem PDF/A pozwalającym na arbitralne załączniki w archiwalnym wrapperze.

Jeśli pracujesz z fakturami, raportowaniem regulacyjnym albo workflow “PDF + structured data”, PDF/A-3 pojawi się w projekcie. Poniżej: co oznacza, czym się różni i jak sprawdzić realną zgodność pliku.

Rodzina PDF/A w skrócie

Profile	ISO part	Year	Cechy
PDF/A-1	19005-1	2005	Pierwszy profil archiwalny. Bez transparency, bez JavaScript, fonts embedded.
PDF/A-2	19005-2	2011	Dodaje JPEG2000, transparency i layer support. Lepsza print fidelity.
PDF/A-3	19005-3	2012	Dodaje embedded file attachments. Wrapper dla Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Nowoczesna rewizja; czystszy conformance model, bez podziału `b` vs `a`.

Poziomy:

b (basic): zachowana wierność wizualna, bez gwarancji semantyki.
a (accessible): structure tagging i Unicode mapping dla screen readerów.
u (Unicode): Unicode mapping bez pełnej struktury.
e / f (tylko PDF/A-4): engineering 3D content i full forms.

“PDF/A-3b” oznacza więc: profil archiwalny 3 z dozwolonymi załącznikami oraz basic level bez wymaganego accessibility tagging. To najczęstszy wariant dla faktur.

Co wyróżnia PDF/A-3

PDF/A-1 i PDF/A-2 zakazują arbitralnych embedded files. Powód: archiwalny PDF musi być self-contained; załącznik data.xlsx może zestarzeć się niezależnie od PDF i złamać gwarancję archiwizacji.

PDF/A-3 luzuje tę regułę pod ścisłym warunkiem: każdy embedded file musi deklarować AFRelationship, czyli relację wobec widocznej treści PDF. Dozwolone wartości to Source, Data, Alternative, Supplement, Unspecified. PDF musi też wymienić załącznik w array /AF i wyemitować XMP metadata opisujące attached file.

Innymi słowy: PDF/A-3 pozwala na załączniki, ale wymaga jasnego wskazania, czym są i jak łączą się z tym, co widzi człowiek. To stało się fundamentem e-faktur: faktura dla człowieka jest w PDF, maszynowy EN 16931 CII XML w załączniku, a AFRelationship="Alternative" mówi, że to dwie reprezentacje tej samej faktury.

Gdzie PDF/A-3 działa w produkcji

Factur-X (Francja, B2B stopniowo obowiązkowe od 2026): PDF/A-3 + CII XML, z namespace XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Niemcy, odbiór obowiązkowy od 2025): PDF/A-3 + CII XML, z namespace XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Archiwizacja CAD engineering: PDF/A-3 z załączonym native CAD file. PDF jest renderingiem, CAD jest source.
Zgłoszenia regulacyjne: PDF/A-3 z XML payloads, np. FDA submissions albo ESEF financial reports spółek notowanych w UE.

W tych przypadkach wrapper nie jest tylko kontenerem. To contract: PDF i attached file są tym samym dokumentem, a oba muszą validate.

Jak zweryfikować zgodność PDF/A-3

Oficjalny checker to veraPDF (verapdf.org), utrzymywany przez PDF Association. Implementuje rule set ISO 19005-3; jeśli veraPDF zgłasza “Pass — PDF/A-3b”, to najmocniejszy sygnał z pojedynczego engine.

Ale single-engine “Pass” nie jest audit-grade standard (Why two PDF/A validators are better than one wyjaśnia dlaczego). Wzorzec audytowy to uruchomienie dwóch independent engines i uznanie pliku za compliant dopiero, gdy oba przejdą.

Dla e-invoice potrzebny jest też Mustang (mustangproject.org), de-facto checker dla Factur-X / ZUGFeRD. Mustang waliduje embedded CII XML względem EN 16931 Schematron. Sama zgodność PDF/A-3 nie wystarczy; attached XML też musi być valid EN 16931, inaczej AP system odbiorcy odrzuci fakturę.

Wiele zespołów instaluje Java, veraPDF CLI i Mustang, a potem pisze shell script łączący wyniki. Działa, ale jest tarciem.

validator uruchamia wszystkie trzy w przeglądarce:

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

Upuść plik, trzy engine działają równolegle, raporty wracają obok siebie. JSON można pobrać jako QA evidence. Bez loginu, bez quota.

Co czytać w raporcie

Failures zwykle grupują się tutaj:

Embedded file metadata missing: brak array /AF, albo embedded file nie jest listed.
AFRelationship missing or wrong: dla e-invoice powinno być Alternative; wiele PDF libraries domyślnie daje Source albo Data.
XMP namespace missing or wrong: Factur-X i ZUGFeRD mają konkretne URI; literówka wystarczy do fail.
Fonts not subsetted or not embedded: PDF/A wymaga, by wszystkie użyte glyphs były embedded z fontem.
Output intent missing: PDF/A wymaga colour intent (sRGB lub inny ICC profile), nawet dla czarno-białego tekstu.
Document metadata incomplete: w information dictionary muszą być /Title, /Producer, /CreationDate.

Raport zwykle wskazuje konkretną sekcję specyfikacji. Naprawiaj u źródła; jeśli generujesz przez gPdf, API obsługuje te reguły, a validator jest publicznym potwierdzeniem.

TL;DR

PDF/A-3 = PDF/A-2 + możliwość legalnego embed arbitrary files. To umożliwia e-fakturowanie w UE: human-readable invoice + structured EN 16931 CII XML w jednym archival wrapper. Przejść muszą zarówno PDF/A-3 wrapper, jak i attached XML.

Generuj przez POST /api/v1/e-invoice/render. Sprawdź w validator. Trzy engines (veraPDF + gPdf edge + Mustang), jeden upload, bezpłatnie.