Aller au contenu

Règles de modèle dans les modèles de processus

Statut : 01.08.2026 • Temps de lecture : ~8 minutes

Les règles de modèle sont un moyen de définir la logique commerciale qui s'exécute lors du traitement des documents. Une fois qu'un document a été capturé et que les champs contiennent des valeurs (provenant de l'OCR, de l'importation ou de la cartographie), les règles peuvent évaluer ces valeurs et y réagir. Cela vous donne une couche contrôlée entre « les données ont été capturées » et « les données sont acceptées », afin que vous puissiez imposer la cohérence, détecter les exceptions tôt et réduire les corrections manuelles.

Une règle a généralement trois ingrédients : elle examine une valeur (ou une valeur dérivée d'autres valeurs), évalue une condition et—si la condition est remplie—déclenche une réponse telle que la création d'une remarque ou la mise à jour d'un ou plusieurs champs.

Parce que les règles peuvent être exécutées dans un ordre défini, vous pouvez construire une logique structurée : normaliser d'abord les valeurs, calculer les valeurs dérivées ensuite, et valider le résultat final par la suite.


Ce que vous pouvez faire avec les règles de modèle

Valider la complétude et la plausibilité de base

Les règles peuvent garantir que les champs les plus importants sont présents et raisonnables. Par exemple, vous pouvez détecter des dates de facture manquantes, des références de fournisseur manquantes, ou des totaux qui sont zéro alors qu'ils ne devraient pas l'être. C'est souvent la première ligne de contrôle : si les éléments de base sont manquants, il n'est pas logique de procéder à des vérifications plus avancées.

Au lieu de bloquer tout, vous pouvez choisir le comportement qui correspond à votre flux de travail. Certains clients marquent les éléments essentiels manquants comme des erreurs (arrêter le traitement jusqu'à ce que ce soit corrigé), tandis que d'autres vérifications peuvent être des avertissements (permettre le traitement mais forcer la révision).


Valider les formats et les modèles (par exemple, numéros de facture, identifiants)

De nombreux champs commerciaux doivent suivre un format structuré : numéros de facture, numéros de commande, identifiants de TVA, IBAN, références internes. Les règles peuvent valider qu'un champ est conforme à la structure attendue et élever une remarque lorsqu'il ne l'est pas.

Ceci est particulièrement utile lorsque l'OCR lit incorrectement des caractères (O contre 0, I contre 1), ou lorsque les fournisseurs utilisent des schémas de numérotation variés et que vous souhaitez détecter des valeurs « inhabituelles » tôt.


Comparer les valeurs pour la cohérence

Les règles peuvent comparer deux valeurs et évaluer si elles correspondent ou diffèrent. Cela peut être aussi simple que de vérifier que deux références extraites sont alignées, ou des vérifications plus orientées vers les affaires telles que s'assurer que la devise correspond à la devise attendue par le fournisseur.

Une approche courante consiste à comparer une valeur extraite à un autre champ capturé, ou à une valeur dérivée des données maîtresses. L'objectif n'est pas de détecter chaque petite déviation, mais d'identifier les contradictions qui indiquent que le document nécessite une attention.


Effectuer des contrôles numériques, y compris des seuils et des tolérances

Les comparaisons numériques sont l'une des fonctionnalités les plus puissantes dans le traitement réel des factures. Vous pouvez signaler des montants élevés pour approbation manuelle, détecter des valeurs négatives là où elles ne devraient pas se produire, et mettre en évidence des différences suspectes.

Lorsque l'égalité est requise, la tolérance est importante car les documents numérisés introduisent souvent de légères déviations par arrondi (surtout avec la TVA). Au lieu de traiter « 118,99 contre 119,00 » comme un échec, vous pouvez permettre une petite bande de déviation et ne soulever une exception que lorsque la différence dépasse votre tolérance définie.

C'est aussi ainsi que les contrôles d'intégrité financière typiques sont exprimés—comme vérifier les totaux et les taxes sans créer trop de faux positifs.


Valider les totaux tels que Net / TVA / Brut

L'un des contrôles les plus demandés est de s'assurer que les totaux s'additionnent correctement. Une règle commerciale typique est : Le Brut doit être égal au Net plus la TVA, éventuellement dans une tolérance. Lorsque la relation ne tient pas, vous pouvez élever une remarque qui demande explicitement une révision.

Ces vérifications peuvent être appliquées au niveau de l'en-tête (totaux du document) et—selon la structure de votre modèle—également au niveau des lignes (par exemple, montant de la ligne = quantité × prix unitaire, ou les totaux des lignes s'additionnent aux totaux de l'en-tête). Même lorsque vous ne faites pas respecter un blocage strict, cela fournit un contrôle opérationnel fort et réduit les erreurs de publication.


Vérifier la résolution des données maîtresses (existence de l'enregistrement)

Un champ peut contenir une valeur et être pourtant incorrect car il ne se résout pas à un enregistrement valide. Les règles peuvent détecter ce type de problème en vérifiant si un enregistrement de données maîtresses correspondant existe. Des exemples typiques incluent la résolution de fournisseur/client, les numéros d'articles sur les lignes, ou d'autres entités référencées.

C'est l'un des types de règles les plus importants car l'enrichissement en aval en dépend. Si un enregistrement de fournisseur ne peut pas être résolu, des champs tels que les conditions de paiement, la logique d'approbation ou la configuration de publication pourraient être peu fiables. En ce sens, les vérifications « l'enregistrement existe » agissent souvent comme des passerelles : si la résolution échoue, le document est marqué pour correction avant de pouvoir procéder.


Utiliser les données maîtresses comme partie de la logique (enrichissement et contrôle)

Une fois qu'un enregistrement est résolu, les règles peuvent utiliser les informations de cet enregistrement comme entrée pour une évaluation ultérieure ou pour remplir des champs de document. Cela permet une logique spécifique au fournisseur et un comportement cohérent.

Par exemple, vous pourriez vouloir élever une remarque lorsque le fournisseur est bloqué, appliquer la devise par défaut du fournisseur lorsque la devise est manquante, ou utiliser les conditions de paiement du fournisseur pour dériver une date d'échéance. Cela réduit le travail manuel et maintient le traitement des documents aligné avec les données maîtresses.


Dériver et calculer des valeurs

Dans de nombreux processus, les valeurs que vous souhaitez valider ne sont pas directement capturées mais peuvent être dérivées. Les règles peuvent soutenir des résultats calculés, tels que des totaux ou des différences attendus. Cela vous aide à exprimer des contrôles comme « comparer le brut capturé au brut calculé » ou « calculer le delta et le signaler lorsqu'il dépasse la tolérance ».

Les valeurs calculées sont également utiles pour construire une logique cohérente et explicable où la validation ne dépend pas d'un seul champ extrait mais des relations entre les champs.


Gérer les dates et la logique des dates d'échéance

Les vérifications de dates sont une exigence fréquente car les champs de date influencent les processus de publication et de paiement. Les règles peuvent vérifier des dates irréalistes (loin dans le futur, ou plus tôt que prévu), imposer des relations (date d'échéance pas plus tôt que la date de facture), et dériver des dates à partir d'autres valeurs.

Un exemple classique est le calcul de la date d'échéance basé sur les conditions de paiement. Lorsque la date d'échéance est dérivée de manière cohérente, vous réduisez les modifications manuelles et évitez de publier des documents avec des dates de paiement incorrectes.


Que se passe-t-il lorsqu'une règle est remplie

Remarques : communiquer clairement à l'utilisateur

Les remarques sont le résultat « orienté utilisateur » des règles. Elles fournissent des indications claires : ce qui a été détecté, pourquoi cela importe, et quoi faire. Les remarques peuvent être informatives, des avertissements, ou des erreurs selon la rigueur que le processus doit avoir.

Un bon texte de remarque est spécifique et actionnable. « Les totaux ne correspondent pas » est utile ; « la règle a échoué » ne l'est pas. Les meilleurs ensembles de règles ressemblent à une liste de contrôle qui s'explique automatiquement au réviseur.


Remplacement de champ : corrections automatiques et standardisation

Les règles peuvent également mettre à jour des champs automatiquement. Cela est approprié lorsque le changement est sûr et déterministe : normaliser les formats de nombre, remplir des valeurs par défaut, copier des valeurs entre des champs, ou appliquer des valeurs dérivées des données maîtresses.

Remplacer des valeurs ne doit pas cacher des problèmes. De nombreux clients combinent les deux approches : ils normalisent les valeurs automatiquement, mais créent toujours une remarque lorsque le document contenait à l'origine quelque chose de suspect. De cette manière, le document devient traitable tout en restant transparent.


Résultats typiques que les clients mettent en œuvre

Les clients mettent couramment en œuvre un ensemble de règles qui délivrent des résultats tels que :

  • « Signaler les factures lorsque les totaux ne s'additionnent pas (net + TVA contre brut), tout en permettant une petite tolérance pour l'arrondi. »
  • « Élever des avertissements lorsque les totaux des factures dépassent les seuils d'approbation. »
  • « Arrêter le traitement lorsqu'un fournisseur ne peut pas être résolu ou lorsque des champs obligatoires sont manquants. »
  • « Détecter des formats invalides pour les numéros de facture, les identifiants de TVA, ou les IBAN. »
  • « Dériver des dates d'échéance basées sur les dates de facture et les conditions de paiement afin que les utilisateurs n'aient pas besoin de les calculer manuellement. »
  • « Normaliser les valeurs capturées afin que les comparaisons et la publication se comportent de manière cohérente. »
  • « Appliquer des contrôles spécifiques au fournisseur, par exemple des fournisseurs bloqués, des incohérences de devise, ou des références manquantes. »