Lorsque la facture est le corps de l'e-mail,
pas la pièce jointe
La plupart des outils d'extraction de factures reposent sur une hypothèse unique : les données que vous recherchez se trouvent dans un fichier joint au message. Cette hypothèse tient pour une grande partie des factures fournisseurs. Elle échoue complètement pour celles où la facture est l'e-mail lui-même, rédigé en HTML ou en texte brut dans le corps du message, sans aucun PDF dans le message. Dans ce cas, un outil axé sur les pièces jointes ne renvoie pas un mauvais chiffre. Il ne renvoie rien, et il ne vous dit pas qu'il n'a rien renvoyé.

Points clés à retenir
- L'analyseur de factures auquel vous faites déjà confiance a raison pour la plupart des factures, car la plupart arrivent sous forme de pièces jointes.
- Sur une facture présente uniquement dans le corps du message, il renvoie une ligne vide et ne signale aucune erreur, ce qui est le type d'échec le plus coûteux.
- En configurant la boîte de réception pour lire le corps du message lui-même, ce même e-mail devient une ligne de feuille de calcul, sans étape d'impression en PDF.
Lorsque la facture n'existe que dans le corps de l'e-mail, les outils axés sur les pièces jointes ne renvoient rien
Une facture qui ne vit que dans le corps de l'e-mail n'a aucun fichier à ouvrir pour un analyseur axé sur les pièces jointes, qui renvoie donc une ligne vide sans signaler d'erreur. Le pipeline d'extraction semble avoir fonctionné. La sortie ressemble à un message qui n'avait simplement rien à extraire. Personne ne reçoit d'alerte, et la facture reste dans la boîte de réception jusqu'à ce qu'un humain remarque que la ligne est vide.
Ce n'est pas un format rare. C'est le format par défaut pour une part spécifique et croissante de la facturation B2B. Les plateformes d'abonnement et de publicité envoient leurs factures sous forme de messages formatés plutôt que de fichiers : reçus Stripe, relevés de facturation mensuels AWS, avis de facturation Google Workspace, factures Meta Ads et Google Ads, relevés de trajets Uber for Business. Les petits fournisseurs et les indépendants font de même, en tapant un numéro de facture et un total directement dans le message, car c'est plus rapide que de générer un PDF.
Le coût de ces oublis n'est pas théorique. Ardent Partners a estimé le coût moyen tout compris du traitement d'une seule facture à 9,40 $ en 2025, contre 2,78 $ pour les équipes les plus performantes, et a constaté que seulement 32,6 % des factures circulent sans intervention humaine (Ardent Partners, AP Metrics That Matter in 2025). Chaque facture qui sort du parcours automatisé est traitée à la main, à l'extrémité manuelle de cette fourchette de coûts.
Un analyseur axé sur les pièces jointes n'échoue pas bruyamment sur une facture présente uniquement dans le corps du message. Il réussit à ne trouver aucune pièce jointe, ce qui est le type d'échec le plus coûteux.
Les factures présentes uniquement dans le corps du message se présentent sous trois formes, et seules deux contiennent des données extractibles

Les factures présentes uniquement dans le corps du message arrivent dans la boîte de réception sous trois formes, et seules deux d'entre elles contiennent des données qu'une machine peut réellement lire. Savoir de quelle forme il s'agit vous indique si l'extraction est possible ou si vous poursuivez un lien qui n'allait jamais devenir une ligne de feuille de calcul.
| Forme | À quoi cela ressemble | Peut-elle devenir une ligne de feuille de calcul ? |
|---|---|---|
| Corps en texte brut | Un indépendant ou un petit fournisseur tape le numéro de facture, le montant et la date d'échéance directement dans le message | Oui. Les valeurs sont présentes sous forme de texte, même si elles ne sont pas structurées |
| Reçu HTML ou tableau | Une plateforme d'abonnement ou de publicité affiche un reçu formaté, souvent un véritable tableau, dans le corps du message | Oui. Les valeurs sont présentes, mais sous forme de mise en page plutôt que de champs |
| Notification de portail | « Votre facture est prête. Connectez-vous pour la consulter et la télécharger. » Le message annonce la facture ; la facture elle-même se trouve derrière la connexion | Non. L'e-mail pointe vers la facture au lieu de la contenir, et le lien de téléchargement expire |
La distinction entre les deux premières formes et la troisième est la différence entre un document structuré et une notification à son sujet. L'Union européenne trace précisément cette ligne dans sa définition de la facturation électronique : une facture électronique est une facture « émise, transmise et reçue dans un format de données structuré qui permet son traitement automatique et électronique » (Commission européenne, directive 2014/55/UE). Un e-mail HTML formaté n'est pas cela. C'est une image de facture dessinée en balisage.
Selon la norme européenne EN 16931, un champ de facture est un élément sémantique défini avec son propre nœud dans la syntaxe UBL : le numéro de facture est cbc:ID, la date d'émission est cbc:IssueDate, le montant à payer est cac:LegalMonetaryTotal/cbc:PayableAmount (Peppol BIS Billing 3.0). Dans un reçu HTML, ces mêmes valeurs se trouvent dans des cellules de tableau positionnées par une feuille de style, sans étiquettes sur lesquelles un programme peut s'appuyer. Cet écart explique pourquoi une facture body only est un problème d'extraction plus difficile qu'un PDF joint, et non plus facile.
Pourquoi les analyseurs échouent ici : le HTML n'est pas du texte brut, et l'impression en PDF dégrade les données

Les analyseurs échouent sur les factures body only pour une raison qui n'a rien à voir avec la qualité de l'OCR : un corps d'e-mail est du HTML, pas le texte brut que la plupart des analyseurs supposent. Une expression régulière réglée sur « Montant dû : $X » lit correctement un corps en texte brut et ne renvoie rien sur la même facture rendue sous forme de tableau HTML, car la valeur et son étiquette sont séparées par le balisage. La partie de repli en texte brut d'un message multipart supprime souvent entièrement le tableau, laissant au lecteur une mise en page qui ne correspond plus.
La solution de contournement habituelle consiste à imprimer l'e-mail en PDF et à traiter ce dernier. C'est ce que font la plupart des comptables aujourd'hui, et c'est fragile pour trois raisons distinctes. La première est la pagination : un long reçu ou un tableau détaillé se divise sur plusieurs pages, et les totaux atterrissent sur une page différente de celle des lignes d'articles. La deuxième est le bruit : le PDF imprimé contient l'expéditeur, l'objet, le bloc de signature et l'avertissement juridique, de sorte que l'extracteur doit distinguer un total de facture d'un pied de page qui contient par hasard le mot « total ». La troisième est que l'étape d'impression en PDF est elle-même une dégradation de la qualité du document.
Un benchmark de 2025 de Fraunhofer IAIS et de l'Institut Lamarr a testé huit modèles multimodaux sur l'extraction de factures et a constaté que le même meilleur modèle obtenait 96,50 % sur les factures numériques propres, 92,71 % sur les factures scannées et 87,46 % sur les reçus scannés (arXiv:2509.04469). La précision suit la qualité du document bien plus qu'elle ne suit le modèle. Rendre une facture HTML en PDF ou en capture d'écran la fait descendre délibérément sur cette échelle.
La frustration transparaît clairement dans les propos des personnes concernées. Sur r/Bookkeeping, un teneur de livres a décrit sa routine : « L'un des fléaux de mon existence, c'est lorsqu'un reçu ou une facture est intégré directement dans le corps d'un e-mail plutôt que d'être joint en pièce jointe PDF bien propre. Je dois manuellement enregistrer l'e-mail en PDF et le téléverser à la place, et c'est rarement net. » Il avait aussi essayé de faire une capture d'écran de la partie du reçu, sans meilleur résultat : « si c'est long, ce n'est pas vraiment pratique et honnêtement, ça prend plus de temps que d'imprimer en PDF de toute façon. » Un autre commentateur dans le même fil a identifié la cause sous-jacente : « La facture intégrée dans le corps d'un e-mail n'est probablement que du HTML sous le capot » (r/Bookkeeping).
La solution de contournement existe parce que l'outil attend un fichier. Supprimez cette attente et la solution de contournement disparaîtra avec elle.
La solution consiste à changer le mode de la boîte de réception pour que l'extraction lise le corps du message lui-même

La solution consiste à changer le mode de traitement de la boîte de réception pour que l'extraction lise directement le corps du message, au lieu d'attendre une pièce jointe qui n'arrivera jamais. L'Email Inbox d'ImageToTable.ai fournit à chaque compte une adresse de boîte de réception dédiée à laquelle vous transférez vos e-mails, et son comportement par défaut est celui qui pose problème : il lit les véritables pièces jointes et ignore le corps. Le paramètre qui compte est celui que vous modifiez ensuite. Vous pouvez passer le traitement en mode body only, qui ignore les pièces jointes, ou en mode attachments and body, qui lit les deux en une seule passe.
Ce simple interrupteur fait d'une facture body only une entrée de première classe plutôt qu'une lacune. Le message n'a plus besoin d'un fichier pour mériter d'être traité, car ce qui est lu, c'est le contenu du message lui-même.
Ce qui arrive au contenu, c'est l'Extraction de colonnes personnalisées. Vous saisissez les noms de colonnes souhaités, tels que Numéro de facture, Fournisseur, Date de facture, Date d'échéance et Montant total, et l'IA localise chaque valeur en comprenant ce qu'elle signifie, et non où elle se trouve. Les noms que vous saisissez deviennent les en-têtes du tableur de sortie. Comme les colonnes sont définies par leur signification, le même ensemble de colonnes lit un corps en texte brut, un reçu HTML et une pièce jointe PDF sans règle distincte pour chacun. Un fournisseur qui modifie son modèle d'e-mail, ou un nouveau fournisseur qui envoie un format que vous n'avez jamais vu, ne nécessite aucune reconfiguration.
Transférez le courrier vers votre adresse de boîte de réception dédiée
Chaque compte reçoit une adresse. Partagez-la avec vos fournisseurs ou configurez une règle de transfert dans votre propre boîte aux lettres pour que les factures y soient routées automatiquement. Activez la liste blanche des expéditeurs pour exclure les courriers non pertinents de la file d'attente. Rien n'est téléchargé ni re-téléversé.
Modifiez ce que la boîte de réception traite
Dans les paramètres de la boîte de réception, quittez le mode par défaut « pièces jointes uniquement ». Choisissez body only si vos factures arrivent sous forme de texte ou HTML sans fichier, ou attachments and body si vous recevez les deux types et souhaitez les lire ensemble. C'est l'étape qui couvre les factures qu'aucun analyseur de pièces jointes ne voit jamais.
Nommez les colonnes une fois et liez-les à un modèle
Saisissez vos noms de colonnes, enregistrez-les comme modèle et activez le traitement automatique pour que l'extraction démarre dès qu'un message arrive. Chaque e-mail devient une ligne. Exportez le lot en Excel, CSV ou JSON, ou envoyez les lignes directement dans Google Sheets.
Si vous utilisez déjà un flux e-mail-vers-feuille de calcul pour les factures en pièces jointes, cette fonctionnalité est la branche manquante plutôt qu'un remplacement. L'analyseur d'e-mails qui lit les pièces jointes et le pipeline fournisseur-e-mail-vers-AP supposent tous deux qu'un fichier est présent. Changer le mode de traitement est la façon dont la même boîte de réception capture aussi les messages qui arrivent sans fichier.
Les fichiers sont traités en toute sécurité et ne sont pas stockés.
Ce que cela ne résout pas
Cette approche traite les factures « body only » qui portent leurs données en texte ou en HTML, et elle ne peut pas aider avec les e-mails qui ne contiennent aucune donnée. Quatre limites méritent d'être énoncées avant de construire un workflow par-dessus.
Une notification de portail n'a rien à lire. Lorsqu'un fournisseur envoie « votre facture est prête » avec un lien de connexion et aucun chiffre, le mode body n'a rien à extraire, car les données se trouvent derrière un portail authentifié. Lire cette facture signifie se connecter et la télécharger, et le lien dans l'e-mail expire souvent. Aucun analyseur de boîte de réception ne comble cette lacune, car l'e-mail n'a jamais été la facture.
Les champs absents du corps du message ne peuvent pas être inventés. Une facture en texte brut qui dit « Invoice 2026-041, $1,850, due Oct 15 » n'a pas de lignes d'article, donc une colonne Line Items revient vide. L'extraction est honnête à ce sujet : elle remplit ce que le message contient et laisse le reste vide, ce qui est plus utile qu'une supposition que vous devrez corriger plus tard. Lorsque le message contient un tableau détaillé, le tableau est lu ; lorsqu'il n'en contient pas, la ligne reflète simplement ce que l'e-mail contenait.
La sortie est des données structurées, et elles restent structurées. Ce que vous obtenez est une feuille de calcul, un CSV ou une ligne JSON, et l'outil ne réaffiche pas l'e-mail HTML comme un document. Si vous avez spécifiquement besoin d'un PDF soigné de l'e-mail pour un dossier d'audit, c'est une tâche distincte.
Ce n'est pas une intégration QuickBooks ou Dext. La sortie arrive dans Excel, CSV, JSON ou Google Sheets, et ce qui se passe ensuite relève de votre workflow. Les équipes qui utilisent Dext, Hubdoc ou Bill.com pour la capture et QuickBooks ou Xero pour la comptabilité traitent généralement cela comme le flux structuré que ces systèmes consomment, plutôt que comme un remplacement. Pour une vue d'ensemble de la place de l'extraction par rapport à ces outils, le guide complet sur l'extraction des données de factures et le guide d'extraction destiné aux comptables couvrent le workflow environnant.
Une autre mise en garde s'applique aux chaînes de transfert. Lorsqu'un message cite plusieurs réponses plus anciennes, le même total peut apparaître plus d'une fois, et la copie la plus ancienne se trouve souvent dans le texte cité. L'extraction lit par le sens, mais une chaîne comme celle-ci est le seul cas où il vaut la peine de passer trente secondes à confirmer de quelle occurrence provient une valeur. Review Mode existe pour cela : survoler une cellule met en évidence exactement d'où provient la valeur dans la source, de sorte que la vérification est un coup d'œil plutôt qu'une relecture.
FAQ
Peut-il lire une facture qui se trouve uniquement dans le corps de l'e-mail, sans aucune pièce jointe ?
Oui. Réglez le mode de traitement de la boîte de réception sur body only, ou sur attachments and body si vous recevez les deux types. Le contenu du message est lu directement, donc une facture saisie dans l'e-mail ou rendue sous forme de reçu HTML devient une ligne de feuille de calcul sans être téléchargée, imprimée ou capturée d'écran au préalable.
Qu'en est-il des factures qui arrivent sous forme de tableau HTML dans l'e-mail ?
Celles-ci fonctionnent dans le même passage. L'IA lit le contenu rendu par le sens plutôt qu'en analysant le balisage brut pour un motif fixe, donc un reçu formaté avec le montant, la date et le numéro de facture disposés dans des cellules de tableau est lu de la même manière qu'une facture en texte brut. Vous n'avez pas besoin de règle par expéditeur ou par mise en page.
Dois-je encore imprimer l'e-mail en PDF ou prendre une capture d'écran ?
Non, et pour les factures longues, c'est la voie la plus faible. Imprimer ou capturer l'écran pagine le reçu, inclut la signature et le texte de clause de non-responsabilité, et réduit la qualité du document que le modèle voit. Lire le corps directement évite ces trois problèmes et supprime une étape manuelle que le fil r/Bookkeeping décrit comme la partie qui « really adds up. »
Qu'en est-il des e-mails « votre facture est prête » avec un lien de portail ?
Ceux-ci ne peuvent pas être extraits de l'e-mail, car l'e-mail ne contient pas la facture. Les données se trouvent derrière une connexion fournisseur, et le lien de téléchargement expire fréquemment. C'est une vraie limite, pas une lacune de configuration : la solution est un téléchargement depuis le portail ou une intégration spécifique au fournisseur, pas un meilleur analyseur.
Est-ce qu'il envoie les données dans QuickBooks ou Xero ?
Il génère des données structurées sous forme Excel, CSV ou JSON, ou écrit des lignes dans Google Sheets. L'intégration avec un système comptable se fait en aval de cette sortie, via votre propre importation ou flux de travail. Ce n'est pas un connecteur natif QuickBooks ou Xero, et cela ne remplace pas les outils de capture et de grand livre que vous utilisez déjà.
Convertira-t-il l'e-mail HTML en PDF ?
Non. La tâche ici est l'extraction : transformer le contenu de la facture dans le message en colonnes nommées. Si vous avez spécifiquement besoin d'un document PDF pour vos archives, générez-le séparément ; cela produit la ligne structurée dont un PDF ne serait qu'une étape intermédiaire.
Le changement utile est petit et précis. Une facture « body only » cesse d'être une exception qui impose une solution manuelle, car ce que le flux de travail lit n'est plus un fichier. Lorsque la facture est l'e-mail, l'e-mail est le document.