Lors de l'envoi d'une facture via la plateforme eConnect, il peut arriver que vous receviez un message d'erreur. La plupart des erreurs sont liées à des données manquantes ou incorrectes dans la facture. Vous trouverez ci-dessous les messages les plus courants, leurs causes et comment les résoudre.

Ce message d'erreur générique est déclenché par la validation pré-envoi de l'interface de la plateforme. La plateforme vérifie avant l'envoi si la valeur de l'identifiant (p. ex. OINO, numéro d'immatriculation) correspond au format attendu. Si cette vérification échoue, ce message d'erreur apparaît.

Exemple courant : le schemeID 0190 (OINO) exige exactement 20 chiffres. Si la valeur contient un préfixe - par exemple NL:OINO:00000001001932779000 au lieu de simplement 00000001001932779000 - la validation échoue.

Remarque : cette erreur peut également survenir pour des factures créées via l'API, pas uniquement pour les factures créées manuellement.

Solution : vérifiez les valeurs d'identifiant et supprimez tout préfixe ou caractère non valide. La valeur doit exactement correspondre au format attendu pour le schemeID (p. ex. 20 chiffres pour OINO, 8 chiffres pour numéro d'immatriculation).

Règle générale -- saisissez uniquement la valeur numérique ; la plateforme ajoute automatiquement le préfixe schemeID. Cette règle s'applique à tous les schémas d'identification, pas seulement OINO. Si l'utilisateur saisit également le préfixe manuellement (p. ex. 0088:1234567890123 alors que le schéma est déjà réglé sur GLN/0088), la validation du format échoue. Exemple GLN (schemeID 0088, GS1) : sélectionnez le schéma GLN et saisissez uniquement les chiffres GLN dans le champ valeur -- sans 0088: devant.

Si un fournisseur place une apostrophe avant le numéro OIN dans le XML (un artefact Excel connu), le routage Peppol échoue. Le système hérité reconnaît la facture et la livre en interne - le destinataire ne voit pas de facture dans sa boîte de créanciers mais reçoit un e-mail de notification avec un lien.

Solution : demandez au fournisseur de saisir le numéro OIN sans apostrophe dans le XML et de vérifier les paramètres d'exportation Excel.

En cas d'erreurs d'envoi depuis 4PS, la cause n'est souvent pas immédiatement claire. Ne supposez pas d'emblée qu'une connexion PSB manquante (Peppol Service Bus) en est la cause.

Étapes :

1. TechSupport établit la cause. Ne redirigez pas directement vers les ventes sur la base d'une supposition.
2. La cause est une connexion PSB active manquante chez eConnect ? L'étape suivante est alors les ventes pour l'onboarding PSB. Ne donnez pas au client de conseils de configuration 4PS - sans connexion PSB il n'y a rien à configurer.
3. La cause est autre chose ? Traitez-la via le message d'erreur ou la solution correspondant sur cette page (ou dans les pages d'intégration 4PS).

En résumé : le diagnostic par TechSupport passe toujours avant la route commerciale. La route commerciale (onboarding PSB) ne s'applique que lorsque TechSupport a établi qu'une connexion PSB manquante en est la cause.

La plateforme valide chaque facture selon les normes Peppol et NLCIUS en vigueur avant l'envoi. Les codes d'erreur commençant par BR (Business Rule) indiquent quelle règle n'a pas été respectée.

Votre propre organisation (le fournisseur) n'est pas correctement sélectionnée dans la facture. Cela se produit lorsque le champ fournisseur a été modifié manuellement ou que l'organisation n'est pas encore activée.

Solution : Cliquez sur l'icône de modification à côté de « Fournisseur » et sélectionnez à nouveau votre organisation. Si votre organisation n'est pas encore activée, faites-le d'abord via Ajouter et activer une organisation.

Vous avez ajouté une pièce jointe avec un type MIME non autorisé dans la validation Peppol BIS Billing V3 actuelle. Les types de pièces jointes autorisés sont (BT-125) :

application/xml n'est pas autorisé comme type MIME de pièce jointe dans la validation BIS Billing V3 actuelle. XML en pièce jointe appartient à EN 16931-1:2026 et à une future version de Peppol (probablement BIS Billing 4.0) - n'ajoutez pas de pièce jointe XML pour résoudre BR-CL-24.

Cause fréquente (Business Central, Unit4 ERPx et autres ERP) : L'ERP intègre automatiquement les pièces jointes liées à la facture validée, ou exporte des blocs UBL incomplets. Un type de pièce jointe non pris en charge (par ex. un document Word) provoque BR-CL-24 ; BT-122 manquant mène à BR-52 ; virement sans IBAN à BR-61 ; balises vides à PEPPOL-EN16931-R008. Plusieurs codes en même temps indiquent la charge utile/l'export ERP, pas une panne d'environnement eConnect. Validez à l'avance via le Document Validator.

Solution :

1. Vérifiez les pièces jointes associées à la facture dans l'ERP (Business Central : Facture vente validée > Pièces jointes).
2. Supprimez ou remplacez les pièces jointes avec un type non autorisé -- par ex. convertissez un document Word en PDF.
3. Renvoyez la facture.

BR-52 apparaît lorsque le bloc document complémentaire (BG-24) est présent sans Supporting document reference (BT-122). Cela arrive notamment avec l'export UBL ERP, par ex. Unit4 ERPx en test ou pilote.

Solution : renseigner un ID (BT-122) par pièce jointe ou référence de document, ou omettre le bloc de pièce jointe incomplet. La correction se fait dans l'export UBL de l'ERP, pas dans eConnect.

BR-61 apparaît lorsque Payment means type code (BT-81) est un virement (par ex. SEPA ou local/non-SEPA credit transfer, codes comme 30 ou 58) sans Payment account identifier (BT-84, généralement IBAN). Il s'agit de EN 16931 BR-61.

Solution : renseigner l'IBAN ou le numéro de compte dans les données de paiement, ou ne pas envoyer de code de virement tant qu'aucun numéro de compte n'est inclus.

PEPPOL-EN16931-R008 apparaît lorsque l'UBL contient des éléments XML vides (balises vides).

Solution : omettre entièrement les champs sans valeur dans l'export UBL ; ne pas envoyer de balises vides. La correction se fait dans l'export ERP/UBL, pas dans eConnect.

L'unité saisie pour une ligne de facture n'est pas reconnue comme un code UN/ECE valide.

Solution : Utilisez une unité standard de la liste de sélection, comme « Pièces » (EA), « Heures » (HUR) ou « Jours » (DAY).

Le type d'identifiant du « OrganisatieID » diffère du type d'identifiant de « Envoyer via ».

Solution : Assurez-vous que les deux champs utilisent le même type d'identifiant.

Le numéro de TVA du fournisseur est manquant dans la facture.

Solution : Renseignez votre numéro de TVA dans les paramètres de l'organisation.

Votre organisation n'a pas de numéro de TVA (par exemple une fondation, un organisme public ou un prestataire de soins de santé qui fournit exclusivement des services exonérés de TVA) ? N'utilisez pas la valeur factice NL000000000B01. Choisissez plutôt la catégorie TVA 'O' - hors champ d'application de la TVA lors de l'établissement de la facture. Avec la catégorie 'O', l'obligation de renseigner un numéro de TVA est supprimée et la facture respecte la norme Peppol. Voir aussi TVA autoliquidée et catégorie TVA O pour une explication des codes de catégorie TVA.

Les fondations, certains organismes publics et prestataires de soins de santé qui fournissent exclusivement des services exonérés de TVA n'ont pas de numéro de TVA. Lors de l'établissement d'une facture via la plateforme, l'obligation de renseigner un numéro de TVA fournisseur apparaît.

Solution : Sélectionnez la catégorie TVA 'O' - hors champ d'application de la TVA (code UNCL5305 O, "Services outside scope of tax") dans le formulaire de facturation. Avec la catégorie 'O', l'obligation dans l'interface pour le champ numéro de TVA est supprimée et la facture peut être envoyée sans numéro de TVA fournisseur.

N'utilisez pas de numéros de TVA factices tels que NL000000000B01 - ce n'est pas la solution prévue pour ce scénario. La catégorie 'O' est le bon choix pour les organisations sans obligation de TVA.

Distinction 'E' et 'O' : La catégorie TVA 'E' (Exempt from VAT) est destinée aux organisations assujetties à la TVA qui facturent une transaction spécifique exonérée. La catégorie 'E' requiert un numéro de TVA. La catégorie 'O' est pour les organisations sans aucune obligation de TVA.

Lors de la facturation à l'administration centrale néerlandaise, un numéro IBAN est obligatoire.

Solution : Renseignez votre numéro IBAN dans les données de paiement de la facture.

Cette erreur se produit lorsque le CompanyID (le champ PartyLegalEntity dans le UBL) contient un numéro de TVA au lieu d'un numéro d'immatriculation au registre du commerce ou d'un OIN. La validation NLCIUS exige que les parties néerlandaises utilisent toujours un numéro d'immatriculation (schemeID 0106) ou un OIN (schemeID 0190) comme CompanyID. NL-R-003 concerne le fournisseur, NL-R-005 le client.

La confusion vient du fait que le EndpointID (l'adresse Peppol utilisée pour le routage) peut, lui, contenir un numéro de TVA (schemeID 9944). Une facture avec un numéro de TVA comme EndpointID arrive donc correctement via le réseau Peppol, mais est quand même rejetée si ce même numéro de TVA figure également dans le CompanyID.

Technique : EndpointID et CompanyID sont deux champs distincts avec chacun leur propre fonction. Le EndpointID détermine le routage via Peppol et accepte tout type de la liste de codes EAS (y compris 9944 pour les numéros de TVA). Le CompanyID identifie l'entité juridique et doit, pour les parties néerlandaises, toujours être un numéro d'immatriculation (0106) ou un OIN (0190).

Solution : Vérifiez le fichier UBL généré par votre système et assurez-vous que le CompanyID contient un numéro d'immatriculation ou un OIN, même si le EndpointID est un numéro de TVA. Les deux champs doivent se référer à la même organisation, mais peuvent avoir des types d'identifiant différents.

Conseil : La législation ViDA rendra progressivement plus stricte la relation entre EndpointID et CompanyID. Assurez-vous que votre intégration est correctement configurée dès maintenant, afin de ne pas être surpris par de futures modifications réglementaires.

Variantes de recherche : «BR-AE-10», «SOAP:CLIENTBR-AE-10», «Reverse charge shall have a VAT exemption reason», «BT-120», «BT-121», «motif d'exonération autoliquidation manquant», «factures rejetées reverse charge».

BR-AE-10 se produit lorsqu'une catégorie TVA AE (Reverse Charge) dans la ventilation TVA (BG-23) ne contient aucun motif d'exonération : ni BT-121 (code) ni BT-120 (texte, par exemple «TVA autoliquidée» ou «Reverse charge»). Il s'agit d'une erreur dans le UBL fourni par l'ERP ou le logiciel de facturation -- eConnect valide la facture mais n'ajuste pas automatiquement les champs AE.

Solution :

1. Vérifiez que chaque ligne ou majoration de facture avec la catégorie TVA AE a un taux de TVA de 0 %.
2. Dans l'export UBL du système source, renseignez le champ TaxExemptionReason (BT-120) et/ou le code (BT-121) pour chaque ventilation AE.
3. Validez la facture au préalable via le Document Validator.
4. Renvoyez la facture corrigée -- renvoyer le XML original erroné ne résout pas ce problème.

Voir aussi TVA autoliquidée : codes K, AE et G pour l'explication complète des codes d'autoliquidation TVA.

Ces règles de validation EN 16931 vérifient si la ventilation de la TVA et les totaux de la facture sont mutuellement cohérents. Les valeurs sont calculées par le logiciel d'envoi - ce ne sont pas des champs que vous pouvez corriger dans l'interface eConnect.

Variantes de recherche BR-CO-12 / BR-E-01 : "BR-CO-12", "BR-E-01", "ChargeTotalAmount", "BT-108", "total des majorations incohérent", "frais de port absents de la ligne de facture", "Shipping costs AllowanceCharge", "ventilation Exempt manquante".

BR-CO-12 survient lorsque le total des majorations au niveau facture ne correspond pas à la somme des majorations document distinctes — par exemple des frais de port inclus comme AllowanceCharge distinct au niveau facture (ChargeIndicator=true, motif "Shipping costs" / code FC). Il s'agit d'UBL valide ; voir Majorations et remises pour la structure. BR-E-01 survient lorsqu'une ligne de facture, une majoration ou une remise document avec catégorie de TVA 'Exonéré de TVA' (E) n'a pas de ventilation Exempt correspondante dans le récapitulatif TVA.

Cause fréquente : arrondir la TVA par ligne au lieu de par taux de TVA, ou une incompatibilité entre les montants de ligne et les remises au niveau facture.

Solution : contactez le fournisseur du logiciel d'envoi pour une correction. eConnect ne peut pas ajuster ces valeurs car le calcul est fixé dans le XML fourni.

Variantes de recherche : « Invalid payload BR-S-08 », « Delivery Failed BR-S-08 », « le récapitulatif TVA ne s'équilibre pas », « ligne de facture sans quantité », « quantité ligne facture manquante », « BT-116 », « VAT category taxable amount ».

Outre les erreurs d'arrondi, BR-S-08 échoue également lorsqu'une ligne de facture n'a pas de quantité (ou une quantité vide) (Invoiced quantity / BT-129). Dans ce cas, le montant de la ligne hors TVA est incorrect (quantité x prix unitaire plus majorations de ligne moins remises de ligne), de sorte que la somme des lignes s'écarte du VAT category taxable amount (BT-116) dans la ventilation TVA pour Standard rated. Le message d'erreur littéral ressemble souvent à : Invalid payload. [BR-S-08]-For each different value of VAT category rate (BT-119) where the VAT category code (BT-118) is Standard rated, the VAT category taxable amount (BT-116)....

Différence avec les erreurs xs:decimal : dans la section « 'n'est pas un xs:decimal valide' » ci-dessus, le champ de montant lui-même n'est pas un nombre décimal valide (vide ou notation scientifique). Avec BR-S-08, le champ de montant est un nombre valide, mais le calcul entre les montants de ligne et la ventilation TVA ne s'équilibre pas.

Liste de contrôle de premier niveau (avant escalade vers le fournisseur logiciel) :

1. Vérifiez que toutes les lignes de facture ont une quantité et un montant de ligne hors TVA renseignés.
2. Montant de ligne = quantité x prix unitaire (plus majorations de ligne, moins remises de ligne) ; aucun champ de montant vide.
3. Faites recalculer les totaux de TVA dans le système source.
4. Envoyez une facture corrigée via Peppol. Renvoyer le même document sans correction ne résout pas BR-S-08 -- Renvoyer dans la boîte d'envoi n'ajuste pas les montants de ligne ou de TVA (même périmètre de renvoi que pour R120 ci-dessus).
5. L'erreur persiste avec des quantités complètes ? Il s'agit alors d'un problème d'arrondi ou d'une autre erreur de calcul dans l'ERP ou l'export UBL -- transmettez au fournisseur logiciel.

Catégorie TVA E vs. O : l'organisation n'a pas de numéro de TVA (fondation, organisme public, santé) ? Utilisez la catégorie O (hors champ d'application) - voir la section « Organisations exonérées de TVA : catégorie O » ci-dessus. La catégorie E exige toujours un numéro de TVA.

R120 est une règle de calcul qui vérifie si LineExtensionAmount = (Quantity × PriceAmount ÷ BaseQuantity) + majorations - remises. R120 n'interdit pas explicitement les montants négatifs ; la validation échoue lorsque le calcul n'est pas équilibré. Cela se produit fréquemment lorsqu'une remise au niveau ligne (AllowanceCharge au niveau ligne) dépasse le prix de l'article.

Solution : utilisez le montant net de l'avoir directement comme PriceAmount et supprimez l'élément AllowanceCharge de la ligne. Consultez l'article sur les majorations et remises pour les détails et un exemple XML.

Ces trois codes d'erreur apparaissent lorsque la facture a été techniquement envoyée, mais que le destinataire ou le validateur rejette le contenu sur des champs de base dans l'UBL/XML. La cause réside dans le fichier XML lui-même, pas dans la connexion Peppol, l'ID Peppol ou le mode de livraison au client.

Solution : ajustez les champs concernés dans le logiciel où la facture est établie -- CustomizationID et ProfileID sont des valeurs fixes par type de document, pas un paramètre de la plateforme eConnect. Si BuyerReference et OrderReference sont tous deux absents, ajoutez l'un des deux avant de renvoyer la facture.

À noter concernant R007 et les autres profils BIS : la valeur par défaut du tableau s'applique à une facture/avoir standard. Le self-billing et d'autres profils Peppol BIS (par ex. self-billing invoicing) ont leur propre ProfileID, différent. Ne forcez pas la valeur par défaut sur des factures qui utilisent délibérément un autre profil BIS -- vérifiez d'abord quel profil s'applique avant d'appliquer cette FAQ.

À ne pas confondre avec : une inscription Peppol manquante chez le destinataire, un EndpointID incorrect, une panne d'Access Point, ou le message « aucune règle de validation disponible » (voir la section correspondante plus bas) -- ces cas présentent des symptômes différents de cette combinaison de spécification, profil et référence.

Cette erreur apparaît lorsque cbc:InvoiceTypeCode (BT-3) a la valeur 326 (facture partielle) ou 384 (facture de correction), alors que le fournisseur et le destinataire ne sont pas tous deux des organisations allemandes. La règle Peppol BIS Billing 3.0 PEPPOL-EN16931-P0112 n'autorise 326 et 384 que lorsque les deux parties sont allemandes.

Interface du portail : le sélecteur de type de facture se trouve à droite sur le brouillon de facture. Les libellés visibles côté client incluent facture partielle (à côté des termes standards « facture de correction » et « facture commerciale ») -- facile à manquer.

Solution (portail, facture NL ou hors DE) :

1. Allez dans Facture de vente → créer une facture.
2. À droite du brouillon : vérifiez le type de facture -- attention au libellé facture partielle.
3. Choisissez Facture commerciale (type 380) au lieu de facture de correction, sauf s'il s'agit réellement d'une correction et que l'expéditeur et le destinataire sont tous deux allemands.
4. Pour une correction vers un destinataire non allemand : utilisez une note de crédit ou une facture 380 négative suivie d'une nouvelle facture -- voir Variantes de note de crédit. N'utilisez pas le type 326/384 en dehors de DE→DE.

Source : Peppol BIS Billing 3.0 -- PEPPOL-EN16931-P0112.

Cette erreur apparaît sur la/les ligne(s) de facture avec la catégorie de TVA Livraison intracommunautaire / Intra-community supply (K, BT-151) lorsqu'une donnée TVA obligatoire est manquante. Pour la catégorie K sont obligatoires : la TVA du fournisseur (seller VAT, BT-31) ou celle du représentant fiscal (seller tax representative VAT, BT-63), et la TVA de l'acheteur (buyer VAT, BT-48). Les données manquantes se trouvent dans les données de la partie (organisation ou client), pas sur la ligne de facture elle-même. L'erreur ne pointe pas vers un numéro de ligne précis -- la règle se déclenche dès qu'une des lignes de facture utilise la catégorie K.

Solution :

1. Déterminez quelle(s) ligne(s) de facture utilisent la catégorie de TVA K (livraison intracommunautaire).
2. Renseignez le numéro de TVA du fournisseur (seller VAT) dans les paramètres de l'organisation, ou renseignez le représentant fiscal (seller tax representative VAT).
3. Renseignez le numéro de TVA du client (buyer VAT) dans les données du client.
4. Renvoyez la facture. Le document dans la boîte d'envoi est en lecture seule -- en cas d'erreur, une nouvelle facture de vente doit être créée.

Les ID Peppol belges peuvent prendre deux formes :

Format numéro de TVA : BE suivi d'exactement 10 chiffres (ajouter des zéros en tête si nécessaire). Vérifiez le numéro de TVA via l'outil de validation VIES de la Commission européenne (ec.europa.eu/taxation_customs/vies).

L'option Peppol n'apparaît pas pour le débiteur belge ? Vérifiez avec quel type d'identifiant le débiteur est enregistré sur Peppol. Certaines organisations belges ne sont enregistrées que via 0208: (KBO) et non via 9925: (TVA). Dans ce cas, essayez le numéro KBO : le numéro de TVA sans BE devant (p. ex. pour BE0123456789 le numéro d'entreprise est 0123456789 ; pour BE1xxxxxxxxx c'est 1xxxxxxxxx -- les deux préfixes sont valides).

AFAS : numéro d'entreprise avec points échoue dans Peppol BIS V3. Quand AFAS envoie initialement une facture SI2.0, aucune validation n'a lieu sur le numéro d'entreprise belge -- les formats avec points (p. ex. 0809.948.614) sont acceptés. Lors du passage à Peppol BIS V3, l'erreur de format apparaît car BIS V3 valide le numéro d'entreprise. Solution : le client met à jour les données de base dans AFAS et supprime les points du numéro d'entreprise. Le format correct est exactement 10 chiffres commençant par 0 ou 1, sans séparateurs.

Autre : les lignes de prix négatifs ne sont pas autorisées pour les factures belges ; utilisez une quantité négative avec un prix positif.

Les codes d'erreur BR-DE-* sont des règles de validation allemandes spécifiques au pays pour XRechnung.

Leitweg-ID manquant (EAS 0204) : fréquent lors de la facturation aux autorités allemandes. Demandez le Leitweg-ID à l'autorité contractante et ajoutez-le comme identifiant avec schemeID 0204.

PDF non accepté : depuis le 1er janvier 2025, l'Allemagne impose une obligation de réception des factures électroniques. Un simple PDF n'est souvent plus suffisant. Envoyez la facture en XRechnung ou ZUGFeRD.

Rejet KSeF : souvent causé par un format XML FA_VAT invalide. Le PSB eConnect assure normalement la transformation correcte vers le format polonais KSeF.

Erreurs de certificat : peuvent survenir si les certificats KSeF ne sont pas correctement installés ou ont expiré.

Limitation de débit : KSeF impose des limites sur le nombre de requêtes. eConnect utilise le traitement par lots pour éviter ce problème.

UWV applique ses propres règles de validation en plus de la validation Peppol/NLCIUS standard.

• UWV Grand Flux d'Argent (réintégration, formation, aides) : OIN 00000004191771249000
• UWV Petit Flux d'Argent (gestion) : OIN 00000004172892677000

Solution par code UWV : complétez le champ manquant dans la facture. La série UWV001 concerne les champs fournisseur obligatoires ; la série UWV002 concerne les éléments d'identification.

Non. eConnect est l'Access Point Peppol : il assure le transport de votre facture sur le réseau Peppol (voir Qu'est-ce que Peppol ?). eConnect n'est pas un logiciel de comptabilité ou de facturation.

Règle pratique pour la limite de périmètre : une erreur qui survient avant que la facture n'arrive chez eConnect -- par exemple une validation de champ sur la Ville, le Code postal ou d'autres données de la fiche client dans le logiciel utilisé pour créer la facture -- ne relève pas du périmètre d'eConnect.

• Vérifiez d'abord vous-même si les champs concernés (Ville, Code postal, etc.) sont correctement renseignés dans la fiche client du destinataire, dans votre propre logiciel de facturation/comptabilité.
• Si le message persiste, contactez l'éditeur de ce logiciel de facturation/comptabilité.
• Voir aussi « Identifiant du fournisseur requis » ou la section sur les numéros de commande inconnus plus bas (note « champ spécifique ERP ») : eConnect peut signaler un code d'erreur, mais n'exploite pas lui-même le progiciel ERP/comptable du client.

Ce message apparaît dans la Boîte d'envoi lorsque la facture n'a pas pu être livrée au destinataire via le réseau Peppol. Causes possibles :

• Destinataire non enregistré sur Peppol : le destinataire n'a pas d'inscription Peppol active. La plateforme propose alors automatiquement le repli par e-mail.
• EndpointID incorrect : l'adresse Peppol du destinataire est incorrecte.
• Problème technique côté destinataire : la facture a été correctement envoyée mais n'a pas pu être traitée par le système du destinataire.

En cas de livraison échouée, vous pouvez renvoyer la facture et corriger le EndpointID.

not available lors de l'envoi (test) à un destinataire signifie : le destinataire n'est pas actif sur Peppol pour recevoir des documents sur l'identifiant utilisé. Il ne s'agit pas d'un problème côté expéditeur.

• Le routage Peppol passe par l'EndpointID du destinataire (numéro de registre du commerce / OIN), et non par le numéro de TVA de l'expéditeur. Un numéro de TVA valide ne rend pas à lui seul une organisation trouvable ou accessible -- une inscription Peppol est requise (voir Qu'est-ce que mon Peppol ID ? et S'enregistrer sur Peppol).
• En cas de not available, la plateforme propose automatiquement le repli par e-mail, afin que le document puisse quand même être remis au destinataire par e-mail.
• Remarque côté expéditeur : l'envoi via Peppol fonctionne automatiquement dès que votre propre organisation est activée. L'activation pour la production est une exigence KYC ; les tests sont possibles via le programme pilote (voir S'enregistrer sur Peppol).

Le champ fournisseur ne contient aucune donnée. Cela se produit lorsque votre organisation n'est pas sélectionnée ou n'est pas activée.

Solution : Cliquez sur l'icône de modification à côté du champ fournisseur et sélectionnez votre organisation.

Le champ fournisseur n'accepte qu'une organisation que vous sélectionnez dans la liste déroulante. Si vous saisissez vous-même du texte dans ce champ -- par exemple le nom de votre propre entreprise -- au lieu de sélectionner l'organisation, la section Fournisseur de la facture n'est pas correctement construite. Le champ semble rempli, mais la facture est rejetée lors de l'envoi. Cette erreur apparaît souvent sous un autre message, comme « Numéro de TVA manquant » ou « Identifiant du fournisseur requis ».

Solution : supprimez le texte saisi dans le champ fournisseur, cliquez sur le champ et sélectionnez votre propre organisation dans la liste déroulante. Renvoyez ensuite la facture.

Il s'agit de la même procédure de correction que pour « Le champ Fournisseur est vide » et BR-NL-1 : sélectionnez votre propre organisation via la liste déroulante. La différence est qu'ici le champ semble rempli au premier abord, car il contient bien du texte -- mais pas de sélection valide.

La règle de validation BR-CO-09 vérifie si le numéro de TVA a un format valide. Le numéro de TVA doit toujours être saisi avec le code pays et sans points, espaces ni séparateurs.

Les codes pays suivent la norme ISO 3166-1 alpha-2. Les numéros de TVA sont obligatoires lorsque le fournisseur ou le destinataire est assujetti à la TVA et que le taux n'est pas exonéré.

Si le montant saisi disparaît lorsque vous passez à l'étape suivante, le champ contient probablement des caractères non autorisés. Le champ de montant n'accepte que des chiffres avec une virgule comme séparateur décimal. Saisissez les montants comme 100,00, pas comme € 100,00 ou 100.00.

Variantes de recherche : « icône d'arrêt rouge envoi », « rond rouge envoi », « facture ne peut pas être envoyée », « envoi échoue », « icône stop facture », « note de facture obligatoire », « IBAN compte bancaire obligatoire », « plus d'infos note de facture », « détails de paiement IBAN vide », « champs obligatoires envoi facture ».

Lors de l'envoi d'une facture de vente manuelle, une icône d'arrêt rouge peut apparaître : la facture ne part pas. La cause est une validation de formulaire côté client -- pas une erreur Peppol ou réseau, et pas un défaut de la plateforme. Le débiteur/OIN, l'accessibilité Peppol et le numéro de commande peuvent déjà être corrects alors que l'envoi échoue encore parce qu'un autre champ obligatoire est resté vide.

Vérifiez ces deux champs :

1. Note de facture (section Plus d'infos) -- renseignez une brève note ou référence, par exemple le numéro de commande ou la référence convenue avec le client.
2. IBAN compte bancaire (section Détails de paiement) -- renseignez l'IBAN sur lequel le paiement doit arriver, via Modifier si nécessaire. L'IBAN au niveau de l'organisation est facultatif, mais un IBAN vide sur la facture elle-même peut néanmoins bloquer l'envoi.

Différence avec d'autres blocages :

• Le bouton d'envoi ne répond pas ou affiche des espaces réservés : voir « Le bouton d'envoi Peppol ne répond pas » ci-dessous (traduction automatique du navigateur).
• La facture reste dans les brouillons : voir la section correspondante (paramètre d'organisation ou « Envoyer via » manquant).

L'envoi échoue toujours après avoir rempli les deux champs ? Demandez une capture d'écran du message d'erreur exact, pas seulement de l'icône d'arrêt.

Variantes de recherche : « numéro de compte bancaire mal formaté », « compte bancaire mal formaté », « IBAN mal formaté », « erreur de format IBAN », « espaces IBAN », « formatage IBAN détails de paiement », « erreur IBAN envoi facture manuelle ».

Lors de l'envoi d'une facture de vente manuelle, un message peut indiquer que le numéro de compte bancaire ou l'IBAN n'est pas correctement formaté, même si le numéro est correct sur le fond. La cause est une validation de format avant envoi sur l'IBAN ou le compte bancaire dans la section Détails de paiement -- pas une erreur Peppol ou réseau. Des espaces, tirets ou autres séparateurs (ou un code pays manquant) font échouer la vérification.

Solution :

1. Ouvrez la facture et allez dans Détails de paiement (IBAN ou compte bancaire).
2. Saisissez l'IBAN complet sous forme de chaîne continue : code pays suivi des chiffres/lettres, sans espaces, tirets ni autres séparateurs (forme : NL00BANK0123456789).
3. N'utilisez pas un ancien numéro de compte sans code pays -- les comptes néerlandais commencent par NL.
4. Enregistrez et renvoyez la facture.

Différence avec d'autres blocages :

• Champ IBAN vide avec icône d'arrêt rouge sur les champs obligatoires -- voir « Icône d'arrêt rouge lors de l'envoi » ci-dessus.
• « ID mal formaté » concerne le formatage de l'identifiant/schemeID, pas le compte bancaire -- voir les sections sur les erreurs inconnues/validation d'identifiant ci-dessus.

Le message persiste ? Demandez le contenu exact du champ (y compris espaces ou caractères) et le message d'erreur littéral ou une capture d'écran.

Variantes de recherche : « le bouton d'envoi ne répond pas », « l'écran de chargement reste bloqué lors de l'envoi », « texte étrange sur la facture », « nom de fournisseur bizarre », « unité illogique sur la facture », « l'organisation affiche un texte étrange », « se reconnecter plusieurs fois pour enregistrer », « se reconnecter pour envoyer », « champs de facture traduits », « traduction du navigateur lors de la création de la facture », « je ne peux pas me connecter », « texte étrange sur la page de connexion ».

Si le bouton d'envoi ne répond pas ou si l'écran de chargement reste bloqué lors de l'envoi d'une facture Peppol, et que vous voyez une syntaxe de modèle non traduite comme {{invoice.data.supplierDetails.name}} à la place des valeurs saisies, la cause probable est la traduction automatique du navigateur.

Le même schéma peut se produire lors de la création d'une (nouvelle) facture : libellés/valeurs de champs illogiques ou « traduits », notamment pour fournisseur, organisation et unité, où l'enregistrement ou l'envoi ne réussit qu'après plusieurs reconnexions. Cela a la même cause que les espaces réservés du bouton d'envoi -- pas un défaut du produit et aucune raison de réinstaller un logiciel client (la plateforme fonctionne uniquement via navigateur).

Le même phénomène se produit sur la page de connexion de platform.econnect.eu et ailleurs dans l'interface : texte d'espace réservé ou clés i18n brutes (par exemple {{lang.text}} ou I18N_COLLABRR_WS.*) à la place des libellés normaux. Les utilisateurs signalent souvent cela comme « je ne peux pas me connecter ». Voir aussi Connexion et 2FA.

La traduction automatique du navigateur (Chrome ou Edge) interfere avec le DOM de la plateforme. Cela empêche les boutons de fonctionner correctement et laisse visibles les espaces réservés de modèle ou i18n, ou des libellés de champs illogiques.

Solution (ordre de première ligne) :

1. Désactivez la traduction automatique dans votre navigateur pour la plateforme eConnect (y compris platform.econnect.eu).
2. Actualisation forcée (Ctrl+F5) et reconnectez-vous ; rouvrez ou recréez la facture si nécessaire.
3. Toujours pas de résultat ? Videz le cache du navigateur et/ou essayez un autre navigateur.
4. Le problème persiste ? Demandez une capture d'écran de la page de facture avec le navigateur et sa version.

Variantes de recherche : « erreur lors de l'envoi », « erreur de portail intermittente », « fonctionne après un redémarrage », « erreur d'envoi sans détails », « message d'erreur sans contenu ».

Il arrive qu'un utilisateur signale une erreur lors de l'envoi via la plateforme, sans le texte d'erreur littéral ni de capture d'écran. Sans ce contenu, il n'y a pas assez d'informations pour un diagnostic ferme ; il ne s'agit pas d'une panne étendue connue.

Première étape possible (cause non confirmée) :

1. Videz le cache du navigateur et/ou essayez un autre navigateur.
2. Si cela n'aide pas, demandez plus de contexte : le message d'erreur littéral ou une capture d'écran, l'heure et le numéro de facture.

À ne pas confondre avec :

• Le bouton d'envoi ne répond pas, l'écran de chargement reste bloqué, ou des libellés/espaces réservés illogiques -- voir « Le bouton d'envoi Peppol ne répond pas » ci-dessus (traduction automatique du navigateur, avec son propre ordre de première ligne).
• Statut SentRetry ou SentError après acceptation -- voir la section sur la relivraison automatique Peppol plus bas sur cette page ; il s'agit d'un mécanisme de nouvelle tentative côté serveur, pas d'un problème de cache navigateur.

Lors de l'envoi d'une facture, le message d'erreur « EndpointID manquant » peut apparaître. Il s'agit d'un bug connu de la plateforme - ce n'est pas un problème d'inscription Peppol côté client. Un diagnostic automatique le classe parfois à tort comme un problème d'inscription ; cette classification est incorrecte.

Solution (contournement) : ouvrez le bloc de la facture → cliquez sur l'icône de crayon en haut à droite → sélectionnez à nouveau le fournisseur et/ou le débiteur → envoyez à nouveau la facture. La plateforme reconstruit les identifiants dans le XML et peut alors envoyer la facture correctement.

Il s'agit du même contournement par icône de crayon que pour « Le champ Fournisseur est vide » / BR-NL-1 et « Identifiant du fournisseur requis ». La différence réside dans le message d'erreur spécifique « EndpointID manquant ».

Ce message apparaît lorsque vous téléchargez une facture XML sur la plateforme. La plateforme reprend les données du fichier XML, mais l'identifiant du fournisseur est absent. La plateforme ne peut donc pas envoyer la facture.

Solution : cliquez sur l'icône de crayon à côté du champ fournisseur et sélectionnez à nouveau votre organisation. La plateforme reconstruit alors la section fournisseur et ajoute les identifiants requis dans le XML.

Il s'agit de la même procédure que pour « Le champ Fournisseur est vide » et BR-NL-1 : sélectionnez à nouveau votre propre organisation via l'icône de crayon. La différence est qu'ici le message spécifique « Identifiant du fournisseur requis » apparaît en raison d'un identifiant fournisseur manquant dans le XML téléchargé.

Variantes de recherche : « Aucun identifiant activé pour l'envoi n'a été trouvé pour la société fournisseur », identifiants activés pour l'envoi, « vérification du fournisseur non encore effectuée », envoi facture nouvelle administration, deux organisations avec et sans SARL, identifiants non vérifiés.

Ce message, et la phrase client « vérification du fournisseur non encore effectuée » sur une première facture ou une nouvelle administration, n'indique généralement pas une étape KYC fournisseur distincte. La cause se situe presque toujours dans l'un de ces quatre points.

Liste de contrôle (dans l'ordre) :

1. Bonne organisation fournisseur sélectionnée ? Avec deux organisations similaires (par exemple le même nom avec et sans « SARL »), la mauvaise a peut-être été choisie. Utilisez l'icône de crayon pour sélectionner l'organisation avec des identifiants vérifiés — une organisation sans identifiants vérifiés ne peut pas envoyer.
2. Organisation activée ? Pas encore activée : activez d'abord via Ajouter et activer une organisation.
3. Bascule « Envoi » activée ? Allez dans Organisations → votre organisation → Détails et vérifiez qu'au moins un identifiant (de préférence le numéro SIREN) a la bascule Envoi activée. Pour une organisation activée, c'est généralement déjà le cas.
4. Numéro de TVA correct ? Vérifiez le numéro de TVA du fournisseur et du débiteur pour le code pays et les séparateurs — voir BR-CO-09 ci-dessus. Une erreur de format TVA peut survenir en même temps que ce message.

Si le message persiste après ces quatre étapes, renvoyez la facture après avoir corrigé les données de l'organisation ou de la facture.

Si une facture ne peut pas être envoyée et reste dans le dossier « Brouillons », vérifiez deux points :

1. Envoi activé : vérifiez dans les paramètres de l'organisation que « Envoi de documents » est activé.
2. Envoyer via configuré : dans la section « Débiteur », en plus de l'OrganisatieID, une option « Envoyer via » doit être sélectionnée.

La plateforme eConnect utilise parfois un préfixe d'espace de noms dans les factures UBL générées (p. ex. <urn:Invoice xmlns:urn="...">). Les deux formes - avec et sans préfixe - sont techniquement du XML valide.

Un destinataire rejetant des factures en raison du préfixe d'espace de noms n'est pas conforme Peppol. Le préfixe d'espace de noms n'est pas configurable par destinataire.

Message au client : la facture est techniquement correcte. Le destinataire doit utiliser un analyseur XML correct qui gère à la fois les espaces de noms préfixés et par défaut. Le rejet basé sur le préfixe d'espace de noms n'est pas autorisé dans Peppol.

Les codes d'erreur EBMS tels que EBMS:0003 et EBMS:0004 sont des erreurs de transport AS4 dans la communication entre points d'accès. Les clients voient SentError ou SentRetry dans la plateforme - le code EBMS lui-même n'est pas visible dans l'interface client.

Action : renvoyez le client vers TechSupport. TechSupport peut consulter les détails de l'erreur via la piste d'audit et Application Insights.

Le code d'erreur statut 40 signifie que le document n'a pas été traité avec succès. Deux causes possibles :

1. Erreur de traitement IDR : l'IDR ne peut pas traiter le document et retourne le statut 40.
2. Rejet côté plateforme : l'IDR a traité le document, mais la plateforme le met ensuite à statut 40 (p. ex. en raison d'une erreur de validation après conversion).

Diagnostic : un employé eConnect doit examiner dans CloudWatch quelles étapes de traitement le document a subies.

Via l'option Renvoyer dans la boîte d'envoi, vous pouvez resoumettre une facture déjà envoyée. Avant l'envoi effectif, vous pouvez encore modifier des champs comme la référence (numéro de commande, OrderReference) ou l'EndpointID (identifiant de routage Peppol). La facture est alors renvoyée avec le même numéro de facture mais avec la valeur corrigée.

EndpointID obsolète ou modifié (par exemple après un changement de numéro de TVA chez le destinataire) : si une facture a été envoyée vers un ID Peppol incorrect ou depuis modifié, Renvoyer avec correction de l'EndpointID est la voie préférée, et non l'avoir suivi d'une nouvelle facturation. Allez dans la boîte d'envoi, recherchez la facture envoyée vers le mauvais ID Peppol, cliquez sur Renvoyer, corrigez l'EndpointID vers le bon ID avant l'envoi, puis envoyez. La facture repart sous le même numéro vers le bon ID Peppol. Vérifiez le bon ID via le Peppol Directory.

Une note de crédit avec refacturation complète n'est pas nécessaire pour ce scénario. Cette voie plus lourde ne s'applique que lorsque la facture d'origine a déjà été (partiellement) livrée ou doit être corrigée pour des raisons comptables.

Un client ne peut effectuer un renvoi lui-même qu'avec un compte plateforme activé disposant d'un accès à la boîte d'envoi. Un partenaire informatique sans compte propre doit d'abord s'enregistrer.

C'est la démarche recommandée lorsqu'un destinataire rejette une facture en raison d'un numéro de commande incorrect ou d'une autre erreur de référence. Cela évite de devoir créer un avoir et une nouvelle facture.

Dans la norme Peppol BIS Billing 3.0 et NLCIUS actuelles, une seule référence de commande (OrderReference) par facture est prise en charge. Il s'agit d'une limitation découlant de la norme européenne EN 16931. Si une facture couvre plusieurs commandes, le fournisseur doit envoyer des factures séparées.

AdditionalDocumentReference peut contenir des références supplémentaires d'autres types (projet, contrat ou référence acheteur), mais pas plusieurs OrderReferences.

Avenir : l'EN 16931-1:2026 révisée (approuvée formellement par le CEN le 13 mars 2026) ajoute la prise en charge de plusieurs bons de commande par facture. Cela devrait être intégré dans une future version du standard Peppol (éventuellement BIS Billing 4.0). En attendant, la limitation actuelle d'1 OrderReference par facture s'applique dans BIS Billing 3.0 et NLCIUS.

Si une facture est rejetée en raison d'un numéro de commande manquant ou inconnu, deux niveaux doivent être distingués.

1. Une référence est obligatoire conformément à EN 16931. Une référence -- numéro de commande ou autre référence (BuyerReference, référence contrat ou projet) -- est requise. Une facture sans référence ne satisfait pas aux règles de base de la norme.

2. eConnect ne rejette pas par défaut sur le contenu de la référence. La seule situation dans laquelle la plateforme rejette sur ce point est lorsqu'aucune référence n'est présente.

3. La configuration spécifique au client peut être plus stricte. Le rejet effectif dépend de la configuration du destinataire. Dans une configuration spécifique, une facture peut être rejetée si la référence est inconnue chez ce destinataire. Ceci est spécifique à la configuration et non un comportement standard de la plateforme eConnect.

4. Le numéro de commande (BT-13, OrderReference/ID) n'est pas reconnu par le destinataire. Un numéro de commande dans le XML devrait normalement être reconnu par l'ERP du destinataire. En pratique, la correspondance échoue parfois pour l'une des raisons suivantes :

• L'ERP du destinataire n'est pas configuré pour faire correspondre automatiquement la valeur de commande.
• L'expéditeur transmet la valeur de commande de manière non standard (par ex. dans un champ de référence différent de celui attendu par l'ERP).
• La valeur de commande se trouve dans un champ de référence différent de celui que l'ERP du destinataire surveille.

eConnect peut corriger cela au niveau du produit par destinataire, afin que le processus de correspondance fonctionne correctement. Cela peut également être configuré pour un expéditeur spécifique.

Action :

• Renvoyez la facture via l'option Renvoyer (voir la section ci-dessus) avec une référence valide.
• Si le numéro de commande est inconnu, contactez le destinataire concernant la procédure souhaitée.
• Si la correspondance échoue systématiquement avec un destinataire spécifique, contactez le support -- eConnect peut mettre en place une solution sur mesure par destinataire (et optionnellement par expéditeur).

Une facture avec statut final InvoiceSentError (après une erreur de validation 4xx) ne tente plus d'autres livraisons. Seules les erreurs 5xx font l'objet de nouvelles tentatives (maximum 8 tentatives, environ 35 heures). Pour une erreur 4xx, une seule tentative est effectuée ; rien d'autre n'est envoyé au destinataire.

Il n'existe pas de point de terminaison DELETE pour les factures de vente (salesInvoice). Une facture de vente envoyée ou rejetée est un événement pertinent pour l'audit et reste disponible dans la piste d'audit pendant 90 jours. Si la facture était incorrecte, établissez un avoir ou une facture corrective selon le flux comptable standard.

Le réseau Peppol dispose d'un mécanisme automatique de relivraison/retry en cas de défaillances de livraison temporaires entre Access Points. Lorsque la livraison au point d'accès récepteur (C3) échoue temporairement -- par exemple en raison d'une panne côté destinataire -- le point d'accès expéditeur (C2) tente de relivrer le document ultérieurement.

• Erreur temporaire (5xx) = retry ; erreur permanente (4xx) = pas de retry. Au niveau d'envoi eConnect, seules les erreurs 5xx sont rejetées (maximum 8 tentatives, environ 35 heures). Une erreur de validation 4xx est permanente et entraîne une seule tentative -- voir aussi la section "InvoiceSentError" ci-dessus.
• Statut dans la plateforme : pendant un retry, le client voit le statut SentRetry (niveau transport AS4). En cas d'échec définitif, ce statut devient SentError.
• Effet d'une panne réseau ou de point d'accès : la facture peut n'être livrée que plusieurs jours après l'envoi, une fois que le retry réussit. L'expéditeur n'a rien à faire -- la relivraison s'effectue automatiquement dans la fenêtre de retry.
• Durée exacte de la fenêtre : la fenêtre de retry exacte du réseau Peppol (en dehors du retry d'envoi eConnect) n'est pas standardisée publiquement et peut varier selon le point d'accès.

Ce mécanisme de relivraison explique en partie pourquoi la date de réception peut être plusieurs jours après la date de facturation (IssueDate). Voir aussi Date de facture (IssueDate) vs. date de réception dans eConnect pour l'explication côté réception.

Source : confirmation d'expert Johan Schaeffer (Peppol & E-facturation), 2026-07-04, concernant le ticket #15268901 (W776).

Des erreurs de validation telles que TaxInclusiveAmount '-1.336061E6' n'est pas un xs:decimal valide surviennent parce que le système source sérialise un montant numérique en notation scientifique (p. ex. -1.336061E6 pour -1 336 061,00). Les champs de montant UBL sont de type xs:decimal, qui ne permet pas la notation E.

Cause fréquente : le système source stocke les montants en interne sous forme double/float et utilise la conversion de chaîne par défaut, qui bascule automatiquement en notation exposant pour les valeurs très grandes ou très petites.

Deuxième cause distincte -- champ de montant vide : l'erreur The string '' is not a valid Decimal value sur un champ PriceAmountType survient lorsqu'un champ de montant (par exemple cbc:PriceAmount) contient une chaîne vide ("") sur une ou plusieurs lignes de facture au lieu d'un nombre décimal. xs:decimal n'autorise pas une chaîne vide comme valeur lexicale. Il s'agit d'une cause différente, séparée de la notation scientifique, mais de la même classe de motif d'erreur (« n'est pas un xs:decimal valide » / « not a valid Decimal value ») : le système source laisse simplement le champ vide au lieu d'envoyer un nombre mal formaté.

Solution côté client (les deux variantes) : mettre à jour le système source pour que les montants soient toujours écrits sous forme de chaîne décimale ordinaire (p. ex. via des types decimal/BigDecimal ou un modèle décimal indépendant de la locale, sans séparateurs de milliers et sans notation E), et qu'aucun champ de montant ne reste vide.

Côté eConnect : ne peut pas être corrigé automatiquement -- la valeur est déjà incorrecte (ou vide) dans le XML fourni. Référer au fournisseur du progiciel ; la facture doit être renvoyée avec un montant valide sur toutes les lignes.

Ce scénario s'applique lorsque le fournisseur affirme avoir envoyé la facture mais que le destinataire n'a rien reçu, et que la facture n'a pas encore atteint le statut final 'Livré' ou que le statut est incertain.

Diagnostic en trois étapes :

1. Vérifier le statut d'envoi dans la plateforme. Accédez à la Boîte d'envoi (plateforme) ou PSB Control > Événements (PSB). Le client peut vérifier cela lui-même (autodiagnostic). Si la facture affiche 'Envoyée' ou 'Livrée' dans la Boîte d'envoi ou comme événement réussi dans PSB Control, la facture a bien été soumise au réseau Peppol. Si l'identifiant Participant du destinataire est enregistré auprès d'un autre Point d'accès ou d'un Point d'accès concurrent, la facture a été livrée à ce Point d'accès -- ce n'est alors pas un problème d'envoi eConnect.
2. Destinataire non activé ? Alors non routable. Vous ne pouvez pas envoyer à une organisation non activée : elle n'est pas publiée en tant que Participant dans le SMP/SML et l'identifiant Participant n'est pas routable via eConnect. Erreur fréquente : les expéditeurs pensent qu'ils doivent également ajouter le destinataire (leur client) comme organisation dans la plateforme -- ce n'est pas nécessaire. Seule l'organisation expéditrice doit être activée ; le destinataire n'a pas besoin de figurer dans le compte.
3. Le destinataire est chez un autre prestataire ? Migration nécessaire. Si le destinataire (ou le fournisseur lui-même) souhaite migrer vers eConnect : désinscrire d'abord l'ancien prestataire de services, puis s'inscrire auprès d'eConnect. Activer d'abord l'organisation pour que l'enregistrement puisse être effectué immédiatement, ou demander un code de migration (cela ne se fait pas encore automatiquement dans la plateforme). Voir Inscription et migration Peppol.

Pour le scénario où le statut affiche déjà Livré mais le destinataire indique ne rien avoir reçu, voir la section "Statut 'livré' mais le destinataire n'a pas reçu la facture" ci-dessous.

Le statut Livré signifie que le point d'accès récepteur (le prestataire Peppol du débiteur) a techniquement accepté le document et confirmé cette acceptation. eConnect reçoit un returnedMessageId (format GUID@econnect.eu) : preuve que la facture est arrivée au point d'accès du destinataire. L'endroit où le returnedMessageId est visible diffère entre la plateforme et le PSB - vérifiez le bon environnement pour le client.

Si le débiteur indique ne pas avoir reçu la facture alors que le statut affiche 'Livré', le document a bien été livré au point d'accès du débiteur, mais n'est pas encore visible dans son propre logiciel ou sa comptabilité. Il s'agit d'un problème en aval du côté du destinataire.

Étapes de résolution :

1. Confirmer au client que la facture a bien été envoyée au point d'accès Peppol du débiteur et qu'eConnect a reçu une confirmation de livraison.
2. Conseiller au client de demander au débiteur de contacter son propre prestataire Peppol. Le returnedMessageId peut être fourni : avec cet identifiant, le point d'accès récepteur peut retrouver le document.
3. La suite du traitement relève du point d'accès du débiteur ; eConnect en tant que partie expéditrice n'a aucune visibilité au-delà du point de livraison.

Variantes de recherche : « ajouter une organisation » pour une facture, portail fournisseur, nom d'organisation + numéro d'immatriculation en haut à droite, impossible de modifier la ligne d'organisation existante, impossible de renommer l'organisation existante, capture d'écran organisation client en haut à droite, message d'identifiant lors de l'ajout d'une organisation (fournisseur), ajouter sa propre organisation séparément, débiteur comme propre organisation, ajouter le destinataire de facture à l'environnement, activer l'organisation débiteur administration publique, le destinataire doit être dans l'environnement, s'enregistrer sous le propre OIN d'une commune, OIN du client comme propre organisation, facturer une commune avec son propre OIN, OIN destinataire pas son propre identifiant, schéma 0190 débiteur.

Les nouveaux utilisateurs -- notamment ceux qui migrent d'autres services de facturation électronique -- essaient parfois d'ajouter l'organisation destinataire comme leur propre organisation sur la plateforme lors de l'envoi d'une facture. Ce n'est pas nécessaire et génère un message d'erreur.

Pour envoyer une facture à un destinataire, cette organisation n'a pas besoin d'être dans votre propre compte : lors de la création de la facture, vous sélectionnez le destinataire via le champ de recherche du débiteur. Vous recherchez par numéro de chambre de commerce, nom d'entreprise ou numéro OIN.

Message d'erreur « L'identifiant a déjà été vérifié dans une autre organisation »

Ce message apparaît lors de la soumission d'une facture (via Peppol) ou lors de la tentative d'« ajouter une organisation destinataire ». Ce message couvre deux scénarios avec des causes et solutions différentes :

Scénario 1 : le message concerne l'identifiant du CLIENT (destinataire/débiteur). C'est l'expression d'une mauvaise utilisation de la plateforme : l'utilisateur tente d'ajouter une organisation cliente/destinataire dans son propre environnement. Il ne s'agit pas d'un problème d'autorisation - le support n'a pas besoin de libérer l'identifiant en interne. La procédure correcte : ajoutez uniquement votre (vos) propre(s) organisation(s) et activez-les dans votre propre environnement. Envoyez ensuite la facture au destinataire via le champ de recherche du débiteur - le destinataire n'a pas besoin d'être dans votre compte.

Scénario 2 : le message concerne le PROPRE identifiant de l'utilisateur. L'identifiant est déjà enregistré sous une autre organisation dans un autre compte. Il ne s'agit pas d'une mauvaise utilisation de la plateforme : l'utilisateur souhaite légitimement créer sa propre organisation. Causes possibles : un collègue a déjà créé l'organisation, ou l'organisation existe encore dans un ancien compte.

• En interne : déterminez qui a créé l'organisation précédemment et ajoutez le nouvel utilisateur à ce compte ou cette organisation.
• Si le créateur est inconnu : le support peut rechercher l'adresse e-mail du créateur afin que l'utilisateur puisse le contacter directement. Le support ne détache ni ne transfère lui-même l'identifiant - cela ne fait pas partie de la procédure de support standard.

Variantes de recherche : "enabled for Peppol sending", "additional Peppol activation", "is sending already enabled", "activation d'envoi supplémentaire", "University of Luxembourg", "9938", "scheme destinataire étranger".

Pour une organisation activée, l'envoi est activé par défaut -- cela fait partie de la connexion standard. Il n'y a pas d'étape séparée « Peppol send enable » en plus d'un statut d'organisation actif. Voir S'inscrire sur Peppol pour la procédure d'activation complà ̈te.

Saisissez le destinataire (par exemple une partie Peppol étrangà ̈re telle qu'une université luxembourgeoise) uniquement sur la facture, via le champ de recherche débiteur (ID organisation + Envoyer via). N'ajoutez pas le destinataire comme propre organisation dans le compte -- voir aussi la section « Confusion : essayer d'ajouter l'organisation destinataire comme sa propre organisation » ci-dessus.

Vous recevez toujours un message d'erreur non décrit ici ? Contactez-nous via support.econnect.eu.

• Créer et envoyer une facture
• Renvoyer une facture
• Envoyer une facture corrective (avoir)