Lettertypen insluiten in PDF/A: waarom Arial vaak ontbreekt en wat helpt

Een veelvoorkomend struikelblok bij ZUGFeRD: de bron-PDF komt uit een ouder systeem en gebruikt Arial of Arial Bold, zonder deze lettertypen in te sluiten. Daarmee is het bestand al vóór elke conversie niet PDF/A-conform.

> Kort antwoord: PDF/A vereist dat alle lettertypen in het bestand ingesloten zijn. Oudere voorraadbeheersystemen sluiten Arial/Arial Bold vaak niet in – de PDF is dan niet PDF/A-conform, en dat is niet te verhelpen door enkel de ZUGFeRD-XML in te sluiten. Oplossing: PDF/A direct uit het systeem exporteren of XRechnung gebruiken.

Waarom lettertypen ingesloten moeten zijn

PDF/A is een archiefformaat: het moet garanderen dat een document over vele jaren nog identiek oogt. Een bestand dat erop vertrouwt dat de lezer Arial geïnstalleerd heeft, voldoet daar niet aan – op een systeem zonder dat lettertype zou de weergave afwijken. Daarom moeten de lettertypegegevens in de PDF zelf zitten.

Zo controleert u het

Adobe Acrobat: Bestand → Eigenschappen → tabblad „Lettertypen”. Ontbreekt de toevoeging „ingesloten”, dan is het lettertype niet aanwezig.
veraPDF: de open PDF/A-validator meldt niet-ingesloten lettertypen als overtreding.

Waarom XML insluiten niet volstaat

Een wijdverbreid misverstand: „als de ZUGFeRD-XML en de PDF/A-metadata erin zitten, is het bestand PDF/A.” Dat klopt niet. Metadata geven alleen de bedoeling aan; de ontbrekende lettertypen blijven ontbreken. Voor echte conformiteit zouden de lettertypen ingesloten en een kleurprofiel toegevoegd moeten worden.

De twee werkbare oplossingen

PDF/A in het bronsysteem genereren: veel voorraadbeheer- en tekstsystemen kunnen direct PDF/A uitgeven (met ingesloten lettertypen). Dan is het daaruit gegenereerde ZUGFeRD-bestand conform.
XRechnung in plaats van ZUGFeRD: bij de zuivere XRechnung (XML) is er geen PDF-container – de lettertypenkwestie stelt zich helemaal niet.

Conclusie

Niet-ingesloten lettertypen zijn de meest voorkomende oorzaak van niet-conforme ZUGFeRD-PDF’s. Wie uit een ouder systeem komt, exporteert het beste direct PDF/A – of kiest voor XRechnung.

---

De e-factuur-XML is bij TaxLayer altijd EN-16931- en KoSIT-gevalideerd. Vragen over de PDF/A-conformiteit? info@landauer.de.

Veelgestelde vragen

Waarom moeten lettertypen in PDF/A ingesloten zijn?

Zodat het document op elke computer en over vele jaren identiek wordt weergegeven. Vertrouwt het bestand op een systeemlettertype zoals Arial, dat niet overal geïnstalleerd is, dan kan de weergave veranderen – dat verbiedt PDF/A.

Waaraan herken ik dat lettertypen ontbreken?

In Adobe Acrobat onder Bestand → Eigenschappen → Lettertypen: staat daar bij een lettertype niet „ingesloten” of „ingesloten subset”, dan ontbreekt het. Een PDF/A-validator zoals veraPDF meldt dit eveneens.

Maakt het insluiten van de ZUGFeRD-XML mijn PDF conform?

Nee. Het insluiten van XML en metadata maakt een PDF niet achteraf PDF/A-conform. Ontbrekende lettertypen blijven ontbreken. Details in PDF/A-3B en veraPDF.

Hoe krijg ik een PDF/A-conforme factuur?

Het beste is de factuur direct als PDF/A (met ingesloten lettertypen) uit het voorraadbeheer- of facturatiesysteem te exporteren. Als alternatief een zuivere XRechnung gebruiken, waarbij de PDF-container vervalt.