L'IDR (Intelligent Document Recogniser) reconnaît automatiquement les données principales d'une facture PDF et les convertit en champs structurés dans l'e-facture. Les champs reconnus dépendent de votre abonnement et de la configuration.

Lors de chaque conversion PDF, les champs suivants sont reconnus automatiquement :

Certains formats fournisseur peuvent amener l’IDR à récupérer un autre champ que le numéro de facture, par exemple un identifiant de transaction au lieu du numéro de facture réel. Un exemple connu est celui des factures Meta (Facebook), où le numéro de facture apparaît en bas d’une page ultérieure du PDF et où l’identifiant de transaction est reconnu de façon plus prominente. Autres cas: le numéro d'entreprise du fournisseur, un numéro de commande/PO ou une référence bancaire/de paiement (par exemple une référence bancaire) à la place du vrai numéro de facture, ce qui entraîne un numéro de facture incorrect en aval vers Coda ou le système ERP. Cette dernière variante peut aussi bloquer un avoir comme doublon (voir Facture en double). Il s'agit d'une erreur de sélection de champ dans la reconnaissance, distincte de la reconnaissance correcte d'une référence de paiement comme champ PaymentID séparé (voir Prélèvement & compte G) : là, la référence de paiement n'écrase pas le numéro de facture, ici elle est reconnue par erreur à sa place.

Cela peut être amélioré pour le format fournisseur concerné. La reconnaissance du numéro de facture n’est pas configurable par le client, mais est optimisée en interne par un membre du support via détection d’outliers, regex et conseils par fournisseur ou format. Aucun changement de feuille de route n’est requis ; il s’agit d’une optimisation ciblée de la fonctionnalité existante. Signalez ce cas au support — sur la base du signalement, l’équipe ajoute un conseil spécifique au fournisseur afin que les futures factures de ce format reçoivent le bon numéro de facture.

Comment fonctionne la reconnaissance en arrière-plan (SampleStore) ? L'IDR utilise pour cela le SampleStore : une base de données de modèles de reconnaissance par fournisseur. Le processus se déroule en trois étapes : (1) recherche de numéros correspondant à un modèle RegEx dans le SampleStore, (2) comparaison avec des exemples précédents du même fournisseur (longueur, structure, tirets, points, underscores, cohérence), (3) ajustement auto-apprenant sur la base de nouvelles factures. Le support enrichit le SampleStore avec des exemples et éventuellement un RegEx après un signalement.

Numéro court ou différent au lieu d'un modèle à préfixe plus long. Lorsque les factures d'un fournisseur ont normalement un préfixe fixe et une longueur fixe, l'IDR reconnaît parfois un numéro plus court ou différent sans ce préfixe. Si le modèle (préfixe, longueur, structure) est déjà clair à partir du signalement, la première étape consiste à ajuster directement le SampleStore ou le RegEx pour ce fournisseur ; un exemple PDF ou XML sert alors de preuve, non d'étape préalable obligatoire. Si la reconnaissance fonctionnait correctement auparavant et est redevenue incorrecte avec le temps, la même approche s'applique : vérifier et ajuster le SampleStore pour ce fournisseur, ce qui n'indique pas un défaut de produit.

Pour l'investigation, le XML de la plateforme provenant de la boîte de réception est le fichier utile : il contient la trace de reconnaissance IDR. Un XML que vous exportez vous-même depuis votre système ERP (par exemple AFAS) une fois le numéro de facture déjà corrigé manuellement manque généralement de ce bloc IDR et n'affiche que le numéro déjà corrigé — ce fichier n'est alors pas adapté pour analyser l'erreur de reconnaissance.

Texte masqué ou transparent dans le PDF (réutilisation de modèle). Certains fournisseurs réutilisent un ancien PDF de facture comme modèle pour de nouvelles factures. D'anciennes dates ou d'anciens numéros de factures peuvent rester sous forme de texte résiduel invisible ou transparent dans la couche de texte du PDF. L'IDR utilise l'OCR hybride : en plus de l'image visible, la couche de texte du PDF est également lue. Sur une capture d'écran ou à l'écran, vous ne voyez que les lignes visibles, mais la reconnaissance voit la couche de texte complète y compris le texte résiduel masqué. Cela peut être la cause lorsqu'un ancien et un nouveau numéro de facture ou date se mélangent dans la reconnaissance. Si vous suspectez ce modèle, demandez toujours le PDF original : une capture d'écran ne suffit pas, car la couche de texte y est absente. Copiez ensuite le texte du fichier dans un éditeur de texte brut pour vérifier l'écart par rapport à l'affichage visible.

Symptôme secondaire : facture marquée à tort comme doublon. Une facture suivante peut ainsi être marquée à tort comme doublon, car l'IDR réutilise ou fait correspondre un numéro de facture incorrect (caché). Il s'agit d'une conséquence de l'erreur de reconnaissance sous-jacente, pas d'un problème distinct : corrigez d'abord la reconnaissance de la couche de texte comme décrit ci-dessus, plutôt que de traiter la détection des doublons de manière isolée (voir Comment une facture en double est-elle reconnue ?).

Variantes de recherche : « numéro d'entreprise différent dans le XML », « numéro d'entreprise facture vs XML », « numéro d'entreprise expéditeur diffère », « fournisseur numéro d'entreprise incorrect dans XML », « numéro d'entreprise fournisseur XML différent de la facture », « ID de partie expéditeur XML PDF », « AccountingSupplierParty numéro d'entreprise ».

Il arrive que le numéro d'entreprise du fournisseur (ou un autre ID de partie, comme un numéro de TVA) dans le bloc expéditeur du XML diffère de ce qui figure sur le PDF original, ou que la reconnaissance associe la facture au mauvais fournisseur. Il s'agit d'une erreur de reconnaissance de champ sur l'identifiant du fournisseur, comme pour les montants, la devise ou le numéro de facture.

Attention — ce n'est pas la même chose que « numéro d'entreprise lu comme numéro de facture ». Dans cet autre cas (voir ci-dessus), le numéro d'entreprise est reconnu par erreur dans le champ du numéro de facture. Ici, il s'agit de l'ID de partie dans le bloc expéditeur lui-même, qui ne correspond pas au PDF. Ce sont deux problèmes de reconnaissance distincts.

Que pouvez-vous faire ? Il n'existe pas d'option en libre-service pour modifier le XML. Rassemblez le PDF original et le XML associé (téléchargeable depuis le document dans la boîte de réception) et/ou l'ID du document de la tâche de conversion, et signalez-le au support. Sur cette base, l'équipe ajuste la reconnaissance ou la correspondance fournisseur. Comme pour les autres erreurs de reconnaissance, aucun délai strict ne s'applique ici.

Variantes de recherche : « devise pas correctement reconnue », « devise mal reconnue », « mauvaise devise IDR », « SEK au lieu de NOK », « currency wrong PDF », « reconnaissance devise facture », « PDF devise incorrect », « devise mal lue ».

La devise est un champ reconnu en standard (voir tableau ci-dessus) et relève des mêmes erreurs de reconnaissance génériques PDF→XML que le numéro de facture ou le montant : l'IDR peut reconnaître incorrectement le code de devise ISO par rapport au PDF (par exemple SEK au lieu de NOK). Ce n'est pas une fonctionnalité séparée et ce n'est pas un problème autonome, mais la même question de reconnaissance que pour les autres champs.

Que pouvez-vous faire ? Signalez l'écart au support et fournissez le PDF original ainsi que le XML associé (provenant de la boîte de réception), ou l'ID du document de la tâche de conversion. Sur cette base, l'équipe optimise la reconnaissance pour le format fournisseur concerné. Comme pour les autres erreurs de reconnaissance, aucun délai strict ne s'applique ici.

Avec l’abonnement Professional, des champs supplémentaires sont reconnus :

Variantes de recherche : "date américaine", "date de facture américaine", "date fournisseur US", "date de facture USA", "date de facture MDY", "MDY au lieu de DMY", "format de date États-Unis", "date de facture mal reconnue fournisseur américain", "American date format invoice date", "US supplier date format MDY".

L'IDR reconnaît les dates sur les factures PDF et les convertit au format de date UBL standard (YYYY-MM-DD). Comme les notations de date varient selon les pays, l'IDR détermine, à partir du pays du fournisseur, comment interpréter les dates ambiguës :

• États-Unis : MDY (mois-jour-année). La date 03/11 est interprétée comme le 11 mars.
• Tous les autres pays : DMY (jour-mois-année). La date 03/11 est interprétée comme le 3 novembre.

Vous voyez, chez un fournisseur des États-Unis, une date de facture que vous pensez mal reconnue ? Vérifiez d'abord cette règle de pays avant de la signaler comme une erreur de reconnaissance de champ : chez un fournisseur américain, 03/11 correspond par exemple au 11 mars, pas au 3 novembre. Si la notation de date n'est pas l'explication, il s'agit d'une autre question de reconnaissance (voir ci-dessus).

Si la détection automatique du pays ne suffit pas, un indice spécifique pour le format de date peut être ajouté par fournisseur via le mécanisme de hints.

Tip : les dates mal interprétées (par exemple 03/11 comme 11 mars au lieu du 3 novembre) relèvent presque toujours de la reconnaissance, pas de la plateforme. La plateforme affiche toujours la date telle qu'elle figure dans l'UBL.

Avec l'abonnement Professional, l'IBAN reconnu est comparé au verification store : une base de données d'IBAN précédemment validés manuellement par fournisseur. Si l'IBAN sur la facture diffère de ce qui a été vérifié auparavant, cela est signalé. Cela aide à détecter les factures fictives ou les coordonnées bancaires modifiées.

Attention : selon la norme européenne EN16931, l'IBAN sur une facture sert d'abord à identifier le fournisseur, pas comme instruction de paiement. Un IBAN modifié doit toujours être validé d'abord dans les données de base de votre système financier avant tout paiement.

Outre les références standard (numéro de commande, numéro de contrat, numéro de projet), d'autres références peuvent être configurées spécifiquement par fournisseur, par exemple des codes budgétaires, des codes de responsable budgétaire ou des références internes. Il s'agit d'une prestation sur mesure mise en place sur la base d'une carte à cases.

La reconnaissance des références configurables s'appuie sur un mécanisme à trois niveaux :

1. Regex : validation de format pour garantir que la référence extraite correspond exactement au format attendu
2. Outlier detection : détection statistique des valeurs peu probables
3. Hints : données d'entraînement générées automatiquement à partir des corrections par l'équipe QC

Tip : le numéro de commande d'achat est la référence la plus utilisée et figure sur la facture chez la plupart des fournisseurs. Si un fournisseur ne peut pas renseigner un champ de référence donné dans son logiciel, il est peu utile de l'exiger. Utilisez alors le numéro de commande d'achat comme référence principale.

Attention : numéro de commande d'achat, numéro de contrat et numéro de projet sont des champs standard Professional, mais la reconnaissance ne s'active qu'après une configuration unique par le support, par client/fournisseur (sur la base d'au moins 5 factures exemples, éventuellement complétée par une regex). Contactez le support et fournissez de préférence une facture exemple.

Recevez-vous via l'API la réponse informative Order Reference detection skipped as Sample store is empty ou Contract Reference detection skipped as Sample store is empty ? Ce n'est pas une erreur de traitement. L'IDR ne remplit ces références qu'une fois que le Customer Sample Store de votre endpoint contient des références exemples pour la correspondance. Si le store est vide, seule cette détection de référence est ignorée ; les autres champs et fonctionnalités sont reconnus normalement.

Solution : fournissez quelques exemples de numéros de commande ou de références de contrat (au moins 3 caractères par exemple) exactement comme ils apparaissent sur les factures, afin que le support puisse les configurer dans le Customer Sample Store. Ensuite, une correspondance d'étiquette s'applique d'abord (par exemple « Your order number »), avec une regex en secours. Un Remote Starter est également disponible via les ventes pour la mise en place de la reconnaissance du numéro PO.

Non, pas directement dans la plateforme. Vous ne gérez pas vous-même le Customer Sample Store, les règles de formatage ou la RegEx pour la reconnaissance du numéro de commande ; c'est le support eConnect qui met cela en place.

En revanche, indirectement, en :

• faisant facturer vos fournisseurs avec un format de référence de commande clair et uniforme (voir bonne pratique ci-dessous) ;
• partageant la connaissance du format (préfixe, longueur fixe, structure) avec le support ;
• fournissant, après un échec de reconnaissance, le PDF original ou l'ID de document ainsi que le bon numéro de commande, afin que le support puisse mettre à jour le Sample Store.

Bonne pratique pour le format de la référence de commande sur le PDF :

• indiquez la référence de commande de préférence une seule fois sur la facture, sans la répéter à plusieurs endroits ;
• utilisez une étiquette courante, par exemple Numéro de commande, Numéro PO, Numéro de commande d'achat ou Your order number ;
• séparez l'étiquette et le numéro par un espace ou un signe de ponctuation, par exemple Numéro de commande : 420000007 au lieu de PO420000007 ;
• conservez une structure fixe et de préférence un emplacement fixe sur la facture.

Voir aussi Erreurs de soumission en cas de facture bloquée ou rejetée suite à un numéro de commande mal reconnu.

Selon la norme européenne EN16931, une référence (buyer reference) est obligatoire sur une facture électronique ; il s'agit souvent d'un numéro de commande ou d'une autre référence du destinataire. Un expéditeur peut placer une valeur incorrecte dans ce champ.

eConnect ne rejette pas une facture sur la référence par défaut. Une facture ne satisfait aux règles de base de la norme européenne que si aucune référence n'est présente. Le fait qu'une facture soit rejetée en raison d'une référence inconnue ou incorrecte dépend de la configuration du destinataire : dans une configuration spécifique du destinataire, une facture peut être rejetée si la référence est inconnue. Il s'agit donc d'une propriété de la configuration réceptrice, et non du traitement eConnect standard.

Conseil : si vous souhaitez rejeter des factures sur des références manquantes ou inconnues, configurez cela via RBE (Rule Based Enrichment) sur l'endpoint récepteur.

Le numéro de facture (champ UBL cbc:ID, BT-1) est obligatoire dans EN 16931, UBL BIS Billing 3.0 et NLCIUS pour les factures régulières. Cependant, l'IDR traite un flux de documents mixte : factures régulières, avoirs, notes de frais et reçus. Les reçus relèvent du régime de facturation simplifiée (transactions jusqu'à environ 100 € TTC), pour lequel l'administration fiscale n'établit pas de numéro de facture comme exigence légale. Rejeter une facture sur un numéro de facture manquant exclurait tous les reçus et notes de frais du traitement.

C'est pourquoi la pipeline IDR génère automatiquement un numéro de substitution lorsqu'aucun numéro de facture ne peut être extrait du document lors de la reconnaissance. Le champ cbc:ID (BT-1) est alors rempli avec la structure :

YYYYMMDDHHmmss-NOTFOUND

L'horodatage est le moment du traitement par la pipeline IDR, non la date sur le document lui-même. Exemple : 20240315143022-NOTFOUND.

Le filtrage est possible à deux niveaux :

1. RBE (Rule Based Enrichment) : configurez une règle qui vérifie si BT-1 (cbc:ID) se termine par -NOTFOUND. Sur cette base, le document peut être mis en attente pour examen manuel, redirigé vers une boîte de réception séparée ou rejeté automatiquement.
2. Systèmes propres (ERP/logiciel comptable) : une recherche de chaîne directe ou une expression régulière sur -NOTFOUND dans le champ cbc:ID est suffisante.

Avec la reconnaissance de lignes, les lignes individuelles de facture sont également reconnues : description, prix unitaire, quantité, montant de ligne et champs de référence par ligne. Il s'agit d'une fonctionnalité distincte que vous pouvez activer vous-même via Mon Environnement.

Vous voulez savoir comment la reconnaissance fonctionne techniquement ? Lisez Comment fonctionne Scan & Reconnaissance (IDR/OCR) ?.

• Comment fonctionne Scan & Reconnaissance (IDR/OCR) ?
• Reconnaissance de lignes : reconnaître automatiquement les lignes de facture
• Identification fournisseur via Purple Pages
• Valeurs fictives dans l'e-facture