PDF/A-3B i ZUGFeRD: czy mój PDF e-faktury jest naprawdę zgodny? (veraPDF)

ZUGFeRD to faktura hybrydowa: czytelny dla człowieka PDF plus maszynowo czytelny XML w środku. Część PDF musi przy tym być szczególnym wariantem archiwalnym -- PDF/A-3. Właśnie tutaj powstaje najwięcej nieporozumień.

> Krótka odpowiedź: Aby plik PDF był naprawdę PDF/A-3(-B), muszą być między innymi osadzone wszystkie czcionki, obecny OutputIntent/profil kolorów ICC oraz odpowiednie metadane PDF/A. Walidator taki jak veraPDF to sprawdza, ale niczego nie naprawia. Jeśli źródłowy PDF nie jest zgodny (np. nieosadzone czcionki), pomaga tylko rzeczywista konwersja -- albo użycie czystej XRechnung.

Czego wymaga PDF/A-3

PDF/A jest stworzony po to, aby dokument był na każdym komputerze i za wiele lat wyświetlany identycznie. Obowiązują w tym celu surowe reguły, najważniejsze z nich:

1. Wszystkie czcionki osadzone -- plik musi zawierać dane czcionek samodzielnie i nie może polegać na tym, że czytelnik ma zainstalowany np. Arial.
2. OutputIntent / profil kolorów ICC -- plik musi określać, jak kolory są odtwarzane.
3. Metadane PDF/A-XMP -- oznaczenie jako PDF/A-3.

Częsta pułapka: nieosadzone czcionki

Starsze systemy gospodarki magazynowej i fakturowania często generują pliki PDF, które odwołują się do czcionek systemowych takich jak Arial czy Arial Bold, ale ich nie osadzają. Taki plik już nie jest zgodny z PDF/A -- i nie da się tego naprawić przez samo uzupełnienie XML ZUGFeRD i metadanych PDF/A.

Walidacja to nie konwersja

Ważny punkt: veraPDF tylko waliduje, nie konwertuje. Walidator zgłasza „niezgodny”, ale z niezgodnego pliku nie czyni zgodnego. Aby naprawdę wygenerować PDF/A-3, potrzebny jest rzeczywisty krok konwersji, który osadza czcionki i dodaje profil kolorów (np. za pomocą Ghostscript lub referencyjnej biblioteki ZUGFeRD Mustangproject).

Co zawsze się zgadza: XML

Niezależnie od kontenera PDF, decydującą, prawnie miarodajną częścią jest ustrukturyzowany XML. Jest on w TaxLayer w pełni walidowany względem standardu weryfikacji KoSIT oraz EN 16931 (0 błędów). Same dane faktury są tym samym poprawne i zgodne -- kwestia PDF/A dotyczy jedynie zewnętrznej powłoki.

Jak bezpiecznie dojść do celu

• Wariant A -- eksport PDF/A z systemu: Jeśli Państwa system gospodarki magazynowej potrafi wyeksportować fakturę jako PDF/A (z osadzonymi czcionkami), wygenerowany z niej plik ZUGFeRD jest zgodny.
• Wariant B -- użycie czystej XRechnung: Przy XRechnung (czysty XML) kontener PDF odpada całkowicie; kwestia zgodności z PDF/A w ogóle się nie pojawia.

Podsumowanie

PDF/A-3 to więcej niż etykieta: wymaga osadzonych czcionek, profilu kolorów i właściwych metadanych. Kto pochodzi ze starszego systemu, najlepiej eksportuje bezpośrednio PDF/A -- albo stawia na XRechnung, gdzie kontener PDF nie odgrywa roli.

---

XML e-faktury jest w TaxLayer zawsze walidowany według EN 16931 i KoSIT. Pytania dotyczące zgodności z PDF/A? Napisz na info@landauer.de.