Automatiser les notes de frais avec l'IA et n8n : extraction, contrôles et approbation

Chaque mois, le même rituel : les salariés photographient leurs tickets, égarent la moitié des justificatifs, remplissent un tableur approximatif, et quelqu'un — souvent vous — ressaisit tout pour la compta en vérifiant les plafonds à la main. Or un reçu est un document court, au format prévisible, dont on extrait toujours les mêmes champs : le candidat idéal à l'automatisation. Avec n8n, un modèle de vision et quelques règles de contrôle, vous pouvez construire le circuit complet : collecte des justificatifs, extraction, vérifications, approbation du manager et export mensuel pour la comptabilité.

Ce guide est le pendant « reçus et tickets » de notre article sur l'extraction de données de factures PDF avec l'IA : même logique de fond, mais des documents plus courts, plus dégradés, et un circuit de validation humaine plus formalisé.

Étape 1 : collecter les justificatifs

Trois points d'entrée couvrent la quasi-totalité des organisations, combinables dans le même workflow :

• Une boîte email dédiée (frais@votre-domaine.fr) : un trigger IMAP ou Gmail récupère chaque message et ses pièces jointes ; transférer une photo depuis son téléphone ne demande aucun outil nouveau aux salariés.
• Un formulaire n8n : le Form Trigger de n8n crée en quelques minutes un formulaire d'upload avec champ fichier, nom du salarié et commentaire, en imposant les champs obligatoires dès la soumission.
• Un dossier Drive partagé : un Google Drive Trigger surveille un dossier « Notes de frais ». Pratique quand l'habitude existe, mais le lien entre fichier et auteur disparaît — prévoyez un sous-dossier par personne.

Quel que soit le canal, la sortie de cette étape doit être un item n8n avec le justificatif en binaire et l'identité du demandeur en JSON. Pour un tri plus intelligent en amont (distinguer un reçu d'une facture fournisseur ou d'un contrat), le pattern de classification de documents entrants par IA s'insère naturellement ici.

Étape 2 : extraire les données avec un modèle vision

Un ticket de caisse est presque toujours une image, pas un PDF texte. Le plus simple est d'envoyer directement l'image à un modèle multimodal — GPT-4o, Claude ou Gemini — qui lit la photo sans étape d'OCR séparée, comme détaillé dans notre guide sur l'analyse d'images par IA dans n8n. Ce n'est pas un pari hasardeux : la compétition SROIE, présentée par Zheng Huang et ses co-auteurs à ICDAR 2019 (étude sur Google Scholar), a établi un benchmark de 1 000 reçus scannés sur lequel les meilleurs systèmes dépassaient déjà 90 % de F1 en extraction de champs clés.

Pour obtenir un JSON fiable plutôt qu'un paragraphe de prose, associez une Basic LLM Chain à un Structured Output Parser avec ce schéma :

{
  "type": "object",
  "properties": {
    "commercant": { "type": "string" },
    "date": { "type": "string", "description": "Date du ticket, format AAAA-MM-JJ" },
    "montant_ttc": { "type": "number" },
    "montant_ht": { "type": ["number", "null"] },
    "montant_tva": { "type": ["number", "null"] },
    "devise": { "type": "string", "description": "Code ISO, ex. EUR" },
    "categorie": {
      "type": "string",
      "enum": ["repas", "transport", "hebergement", "fournitures", "autre"]
    },
    "lisible": { "type": "boolean", "description": "false si un champ critique est indéchiffrable" }
  },
  "required": ["commercant", "date", "montant_ttc", "categorie", "lisible"]
}

Deux consignes de prompt font la différence : ne jamais inventer une valeur absente (renvoyer null pour le HT ou la TVA s'ils manquent sur le ticket, ce qui est fréquent) et positionner lisible: false dès qu'un champ requis est indéchiffrable plutôt que de deviner. Le champ categorie en enum force le modèle à choisir dans votre plan de dépenses — c'est lui qui pilotera les plafonds. La structuration sémantique des reçus est elle aussi bien documentée : le jeu de données CORD, publié par Seunghyun Park et son équipe au workshop Document Intelligence de NeurIPS 2019 (référence sur Google Scholar), annote des milliers de reçus précisément pour ce parsing post-OCR.

Étape 3 : les contrôles automatiques

C'est ici que le workflow gagne sa légitimité auprès de la compta. Trois règles couvrent l'essentiel, implémentées dans un node Code suivi d'un Switch :

const PLAFONDS = { repas: 25, transport: 300, hebergement: 130, fournitures: 150, autre: 50 };
const r = $json;
const anomalies = [];

// 1. Justificatif illisible → demande de renvoi
if (!r.lisible || !r.montant_ttc) anomalies.push("illisible");

// 2. Dépassement de plafond par catégorie
if (r.montant_ttc > (PLAFONDS[r.categorie] ?? PLAFONDS.autre)) anomalies.push("plafond_depasse");

// 3. Cohérence des montants et de la date
if (r.montant_ht && r.montant_tva
    && Math.abs(r.montant_ht + r.montant_tva - r.montant_ttc) > 0.05) anomalies.push("montants_incoherents");
if (new Date(r.date) > new Date()) anomalies.push("date_future");

// Clé de déduplication
const cle = `${r.commercant}|${r.date}|${r.montant_ttc}`.toLowerCase();
return { ...r, anomalies, cle_deduplication: cle, statut: anomalies.length ? "a_verifier" : "conforme" };

Pour le doublon de reçu, la clé commercant|date|montant est comparée aux dépenses déjà enregistrées : par requête sur votre table de suivi, ou avec le node Remove Duplicates en mode inter-exécutions. Cette clé sémantique attrape le cas classique : le même ticket soumis deux fois, une fois par email puis re-déposé dans Drive.

Le routage en sortie du Switch :

• illisible → email automatique au salarié demandant une nouvelle photo, et arrêt du traitement pour cet item.
• plafond_depasse ou incohérence → circuit d'approbation manager (étape 4), anomalie mentionnée explicitement.
• conforme sous votre seuil d'auto-approbation (50 € par exemple) → insertion directe, aucun humain sollicité.

Étape 4 : l'approbation manager avec le node Wait

Pour les dépenses qui exigent un regard humain, n8n propose un mécanisme natif : le node Wait en mode reprise par webhook, ou plus simplement les opérations « Send and Wait for Response » des nodes Slack et Gmail. Le manager reçoit un récapitulatif (salarié, commerçant, montant, catégorie, anomalie, lien vers la photo) avec deux boutons Approuver / Refuser ; le workflow reste en pause tant qu'il n'a pas cliqué. La mise en place complète — boutons, délais d'expiration, relances — est détaillée dans notre guide de l'approbation humaine avec Wait et Slack.

Deux réglages valent la peine :

• Un timeout de relance : sans réponse sous 72 heures, une branche de rappel renvoie la notification plutôt que de laisser la dépense en limbes.
• Le motif de refus : en cas de rejet, demandez un commentaire court et transmettez-le au salarié. Un refus inexpliqué génère plus de frictions qu'il n'en évite.

Étape 5 : table de suivi et export mensuel

Chaque dépense traitée — approuvée, refusée ou auto-validée — est écrite dans une table de suivi avec son statut, l'horodatage de décision et l'identité de l'approbateur. Les Data Tables intégrées à n8n suffisent pour un volume de PME ; une base Postgres ou Airtable convient si la compta veut requêter directement.

Pour la clôture mensuelle, un Schedule Trigger (le 1er du mois) filtre les dépenses approuvées du mois écoulé et génère le fichier avec le node Convert to File : CSV pour un import direct en compta, ou Excel avec une feuille par catégorie. Notre guide sur la génération de fichiers Excel et CSV dans n8n couvre les options de format ; le fichier part ensuite par email au cabinet comptable ou se dépose dans le Drive partagé.

Limites et bonnes pratiques

• L'extraction n'est pas infaillible : visez un système où l'IA traite 90 % des cas et route proprement le reste vers un humain, pas un système qui prétend tout automatiser. Le champ lisible et les contrôles de cohérence sont là pour ça.
• Les plafonds évoluent : stockez-les dans une Data Table ou des variables d'environnement plutôt qu'en dur dans le node Code, pour les modifier sans toucher au workflow.
• Conservez le justificatif original : archivez la photo (Drive, S3) avec un lien depuis la table de suivi. En cas de contrôle fiscal, c'est le document source qui fait foi, pas le JSON extrait.
• Attention aux devises : un ticket en livres ou en dollars ne se compare pas à un plafond en euros sans conversion. Au minimum, routez toute devise non-EUR vers l'approbation manuelle.
• Testez sur vos vrais tickets : constituez un jeu d'essai (tickets froissés, encre thermique pâlie, additions manuscrites) avant la mise en production, et mesurez le taux d'extraction correcte.

En résumé

Un workflow n8n de notes de frais enchaîne cinq blocs : collecte multi-canale (email dédié, formulaire n8n, dossier Drive), extraction par modèle vision cadrée par un Structured Output Parser, contrôles automatiques (doublons, plafonds par catégorie, lisibilité), approbation manager via Wait avec auto-validation sous un seuil, puis table de suivi et export Excel/CSV mensuel. Le schéma JSON à enum de catégories et le node Code de règles présentés ici constituent le cœur du système — le reste est de l'assemblage de briques n8n standard. Commencez par le circuit email + extraction + table de suivi, puis ajoutez contrôles et approbation une fois la qualité d'extraction validée sur vos propres justificatifs.