Lorsque vous soumettez une facture chez eConnect, le document passe par une série d'étapes de traitement. Le déroulement exact de ce traitement dépend du type de fichier (XML ou PDF) et de la qualité du fichier fourni. Cet article explique ce qui se passe en coulisses.

eConnect dispose de deux routes de traitement fondamentalement différentes :

Traitement XML (route directe) : si vous soumettez une facture UBL valide (SI-UBL 2.0, Peppol BIS Billing 3.0 ou un autre format XML pris en charge), elle est traitée directement. La plateforme lit les données structurées du XML, les valide et route le document vers le destinataire. C'est la route la plus rapide et la plus fiable.

Traitement PDF (conversion via IDR) : si vous soumettez une facture PDF, elle est traitée par l'Intelligent Document Recogniser (IDR). L'IDR extrait les données de facturation via l'OCR et la reconnaissance de motifs, et produit une facture UBL basée sur les données reconnues. Ce processus est intrinsèquement moins fiable que le traitement XML direct, car il dépend de la qualité du PDF.

Conseil : la fourniture UBL est toujours préférable au PDF. C'est plus rapide, moins cher et plus fiable. Demandez à votre fournisseur ou logiciel si l'export UBL est disponible.

Lors de la soumission d'un fichier XML, eConnect effectue les étapes suivantes :

La plateforme reconnaît automatiquement quel format suit le fichier sur la base du CustomizationID et du schéma XML. Les formats pris en charge comprennent entre autres NLCIUS, BIS Billing V3, XRechnung, CII et Factur-X.

La facture est validée par rapport aux règles du profil reconnu. Cela comprend :

• Validation du schéma : le XML respecte-t-il la structure du schéma UBL 2.1 ou CII ?
• Règles métier : les calculs sont-ils corrects ? Les champs obligatoires sont-ils remplis ? Les valeurs des listes de codes correspondent-elles ?
• Règles nationales : les règles NL-R-, DK-R- ou autres règles nationales sont-elles respectées ?

Tip : Vous recevez le message qu'aucune "règle de validation" n'a été trouvée ? Cela signifie généralement que le CustomizationID dans votre XML est absent ou non reconnu. Sans profil identifiable, le validateur ne peut pas appliquer les règles métier. Vérifiez que votre facture contient un CustomizationID valide, comme celui de NLCIUS ou BIS Billing V3.

Une caractéristique notable du traitement eConnect est la réparation automatique des fichiers XML. Via des transformations XSL, les erreurs connues sont corrigées. La plateforme accepte en principe tout UBL ; les champs non essentiels manquants sont remplis avec des valeurs par défaut. Cette fonction de réparation est continuellement améliorée sur la base des retours clients et est prête pour la production.

Exemples de réparations automatiques :

• Les champs optionnels manquants sont complétés avec des valeurs par défaut correctes
• Les erreurs de format connues dans les champs d'identification sont corrigées
• Les coordonnées incomplètes sont complétées (si le champ ElectronicMail du fournisseur est vide, eConnect remplit automatiquement support@econnect.eu, afin que les factures rejetées arrivent tout de même chez l'expéditeur)

Si le destinataire prend en charge un format différent du format source, le PSB transforme automatiquement le document. Une facture NLCIUS peut par exemple être transformée en XRechnung si le destinataire est une administration publique allemande. Cela est possible parce que tous les formats pris en charge sont basés sur le même modèle sémantique (EN 16931).

Technique : lors du téléchargement d'une facture via l'API, vous pouvez spécifier le format de réception souhaité via le paramètre targetDocumentTypeId. Le PSB transforme alors le document vers ce format.

eConnect ne reconnaît jamais une commande de vente (document de commande) comme une facture et ne la convertit pas automatiquement en facture. Si vous soumettez une commande de vente à un endroit où une facture est attendue, le document sera rejeté.

Le fournisseur doit lui-même fournir un document de facture correct : une UBL Invoice avec le InvoiceTypeCode correct. eConnect ne modifie pas le document source et n'effectue pas cette conversion.

Exception -- orderflip : via la fonction orderflip, les données de commande peuvent servir de base à la préparation d'une facture provisoire (draft). Il s'agit d'une action distincte de l'utilisateur, non d'une conversion automatique d'une commande de vente en facture définitive. Le fournisseur doit lui-même compléter cette facture provisoire et la soumettre comme document de facture définitif (UBL Invoice + InvoiceTypeCode).

Remarque : ne confondez pas la reconnaissance du type de document avec la reconnaissance de référence. Un numéro de commande de vente qui doit être reconnu sur une facture (comme OrderReference ou order_reference) est un champ de référence, non le type de document lui-même. eConnect lit ce numéro de commande dans la facture et le lie comme référence, sans pour autant changer le type du document.

ZUGFeRD et Factur-X sont des formats de facture hybrides : un fichier PDF/A-3 contenant une facture CII XML intégrée. Pour ces documents, la plateforme tente d'abord d'extraire le XML intégré du PDF. Si le XML est valide, il est traité directement, comme une facture XML régulière. Ce n'est que si le XML intégré s'avère non valide que le système passe au traitement OCR via l'IDR.

Une facture ZUGFeRD qui passe les validateurs externes mais est néanmoins traitée via l'OCR indique un problème avec le XML intégré dans le processus de validation eConnect. Dans ce cas, vous pouvez contacter le support.

Technique : la plateforme legacy ne peut stocker que des factures UBL valides. Lorsqu'une facture ZUGFeRD est traitée via l'IDR comme PDF, la sortie IDR doit d'abord être transformée en UBL valide (BIS Billing V3 ou NLCIUS). Si cette transformation échoue parce que les données source ne contiennent pas suffisamment de champs pour une facture UBL valide, la plateforme ne peut pas stocker la facture. Dans le PSB/Control, ce problème est moindre, car les factures y sont stockées dans leur format d'origine et ne sont transformées qu'à la livraison.

Si vous soumettez un fichier XML non valide, le système passe automatiquement au PDF joint. Voici comment cela fonctionne :

1. La plateforme tente d'abord de traiter le composant XML.
2. Si l'UBL n'est pas valide, le PDF joint est utilisé comme fallback.
3. Le PDF est traité via la route IDR (OCR et reconnaissance de motifs).

Ce mécanisme garantit que la facture est toujours traitée, même si le XML contient des erreurs. C'est toutefois une route plus coûteuse et plus lente que le traitement XML direct.

Si un UBL est rejeté (car non valide), eConnect traite tout de même les autres pièces jointes du même e-mail, comme un PDF. L'expéditeur reçoit alors un e-mail avec :

• la notification que la facture UBL ne sera pas traitée, y compris le message d'erreur ;
• la notification que les autres pièces jointes de l'e-mail seront traitées.

Remarque : ce message d'erreur sur la facture XML ne peut pas être supprimé tant que d'autres pièces jointes du même e-mail sont traitées.

Exemple -- BR-AE-10 (Autoliquidation) : un UBL avec la catégorie de TVA AE (Autoliquidation) sans BT-121 (code du motif d'exonération de TVA) ni BT-120 (texte du motif d'exonération de TVA) déclenche la règle de validation BR-AE-10. Pour la catégorie AE, au moins un de ces champs doit être présent. L'UBL est rejeté, un PDF joint est traité via le fallback IDR, et le message d'erreur concernant l'UBL reste visible dans l'e-mail à l'expéditeur.

Exemple -- BR-CO-18 / BR-Z-01 / BR-Z-05 (Zero rated / taux zéro) : un UBL avec catégorie de TVA Zero rated (Z) sur une ligne de facture, une majoration ou une remise document, sans ventilation TVA complète correspondante (BG-23), déclenche la règle de validation BR-CO-18 (ventilation manquante), BR-Z-01 (aucune ligne de ventilation avec catégorie Z) ou BR-Z-05 (taux de TVA pour la catégorie Z différent de 0). Le dual-path s'applique ici aussi : l'UBL est rejeté sur cette (ces) règle(s), tandis qu'un PDF joint dans le même e-mail est néanmoins traité et arrive dans la boite de réception. La faute se trouve dans l'UBL soumis par l'expéditeur ou son logiciel -- eConnect n'ajuste pas les ventilations TVA. La correction nécessite une nouvelle UBL corrigée (ventilation Z complète, taux 0, lignes et totaux cohérents) ; fournir uniquement le PDF n'est pas un substitut structurel sur le chemin Peppol/UBL natif. Détail first-line : support/troubleshooting-sending.md § calcul total TVA.

SI-UBL 1.2 (Simplerinvoicing 1.2) a été définitivement abandonné au 1er janvier 2024. Les factures dans ce format sont rejetées sur le réseau Peppol. eConnect peut parfois encore transformer les anciens fichiers SI reçus par e-mail en NLCIUS valide, à condition que les données essentielles soient présentes. En cas de données manquantes, la validation peut échouer.

Attention : Recevez-vous des messages d'erreur lors de l'envoi de factures ? Vérifiez si votre logiciel génère encore du SI-UBL 1.2. Si oui, demandez à votre fournisseur une mise à niveau vers NLCIUS/SI-UBL 2.0 ou BIS Billing V3.

Le traitement diffère légèrement entre la plateforme legacy et le PSB/Control :

• Plateforme legacy : une facture est toujours d'abord transformée en UBL valide (BIS Billing V3 ou NLCIUS) avant d'être stockée. Si cette transformation échoue, la facture ne peut pas être stockée.
• PSB/Control : une facture est validée et stockée à la réception. La transformation n'a lieu que plus tard si nécessaire, par exemple lors de la livraison à un système ERP. Cela signifie qu'une facture peut être stockée dans le PSB, mais qu'une erreur de transformation peut survenir ultérieurement si le format cible ne peut pas être généré.

eConnect traite les champs UBL à la réception tels que fournis dans l'UBL source et n'en modifie pas le contenu. Il n'existe aucun mappage de champs configurable par le client côté destinataire pour réécrire les valeurs fournies. Les valeurs manquantes ou incorrectes doivent être corrigées par l'expéditeur dans l'UBL source. eConnect corrige uniquement les erreurs de format techniques connues et complète les champs optionnels non essentiels avec des valeurs par défaut (voir réparation XML automatique ci-dessus).

Un exemple concret avec une note de crédit intracommunautaire entrante (champs de livraison) :

Les deux champs sont traités par eConnect à la réception tels que fournis. BT-80 n'est obligatoire que lorsqu'un groupe Deliver-to-address (BG-15) est inclus dans la facture. eConnect ne fournit pas de mappage côté destinataire pour réécrire BT-72 ou BT-80. Les corrections des valeurs manquantes ou incorrectes sont effectuées par l'expéditeur dans l'UBL source.

Une adresse sur l'affichage de la facture qui montre un mélange de données d'adresse domiciliaire et de boîte postale n'est pas un mélange créé par eConnect à la réception. eConnect transmet les champs d'adresse UBL (cac:PostalAddress) 1:1 et ne réécrit ni ne normalise les adresses. Si l'UBL source mélange les composants d'adresse domiciliaire et de boîte postale dans un seul bloc PostalAddress, l'affichage suit cette source.

Un schéma de mélange typique dans l'UBL source :

• cbc:StreetName = rue et numéro (adresse domiciliaire)
• cbc:AdditionalStreetName = code postal de l'adresse domiciliaire, dans le mauvais champ
• cbc:BuildingName = Boîte postale N (le champ canonique de boîte postale en UBL est cbc:Postbox)
• cbc:PostalZone = code postal de la boîte postale

L'affichage de la facture montre alors souvent la ligne de rue avec PostalZone/CityName, produisant visuellement une "adresse mélangée" sans qu'eConnect ne combine ni ne corrige de champs. Les deux composants d'adresse peuvent être corrects individuellement, mais leur combinaison dans un bloc d'adresse partagé avec des codes postaux croisés est une erreur de mapping dans l'UBL source.

Action : ouvrez l'UBL source et vérifiez les éléments enfants PostalAddress de la partie concernée. Le fournisseur corrige le mapping : soit une adresse domiciliaire cohérente (StreetName avec le PostalZone correspondant), soit une boîte postale dans le champ de boîte postale correct (Postbox) avec le code postal correspondant -- pas les deux mélangés avec des codes postaux croisés. Une fois l'UBL source correcte, l'affichage se résout de lui-même.

Exemple -- facture de crédit « Payee/destinataire = propre organisation » : lors d'un crédit versus débit, AccountingSupplierParty et AccountingCustomerParty ne s'inversent pas. La direction (à payer ou à recevoir) est dans le type de document et le signe de PayableAmount, pas dans des parties inversées. eConnect n'ajuste pas les rôles des parties et ne réapplique pas automatiquement une correction Payee antérieure si l'UBL source est déjà correct -- même principe de passthrough que ci-dessus. Détaillé avec exemple : Variantes de note de crédit.

Variantes de recherche : "facture de crédit Payee", "facture de crédit Payee propre organisation", "Supplier Customer inverser crédit".

Exemple -- IBAN ou compte bancaire (PaymentMeans) lors d'une réception via Peppol : l'IBAN et les autres données de paiement sur une facture reçue via Peppol proviennent de l'UBL source du fournisseur, généralement dans cac:PaymentMeans / cac:PayeeFinancialAccount (mode de paiement et numéro de compte ; éventuellement un autre bénéficiaire via PayeeParty, par exemple en cas d'affacturage). eConnect ne remplit pas lui-même ce numéro de compte et ne modifie pas le contenu de la valeur fournie -- le même principe de passthrough 1:1 s'applique ici aussi. Si l'IBAN sur un affichage PDF diffère des données XML structurées, la différence réside dans ce que le fournisseur a saisi dans l'UBL par rapport au PDF, non dans une modification par eConnect.

Action en cas d'IBAN erroné ou différent : contactez le fournisseur pour obtenir une e-facture corrigée avec l'IBAN correct dans l'UBL. Vérifiez via un téléchargement XML si le champ PaymentMeans/IBAN diffère réellement. Vérifiez également le canal de soumission : l'icône Peppol et l'icône de scan (Scan & Reconnaissance) sur la plateforme montrent la différence entre soumission XML et reconnaissance PDF (voir Icônes de la plateforme). Pour une e-facture via Peppol, il n'y a pas de reconnaissance IDR/scan sur l'IBAN -- ce chemin ne s'applique qu'à la soumission PDF via Scan & Reconnaissance.

Exemple -- plusieurs comptes bancaires enchâînés dans un seul champ PaymentMeans : parfois, la correspondance fournisseur échoue sur l'IBAN car dans l'UBL transmise, plusieurs numéros de compte sont enchâînés dans cac:PayeeFinancialAccount/cbc:ID (par exemple IBAN1 directement suivi d'IBAN2, en une seule chaîne au lieu de blocs de compte séparés), et éventuellement aussi plusieurs codes BIC enchâînés dans cac:FinancialInstitutionBranch/cbc:ID. Cela provient de l'UBL source ou du mappage du fournisseur : eConnect transmet le XML 1:1 et ne sépare ni ne normalise IBAN/BIC sur le chemin Peppol/XML. Pour la même facture via PDF (Scan & Reconnaissance), l'OCR reconnaît généralement les numéros de compte comme des comptes séparés et corrects dans l'UBL générée -- la différence réside dans le chemin source (UBL mal concaténée versus reconnaissance OCR), non dans une erreur aléatoire de la plateforme.

Action : vérifiez le canal de soumission (icône Peppol versus icône de scan). Pour une soumission via Peppol/XML, le passthrough ci-dessus s'applique : affichez le champ PaymentMeans via un téléchargement XML et faites corriger l'UBL source par le fournisseur avec des blocs PaymentMeans/PayeeFinancialAccount séparés, ou un seul IBAN primaire correct par bloc. Si un PDF arrive aussi du même expéditeur, l'OCR peut fournir temporairement des IBAN utilisables et séparés -- la solution structurelle reste la correction de l'UBL source. Ne confondez pas ceci avec la validation IDR-IBAN via le verification store : c'est un chemin de reconnaissance PDF distinct.

Correction sur mesure via consulting (pas de self-service) : eConnect peut, sur la base de consulting, configurer le RBE (rule/business engine) pour des corrections automatiques dans le flux. Ceci est un travail sur mesure via le consulting eConnect, pas quelque chose que le client configure lui-même. Il n'existe pas de réécriture en self-service configurable par le client des champs UBL fournis côté destinataire.

Vous souhaitez vérifier si votre fichier XML est correctement traité ? Utilisez le validateur eConnect gratuit pour tester votre facture au préalable.

• La structure d'une facture UBL
• Quelle est la différence entre XML, UBL, BIS Billing V3 et NLCIUS ?
• Champs d'envoi importants dans UBL
• SEEF : la Standaard Energie eFactuur
• Télécharger des fichiers XML d'exemple
• De la sémantique à la syntaxe