Peppol BIS et EN 16931 : le format de la facture, et pourquoi elle se fait refuser

Deux couches qu'on confond souvent

Derrière « le format », il y a en réalité deux choses distinctes.

EN 16931 est la norme européenne. Elle définit le sens : quelles informations une facture doit porter, et comment elles s'appellent. C'est un vocabulaire commun, où chaque donnée a un identifiant — le numéro de TVA du vendeur, par exemple, est toujours BT-31, quel que soit le pays.

Peppol BIS Billing 3.0 est la mise en œuvre de cette norme sur le réseau Peppol. Elle en reprend les noms d'éléments et précise comment les écrire concrètement, en XML, dans une structure appelée UBL — avec deux documents : la facture et l'avoir.

La Belgique renvoie à ces textes : les factures doivent respecter les normes EN 16931-1 et CEN/TS 16931-2, autrement dit pouvoir être établies au format Peppol-BIS.

Pourquoi une facture est refusée

Les contrôles portent sur la cohérence, pas sur l'apparence. Trois causes reviennent constamment, et nous les avons toutes rencontrées sur nos propres envois :

• Le destinataire est introuvable sur le réseau. L'adresse de routage ne correspond à aucun participant enregistré, et l'envoi est refusé avant même de partir. En Belgique, cette adresse est le numéro d'entreprise BCE : un chiffre erroné et la facture ne sort pas.
• Un identifiant obligatoire manque. Peppol BIS exige le numéro de TVA du vendeur dès qu'une ligne est au taux normal. Sans lui, le document est rejeté à la validation — alors qu'il serait parfaitement lisible pour un humain.
• Une date attendue est absente. Certaines règles imposent une date de livraison ou son équivalent ; à défaut, le contrôle échoue.

Aucune de ces erreurs n'est visible à l'œil nu sur le PDF. C'est tout le changement de nature de la facture électronique : elle est vérifiée par une machine, selon des règles écrites, avant d'exister.

Ce que cela change pour vos données

La conséquence est moins technique qu'organisationnelle : la qualité de votre fichier clients devient un sujet comptable. Des informations qu'on tolérait approximatives — un numéro d'entreprise saisi de mémoire, un numéro de TVA absent, une adresse incomplète — deviennent bloquantes.

Le bon réflexe avant de basculer tient en trois vérifications :

• les numéros d'entreprise de vos clients belges, à dix chiffres, contrôlés et non ressaisis ;
• votre propre numéro de TVA, correctement renseigné dans votre logiciel — c'est lui qui manque le plus souvent ;
• les mentions de vos lignes de facture, en particulier les taux de TVA appliqués.

Faut-il comprendre tout cela ?

Non. Un dirigeant n'a pas à connaître BT-31 ni la structure UBL, pas plus qu'il n'a besoin de connaître le protocole SMTP pour envoyer un courriel. C'est le travail du logiciel.

Ce qu'il est utile de savoir, en revanche, c'est que ces contrôles existent. Parce que le jour où une facture est refusée, la question n'est pas « mon logiciel est-il en panne ? » mais « quelle donnée manque ? » — et poser la bonne question fait gagner plusieurs jours.

Le bon critère de choix d'un logiciel n'est donc pas qu'il « fasse du Peppol », mais qu'il vous dise pourquoi une facture a été refusée, dans des termes que vous pouvez corriger.

Où en est xComm

En France, où la chaîne est complète et en production, xComm génère nativement le fichier structuré, le contrôle au regard des règles de validation avant envoi et suit le statut de chaque facture — c'est ce suivi qui permet de savoir qu'un document a été refusé, et pourquoi. Première facture réelle transmise le 31 août 2026.

Soyons exacts, quitte à nous desservir : xComm n'émet pas encore de factures via Peppol, et le raccordement d'une entreprise belge n'est pas ouvert à ce jour. Le générateur de l'artefact légal belge — le fichier UBL exigé par Peppol BIS — reste à écrire ; celui que xComm produit aujourd'hui est le format français.

Les causes de rejet décrites plus haut ne sont donc pas théoriques : ce sont celles que nous avons rencontrées sur nos propres envois.