Réponse courte : un PDF est une image de facture, l'UBL est un fichier de données : chaque information (numéro, lignes, TVA, échéance) y occupe un champ précis que le système du destinataire lit sans encodage. La conversion se fait par un mapping développé pour vos fichiers, validé avant chaque envoi.

Un PDF de facture contient toutes les bonnes informations, lisibles par n'importe quel humain. Pour une machine, c'est une autre histoire : rien n'indique que « 1.210,00 » est un total TVAC et pas un numéro de client. Voici ce qui se passe entre votre fichier et l'UBL qui part sur le réseau.

Pourquoi le PDF ne suffit plus

Une facture électronique structurée est un fichier de données : chaque information vit dans un champ identifié. Dans l'UBL exigé par le réseau Peppol, le numéro de facture, la date, chaque ligne, chaque taux de TVA et l'échéance ont une place définie par le standard. Le système comptable du destinataire lit ces champs directement, sans encodage manuel et sans erreur de recopie. C'est tout l'objet de l'obligation belge de 2026 : faire circuler des données, pas des images de données.

La nuance qui piège : un PDF auquel on ajoute un fichier XML en pièce jointe reste un PDF pour le réseau. Le format hybride existe ailleurs en Europe, mais ce qui circule sur Peppol, c'est le document structuré lui-même.

Le mapping, traducteur sur-mesure

Vos factures existent déjà quelque part sous forme de données : dans l'export XML ou JSON de votre ERP, dans un CSV, dans la base de votre logiciel maison, ou dans le PDF lui-même. Le mapping est le traducteur entre cette forme et l'UBL :

  1. Analyse : on regarde vos fichiers réels et on identifie où vit chaque information obligatoire
  2. Développement : les règles de conversion sont écrites pour votre format précis, cas particuliers compris (acomptes, remises, notes de crédit, devises)
  3. Tests : vos vraies factures passent dans le mapping, et le résultat est validé contre les règles Peppol BIS jusqu'à zéro écart
  4. Production : le mapping tourne ensuite en automatique sur chaque envoi

Le point important : c'est le mapping qui s'adapte à vos fichiers, jamais l'inverse. Votre système ne change pas d'un octet.

Les champs qui posent problème en pratique

L'analyse va vite sur 80 % d'une facture. Le temps se joue sur le reste, et ce sont toujours les mêmes points :

  • La TVA. Un taux ne suffit pas : la norme EN 16931 attend une catégorie et, pour tout ce qui n'est pas taxé au taux normal, un motif d'exonération. Autoliquidation, intracommunautaire, exportation, franchise : chacun a son code
  • Les remises. Une remise de pied de facture et une remise de ligne ne se codent pas au même endroit, et le total doit retomber juste au centime
  • Les acomptes. La facture finale doit référencer la facture d'acompte déjà émise, sans quoi le client paie deux fois ou rejette
  • Les références client. Bon de commande, numéro de contrat, code chantier : beaucoup de grands donneurs d'ordre rejettent automatiquement une facture qui ne porte pas leur référence au champ prévu
  • Les arrondis. Deux systèmes qui arrondissent différemment à la ligne et au total produisent un écart d'un centime, et le contrôle du réseau le refuse

Ces cas ne se devinent pas dans une documentation : ils se découvrent dans vos factures réelles. C'est la raison d'être de la phase de tests.

Et pour les PDF, comment on fait ?

Quand la donnée source n'existe qu'en PDF, l'extraction s'appuie sur la structure du document : vos PDF sont générés par un logiciel, donc réguliers, ce qui rend l'extraction fiable une fois calibrée sur vos gabarits. Quand une facture sort du cadre, elle est signalée au lieu de partir fausse. La validation avant envoi reste la même que pour les autres formats.

Un conseil de méthode : si votre système sait produire un export de données, même laid, même incomplet, il vaut toujours mieux partir de là que du PDF. Un CSV bancal est une source plus sûre qu'un beau document mis en page.

La validation, filet de sécurité

Chaque facture transformée est contrôlée avant envoi : champs obligatoires présents, cohérence des totaux et de la TVA, identifiant Peppol du destinataire joignable. Une facture qui ne passe pas les contrôles ne part pas, et vous savez pourquoi. Ce filet évite le scénario pénible du rejet par le client trois jours plus tard.

Après l'envoi, le réseau renvoie des accusés de réception qui referment la boucle : vous savez ce qui est arrivé, ce qui a été accepté, et ce qui doit être repris.

C'est ce mécanisme complet, mapping, validation, envoi et suivi des accusés, que couvre Peppol OutBox, pour un logiciel maison comme pour un ERP du marché. Les questions pratiques (formats acceptés, délais, tarifs) sont dans la FAQ.