Validation des factures : pourquoi l'OCR ne réduit pas par deux le délai de traitement

Inhaltsverzeichnis+

La validation des factures est le processus administratif qui génère le plus de projets d’automatisation et le plus grand taux de projets dont le business case ne se réalise pas ensuite. La raison se montre dans un modèle calculé.

« Remarque : » Les chiffres ci‑dessous proviennent d’un modèle d’exemple, pas d’un mandat réel. Ils sont choisis pour correspondre à des ordres de grandeur typiques dans les entreprises moyennes. Utilisez vos propres valeurs. Le modèle reste valide.

Le modèle de départ

Une entreprise traite 1200 factures fournisseurs par mois, soit environ 60 par jour ouvré. Le processus comporte cinq étapes :

Si l’on additionne seulement les temps de traitement, on obtient environ 20 à 30 minutes par facture. Le délai réel d’un bout à l’autre, de la réception à l’autorisation de paiement, est dans de telles configurations régulièrement de huit à douze jours ouvrés.

Il y a environ trois ordres de grandeur entre 25 minutes et dix jours. Cet écart est l’objet principal du projet. Il se compose presque entièrement de temps d’attente.

Où se crée le temps d’attente

Si l’on répartit les dix jours sur les étapes, on obtient un schéma qui apparaît quasiment toujours sous cette forme :

• Réception à saisie : moins d’un jour. La capacité suffit.
• Saisie : un à deux jours. Taux d’utilisation autour de 80 %, donc sensible mais gérable.
• Attente de la validation métier : cinq à huit jours. C’est là que le processus bloque.
• Imputation et contrôle : moins d’un jour.
• Attente du prochain paiement groupé : en moyenne 1,5 jour.

La raison de l’attente est structurelle et n’a rien à voir avec de la paresse : la validation n’est pas un travail à temps plein. C’est une activité accessoire pour 14 personnes qui ont une tâche principale. Chacune traite les validations quand elle en a l’occasion, typiquement une fois par jour, parfois moins, jamais pendant les congés.

Ainsi, cette étape a deux caractéristiques qui, combinées, sont fatales :

1. Très grande dispersion. Une facture est validée en dix minutes ou en six jours. La dispersion est le principal moteur du temps d’attente. Elle entre au carré dans la formule des files d’attente.
2. Pas de remplaçant. Si une personne est absente, sa part attend son retour. Il n’y a pas de pool pour reprendre.

Ce que fait réellement l’OCR

La proposition de projet habituelle est : introduire la reconnaissance des pièces, importer automatiquement les données des factures dans l’ERP, réduire le temps de saisie de 10 à 2 minutes.

Le calcul : 8 minutes × 1200 factures × 12 mois = 1920 heures par an. À 55 €/h, cela fait 105 600 €. Le projet est approuvé.

Ce qui arrive réellement :

La saisie devient plus rapide, et nettement. Ce n’est pas un slogan marketing, cela se produit. Le taux d’utilisation de la comptabilité fournisseurs passe de 80 % à moins de 30 %.

Le délai de traitement baisse d’environ un jour. De dix à neuf. Car la saisie n’était jamais le goulot d’étranglement.

Et ensuite c’est pire avant d’aller mieux. Avant, la saisie relayait environ 60 factures par jour vers la validation, réparties régulièrement. Maintenant elles arrivent par paquets. Dès que la numérisation est terminée, elles arrivent toutes en même temps. La validation, auparavant limitée par la saisie, reçoit maintenant le volume complet et la variation complète. Son temps d’attente augmente.

Le goulot n’a pas disparu. Il a migré. Le temps économisé apparaît maintenant comme attente devant le service opérationnel.

L’économie qui existe vraiment

Ne vous méprenez pas : les 1920 heures sont réelles. Elles ne correspondent simplement pas à ce que le business case avait promis.

• Ce qui se réalise : capacité dans la comptabilité fournisseurs. C’est précieux : pour la croissance sans embauche, pour profiter des escomptes, pour la qualité.
• Ce qui ne se réalise pas : la promesse de réduire de moitié le délai de traitement. Et c’est sur ce critère que le projet sera jugé, car les services opérationnels s’en plaindront.

La différence entre les deux est la raison pour laquelle un projet techniquement réussi finit en déception.

Ce qui réduit vraiment le délai de traitement

Toutes les mesures efficaces interviennent sur la validation métier, et aucune d’entre elles n’est un achat de logiciel :

1. Seuils de valeur. Les factures en dessous d’un seuil n’ont pas besoin d’une validation individuelle a priori, mais d’un échantillonnage a posteriori. Dans des distributions typiques, la moitié des pièces représente une faible part du montant. Elles mobilisent pourtant la moitié des opérations de validation.

2. Règles de délégation avec automatisme. Pas de réacheminement manuel, mais : après X jours sans réaction, la facture va automatiquement au remplaçant. Cela coupe la longue queue de la distribution, qui est celle qui ruine la moyenne.

3. Validation groupée à heures fixes. Au lieu de « quand j’y arrive », un créneau fixe quotidien. Cela réduit fortement la dispersion, sans que personne travaille plus.

4. Validation avant saisie. Le classique des erreurs d’ordre : on saisit soigneusement, puis on découvre que la facture est litigieuse. Un contrôle métier court en amont évite la saisie de tous les cas litigieux.

L’action 3 est, par expérience, la plus efficace par rapport à l’effort. C’est aussi celle qui ne figure dans aucune offre, car elle ne se vend pas.

L’ordre qui fonctionne

1. Mesurer d’abord où est le temps. Compter l’encours avant chaque étape, diviser par le débit journalier. Cela prend une matinée et répond à la question centrale.
2. Alléger ensuite la validation. Seuils, délégation, créneaux fixes. Aucun budget nécessaire.
3. Mesurer à nouveau. Le goulot sera désormais ailleurs, probablement dans la saisie.
4. Automatiser ensuite. Là l’automatisation atteint le vrai goulot, et l’économie apparaît aussi dans le délai de traitement.

Qui suit cet ordre achète le même logiciel, mais obtient un projet qui tient les promesses du business case.

Pourquoi il faut simuler avant d’acheter

L’effet décrit (le goulot migre, l’économie s’évapore) n’apparaît pas dans un tableau, car un tableau calcule chaque étape séparément. Dans un modèle de simulation, on le voit en quelques secondes : on réduit la durée de saisie, et la file devant la validation grandit sous vos yeux.

C’est précisément pour cela que FlowVisual a été conçu. Le processus ci‑dessus se modélise en environ une demi‑heure ; ensuite la question « que se passe‑t‑il si nous introduisons l’OCR ? » se répond par un clic. La réponse vient avec une fourchette P10–P90, au lieu d’un seul chiffre que personne ne peut défendre.