66 % des équipes AP saisissent encore les factures à la main.
Le chiffre augmente, il ne diminue pas.

66 % des équipes AP saisissent encore les factures à la main. Et ce chiffre augmente, pas l'inverse.

Le rapport IFOL Accounts Payable Automation Trends 2025 a interrogé près de 200 professionnels de l'AP et de la finance — dont 78 % travaillent directement dans la comptabilité fournisseurs. Les résultats ne correspondent pas au récit habituel.

66 % saisissent encore manuellement les données des factures dans leur ERP ou leur système financier — contre 60 % en 2023. 63 % consacrent plus de 10 heures par semaine au traitement des factures — contre 52 % en 2024. 73 % des équipes financières ne sont pas entièrement automatisées. 27 % n'ont aucune automatisation.

Parallèlement, le rapport AI Momentum 2025 de Vic.ai révèle que 37 % des professionnels de l'AP classent encore la saisie manuelle des données comme leur principale difficulté — devant les coûts de traitement élevés, les approbations lentes et tous les autres maux opérationnels.

Ce n'est pas une histoire de progrès. C'est l'histoire d'un problème qui semble résolu de l'extérieur, mais qui ne l'est pas. Les outils d'automatisation existent. Les cas de rentabilité sont clairs. Alors pourquoi le taux de saisie manuelle augmente-t-il ?

La réponse n'est pas « les entreprises n'ont pas encore acheté d'outils ». C'est que les outils que la plupart des entreprises ont achetés ne résolvent pas le problème fondamental. Et le problème fondamental n'est pas que la saisie des données est lente — c'est que chaque facture arrive dans un format différent, et que l'automatisation basée sur des modèles échoue précisément à ce stade.

À quoi ressemble concrètement la « saisie manuelle des données » au quotidien

Si vous travaillez dans l'AP, vous n'avez pas besoin de cette section. Mais si vous êtes un CFO, un fondateur, ou quelqu'un qui a approuvé le budget d'automatisation en supposant que le problème était réglé — voici ce que votre équipe fait réellement.

Une facture arrive sous forme de pièce jointe PDF dans une boîte de réception partagée. Quelqu'un l'ouvre. Il lit le nom du fournisseur, le numéro de facture, la date, la date d'échéance, les lignes d'articles, le sous-total, la taxe et le total. Il saisit chacun de ces champs dans NetSuite. Ou SAP. Ou QuickBooks. Il rapproche la facture d'un bon de commande — manuellement, à l'œil. Il l'achemine pour approbation par e-mail. Puis il relance l'approbateur qui n'a pas répondu depuis trois jours.

Multipliez maintenant par 200. Ou 1 500. Ou 5 000 — le volume que 36 % des répondants IFOL traitent chaque mois.

Un professionnel de l'AP sur le subreddit r/Accounting l'a décrit sans détour : « Nous recevons environ 1 500 à 2 000 factures par mois de nos fournisseurs. J'entends sans cesse que l'automatisation de l'AP est pratiquement résolue, mais notre processus reste : les factures arrivent dans une boîte de réception partagée en PDF, quelqu'un ouvre chacune, saisit les informations d'en-tête dans NetSuite, rapproche manuellement avec le bon de commande, achemine pour approbation par e-mail, relance les approbateurs quand ils ignorent. Nous avons essayé l'OCR intégré à NetSuite, mais il échoue sur la moitié de nos factures parce que chaque atelier d'usinage et chaque fournisseur de matières premières formate les siennes différemment. »

Ce post a plus de 200 votes positifs et des dizaines de commentaires de personnes disant la même chose. Ce ne sont pas de petites entreprises. Ce sont des fabricants de taille moyenne, des distributeurs et des entreprises de services qui traitent des centaines ou des milliers de factures par mois — et la personne qui saisit est un comptable diplômé, pas un opérateur de saisie.

La recherche 2025 d'Ardent Partners chiffre le coût à 15,97 $ par facture traitée manuellement, contre 2,36 $ pour un traitement automatisé de classe mondiale. Pour une entreprise traitant 3 000 factures par mois, cela représente un écart annuel de 490 000 $ — sans compter le coût des erreurs, des retards de paiement ou des escomptes de règlement manqués.

Le problème du format : pourquoi chaque facture fournisseur casse votre modèle

Si toutes les factures suivaient une mise en page standard, l'OCR basé sur des modèles aurait résolu ce problème il y a dix ans. Ce n'est pas le cas. Et cela ne le sera jamais.

Un fournisseur en Allemagne place la ventilation de la taxe en pied de page. Un fournisseur au Texas la place dans une colonne à droite des lignes d'articles. Un entrepreneur à Singapour n'affiche pas la taxe du tout — elle est incluse dans le prix unitaire. Un atelier d'usinage local envoie un PDF scanné avec des notes manuscrites dans la marge. Un autre envoie par e-mail une photo prise au téléphone d'une facture papier posée sur un bureau.

Chacune de ces variations de format casse l'automatisation basée sur des modèles. L'OCR par modèle fonctionne en mémorisant l'emplacement des champs sur une mise en page connue : « Le numéro de facture se trouve aux coordonnées X, Y. Le total se trouve aux coordonnées A, B. » Dès qu'un fournisseur modifie son modèle de facture — ou que vous ajoutez un nouveau fournisseur — ces coordonnées ne sont plus valides.

Ce n'est pas un cas marginal. C'est la norme. Une entreprise de taille moyenne reçoit en moyenne des factures de 200 à 500 fournisseurs différents, chacun utilisant sa propre mise en page. Les systèmes ERP, les logiciels de comptabilité et les outils SaaS verticaux génèrent des factures dans des formats choisis par leurs développeurs — pas dans des formats que votre équipe AP peut contrôler.

Et cela empire. Les fournisseurs modifient leurs formats de facture. Un fournisseur met à niveau son système de facturation. Une chaîne de restaurants redessine son modèle. Un indépendant passe d'une application de facturation à une autre. Chaque changement casse silencieusement le modèle qui fonctionnait le mois dernier. Votre équipe AP découvre la panne lorsque les données sortent incorrectes — ou lorsqu'elle remarque qu'elle corrige manuellement le même champ depuis des semaines.

Le piège du modèle : quand « plus d'automatisation » signifie plus de maintenance

Voici le paradoxe structurel que la plupart des fournisseurs d'automatisation ne vous diront pas.

Le traitement des factures basé sur des modèles évolue de manière linéaire avec le nombre de fournisseurs. Chaque nouveau fournisseur signifie un nouveau modèle à créer, tester et maintenir. Avec 20 fournisseurs, vous avez 20 modèles. Gérable. Avec 200 fournisseurs — ce qui est courant pour un fabricant ou un distributeur de taille moyenne — vous avez 200 modèles. Chacun doit être mis à jour lorsque le fournisseur modifie son format, ce qu'il fait régulièrement, sans vous prévenir.

L'analyse d'Infrrd sur l'automatisation du parsing des factures l'a dit sans détour : « Chaque nouveau fournisseur ajouté à un système basé sur des modèles nécessite un travail de configuration avant qu'une seule facture puisse être traitée avec précision. Lorsque le nombre de fournisseurs augmente ou que l'intégration se fait rapidement, l'arriéré de modèles devient un goulot d'étranglement. Les équipes passent plus de temps à gérer les modèles qu'à traiter les factures — ce qui est l'inverse de ce que l'automatisation est censée accomplir. »

À grande échelle, le calcul s'inverse. Si la maintenance de 200 modèles prend une personne à temps plein et que la saisie manuelle de 3 000 factures en prend deux, vous n'avez pas automatisé — vous avez simplement remplacé le travail de saisie de données par un travail de maintenance de modèles. Le coût a été déplacé, il n'a pas disparu.

C'est pourquoi 66 % des équipes saisissent encore manuellement des données malgré un système d'« automatisation » en place. Elles ont acheté un outil qui automatise 80 % des factures de leurs 20 principaux fournisseurs — et continuent de gérer manuellement les 180 autres fournisseurs dont les formats ne peuvent pas être analysés par l'outil. L'outil est là. Il fonctionne. Mais la majorité du travail repose encore sur des mains humaines.

La spirale des exceptions : 20 % de vos factures consomment 80 % du temps

Même dans les services AP partiellement automatisés, il existe une catégorie de travail que presque personne ne mesure : la gestion des exceptions.

Les recherches du rapport 2025 State of ePayables montrent que environ 22 % des factures nécessitent une gestion des exceptions — numéros de PO manquants, montants incorrects, anomalies de format, soumissions en double. Dans un processus manuel, ces exceptions font simplement partie du flux. Dans un processus automatisé, elles deviennent des obstacles.

L'automatisation signale l'exception. Interrompt le traitement. Génère une notification. Et puis... un humain doit intervenir. Ouvrir le PDF original. Le comparer aux données signalées. Envoyer un e-mail au fournisseur. Attendre une réponse. Saisir à nouveau les données corrigées. Relancer le circuit d'approbation. Chaque exception peut prendre 15 à 30 minutes à résoudre.

Faites maintenant le calcul : 3 000 factures par mois × 22 % de taux d'exceptions = 660 exceptions. À 20 minutes chacune, cela représente 220 heures — plus que la capacité mensuelle d'un employé à temps plein — consacrées uniquement aux exceptions. Et cela après que l'automatisation a déjà « traité » la facture.

C'est le piège de la semi-automatisation. Les entreprises investissent dans l'automatisation, réduisent les 80 % faciles, et découvrent que les 20 % restants sont plus difficiles que les 100 % d'origine, car les exceptions brisent le rythme du flux de travail. L'équipe ne fait pas moins de travail — elle fait un travail plus fragmenté et plus exigeant en changements de contexte. Vic.ai appelle cela « le dernier kilomètre de l'automatisation AP encore parcouru à pied ».

Pourquoi l'OCR basé sur des modèles atteint un plafond — et ce qui le dépasse

Les trois sections précédentes décrivent un problème racine : la dépendance au format. L'OCR par modèles, l'extraction basée sur des règles et les modèles d'apprentissage automatique traditionnels partagent tous la même limite — ils doivent savoir où se trouvent les données, pas ce qu'elles sont.

Un système à modèles voit des coordonnées. Il demande : « Où sur la page se trouve le numéro de facture ? » La réponse est différente pour chaque fournisseur. Un modèle de langage visuel (VLM) voit la sémantique. Il demande : « Qu'est-ce qui, sur cette page, fonctionne comme un numéro de facture ? » La réponse est la même, quel que soit l'endroit où cela se trouve.

Ce n'est pas une amélioration marginale. C'est une différence de catégorie. Lorsque vous demandez à un système basé sur un VLM d'extraire « Numéro de facture », « Nom du fournisseur », « Date de facture » et « Total », il ne recherche pas ces mots à des positions attendues — il lit le document comme le ferait une personne, comprenant que « INV-2025-08472 » à côté d'une étiquette indiquant « Facture n° » ou « Référence » ou « N° de document » est le numéro de facture, quel que soit l'endroit où cette paire apparaît sur la page.

Trois implications découlent directement de cela :

1. Aucun modèle à construire ou à maintenir. La facture d'un nouveau fournisseur est traitée de la même manière que celle d'un fournisseur avec lequel vous travaillez depuis dix ans. Le système lit chaque document à nouveau, en comprenant sa structure de manière indépendante.

2. Les changements de format ne cassent pas le pipeline. Lorsqu'un fournisseur redessine la mise en page de ses factures, le VLM trouve toujours les champs par leur rôle sémantique, pas par leur position. Vous n'avez rien à mettre à jour.

3. Les données multi-fournisseurs arrivent dans un tableau unifié. Vous définissez les noms de colonnes souhaités — « Fournisseur », « Date de facture », « Description de ligne », « Qté », « Prix unitaire », « Total » — et chaque facture, quel que soit son format d'origine, génère des données dans ces colonnes. Un seul tableur, tous les fournisseurs, aucune maintenance de modèle.

Ce n'est pas de la théorie. Le changement architectural de « où se trouvent les données » (OCR par modèles) à « ce que signifient ces données » (VLM) est ce qui rend le problème de format résoluble à grande échelle.

Ce qui change concrètement quand vous passez à l'extraction par IA

Prenons des chiffres concrets. Pour une équipe AP de taille moyenne qui traite 3 000 factures par mois auprès de 300 fournisseurs :

Le flux de travail côté VLM est simple : téléversez vos factures (glisser-déposer, téléversement par lots depuis un dossier, ou partagez un lien de collecte pour que les fournisseurs les soumettent directement), précisez les noms de colonnes à extraire, puis téléchargez un seul fichier Excel avec toutes les données fusionnées. Si vous utilisez Google Sheets, le module complémentaire vous permet de le faire sans quitter votre feuille de calcul — les données extraites sont ajoutées directement à votre feuille active.

Et pour les équipes qui ont besoin de plus que de l'extraction, les colonnes calculées vous permettent de définir des calculs exécutés pendant l'extraction. Besoin de calculer les totaux des lignes à partir de la quantité × le prix unitaire ? Vous voulez signaler les factures dont le total facturé ne correspond pas à la somme des lignes ? Définissez le calcul une fois, et l'IA l'applique automatiquement à chaque facture. Pour une présentation plus détaillée du flux de traitement par lots, consultez notre guide sur l'extraction par lots des données de factures depuis plusieurs PDF vers un seul fichier Excel.