PDF/A-3B en ZUGFeRD: is mijn e-factuur-PDF echt conform? (veraPDF)

ZUGFeRD is een hybride factuur: een voor mensen leesbare PDF plus de machineleesbare XML aan de binnenkant. Het PDF-deel moet daarbij een bijzondere archiefvariant zijn – PDF/A-3. Precies hier ontstaan de meeste misverstanden.

> Kort antwoord: Om een PDF echt PDF/A-3(-B) te maken, moeten onder andere alle lettertypen ingesloten zijn, een OutputIntent/ICC-kleurprofiel aanwezig zijn en passende PDF/A-metadata. Een validator zoals veraPDF controleert dat, maar repareert niets. Is de bron-PDF niet conform (bijv. niet-ingesloten lettertypen), dan helpt alleen een echte conversie – of u gebruikt een zuivere XRechnung.

Wat PDF/A-3 vereist

PDF/A is ervoor gemaakt dat een document op elke computer en over vele jaren identiek wordt weergegeven. Daarvoor gelden strenge regels, de belangrijkste:

1. Alle lettertypen ingesloten – het bestand moet de lettertypegegevens zelf bevatten en mag er niet op vertrouwen dat de lezer bijv. Arial geïnstalleerd heeft.
2. OutputIntent / ICC-kleurprofiel – het bestand moet vastleggen hoe kleuren worden gereproduceerd.
3. PDF/A-XMP-metadata – de aanduiding als PDF/A-3.

Het veelvoorkomende struikelblok: niet-ingesloten lettertypen

Oudere voorraadbeheer- en facturatiesystemen genereren vaak PDF’s die verwijzen naar systeemlettertypen zoals Arial of Arial Bold, maar deze niet insluiten. Zo’n bestand is al niet PDF/A-conform – en dat is niet te verhelpen door alleen de ZUGFeRD-XML en PDF/A-metadata aan te vullen.

Valideren is niet converteren

Een belangrijk punt: veraPDF valideert alleen, het converteert niet. Een validator meldt „niet conform”, maar maakt van een niet-conform bestand geen conform bestand. Om echt PDF/A-3 te genereren, is een echte conversiestap nodig die lettertypen insluit en een kleurprofiel toevoegt (bijv. met Ghostscript of de ZUGFeRD-referentiebibliotheek Mustangproject).

Wat altijd klopt: de XML

Onafhankelijk van de PDF-container is het beslissende, juridisch maatgevende deel de gestructureerde XML. Deze wordt bij TaxLayer volledig gevalideerd tegen de KoSIT-controlestandaard en EN 16931 (0 fouten). De factuurgegevens zelf zijn daarmee correct en conform – de PDF/A-kwestie betreft alleen de buitenste omhulling.

Zo komt u zeker tot uw doel

• Variant A – PDF/A uit het systeem exporteren: Kan uw voorraadbeheersysteem de factuur als PDF/A (met ingesloten lettertypen) uitgeven, dan is het daaruit gegenereerde ZUGFeRD-bestand conform.
• Variant B – zuivere XRechnung gebruiken: Bij de XRechnung (zuivere XML) vervalt de PDF-container volledig; de vraag naar PDF/A-conformiteit stelt zich niet.

Conclusie

PDF/A-3 is meer dan een etiket: het vereist ingesloten lettertypen, een kleurprofiel en de juiste metadata. Wie uit een ouder systeem komt, exporteert het beste direct PDF/A – of kiest voor XRechnung, waar de PDF-container geen rol speelt.

---

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