← Back to all articles

Czym jest PDF/A-3 i dlaczego ma znaczenie dla e-fakturowania

SealDoc Team · · 4 min read

Jeśli przez ostatnie dwa lata miałeś cokolwiek wspólnego z europejskim e-fakturowaniem, prawdopodobnie widziałeś termin PDF/A-3 używany tak, jakby każdy już wiedział, co oznacza. Większość artykułów zakłada, że czytelnik rozumie różnicę między PDF, PDF/A i PDF/A-3, i przechodzi dalej. Różnice te nie są akademickie. Decydują o tym, czy faktura wysłana dziś będzie nadal możliwa do otwarcia, weryfikacji i prawnie ważna w 2036 roku.

Oto wersja, którą sami chcieliśmy kiedyś znaleźć.

PDF, PDF/A, PDF/A-3: trzy różne rzeczy

Zwykły PDF to format prezentacyjny. Może zawierać wszystko, czego projektant sobie życzy: zewnętrzne odniesienia do czcionek, JavaScript, osadzone filmy, linki do zewnętrznych zasobów. Ta elastyczność jest świetna dla broszur marketingowych i fatalna dla archiwów. PDF napisany w 2005 roku może już wyglądać inaczej w przeglądarce z 2025 roku, bo czcionka została zastąpiona, zewnętrzny zasób zwrócił błąd 404 lub rozszerzenie dostawcy zostało wycofane.

PDF/A (ISO 19005) to ścisły podzbiór PDF zaprojektowany tak, aby wyświetlać się identycznie na zawsze. Zabrania dynamicznych funkcji. Każda czcionka musi być osadzona. Każdy profil kolorów musi być samowystarczalny. Brak JavaScript, zewnętrznych treści i szyfrowania. Efektem jest plik, który za kilkadziesiąt lat będzie możliwy do otwarcia i wizualnie identyczny.

PDF/A-3 to trzecia rewizja tego standardu, opublikowana w 2012 roku. Zmieniła dokładnie jedną rzecz: pozwala osadzać dowolne załączniki wewnątrz PDF. Wcześniejsze wersje (PDF/A-1, PDF/A-2) dopuszczały wyłącznie załączniki same w sobie zgodne z PDF/A. PDF/A-3 usunął to ograniczenie. Teraz możesz osadzić plik XML, CSV, JSON lub cokolwiek innego jako ustrukturyzowany załącznik.

Ta jedna zmiana umożliwiła nowoczesne e-fakturowanie.

Dlaczego e-fakturowanie potrzebowało dokładnie tego

Zgodna europejska faktura elektroniczna musi być jednocześnie dwiema rzeczami:

  1. Czytalna maszynowo. System księgowy nabywcy musi wczytywać pozycje, stawki VAT i warunki płatności bez ingerencji człowieka.
  2. Czytelna dla człowieka przez lata. Prawo podatkowe w większości krajów UE wymaga archiwizowania faktury w formie, którą ludzki audytor może otworzyć i przeczytać przez 7 do 10 lat.

Czysty plik XML UBL spełnia pierwszy wymóg, ale nie spełnia drugiego. Czysty PDF spełnia drugi, ale nie pierwszy. PDF/A-3 z osadzonym UBL spełnia oba, w jednym odpornym na manipulacje kontenerze, a warstwa wizualna jest bitowo identyczna z warstwą ustrukturyzowaną.

To jest architektura kryjąca się za standardami Factur-X (francusko-niemiecki hybrydowy standard fakturowania) i ZUGFeRD (jego niemieckim poprzednikiem). Oba to PDF/A-3 ze specyficznym załącznikiem XML w określonej lokalizacji i o określonej nazwie pliku. Odrzuć nazwy marketingowe, a zobaczysz, że są to w rzeczywistości “PDF/A-3 plus umowa o to, jaki XML umieszczasz w środku.”

Czego PDF/A-3 nie gwarantuje

PDF/A-3 to format archiwalny. Nie jest to certyfikat zgodności ani podpis. Trzy rzeczy, których konkretnie nie robi:

  • Nie waliduje osadzonego XML. Możesz umieścić zniekształcony UBL wewnątrz PDF/A-3 i plik nadal przejdzie walidację PDF/A-3. Format gwarantuje tylko kontener, nie zawartość.
  • Nie dowodzi, kiedy plik został utworzony. Plik PDF/A-3 można ponownie zapisać, przestemplować i przesłać bez śladu. Jeśli musisz udowodnić, że “ta faktura istniała w tym dniu”, potrzebujesz dodatkowo znacznika czasu RFC 3161.
  • Nie gwarantuje dostarczenia. Zgodność z formatem a zgodność z krajowym obowiązkiem (Peppol, KSeF, Chorus Pro) to odrębne kwestie. PDF/A-3 jest konieczny, ale niewystarczający.

Właśnie dlatego system SealDoc generuje PDF/A-3 plus znacznik czasu RFC 3161 plus pakiet dowodowy ze skrótami manifestu. Każda warstwa odpowiada na inne pytanie, a prawdziwy audyt będzie chciał wszystkich trzech.

Typowe błędy systemów przy generowaniu PDF/A-3

Widzimy te same pięć błędów w systemach klientów:

  1. Połowicznie przekonwertowane PDF-y. Biblioteka twierdzi, że “generuje PDF/A-3”, ale pomija osadzanie czcionek systemowych, które następnie rozwiązują się inaczej na maszynie audytora.
  2. Nieprawidłowa relacja załącznika. PDF/A-3 rozróżnia relacje Source, Data, Alternative, Supplement i Unspecified. Factur-X wymaga Alternative. Wiele programów osadzających domyślnie używa Unspecified i plik nie przechodzi rygorystycznej walidacji.
  3. Brakujące metadane XMP. PDF/A wymaga samoopisujących się metadanych w XMP. Plik bez wymaganych kluczy pdfaid:part i pdfaid:conformance technicznie nie jest PDF/A-3, niezależnie od struktury.
  4. Dryf profilu kolorów. PDF/A-3 musi deklarować każdą przestrzeń kolorów, której używa. Systemy przepuszczające dowolne obrazy RGB bez osadzonego profilu po cichu generują pliki niezgodne ze standardem.
  5. Ponowne renderowanie istniejącego PDF. Niektóre systemy rasteryzują wejściowy PDF przed ponownym osadzeniem XML. Wizualnie to działa, ale niszczy warstwę wyszukiwalnego tekstu i psuje dostępność.

Każdy z powyższych przypadków możesz sprawdzić naszym publicznym walidatorem pod adresem /check. Wrzuć plik, uzyskaj wynik w ciągu sekund, bez rejestracji. Jeśli plik nie przejdzie, raport wskazuje dokładnie, który zapis której specyfikacji został naruszony.

Kiedy PDF/A-3 jest właściwym wyborem (a kiedy nie)

PDF/A-3 jest właściwym wyborem, gdy musisz przechowywać czytelną dla człowieka kopię ustrukturyzowanego dokumentu przez lata i chcesz mieć obie warstwy w jednym kontenerze. Dotyczy to e-faktur, e-paragonów, ustrukturyzowanych umów i coraz częściej biletów elektronicznych i dokumentów celnych.

Nie jest właściwym wyborem dla dokumentów efemerycznych (np. listu dostawy wygasającego w ciągu tygodnia), dokumentów, w których ustrukturyzowany ładunek jest jedyną istotną rzeczą (czysty EDI), ani gdy warstwa czytelna dla człowieka jest czysto dekoracyjna i nigdy nie będzie audytowana.

Dla wszystkich pozostałych w europejskim B2B w 2026 roku PDF/A-3 jest właściwym formatem. Techniczne szczegóły opisane powyżej to powód, dla którego działa, i powód, dla którego zła implementacja po cichu produkuje pliki przechodzące wewnętrzną kontrolę jakości, a zawodzące na biurku audytora trzy lata później.


← Back to all articles