FlowKit

Circuit d'approbation des factures fournisseurs dans n8n : seuils, rapprochement et audit

Publié le 19 août 2026 · 6 min de lecture

Extraire automatiquement le montant, la date et le fournisseur d'une facture PDF — voir notre guide d'extraction IA de factures — ne résout que la moitié du problème. La vraie friction dans une PME n'est presque jamais la saisie : c'est le circuit de décision qui suit. Qui a le droit de valider une dépense de 200 € ? Et une de 8 000 € ? Faut-il vérifier qu'un bon de commande existe avant de payer ? Et qui répond quand le bon approbateur est en congés ? Ce sont ces questions, pas l'OCR, qui font qu'une facture traîne encore quinze jours dans une boîte mail avant d'être réglée. Ce guide construit le circuit d'approbation lui-même, au-dessus d'un pipeline d'extraction déjà en place.

Le problème que l'extraction seule ne résout pas

Une fois les champs d'une facture extraits proprement dans une table Supabase (factures_extraites), il reste à décider automatiquement : payer directement, demander une validation, ou bloquer et alerter. Sans cette couche de décision, deux dérives apparaissent en pratique — soit tout repasse par un humain qui revalide chaque ligne à la main (l'automatisation n'a rien changé), soit tout est payé sans contrôle dès que le champ « montant » est bien rempli (le risque d'erreur ou de fraude explose). Le bon réglage se trouve entre les deux, et il dépend du montant, du fournisseur et de l'existence ou non d'un bon de commande associé.

Définir les seuils avant de construire le workflow

C'est la partie qui se fait sur papier, pas dans n8n : sans grille de seuils claire, le workflow ne fait que reproduire un flou existant. Une grille simple, à stocker dans une table Supabase ou un Google Sheet plutôt qu'en dur dans le workflow (pour pouvoir l'ajuster sans republier) :

  • En dessous d'un premier seuil (par exemple 300 €) et fournisseur déjà connu : paiement automatique, journalisé, sans intervention humaine.
  • Entre ce seuil et un second (par exemple 300 à 3 000 €) : un seul approbateur, désigné par catégorie de dépense.
  • Au-dessus du second seuil, ou fournisseur jamais vu auparavant : deux approbateurs requis (le responsable de service, puis la finance), quel que soit le montant.

Ranger ces valeurs dans une table plutôt que dans un node IF codé en dur est ce qui permet de faire évoluer la politique de dépense sans toucher au workflow — un node Switch (n8n-nodes-base.switch) lit ensuite cette table et route chaque facture vers la bonne branche.

Rapprocher la facture avec le bon de commande (three-way matching)

Avant tout paiement au-dessus du premier seuil, comparez trois éléments : ce qui a été commandé (bon de commande), ce qui a été reçu (bon de livraison ou confirmation) et ce qui est facturé. C'est le principe du rapprochement à trois voies, standard en comptabilité fournisseurs pour éviter les doubles facturations, les écarts de prix et les factures pour des biens jamais livrés. Dans n8n, cela se traduit simplement : une requête Supabase (node Select) sur la table des commandes, filtrée par numéro de bon de commande extrait de la facture, puis un node IF qui compare le montant facturé au montant commandé avec une tolérance (2 à 5 % selon votre politique, pour absorber les frais de port ou petits arrondis). Un écart hors tolérance route automatiquement la facture vers une relecture manuelle plutôt que vers l'approbation standard.

C'est précisément le genre de contrôle qu'une étude de référence sur l'automatisation, Parasuraman & Manzey (2010), Complacency and Bias in Human Use of Automation, publiée dans Human Factors, permet de justifier : les auteurs montrent que la confiance excessive envers un système automatisé — ici, faire confiance aveuglément à l'extraction IA sans jamais la confronter à une source indépendante — augmente le taux d'erreurs non détectées, y compris chez des utilisateurs expérimentés. Le rapprochement bon de commande n'est pas une étape bureaucratique de plus : c'est le garde-fou qui évite qu'un chiffre mal extrait ou une facture frauduleuse passe simplement parce que le format PDF avait l'air correct.

Router vers l'approbateur : Switch, Wait et Slack

Une fois le montant et le résultat du rapprochement connus, le node Switch envoie la facture vers la branche adaptée. Pour les factures nécessitant une validation humaine, le mécanisme est celui déjà détaillé dans notre article sur l'approbation humaine avec le node Wait et des boutons Slack : message Slack avec les champs clés de la facture (fournisseur, montant, écart éventuel avec le bon de commande), boutons « Approuver » / « Rejeter », node Wait en mode On Webhook Call pour suspendre l'exécution sans consommer de ressources, et reprise via le resumeUrl au clic. Pour le circuit à deux approbateurs, il suffit d'enchaîner deux passages par ce même patron — le second Wait ne se déclenche qu'après validation du premier — chacun avec sa propre limite de temps et son escalade en cas d'absence de réponse.

Un point de vigilance issu d'un tout autre champ de recherche s'applique directement ici : l'étude désormais classique de Danziger, Levav & Avnaim-Pesso (2011), Extraneous Factors in Judicial Decisions, publiée dans PNAS, documente comment la fatigue décisionnelle pousse à revenir vers l'option la plus simple — approuver sans vérifier — à mesure que le nombre de décisions consécutives augmente. Concrètement pour un circuit de factures : évitez d'envoyer vingt demandes d'approbation isolées dans la même heure à la même personne. Un digest groupé (une seule notification Slack listant les factures en attente, plutôt qu'un message par facture) réduit ce risque et se construit facilement avec un Schedule Trigger deux fois par jour — voir notre guide du node Schedule Trigger — qui interroge Supabase pour toutes les factures en statut « en attente ».

Journaliser chaque décision

Un circuit d'approbation qui ne laisse aucune trace ne protège personne en cas de contrôle ou de litige avec un fournisseur. À chaque reprise du node Wait, écrivez une ligne dans une table d'audit append-only (journal_factures : facture, montant, approbateur, décision, horodatage) — le même principe que celui détaillé dans notre guide de piste d'audit RGPD avec n8n et Supabase, appliqué ici à la conformité comptable plutôt qu'à la protection des données. Si votre credential Supabase n'est pas encore configuré, notre guide de connexion n8n à Supabase couvre la mise en place complète.

Gérer les échecs sans perdre de facture

Un appel Slack qui échoue, une expiration de délai sans réponse, une requête Supabase qui timeout : ces cas ne doivent jamais faire disparaître silencieusement une facture en attente de paiement. Branchez un Error Workflow dédié — voir notre guide de gestion des erreurs dans n8n — qui repasse le statut de la facture à « erreur » plutôt que de la laisser dans un angle mort, et alerte un canal Slack de supervision distinct du canal d'approbation. Pensez aussi aux doublons : un même email de relance fournisseur, reçu deux fois, ne doit pas générer deux demandes d'approbation pour la même facture — le principe d'idempotence des webhooks n8n s'applique tout aussi bien ici, en vérifiant le couple numéro de facture + fournisseur avant toute insertion.

Pièges fréquents

  • Seuils codés en dur dans des nodes IF. Toute évolution de la politique de dépense oblige alors à modifier et republier le workflow. Une table de configuration lue au runtime évite ce couplage.
  • Un seul approbateur, sans suppléant. Un node Wait sans limite de temps configurée bloque indéfiniment une facture si la personne désignée est absente — prévoyez systématiquement une escalade vers un second approbateur après un délai raisonnable (24 à 48 heures ouvrées).
  • Aucun rapprochement pour les factures récurrentes. Un abonnement mensuel « connu » est justement la cible privilégiée d'une fraude par changement discret de RIB — vérifiez le montant et les coordonnées bancaires à chaque occurrence, pas seulement à la première facture.

Pour aller plus loin

Ce circuit — extraction, seuils, rapprochement, approbation multi-niveaux et piste d'audit — correspond exactement à l'architecture du bot de questionnaire et du module de journalisation Supabase du Pack Conformité & Audit (149 €), à combiner avec le tri automatique des factures entrantes du Pack Inbox IA (79 €) pour couvrir la chaîne complète depuis la réception de l'email jusqu'au paiement validé. Le Bundle FlowKit Complet (269 €) réunit les deux, avec le Pack Assistant RAG en plus. Si votre équipe traite encore les factures fournisseurs dans une boîte mail partagée sans piste d'audit, c'est le premier chantier à automatiser avant d'aller chercher plus loin.

Bundle FlowKit Complet

269 €