Validateur de facture UBL/Peppol

Vérifiez la structure avant que le réseau ne le fasse pour vous

La façon coûteuse de découvrir qu'un fichier de facture est cassé, c'est de l'envoyer : il voyage jusqu'à votre client ou un point d'accès, se fait rejeter des heures ou des jours plus tard, et le compteur de paiement repart de zéro. La façon économique, c'est trente secondes ici d'abord. Ce validateur répond aux questions franches et utiles : le fichier est-il seulement du XML bien formé, s'agit-il réellement d'une facture UBL, et les champs présents sont-ils ceux dont toute facture lisible a besoin — numéro, dates, les deux parties, lignes et totaux. Les fichiers sont vérifiés en mémoire serveur puis immédiatement supprimés, ce qui est la bonne façon de traiter un document portant des noms, des montants et des coordonnées bancaires. Il se rend particulièrement utile dans deux situations : une petite entreprise qui génère ses premières factures UBL à partir d'un modèle ou d'un module ERP peu familier, et un développeur qui teste un pipeline d'export et veut un avis extérieur rapide sur le résultat avant de le pointer vers le vrai réseau.

Ce qu'est un contrôle structurel — et ce qu'est Schematron

L'honnêteté compte ici. La validation officielle Peppol BIS Billing 3.0 est un jeu de règles Schematron : des centaines de règles métier qui vérifient par exemple si les codes de catégorie de TVA sont cohérents et si les totaux de taxe correspondent bien à la somme des lignes. Cet outil n'exécute pas ces règles. Lisez les deux résultats en conséquence : un échec ici est définitif — un fichier qui ne s'analyse pas, ou qui manque de champs obligatoires, échouera partout, donc corrigez-le avant de l'envoyer. Une réussite ici signifie que la structure est exploitable, pas que chaque règle métier est satisfaite ; le réseau peut encore le rejeter pour une violation au niveau des règles. Structurel d'abord, Schematron ensuite, c'est l'ordre naturel du contrôle. La limite est délibérée, pas paresseuse : les jeux de règles officiels sont versionnés et maintenus de façon centralisée, et les exécuter correctement est le travail de l'infrastructure Peppol elle-même — les imiter maladroitement vous desservirait plus que de nommer clairement la limite.

Les échecs que l'on voit réellement

La plupart des fichiers rejetés suivent quelques schémas classiques. Le fichier est une note de crédit plutôt qu'une facture — un type de document UBL différent que ce validateur ne couvre pas encore. C'est un PDF Factur-X plutôt que du XML brut — la facture est intégrée à l'intérieur d'un PDF et doit d'abord être extraite avec l'outil Factur-X de ce site. Il a été tronqué ou réencodé quelque part au fil d'un trajet par e-mail, si bien que le XML ne s'analyse plus. Ou un export ERP a laissé des champs de partie ou de total obligatoires vides parce qu'une fiche de données de référence était incomplète. Le validateur nomme ce qui manque, ce qui indique généralement directement lequel de ces cas s'est produit. Une variante plus subtile mérite d'être connue : un fichier qui s'ouvre parfaitement dans un éditeur de texte peut quand même échouer à s'analyser parce qu'une passerelle e-mail ou une étape de copier-coller a changé son encodage de caractères — invisible à l'œil, fatal pour du XML. Réexportez depuis le système source plutôt que de réparer à la main.

Le même analyseur que le moteur de rendu PDF — et quand appeler votre prestataire

Ce validateur partage son analyseur, ligne pour ligne, avec l'outil facture électronique en PDF de ce site. Cela vous offre un petit flux de travail fiable : validez le fichier, puis rendez-le et lisez la facture comme le ferait un humain — un IBAN erroné ou un total absurde est souvent plus facile à repérer sur une page que dans du XML. Et sachez où se trouve la limite : si un fichier réussit ici, se rend de façon sensée, et est quand même rejeté par le réseau Peppol, le problème se situe au niveau des règles métier ou de la transmission. Cette conversation revient à votre point d'accès ou à votre éditeur logiciel, qui peut voir le rapport de validation officiel — apportez-lui son message d'erreur, car il nomme la règle exacte qui s'est déclenchée.

Ce que ce contrôle vérifie réellement

Ceci confirme que le fichier est un XML bien formé, possède une racine UBL Invoice, et contient les champs nécessaires à une facture lisible : un numéro de facture, des dates, les parties fournisseur et client, les lignes de facturation et les totaux. Il s'agit d'un contrôle structurel de base, pas de la validation Schematron officielle Peppol BIS Billing 3.0 — il ne détectera pas toutes les violations de règles métier (par exemple des totaux de TVA qui ne s'additionnent pas correctement), seulement si la structure est globalement exploitable.