Extraction de données de factures

Une facture est un document commercial qu'un fournisseur émet pour facturer un acheteur au titre de biens ou de services livrés. Les équipes finance et comptabilité fournisseurs les traitent au quotidien, en rapprochant les montants des bons de commande et en poussant les données validées vers les systèmes ERP ou de comptabilité. Les volumes vont de quelques factures par semaine à plusieurs milliers par jour, et le format varie énormément d'un fournisseur à l'autre, ce qui explique précisément pourquoi la saisie manuelle reste lente et source d'erreurs. L'extraction automatisée transforme un PDF ou une page scannée en sortie structurée qui peut alimenter directement les workflows de paiement et de rapprochement sans qu'un humain ait à ressaisir les chiffres.

Champs à extraire

Pourquoi ce document est difficile à traiter

Les factures n'ont pas de mise en page fixe. Deux fournisseurs vendant le même produit peuvent produire des documents qui n'ont presque rien en commun sur le plan structurel : l'un utilise un tableau avec des en-têtes de colonnes clairs, l'autre liste les articles sous forme de texte libre avec des prix qui débordent vers la marge droite. Les factures multilingues sont courantes dans le commerce transfrontalier, et un même document peut mélanger un en-tête en français avec des lignes de facturation en anglais. Beaucoup de factures arrivent sous forme de scans d'originaux imprimés, parfois avec un tampon, une annotation manuscrite, ou un artefact de fax qui recouvre le texte qu'un système doit lire.

Les factures multipages répartissent les totaux et les lignes de facturation sur plusieurs pages, et un analyseur naïf peut compter deux fois certains éléments ou passer complètement à côté de la page de synthèse finale. Les avoirs, les factures partielles et les documents proforma ressemblent suffisamment à de vraies factures pour que le risque d'erreur de classification soit réel. Les conventions d'arrondi diffèrent selon les pays, et la logique fiscale varie (TVA, taxe sur les ventes, autoliquidation), si bien qu'une règle qui fonctionne pour une juridiction ne fonctionne pas pour une autre.

La fraude ajoute une couche supplémentaire de complexité : coordonnées bancaires modifiées, numéros de facture dupliqués ou identifiants fournisseurs fabriqués sont des vecteurs connus de fraude au paiement, et un système qui se contente de lire le texte sans le vérifier par rapport à des données de référence acceptera un document falsifié aussi facilement qu'un document authentique. Voir notre note sur la détection de fraude documentaire pour comprendre comment cela se joue en pratique, ainsi que la comparaison OCR contre VLM pour comprendre pourquoi un OCR aveugle à la mise en page peine sur ce type de document.

Comment Sygnet le traite

Sygnet commence par classifier le document entrant (facture, avoir, proforma) avant de lancer l'extraction, car mal orienter un avoir en tant que facture corrompt la comptabilité en aval. L'inférence de schéma s'adapte à la mise en page de chaque fournisseur plutôt que de s'appuyer sur un modèle rigide, ce qui compte vu à quel point les formats de facture varient. Chaque champ extrait reçoit un score de confiance, et chaque valeur porte une provenance au niveau du champ : une bounding box qui pointe vers l'emplacement exact sur la page d'où elle provient, pour qu'un relecteur puisse vérifier un chiffre par rapport à la source en quelques secondes plutôt que de relire tout le document.

Des règles de validation s'exécutent automatiquement : contrôles de somme de contrôle sur les numéros fiscaux et les IBAN, contrôles arithmétiques sur les totaux de ligne et les montants de TVA, logique de date sur les échéances par rapport aux conditions de paiement. La validation croisée entre documents relie la facture à son bon de commande et à son bon de réception quand ils sont disponibles, ce qui permet de repérer les incohérences avant qu'elles n'atteignent le paiement. Seuls les champs dont le score de confiance est inférieur à un certain seuil sont envoyés à un relecteur humain, ce qui permet de concentrer l'effort de relecture sur les cas qui nécessitent réellement un jugement plutôt que de tout valider à l'aveugle.

Le résultat est livré sous forme de JSON structuré via API, avec un webhook à la fin du traitement et des clés d'idempotence pour que les tentatives répétées ne créent pas de doublons dans les enregistrements de paiement. Pour les équipes qui traitent de gros volumes de factures françaises, notre page sur la facturation électronique en France couvre spécifiquement les formats Factur-X, UBL et Peppol.

Règles de validation à appliquer

• Vérifier les sommes de contrôle des numéros fiscaux selon l'algorithme du pays émetteur, et pas seulement le format
• Recalculer les totaux de ligne (quantité × prix unitaire) et signaler les écarts au-delà d'une faible tolérance d'arrondi
• Confirmer que sous-total + TVA = total, en tenant compte des règles d'arrondi propres à chaque juridiction
• Comparer l'IBAN du fournisseur avec les comptes précédemment validés ; signaler tout changement comme un signal de fraude potentiel
• Rejeter ou signaler les numéros de facture qui dupliquent une soumission déjà traitée du même fournisseur
• Valider la date d'échéance par rapport aux conditions de paiement indiquées (Net 30, Net 60) plutôt que de se fier uniquement à la date imprimée
• Rapprocher la référence de bon de commande des bons de commande ouverts et confirmer la quantité ou le budget restant
• Vérifier l'immatriculation du fournisseur (SIREN/SIRET en France, numéro de TVA ailleurs) auprès d'un registre d'entreprises public

FAQ

L'extraction peut-elle traiter des factures multilingues au sein d'un même document ?

Oui, à condition que le modèle sous-jacent soit entraîné pour du texte multilingue plutôt que d'être un simple moteur OCR monolingue. Les factures multilingues (un en-tête en français avec des descriptions de produits en anglais, par exemple) sont courantes dans le commerce transfrontalier. La couche d'extraction doit identifier le sens d'un champ indépendamment de la langue, et c'est précisément là que les modèles multimodaux ont tendance à surpasser les pipelines OCR fondés sur des règles.

Comment Sygnet détecte-t-il les factures frauduleuses ou modifiées ?

Grâce à une combinaison de contrôles de cohérence (l'IBAN correspond-il au compte connu du fournisseur) et de signaux au niveau du document, comme des polices incohérentes, des métadonnées inhabituelles, ou une arithmétique qui ne colle pas. Aucun système ne détecte toutes les tentatives de fraude, mais signaler les anomalies pour une relecture humaine avant le déclenchement du paiement ferme la porte au vecteur d'attaque le plus courant : des coordonnées bancaires modifiées sur une facture qui, par ailleurs, semble parfaitement légitime.

Que se passe-t-il quand le niveau de confiance sur un champ est faible ?

Le champ est transmis à un relecteur humain accompagné de sa bounding box, pour que le relecteur voie exactement où, sur le document, la valeur a été trouvée, sans avoir à fouiller dans les pages. C'est un choix délibéré : automatiser 100 % des champs sans tenir compte du niveau de confiance introduit des erreurs silencieuses, alors qu'une relecture en mode human-in-the-loop sur la minorité de cas incertains permet de maintenir un faible taux d'erreur sans ralentir le traitement de la majorité des factures simples.

Pour une analyse plus approfondie de l'impact du niveau de confiance et de la complexité de mise en page sur la précision selon les types de documents, voir notre analyse des limites d'OmniDocBench pour le traitement des factures, ainsi que le décryptage des coûts plus large dans notre article sur le traitement manuel des factures.