PDF/A to archiwalna odmiana PDF: obietnica, że dokument w 2050 roku wyrenderuje się tak samo jak w 2026. Istnieją cztery główne profile: PDF/A-1, PDF/A-2, PDF/A-3 i PDF/A-4, każdy z własnymi poziomami zgodności. Spośród nich PDF/A-3 jest profilem, który po cichu zasila e-fakturowanie w UE i jedynym szeroko używanym profilem pozwalającym na dowolne załączniki plikowe wewnątrz archiwalnego opakowania.

Jeśli dotykasz faktur, zgłoszeń regulacyjnych albo jakiegokolwiek procesu “PDF + dane strukturalne”, PDF/A-3 jest specyfikacją, którą spotkasz. Oto czym jest, czym różni się od pozostałych profili i jak sprawdzić, czy plik naprawdę spełnia wymagania.

Rodzina PDF/A w jednym akapicie

Profil	Część ISO	Rok	Cecha definiująca
PDF/A-1	19005-1	2005	Pierwszy profil archiwalny. Bez przezroczystości, bez JavaScript, fonty osadzone.
PDF/A-2	19005-2	2011	Dodaje JPEG2000, przezroczystość i warstwy. Lepsza wierność druku.
PDF/A-3	19005-3	2012	Dodaje osadzone załączniki plikowe. Opakowanie dla Factur-X / ZUGFeRD.
PDF/A-4	19005-4	2020	Nowoczesna rewizja, czystszy model zgodności, bez podziału `b` vs `a`.

Każdy profil ma poziomy podrzędne:

b (basic): zachowana jest wierność wizualna. Każdy może odczytać plik, ale nie ma gwarancji semantyki treści.
a (accessible): tagowanie struktury i mapowanie Unicode. Czytniki ekranowe mogą wydobyć tekst we właściwej kolejności.
u (Unicode): mapowanie Unicode bez pełnej struktury. Rozwiązanie pośrednie.
e / f (tylko PDF/A-4): treść inżynierska 3D oraz pełne formularze.

“PDF/A-3b” oznacza więc: profil archiwalny 3, który pozwala na załączniki, oraz poziom basic, bez wymaganego tagowania dostępnościowego. To najczęstszy wariant w fakturowaniu.

Co wyróżnia PDF/A-3

PDF/A-1 i PDF/A-2 zakazują dowolnych osadzonych plików. Uzasadnienie jest proste: archiwalny PDF powinien być samowystarczalny, a osadzony data.xlsx mógłby zestarzeć się niezależnie od PDF, łamiąc gwarancję archiwalną.

PDF/A-3 wyraźnie rozluźnia tę regułę pod ściśle określonym warunkiem: każdy osadzony plik musi mieć atrybut AFRelationship, który mówi, jak plik odnosi się do widocznej treści PDF. Prawidłowe wartości to Source, Data, Alternative, Supplement, Unspecified. Deklaracja PDF musi też wymienić załącznik w tablicy /AF i wyemitować metadane XMP opisujące osadzony plik.

Innymi słowy: PDF/A-3 mówi, że możesz dołączać pliki, ale tylko wtedy, gdy jasno deklarujesz, czym są i jak odnoszą się do tego, co widzi człowiek. Ta deklaracja zrobiła z PDF/A-3 nośnik e-fakturowania: faktura czytelna dla człowieka znajduje się w PDF, maszynowy XML CII EN 16931 w załączniku, a AFRelationship="Alternative" deklaruje, że to alternatywne reprezentacje tej samej faktury.

Gdzie PDF/A-3 działa w produkcji

Factur-X (Francja, obowiązkowe B2B od 2026 roku): PDF/A-3 + XML CII, z przestrzenią nazw XMP urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#.
ZUGFeRD 2.x (Niemcy, obowiązkowy odbiór od 2025 roku): PDF/A-3 + XML CII, z przestrzenią nazw XMP urn:zugferd:pdfa:CrossIndustryDocument:invoice:2p0#.
Archiwizacja CAD w inżynierii: PDF/A-3 z dołączonym natywnym plikiem CAD. PDF jest renderem, a CAD plikiem źródłowym.
Zgłoszenia regulacyjne: PDF/A-3 z dołączonymi ładunkami XML, na przykład zgłoszenia FDA albo raporty finansowe ESEF dla emitentów notowanych w UE.

We wszystkich tych przypadkach opakowanie nie jest tylko kontenerem. To kontrakt mówiący: “ten PDF i ten dołączony plik są tym samym dokumentem, a oba muszą przejść walidację”.

Jak zweryfikować zgodność pliku z PDF/A-3

Oficjalnym narzędziem sprawdzającym zgodność jest veraPDF (verapdf.org), utrzymywane przez PDF Association. Implementuje zestaw reguł ISO 19005-3. Jeśli veraPDF raportuje “Pass — PDF/A-3b”, to najmocniejszy sygnał, jaki może dać pojedynczy silnik.

Jednak pojedynczy wynik “Pass” nie jest standardem audytowym. Artykuł Dlaczego dwa walidatory PDF/A są lepsze niż jeden wyjaśnia powód. Wzorzec audytowy polega na uruchomieniu dwóch niezależnych silników i uznaniu pliku za zgodny dopiero wtedy, gdy oba przejdą.

Dla pliku e-faktury potrzebujesz jeszcze drugiego typu sprawdzenia: Mustang (mustangproject.org), de facto narzędzia dla Factur-X / ZUGFeRD. Mustang waliduje osadzony XML CII względem Schematron EN 16931. Sama zgodność PDF/A-3 nie wystarczy. Dołączony XML także musi być prawidłowy według EN 16931, inaczej system AP po stronie odbiorcy odrzuci fakturę.

Większość zespołów instaluje Javę, konfiguruje CLI veraPDF, instaluje Mustang i pisze skrypt powłoki, który łączy wyniki. To działa, ale dodaje tarcie.

validator uruchamia wszystkie trzy mechanizmy w przeglądarce:

veraPDF: oficjalny punkt odniesienia, zgodność PDF/A-3.
silnik Rust+WASM gPdf na edge: niezależna reimplementacja, druga opinia.
Mustang: Schematron XML CII EN 16931 dla osadzonych danych e-faktury.

Upuszczasz plik, wszystkie trzy sprawdzenia działają równolegle, a raporty wracają obok siebie. JSON można pobrać jako dowód QA. Bez logowania, bez limitu kwoty.

Co naprawdę czytać w raporcie PDF/A-3

Gdy uruchamiasz walidator i jeden z silników zgłasza błąd, problemy zwykle grupują się w kilku obszarach:

Brak metadanych osadzonego pliku: tablica /AF nie istnieje albo osadzony plik nie jest w niej wymieniony.
Brak lub błędny AFRelationship: dla e-faktury powinno być Alternative; Source albo Data to domyślne wartości wielu bibliotek PDF.
Brak lub błędna przestrzeń nazw XMP: Factur-X i ZUGFeRD mają konkretne URI przestrzeni nazw, a literówka o jeden znak oblewa sprawdzenie.
Fonty nie są podzestawione albo osadzone: PDF/A wymaga, aby wszystkie glify użyte w dokumencie były osadzone z fontem. Przypadek brzegowy: referencja do fontu zadeklarowanego, ale faktycznie nieużytego, nadal może oblać test.
Brak output intent: PDF/A wymaga deklaracji intencji koloru, na przykład sRGB albo innego profilu ICC, nawet jeśli dokument jest czarno-białym tekstem.
Niekompletne metadane dokumentu: /Title, /Producer, /CreationDate muszą być obecne w słowniku informacji dokumentu.

Każdy z tych błędów ma konkretną sekcję specyfikacji, do której raport zwykle odsyła. Naprawiasz problem u źródła. Jeśli generujesz przez gPdf, API obsługuje te reguły automatycznie, a walidator jest publicznym potwierdzeniem.

TL;DR

PDF/A-3 = PDF/A-2 + możliwość legalnego osadzania dowolnych plików. Ta możliwość sprawia, że e-fakturowanie w UE jest praktyczne: faktura czytelna dla człowieka i strukturalny XML CII EN 16931 mieszczą się w jednym archiwalnym opakowaniu. Zgodność wymaga zarówno poprawnego opakowania PDF/A-3, jak i poprawnego XML w załączniku. Oba muszą przejść przed wysyłką.

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