PDF/A-3B si ZUGFeRD: este PDF-ul facturii mele electronice cu adevarat conform? (veraPDF)

ZUGFeRD este o factura hibrida: un PDF lizibil pentru oameni plus XML-ul citibil de masina in interior. Partea PDF trebuie sa fie in acest caz o varianta de arhivare speciala – PDF/A-3. Exact aici apar cele mai multe neintelegeri.

> Raspuns scurt: Pentru ca un PDF sa fie cu adevarat PDF/A-3(-B), trebuie, printre altele, ca toate fonturile sa fie incorporate, sa existe un OutputIntent/profil de culoare ICC si metadate PDF/A corespunzatoare. Un validator precum veraPDF verifica acest lucru, dar nu repara nimic. Daca PDF-ul de origine nu este conform (de ex. fonturi neincorporate), ajuta doar o conversie reala – sau folositi XRechnung pura.

Ce cere PDF/A-3

PDF/A este conceput pentru ca un document sa fie afisat identic pe orice calculator si peste multi ani. Pentru aceasta se aplica reguli stricte, cele mai importante:

1. Toate fonturile incorporate – fisierul trebuie sa contina el insusi datele de font si nu are voie sa se bazeze pe faptul ca cititorul are instalat de ex. Arial.
2. OutputIntent / profil de culoare ICC – fisierul trebuie sa stabileasca modul in care sunt reproduse culorile.
3. Metadate XMP PDF/A – marcarea ca PDF/A-3.

Piatra de poticnire frecventa: fonturi neincorporate

Sistemele mai vechi de gestiune a marfurilor si de facturare genereaza adesea PDF-uri care fac trimitere la fonturi de sistem precum Arial sau Arial Bold, dar nu le incorporeaza. Un astfel de fisier este deja neconform PDF/A – iar acest lucru nu se poate remedia prin simpla adaugare a XML-ului ZUGFeRD si a metadatelor PDF/A.

Validarea nu este conversie

Un punct important: veraPDF doar valideaza, nu converteste. Un validator semnaleaza „neconform”, dar dintr-un fisier neconform nu face unul conform. Pentru a genera cu adevarat PDF/A-3 este nevoie de un pas de conversie real, care incorporeaza fonturile si adauga un profil de culoare (de ex. cu Ghostscript sau cu biblioteca de referinta ZUGFeRD Mustangproject).

Ce este intotdeauna corect: XML-ul

Independent de containerul PDF, partea decisiva, relevanta din punct de vedere juridic, este XML-ul structurat. Acesta este validat la TaxLayer complet fata de standardul de verificare KoSIT si EN 16931 (0 erori). Datele facturii in sine sunt astfel corecte si conforme – chestiunea PDF/A priveste doar invelisul exterior.

Cum ajungeti sigur la tinta

• Varianta A – exportati PDF/A din sistem: Daca sistemul dumneavoastra de gestiune a marfurilor poate genera factura ca PDF/A (cu fonturi incorporate), fisierul ZUGFeRD rezultat este conform.
• Varianta B – folositi XRechnung pura: La XRechnung (XML pur) dispare complet containerul PDF; chestiunea conformitatii PDF/A nu se pune.

Concluzie

PDF/A-3 este mai mult decat o eticheta: cere fonturi incorporate, un profil de culoare si metadatele corecte. Cine vine dintr-un sistem mai vechi exporta cel mai bine direct PDF/A – sau mizeaza pe XRechnung, unde containerul PDF nu joaca niciun rol.

---

XML-ul facturii electronice este la TaxLayer intotdeauna validat EN 16931 si KoSIT. Intrebari despre conformitatea PDF/A? Scrieti la info@landauer.de.