Automatiser le traitement des factures fournisseurs, ce n’est pas brancher un outil de lecture de PDF sur la boîte mail de la comptabilité. C’est décrire le circuit complet, de la réception au bon à payer, puis décider pour chaque étape ce qui relève d’une règle codée, de l’IA ou d’une validation humaine. Dans un circuit bien construit, la plupart des factures conformes passent sans ressaisie, et le temps des équipes se concentre sur les écarts, les fournisseurs nouveaux et les décisions de paiement. Cette page détaille ce découpage étape par étape, avec les exceptions et les contrôles anti-fraude à prévoir.
Une précision de périmètre : on parle ici du processus interne de traitement, pas de l’obligation légale. La généralisation de la facture électronique entre entreprises change le format et le canal de réception, et fait l’objet d’une page dédiée sur la réforme de la facturation électronique et son calendrier. Elle ne dit rien de la façon dont vous rapprochez, validez et payez.
Le circuit tel qu’il fonctionne souvent aujourd’hui
Dans beaucoup de PME et d’ETI, le traitement d’une facture fournisseur suit sept étapes, rarement écrites noir sur blanc.
- Réception multicanale. Les factures arrivent par une adresse générique, dans la boîte d’un acheteur, par courrier, sur un portail fournisseur ou via une plateforme. Une partie n’arrive jamais au bon endroit du premier coup.
- Saisie. Quelqu’un recopie le fournisseur, la date, le numéro, les montants HT, TVA et TTC, parfois les lignes, dans l’ERP ou le logiciel comptable.
- Rapprochement. La facture est comparée à la commande et, quand elle existe, à la réception (bon de livraison, service fait). C’est le rapprochement « à trois voies ».
- Gestion des écarts. Prix différent, quantité facturée supérieure à la quantité reçue, commande introuvable : la facture part en attente, souvent avec un e-mail à l’acheteur.
- Circuit de validation. Le demandeur ou le responsable budgétaire confirme que la dépense est justifiée, selon des seuils qui existent parfois seulement dans les habitudes.
- Comptabilisation. Imputation sur les bons comptes, le bon code TVA, les bons axes analytiques.
- Mise en paiement. La facture validée reçoit un bon à payer, entre dans une proposition de règlement et part dans un fichier de virement.
Le temps ne se perd pas uniformément. Il se concentre sur la saisie, sur les allers-retours liés aux écarts, et sur la recherche de « qui doit valider cette facture ». C’est aussi là que se cache le savoir tacite : la personne qui sait que tel fournisseur facture toujours le transport à part, ou que tel écart de quelques euros est accepté depuis des années.
Les données dont chaque étape a besoin
Avant de parler d’outil, il faut savoir où se trouvent les informations nécessaires et si elles sont fiables. C’est souvent là que le projet se joue.
- Référentiel fournisseurs : raison sociale, SIREN, numéro de TVA intracommunautaire, coordonnées bancaires, conditions de paiement, compte de charge par défaut. Un référentiel en doublon ou incomplet fait échouer l’identification automatique.
- Commandes : numéro, lignes, prix unitaires, quantités, demandeur. Si une partie des achats se fait sans commande, le rapprochement automatique ne peut pas s’appliquer à ces factures, et il faut une autre règle.
- Réceptions : saisies dans l’ERP, sur un bon de livraison papier ou pas du tout pour les prestations de service. La qualité de cette donnée conditionne le rapprochement à trois voies.
- Règles de validation : seuils, délégations, suppléants en cas d’absence.
- Paramètres comptables : codes TVA, comptes, axes analytiques, règles d’imputation par fournisseur ou par nature d’achat.
Si vous ne pouvez pas répondre à la question « où est la liste à jour des personnes habilitées à valider une facture au-delà de tel montant ? », le premier chantier n’est pas technique.
Les exceptions qui font le vrai travail
Un circuit automatisé est jugé sur sa façon de traiter les exceptions, pas sur les factures qui passent sans difficulté. Voici celles qu’on retrouve presque partout.
Écarts de prix et de quantité
La facture ne correspond pas à la commande : hausse tarifaire non répercutée dans la commande, livraison partielle, remise oubliée. La règle doit fixer une tolérance explicite (en valeur, en pourcentage ou les deux), ce qui passe automatiquement en dessous, et à qui l’écart est adressé au-dessus. Sans tolérance écrite, soit tout part en exception, soit tout passe.
Fournisseur inconnu ou mal identifié
Nouveau fournisseur, changement de raison sociale, filiale qui facture à la place du groupe. La facture ne doit pas créer un fournisseur automatiquement : la création d’un tiers est une étape contrôlée, avec vérification d’identité et des coordonnées bancaires.
Doublons
La même facture reçue par e-mail puis par courrier, un duplicata, une relance jointe à la facture d’origine. Le contrôle croise fournisseur, numéro de facture, date et montant, et signale aussi les quasi-doublons (même montant, même fournisseur, numéro légèrement différent).
TVA
Taux incohérent avec la nature de l’achat, autoliquidation mal appliquée, TVA intracommunautaire, montant de TVA qui ne correspond pas à la base. Ces contrôles sont arithmétiques ou fondés sur des règles : ils relèvent du code, pas de l’IA.
Factures sans commande
Abonnements, frais généraux, honoraires. Elles suivent un circuit différent : validation par le responsable budgétaire, parfois contrat de référence à la place de la commande.
Code, IA ou humain : qui fait quoi
Le principe est simple : tout ce qui peut s’écrire comme une règle stable reste du code, parce qu’il est prévisible, testable et explicable. L’IA intervient là où l’entrée est trop variable pour une règle, typiquement la lecture de PDF non structurés dont la mise en page change d’un fournisseur à l’autre. Les décisions qui engagent de l’argent ou qui supposent un jugement restent humaines. La grille générale est détaillée dans notre ressource sur le choix entre code, IA et validation humaine.
| Étape | Ce qui peut être automatisé | Par quoi | Contrôle à prévoir |
|---|---|---|---|
| Réception | Collecte depuis les canaux, classement, suppression des pièces qui ne sont pas des factures | Code, IA pour le tri des pièces jointes ambiguës | Journal de réception, alerte si un canal ne remonte plus rien |
| Lecture | Extraction des champs d’une facture structurée | Code | Validation du format et des champs obligatoires |
| Lecture | Extraction des champs d’un PDF non structuré | IA | Cohérence arithmétique HT + TVA = TTC, score de confiance, relecture humaine sous un seuil |
| Identification du fournisseur | Rapprochement avec le référentiel | Code (SIREN, TVA, IBAN) | Aucune création automatique de tiers |
| Rapprochement | Comparaison facture, commande, réception | Code | Tolérances écrites, versionnées, revues périodiquement |
| Gestion des écarts | Qualification de l’écart, proposition de motif, routage vers la bonne personne | Code, IA pour proposer un motif | Décision humaine au-delà de la tolérance, motif obligatoire |
| Validation | Envoi au bon valideur selon montant et centre de coût | Code | Délégations à jour, relance et escalade datées |
| Comptabilisation | Proposition d’imputation sur les flux récurrents | Code, IA pour les cas non couverts par une règle | Revue humaine des imputations proposées par l’IA |
| Bon à payer | Préparation de la proposition de règlement | Code | Bon à payer donné par une personne habilitée, distincte de celle qui a modifié le fournisseur |
| Paiement | Génération du fichier de virement | Code | Comparaison IBAN du fichier et IBAN validé, double validation au-delà d’un seuil |
Deux remarques sur ce tableau. D’abord, à mesure que les factures arrivent sous forme structurée, la part confiée à l’IA pour la lecture diminue ; le rapprochement, les exceptions et les validations, eux, restent à construire. Ensuite, l’IA ne décide jamais seule d’un écart ni d’un paiement : elle propose, le code vérifie, un humain tranche quand la règle ne suffit pas.
Les contrôles anti-fraude à construire dès le départ
Automatiser la chaîne ne doit pas ouvrir de nouvelles portes. Deux fraudes méritent un traitement explicite dans la conception.
Changement de coordonnées bancaires
Le scénario classique : un e-mail, apparemment envoyé par un fournisseur habituel, annonce un nouveau RIB. Les contrôles à coder :
- une modification d’IBAN ne peut jamais venir d’une facture ou d’un e-mail traité automatiquement ; elle passe par une demande identifiée ;
- elle est confirmée par un contre-appel à un numéro déjà connu, pas à celui figurant dans la demande ;
- la personne qui modifie le RIB n’est pas celle qui donne le bon à payer ;
- toute facture dont l’IBAN diffère de l’IBAN validé est bloquée ;
- les paiements vers un IBAN modifié récemment passent par une validation renforcée pendant une période définie.
Doublons et factures fictives
Au-delà du contrôle de doublon déjà cité, on vérifie qu’une facture sans commande concerne un fournisseur actif, que les montants juste sous les seuils de validation ne se répètent pas anormalement, et que chaque modification apportée à une facture ou à un fournisseur est tracée avec son auteur et sa date.
Ces contrôles sont presque tous déterministes. Ils relèvent du code et de l’organisation des droits, et c’est une bonne nouvelle : ils sont testables. La manière dont nous traitons les accès et la journalisation est décrite dans notre approche de la sécurité et des données.
Par où commencer, et quand ne pas construire
Un exemple de déroulé, à titre illustratif, pour une entreprise qui reçoit ses factures par plusieurs canaux et les saisit à la main :
- Observer le circuit réel sur quelques semaines de factures : canaux, délais, motifs d’attente, personnes sollicitées.
- Formaliser les règles : tolérances d’écart, seuils de validation, règles d’imputation, traitement des factures sans commande.
- Construire d’abord la réception, la lecture et le rapprochement, avec une file d’exceptions claire, puis le routage des validations.
- Contrôler en production : taux de factures traitées sans intervention, délai jusqu’au bon à payer, nombre et motifs d’exceptions, corrections apportées après comptabilisation.
Quand le processus n’est pas assez clair pour être chiffré, une cartographie du processus permet de poser ces règles avant de décider quoi construire.
Il y a aussi des cas où un développement spécifique n’est pas la bonne réponse. Si votre ERP ou votre plateforme de facturation propose déjà un module de rapprochement et de circuit de validation qui couvre vos cas, paramétrez-le d’abord. Si vous traitez quelques dizaines de factures par mois avec peu d’exceptions, un circuit de validation simple et un contrôle manuel bien organisé suffisent souvent. Enfin, si une grande partie des achats se fait sans commande ni réception enregistrée, le premier chantier est la discipline d’achat, pas l’automatisation : aucun système ne rapproche une facture avec une commande qui n’existe pas.
L’automatisation sur mesure devient pertinente quand les factures viennent de canaux variés, que les exceptions sont nombreuses et suivent des règles propres à l’entreprise, ou que le travail se fait entre plusieurs outils mal connectés. Pour situer ce processus parmi les autres usages en finance, voir aussi l’IA appliquée à la fonction finance.
Pour aller plus loin
Si vos règles sont déjà claires et que vous voulez passer à la construction du circuit, notre offre d’implémentation d’un processus automatisé et contrôlé décrit la manière dont nous livrons ce type de système, avec ses contrôles et ses limites.