L'Email Receiver (aussi appelé Expéditeur de confiance) est une App de la plateforme eConnect qui permet de recevoir et de traiter des factures par e-mail, dans le cadre de Scan et reconnaissance. Vous définissez une adresse e-mail ou un domaine de confiance, et les factures envoyées depuis cette adresse sont traitées automatiquement.

Attention : l'Email Receiver est une App (sous Apps dans le menu de la plateforme), pas une connexion. Si vous voulez que les factures reçues soient transférées automatiquement vers une adresse e-mail, utilisez le connecteur Email. Il appartient aux Connexions. Voir Clés de connexion : connecteur Email, transférer les factures reçues.

Beaucoup de logiciels utilisent l'Email Receiver comme méthode de couplage principale avec eConnect. La plateforme génère une adresse e-mail unique par organisation. Votre logiciel envoie les factures en pièce jointe à cette adresse et la plateforme les traite ensuite, selon le type de document configuré.

À la création d'un Email Receiver, la plateforme génère une adresse e-mail unique. Vous transmettez cette adresse à votre éditeur ou vous la saisissez dans votre logiciel. Dès que votre logiciel envoie une facture en pièce jointe à cette adresse, la plateforme traite la facture automatiquement. Les factures XML sont traitées directement. Les factures PDF sont converties au format e-facture (UBL) via la conversion IDR.

Le traitement dépend du type de document que vous avez défini : facture brouillon, facture de vente ou facture d'achat.

Un e-mail fournisseur entrant arrive d'abord à l'Email Receiver. La classification, le contrôle de l'expéditeur de confiance et l'attribution du type de document se font là. Le flux se sépare ensuite : facture vers le traitement, rattacher une spécification, ou ignorer un logo et des conditions. Chaque fournisseur reçoit une adresse unique sur trust.econnect.eu.

À la création d'un Email Receiver, vous choisissez un type de document. Il détermine comment la facture reçue est traitée.

La facture est préparée comme brouillon sur la plateforme. Vous pouvez la contrôler, puis l'envoyer manuellement au destinataire via Peppol. Si vous activez l'envoi automatique XML (auto-send), les factures XML valides sont envoyées sans intervention manuelle.

La facture va directement aux archives pour le traitement administratif. Cela convient lorsque la facture est déjà définitive et n'a pas besoin d'un contrôle supplémentaire avant archivage.

La facture est livrée au destinataire comme facture d'achat. Si la facture est déjà fournie en UBL, la conversion est ignorée. Pour une facture PDF, une conversion IDR vers le format e-facture a lieu.

Navigation pour les nouveaux clients : après l'inscription, vous arrivez sur la vue environnement / gestion de compte. L'Email Receiver n'y est pas visible directement. Dans le menu, cliquez sur Apps → Récepteur e-mail (Email Receiver) pour ouvrir la vue d'ensemble. Sous Tout, vous voyez l'adresse e-mail de réception créée automatiquement pour votre organisation.

1. Connectez-vous sur platform.econnect.eu.
2. Ouvrez l'app Email Receiver (sous Apps dans le menu de gauche).
3. Cliquez sur Nouvel expéditeur (le bouton orange avec le signe plus).
4. Renseignez les champs suivants :
   • Organisation : sélectionnez l'organisation pour laquelle vous voulez traiter des factures.
   • Type de facture : choisissez Facture brouillon, Facture de vente ou Facture d'achat.
   • Type de liste blanche : saisissez l'adresse e-mail ou le domaine de l'expéditeur autorisé à soumettre. Un seul domaine ou une seule adresse e-mail peut être ajouté par Email Receiver.
   • Adresse e-mail de contact : l'adresse vers laquelle les avis de rejet sont envoyés.
5. Cliquez sur Enregistrer. La plateforme génère une adresse e-mail unique pour cette connexion.
6. Activez l'expéditeur de confiance. Deux possibilités : passer le statut manuellement à "Actif", ou envoyer une invitation à l'expéditeur. Avec une invitation, l'expéditeur reçoit un e-mail qui explique l'adresse générée. Au premier usage, l'Email Receiver est activé automatiquement.
7. Transmettez l'adresse e-mail générée à votre éditeur ou saisissez-la dans votre logiciel.

Une organisation doit-elle recevoir des factures depuis plusieurs domaines ? Créez une adresse Email Receiver distincte pour chaque domaine.

• Notification à la réception : vous recevez un e-mail lorsqu'une facture a été soumise et traitée.
• Exigence SSL/TLS : ne traiter que les e-mails envoyés via une connexion sécurisée.
• Envoi automatique XML (auto-send) : les factures XML valides sont envoyées sans contrôle manuel. SSL/TLS doit être activé et le XML doit être valide.
• Types de documents autorisés : indiquez si vous acceptez uniquement les e-factures (XML), uniquement les factures numériques (PDF), ou les deux.
• Reconnaissance du fournisseur : indiquez quel champ e-mail sert à reconnaître le fournisseur. Par défaut, c'est l'adresse de l'expéditeur. Pour les alias ou les transferts, vous pouvez choisir un autre champ (par exemple Reply-To). L'adresse reconnue est aussi reprise dans le XML livré à votre système comptable.
• Conversion pour plusieurs organisations (Conversion for multiple organizations) : détection d'administration / conversion multiparty. L'IDR détermine automatiquement pour quelle administration du même compte une facture PDF est destinée, même si elle a été soumise via l'email receiver d'une autre organisation. Exige au minimum Professional (mentionné séparément au contrat), l'option de feature pack Allow multi party for IDR conversion (onglet IDR Features) et l'option sur l'email receiver. L'activation crée un groupe IDR (groupe d'administrations) avec les organisations du compte. La valeur par défaut est l'organisation de l'email receiver. En cas de meilleur correspondance, le système place la facture sur l'autre administration. En cas de doute, la valeur par défaut reste. La phase plateforme route sur Invoice/AccountingCustomerParty/Party/PartyLegalEntity/CompanyID et fait foi pour l'enrichissement XML (notamment numéro de TVA et nom d'organisation). Un Leitweg-ID fictif dans CompanyID (Allemagne) peut faire échouer la correspondance, la facture reste alors sur l'organisation par défaut. Détails : Récepteur e-mail.

Attention : une facture définitive issue de votre logiciel ne doit plus être modifiée sur le débiteur et les lignes de facture après réception comme facture brouillon sur la plateforme eConnect. Contrôlez uniquement l'exactitude de la facture, puis envoyez-la.

Un Email Receiver défectueux ou inactif ne doit pas forcément être réparé en créant un nouvel Email Receiver. Souvent, l'Expéditeur de confiance n'est pas encore actif ou est mal configuré. En cas d'"e-mail non reçu", vérifiez d'abord ces points :

1. Adresse e-mail reprise correctement. Vérifiez les fautes de frappe dans l'adresse générée …@trust.econnect.eu transmise au logiciel.
2. Statut Email Receiver Actif. Si l'Expéditeur de confiance est encore au statut "Créé brouillon", l'Email Receiver n'est pas encore actif et ne peut pas être utilisé. L'expéditeur reçoit alors un bounce (sauf si un autre Email Receiver actif avec une autre adresse de contact est configuré).
3. Liste blanche correcte. Vérifiez que l'adresse e-mail ou le domaine de l'expéditeur est correctement défini dans la liste blanche de l'Email Receiver.
4. Type de document correct. Avec un mauvais type de document, les factures sont mal traitées. Exemple : un Expéditeur de confiance créé avec le type Facture d'achat traite les factures comme facture d'achat au lieu de facture brouillon. Créer un nouvel Email Receiver en type Facture brouillon a pu servir de contournement temporaire, mais corrigez de préférence le type de document sur l'Email Receiver existant.

La facture est visible sur la plateforme après réception via l'Email Receiver, mais pas (encore) dans UBW/Agresso, Unit4 ou un autre logiciel connecté ? Distinguez d'abord un retard temporaire de lot ou de transfert d'un transfert qui n'arrive pas durablement : voir Dépannage ERP.

Lorsque des factures sont envoyées par e-mail à des destinataires qui ne sont pas dans Peppol, le compte client définit quels documents sont joints au repli e-mail. Vous voulez que des documents soient joints au repli e-mail ? Contactez-nous pour les possibilités et les éventuels coûts.

Alternatives recommandées pour les destinataires hors Peppol :

• Enregistrement Peppol du destinataire : la voie la plus robuste. Les factures passent alors par Peppol au lieu de l'e-mail.
• Compte sur la plateforme : le destinataire crée un compte et utilise un connecteur Email (Connexions) pour transférer automatiquement les factures reçues. Voir Clés de connexion : connecteur Email.

En cas de rejet, l'Email Receiver envoie un message d'erreur à l'adresse e-mail de contact de ce receiver. Ce champ n'est pas l'adresse e-mail de repli. Où vont les notifications du receiver, et comment modifier vous-même l'adresse e-mail de repli : voir Adresse e-mail de repli (fallback).

Un XML invalide ou non reconnu est rejeté et n'apparaît pas comme facture traitée sur la plateforme. Un blocage de liste blanche est un chemin distinct (expéditeur non autorisé). La présence de l'expéditeur sur la liste blanche n'exclut pas un rejet XML.

• Aucune pièce jointe traitable : aucun fichier de facture reconnu dans l'e-mail.
• Blocage de liste blanche : l'expéditeur n'est pas sur la liste blanche. Aucun fichier n'est traité.
• Erreur SSL/TLS : l'e-mail n'a pas été envoyé via une connexion sécurisée et n'est pas traité.
• XML invalide ou non reconnu : message d'erreur avec des instructions sur la validité UBL et l'encodage UTF-8. Si l'e-mail contient aussi un PDF à côté du XML, le PDF est quand même traité. L'avis pour le XML rejeté ne peut pas être supprimé tant que le PDF est traité.
• Erreur de validation UBL sur la pièce XML (par exemple BR-CO-18 / BR-Z-01 / BR-Z-05 Zero rated / taux zéro) : le rejet ne concerne que la pièce XML jointe. Si le même e-mail contient aussi un PDF, ce PDF est traité normalement tandis que le XML rejeté génère le message d'erreur ("Le traitement n'est pas possible" / "Nous n'avons pas pu traiter la facture UBL en pièce jointe").

Conseil en cas d'envoi structurel XML et PDF : si un fournisseur envoie toujours à la fois le XML et le PDF alors que seul le PDF est souhaité, deux voies existent : (1) le fournisseur corrige le XML ou omet la pièce XML (retirer le XML) ; (2) le support peut régler l'Email Receiver sur les factures numériques (PDF) uniquement. Avec la voie 2, le XML n'est plus proposé à la validation et le message d'erreur associé disparaît. C'est un changement de configuration par le support, à la demande du client.

L'Email Receiver classe les pièces jointes d'un e-mail entrant et détermine quel document est la facture et lequel est une pièce jointe. eConnect contrôle chaque document soumis séparément sur le statut pièce jointe / facture. Les documents sont fusionnés dans l'ordre de soumission : le premier document devient la première page de la facture, même s'il s'agit d'une pièce jointe. Dès qu'un fichier est reconnu comme pièce jointe, tous les fichiers suivants du même e-mail sont aussi traités comme pièces jointes.

Lors de la soumission de plusieurs fichiers PDF :

• Un fichier reconnu comme facture, les autres sont d'autres types de document. Les autres documents du même e-mail sont traités comme pièces jointes et ajoutés à la facture par défaut. Pensez à une note de sinistre, un bon de livraison ou une spécification à côté du vrai PDF de facture : vous pouvez appeler les deux documents "facture", mais si Detect n'en reconnaît pas un comme facture, ce n'est pas une erreur de découpage, c'est le comportement attendu. Le document non facture devient une pièce jointe de la facture reconnue. Un doute sur le fait que le second document soit quand même une facture (numéro de facture, TVA, montant à payer, fournisseur/destinataire présents) ? Demandez les pièces PDF d'origine et le XML depuis la boîte de réception pour enquête.
• Plusieurs pièces jointes reconnues comme facture. Chaque PDF de facture est traité individuellement (factures distinctes). Le système ne rattache pas automatiquement les autres pièces à une facture précise du même e-mail. En cas de doute, envoyez 1 facture par e-mail.

Logique de fusion avec et sans XML dans l'e-mail : si l'e-mail ne contient pas de XML, la logique ci-dessus s'applique selon la classification Detect (une déclaration ou facture, les pièces sont ajoutées ; deux déclarations ou factures ou plus, tout est traité séparément). Si l'e-mail contient une facture XML valide, une autre règle s'applique : un PDF dont le nom de fichier est exactement celui du XML est ajouté à ce XML. Les autres pièces sont classées via Detect et peuvent être traitées séparément. Avec deux XML valides ou plus dans le même e-mail, une pièce au nom exactement identique est ajoutée au XML concerné. Les autres fichiers sont traités séparément.

Si Detect reconnaît à tort un PDF d'aperçu ou de spécification isolé comme facture, une facture supplémentaire apparaît à côté de la vraie facture. Voir Plusieurs pièces jointes PDF dans un même e-mail pour éviter cela.

Pièce Excel/ODS/CSV à côté d'une facture PDF : la présence d'une pièce Excel ne bloque pas le traitement de la facture PDF, à condition que le fichier soit dans un format pris en charge et ne dépasse pas 5 Mo. Comportement par scénario :

• Format pris en charge et pas plus de 5 Mo (.xlsx, .ods, .csv) : le fichier est ajouté à la facture comme pièce secondaire (non envoyé à l'IDR). La facture PDF est traitée normalement.
• Format pris en charge et plus de 5 Mo : l'e-mail entier est refusé avec un e-mail de bounce.
• Format non pris en charge (.xls, .doc, .docx) : le traitement n'est pas possible.

Types MIME pris en charge : application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xlsx), application/vnd.oasis.opendocument.spreadsheet (.ods), text/csv (.csv). Non pris en charge : application/msword (.doc), application/vnd.openxmlformats-officedocument.wordprocessingml.document (.docx), application/vnd.ms-excel (.xls).

Rotation de page : les pages ne sont pas tournées automatiquement. Le client est responsable de la bonne orientation à la soumission.

Grandes pièces jointes : une très grande pièce est réduite pour que le PDF reste utilisable.

Fusion des pièces : la plateforme peut fusionner toutes les pièces d'une e-facture en un seul PDF.

Générer un PDF à partir du XML : une option génère automatiquement un PDF de la facture XML. Elle se combine avec la fusion et se règle sur : toujours, jamais, ou seulement s'il n'existe pas encore de PDF.

PDF soumis inchangé : eConnect ne fait que la traduction/le traitement et ne modifie pas le fichier PDF soumis lui-même (un PDF peut quand même être généré).

Un expéditeur reçoit-il un bounce ou une notification indiquant qu'un document est "une pièce jointe ou une spécification", alors que la facture associée du même e-mail a bien été traitée ? Le même message apparaît aussi comme "Type de document incorrect" ou "Le fichier soumis (Facture d'achat) ne peut pas être traité parce que le type de document est incorrect". L'objet anglais du même message est "This is an attachment/specification". Le bounce peut aussi porter sur une image inline (image012.png) ou sur un récapitulatif de factures dans un e-mail transféré. Ce n'est pas une contradiction. Ce sont deux résultats distincts dans un même e-mail.

1. Le message est indépendant du statut de la facture. Il ne dit rien sur l'échec ou non de la facture elle-même. Contrôlez le statut de la facture séparément dans la boîte de réception.
2. Démarrage faux positif d'une tâche de conversion. Un PDF ou une image avec assez de signal facture (par exemple le mot "Facture" avec un numéro) démarre sa propre tâche de conversion. Si ce document n'est pas une facture, le bounce sur ce document est justifié, indépendamment de la vraie facture du même e-mail.
3. Pas de rattachement tardif. Une fois une tâche de conversion démarrée pour une pièce jointe, cette pièce n'est pas rattachée ensuite à la facture.
4. Les tâches de conversion séparées ne se fusionnent pas. Plusieurs fichiers qui ont démarré comme facture restent des tâches de conversion distinctes. Ils ne peuvent pas être fusionnés ensuite.

Feuille de route produit : une amélioration structurelle de la classification "à la porte d'entrée" est prévue dans une future version PSB de l'Email Receiver (horizon d'environ 12 mois à partir de septembre 2026). Jusque-là, le comportement ci-dessus s'applique.

Les clients avec Microsoft 365 / Exchange peuvent transférer le courrier de facturation depuis leurs propres adresses (par exemple factures@client.fr) vers l'Email Receiver sans donner de droits de boîte supplémentaires aux utilisateurs finaux. Il s'agit d'un transfert côté client vers une adresse de réception eConnect. Ce n'est pas la connexion Office 365 dans laquelle PSB lit la boîte via Graph/OAuth.

Schéma : contact de messagerie + groupe de distribution (conserve l'expéditeur d'origine) :

1. Créez une adresse Email Receiver sur la plateforme et passez le statut à Actif.
2. Dans le Centre d'administration Exchange, créez un contact de messagerie dont l'adresse externe est l'adresse Email Receiver de la plateforme.
3. Créez un groupe de distribution avec l'adresse de facturation côté client. Membre = le contact de messagerie. Facultatif : un alias supplémentaire sur le même groupe.
4. Testez la réception sur la plateforme.

Avec une seule adresse de facturation générique, le receiver est souvent en liste blanche Tout accepter (pas avec Facture brouillon). Si Exchange bloque le transfert externe, choisissez la connexion de boîte Office 365. Évitez les boucles de transfert : ne transférez pas le courrier des domaines everbinding.nl ou econnect.eu.

Voir aussi Récepteur e-mail pour le parcours dans l'interface de la plateforme.

Vous voulez savoir quelles méthodes d'intégration existent pour votre logiciel ? Voir l'aperçu des méthodes d'intégration.