PDF/A-3B et ZUGFeRD : mon PDF de facture électronique est-il vraiment conforme ? (veraPDF)

ZUGFeRD est une facture hybride : un PDF lisible par l'homme, auquel s'ajoute le XML lisible par la machine à l'intérieur. La partie PDF doit être une variante d'archivage particulière – PDF/A-3. C'est précisément là que naissent la plupart des malentendus.

> Réponse rapide : Pour qu'un PDF soit vraiment PDF/A-3(-B), toutes les polices doivent être incorporées, un OutputIntent / profil colorimétrique ICC doit être présent, de même que des métadonnées PDF/A appropriées. Un validateur comme veraPDF vérifie ces points, mais ne répare rien. Si le PDF source n'est pas conforme (par ex. polices non incorporées), seule une véritable conversion peut aider – à moins d'utiliser une XRechnung pure.

Ce qu'exige le PDF/A-3

PDF/A est conçu pour qu'un document s'affiche à l'identique sur n'importe quel ordinateur et dans de nombreuses années. Pour cela, des règles strictes s'appliquent, les principales étant :

1. Toutes les polices incorporées – le fichier doit contenir lui-même les données de police et ne pas compter sur le fait que le lecteur ait installé, par exemple, Arial.
2. OutputIntent / profil colorimétrique ICC – le fichier doit définir la façon dont les couleurs sont reproduites.
3. Métadonnées XMP PDF/A – l'identification en tant que PDF/A-3.

Le piège fréquent : les polices non incorporées

Les systèmes de gestion commerciale et de facturation plus anciens produisent souvent des PDF qui renvoient à des polices système comme Arial ou Arial Bold sans les incorporer. Un tel fichier n'est déjà pas conforme au PDF/A – et cela ne se corrige pas en ajoutant seulement le XML ZUGFeRD et les métadonnées PDF/A.

Valider n'est pas convertir

Un point important : veraPDF valide seulement, il ne convertit pas. Un validateur signale « non conforme », mais ne transforme pas un fichier non conforme en fichier conforme. Pour produire réellement du PDF/A-3, il faut une véritable étape de conversion qui incorpore les polices et ajoute un profil colorimétrique (par ex. avec Ghostscript ou la bibliothèque de référence ZUGFeRD Mustangproject).

Ce qui reste toujours juste : le XML

Indépendamment du conteneur PDF, la partie décisive et juridiquement déterminante est le XML structuré. Chez TaxLayer, celui-ci est entièrement validé selon le standard de contrôle KoSIT et la norme EN 16931 (0 erreur). Les données de facturation elles-mêmes sont ainsi correctes et conformes – la question du PDF/A ne concerne que l'enveloppe extérieure.

Comment atteindre le but à coup sûr

• Variante A – exporter le PDF/A depuis le système : si votre système de gestion commerciale peut produire la facture en PDF/A (avec polices incorporées), le fichier ZUGFeRD qui en découle est conforme.
• Variante B – utiliser une XRechnung pure : avec la XRechnung (XML pur), le conteneur PDF disparaît entièrement ; la question de la conformité PDF/A ne se pose pas.

Conclusion

PDF/A-3 est plus qu'une étiquette : il exige des polices incorporées, un profil colorimétrique et les bonnes métadonnées. Qui part d'un système plus ancien exporte de préférence directement en PDF/A – ou mise sur la XRechnung, où le conteneur PDF ne joue aucun rôle.

---

Le XML de la facture électronique est chez TaxLayer toujours validé EN 16931 et KoSIT. Des questions sur la conformité PDF/A ? Écrivez à info@landauer.de.