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.

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-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é.

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".

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